Wandering Thoughts

An extravagant and dense piece of malware-laden email

In the process of looking through our mail system logs for my entry on phish spam with multiple tries, I stumbled over the following extravagant and apparently densely packed email message:

<ID> attachment application/zip; MIME file ext: .zip; zip exts: .jar; inner zip exts: .class[4] .mf none[2]; email is in-dnsbl
rejected <ID> from 185.61.138.98/info@cimexcuritibas.com to <redacted>: identified virus: CXmail/JarZip-A, Mal/Jacksbot-A, Mal/Jeetrat-A, Troj/JavaBz-WB
detail <id> Subject: [PMX:SPAM] [PMX:VIRUS] Kindly Quota

That's a single attachment with a relatively ordinary looking '.jar in .zip' (well, for malware), where Sophos identified no less than four different sorts of bad things. I wonder if every single .class file in that JAR had a different piece of malware in it.

(It also appears possible that Sophos identified the JAR file as a whole as being one sort of malware and then some pieces inside it as being additional sorts of malware. But all of this is opaque.)

At the time of this message, the IP address was in zen.spamhaus.org and cimexcuritibas.com was in dbl.spamhaus.org. Neither are true any more, so someone cleaned up something. We logged the message headers, but none of them have anything interesting except that the message was DKIM-signed by cimexcuritibas.com with a valid signature.

(This goes to show that valid DKIM signatures mean absolutely nothing about the quality of the email itself. I'm sure we all knew this already, but I like to provide examples every so often.)

PS: It appears that we don't receive any valid, accepted email that has a single .jar in a .zip by itself. It's possible that this is a case like singleton nested zipfiles, where we should just block all of these out of hand. On the other hand, if we did this I wouldn't get lovely log reports like this (we reject bad attachment types before we run them past Sophos PureMessage).

If one phish spam doesn't succeed, maybe another will

Here is another entry in the annals of spammers trying extra hard, to go with an earlier one. Recently, our mail system logged the following two interesting cases. Let's start with the first one:

<ID> attachment application/octet-stream; MIME file ext: .pdf
<ID> attachment application/octet-stream; MIME file ext: .htm
rejected <ID> from 194.201.253.234/info@deltaexpress.co.ke to <redacted>: identified virus: Mal/Phish-A, Troj/PDFUri-FUP
detail <ID> Subject: [PMX:SPAM] [PMX:VIRUS] Re: Document for Last Shipments

It seems our spammer is trying to get people two ways, trying both some malware and also a phish spam as a HTML attachment. At one level this feels like a sensible approach; if the recipient's system blocks the malware attack, maybe the recipient will still respond manually to the phish spam. But that seems to assume a world where people can have malware not work and be blocked without having big red alerts show up all over the entire email. Perhaps that is the case; if so, that's depressing.

Then there's the second and perhaps more interesting case:

<ID> attachment application/octet-stream; MIME file ext: .html
<ID> attachment application/octet-stream; MIME file ext: .html
rejected <ID> from 31.220.2.200/TAX@GOV.COM to <redacted>: identified virus: Troj/Phish-DFM, Troj/Phish-DGF
detail <ID> Subject: [PMX:SPAM] [PMX:VIRUS] Tax Clearance Certificate

Apparently this spammer hopes that if one phish spam doesn't succeed, maybe another one will. Or perhaps these are actually malware, as it's not clear from Sophos' pages. Sophos describes the file type of Troj/Phish-DFM as 'HTML', which could be a plain phish, but the file type of Troj/Phish-DGF as 'JavaScript', which is likely to be malware. Certainly the spammer is trying more than one thing at once here.

(This 'TAX@GOV.COM' spammer turns out to have been trying for a while from several sources.)

This prompted me to go looking through our logs in search of messages that were identified by Sophos as having multiple bad things in them in the hopes that I'd find a double-phish case. Sadly I wasn't able to find any, and most of them were less interesting than these ones. There was one exception, but that's going to be another entry.

Some malware apparently believes in covering its bases

Today our system for logging email attachment type information caught something interesting. Here's the important log messages:

<MSGID> attachment application/rtf; MIME file ext: .rtf
<MSGID> attachment application/zip; MIME file ext: .zip; zip exts: .pdf .rtf .xlsx
rejected <MSGID> from 185.185.25.104/luizhenrique@vencetudo.ind.br to <redacted>: identified virus: CXmail/Rtf-E, Exp/20180802-B

Exp/20180802-B is apparently an OLE2 based exploit using CVE-2017-11882, which appears to often be RTF-based (cf). This opens up the interesting and amusing possibility that both attachments are RTF based attacks (with the .pdf and .xlsx included in the .zip as either cover or supporting elements), and perhaps that they're the same RTF file. At the very least, this malware seems to believe in covering its bases; maybe you'll open a direct RTF attachment, or maybe you'll unzip the ZIP archive and use something in that.

We actually got several copies of this to various different local addresses, all apparently coming directly from this IP address (ie with no additional Received: headers) and all with the same 'Subject: Payment Advice'. The IP address in question isn't currently in the CBL or in Spamhaus ZEN, although it is in b.barracudacentral.org.

In a further interesting development, looking at our logs in more detail showed that there's actually a second run from the same IP an hour or so earlier, with a HELO of '163.com', a MAIL FROM of 'changlimachine101@163.com', and a Subject of 'Purchase Inquiry RG LLC'. This run was detected as the same two types of malware, but it has a different mix of attachment types:

attachment application/pdf; MIME file ext: .pdf
attachment application/octet-stream; MIME file ext: .xlsx; zip exts: .bin[8] .png[2] .rels[10] .vml[3] .xml[21] none

This may mean that the first attachment is basically a cover letter and it's the second attachment where all the malware lurks.

Sidebar: More spammers covering their bases

In the past nine days or so, we've also seen:

attachment application/msword; MIME file ext: .doc; zip exts: .rels .xml[3] none
attachment application/vnd.ms-excel; MIME file ext: .xls; zip exts: .rels .xml[3] none
rejected [...] identified virus: CXmail/OleDl-AD, CXmail/OleDl-AQ

(with the Subject of 'Re: August PO #20180911000'.)

The idea of putting together two different OLE-based attacks in two different documents amuses me. It's kind of brute force, and also optimistic (since you're hoping that neither is recognized and thus blocks your email).

Then there's:

attachment application/msword; MIME file ext: .doc
attachment application/pdf; MIME file ext: .pdf
rejected [...] identified virus: CXmail/RTF-F, Troj/20170199-P

And then there's what is probably a case of 'let's throw two phish attempts into one email':

attachment text/html; MIME file ext: .html
attachment text/html; MIME file ext: .html
rejected [...] identified virus: Troj/Phish-CZV, Troj/Phish-DAG

As I discovered once we started logging attachment types, our commercial anti-spam system identifying something as having phish 'malware' probably means it's in the attachments. This one had a Subject of 'Details Attached'. I bet they were.

A recent spate of ZIP attachments with everything

Our program for logging email attachment type information looks inside .zip and .jar archives, including one level of nesting. Often what we see in this is routine, with basically the sort of content you'd expect from either routine stuff or malware, but recently we've been seeing zip archives that are just stuffed with at least one of almost any file extension you can think of. A few days ago we logged an extreme example:

1fnnAC-0003dZ-EP attachment application/zip; MIME file ext: .zip; zip exts: .jar; inner zip exts: .abc .abl .acc .ach .adc .adz[2] .afd .age .ago .agy .aht .ake .ala .alp .and .ans .aob[2] .aor .app .apt .ara .ary .aud .aus .ave .axe .baa .bag .bap .bat .bde .bet .bin .bis .bkg .boe .bra .bsh .buz .bye .cai .cal .cat .caw .cdg .chm .cit .class[10] .cli[2] .clo .col .cop .cpl .crc .crs .cst .ctg .cto .cup .cwt .dad .dbl .dcb .der .det[2] .dew .dey .dig .dil[3] .dks[2] .dur .dwt .dye .eft .ego .elb[2] .elm .els[2] .emf .emm[2] .emu .err .esd .esq .ext .eyn .fax .fbi[2] .fcs .fee .fei .fem .ffa .fgn .fig .flb .fly[3] .foe .fog .fud .gab .gae .gal .gas .geb .gig .gin .gio[2] .goa .gob .god .gon .goo .gox .gtc .gun .had[2] .hah .hak[2] .hao .hat .hau .hcb .hcl[2] .hed .heh .hen[2] .hes[3] .hia .hip .hir .hld .hoc .hoe .hts .hug .hye .ibo .ide .ihp[2] .ijo .ilk .imu .ing[2] .ipr[2] .iqs .ire .iwa .iyo[2] .jah .jap .jay .jct .jem[2] .jud .jur .kat .kaw .kay .key .khi .kop .kor .kos .kph .kyl .lab[3] .lap .lcm .lea .lek .les .lib .lid .lit .llb .lou .lub .lxx .mao .map .maw .meu .mf .mix .mks .mog .mor .mot .mph .mus .nee .nef .nei .nep .nut .oak[2] .obb .ofo .oki .one .oni .ops .ora .our .pan .pap .par .paw .pax .pay .pdq .peh .pep .pia .pie .pig .pit .pks .poh .pos .pot .ppa .pps .pre .pry[2] .psi .pwr .pyr .rab .ram .rat .raw .rct .ref .reg .res .rfs .rig .rim .rix .rld .roc .roi .rpm .rut .rux .rwd .rwy .rye .sab .sau .sds .sed[2] .sei .sel .sew .she .shr .sie .sil .sim .sip .six .sny .soe .sou .soy .sqq .stg .sum .sur[2] .syd .tar .tat .tay .ted .tef .tem .tng .ton .tou .twa .udo .uns .urb .urn .uti .vac[2] .vil .von .vum .wab .wae .wea .wop[2] .wot .wro[2] .wud .xii[2] .xiv .xxi .xxv .xxx .yam[2] .yay .yea .yeo .yer .yez .yoe .yrs .yun .zat .zen .zho .zig .zip .zod

(We deliberately log file extensions inside zip archives in alphabetical order, so it may well have had a much different order originally.)

This particular message was detected by Sophos PureMessage as 'Mal/DrodZp-A', which may be a relatively generic name. The Subject: of the message was the relatively generic 'Re: Invoice/Receipt', and I don't know what the overall MIME filename of the .zip was claimed to be. We've received a bunch of very similar attachments that were just .jars (not .zip in .jar) with giant lists of extensions. Many of them have been rejected for containing (nominal) bad file types, and their MIME filenames have been things like 'ORIGIAL SHIPPING DOCUMENTS.qrypted.jar' and "0042133704 _ PDF.jar".

(It's possible that these direct .jars would also be detected as Mal/DrodZp-A, but we reject for bad file types before we check for known viruses.)

I doubt that the attachment had genuine examples of these file types, especially things like .rpm (RPM packages) and .nef (Nikon camera RAWs, which are invariably anywhere from several megabytes to tens of megabytes for the latest high-resolution Nikon DSLRs). I'm sure that the malware has some reason for doing this spray of files and file extensions, but I have no idea what it might be. If there are some anti-virus products that give up if a .jar has enough different file extensions in it, that's kind of sad (among other things).

Sadly for any additional filtering we might considering doing, I suspect that the dangerous parts of this were in the actual Java stuff (eg the .class files) and everything else is distraction. It'd be somewhat interesting to pick through a captured sample, because I am curious about what's in all of those files (or if they're just zero-length ones put in to pad things out) and also what file names they have. Did the malware make up some jumble of random file names, or is it embedded a message in them or something clever? I'll never know, because it's not important enough to bother doing anything special for.

Today I saw a spammer parasite itself on another spammer (probably)

We have an account request management system that sends out email to people as part of its activities, using an administrative email address as the sender address. We don't directly expose the address anywhere on our web pages, but it winds up in people's email address books when they get email from it and so years ago it leaked into the hands of spammers and we started to get occasional spam to it. Today it got two such pieces of email, both from and through Mailchimp and both theoretically sent by 'naturaful.com'.

The first one went like this:

From: Support Naturaful <support@naturaful.com>
Subject: INV04732 from Naturaful Support
Date: Thu, 26 Jul 2018 14:49:59 +0000

View invoice ([an-URL])
$ 1750.00 due 30 July
INV04732

[...]

The URL went off to a random and likely hijacked URL on a random website, or at least it tried to; it was probably broken (one part of it was a literal '[UNIQID]' as a query parameter). This was clearly basically a phish spam, and it appears to have tried to redirect from the initial URL to an invoice page on 'xerotransfers.com', where it would presumably have tried to extract some sort of payment from visitors.

It was followed less than two hours later by a second email message, a rather flustered one:

From: Support Naturaful <support@naturaful.com>
Subject: We're Sorry - Please Ignore Email About Invoice
Date: Thu, 26 Jul 2018 16:35:10 +0000

Please ignore the last email about a large invoice amount. .
Please do not click on the button or pay any money.
Any links that do not have [list of domains] is not our website. Any sales of Naturaful products are paid on our website and you don't owe anything after.
Please ignore the last email, we're currently cleaning up our database and ensuring this does not happen again.
Security is our primary concern.

What appears to have happened here is that our administrative address was bought by naturaful.com and added to a mailing list that they were going to use to send out spam (through Mailchimp). Before they could use their shiny new mailing list to send out their own spam, another spammer came by and exploited a security vulnerability of some sort to hijack naturaful.com's mailing list and Mailchimp account (and 'good' name) to send out their own spam.

As a bonus prize, naturaful.com claims to be in Canada, which makes what they're doing completely unambiguously illegal under our anti-spam law. The odds are that the government will never get around to doing anything to them, but one can always hope. In the mean time, neither these people nor Mailchimp are going to be successfully sending email to this particular administrative address.

(As far as Mailchimp goes, well, they know what business they're in and they're evidently not interested in doing better even though they certainly could.)

(This elaborates on my tweet.)

The irritatingly many executable formats of Windows

So I tweeted:

It's impressive how many different executable file formats Windows has.

(I care because our email system wants to reject top-level attachments that are Windows 'executables' and boy is the list getting long.)

I put 'executables' into quotes in this tweet because many of these file formats (or more exactly file types) are not binaries; instead they're text files that Windows will feed to various things that will interpret them in ways that you don't want. Typical extensions that we see as top level attachments (and reject at SMTP time) include .lnk, .js, .bat, .com, .exe, .vbs, and .vbe. Some of these are encoded binaries, while others are text.

We mostly do this checking and rejection based on MIME file extensions, partly because it's easiest. Also, for the ones that are text (and at least some of the ones that are encoded binaries), my understanding is that what makes them dangerous on a Windows machine is their file extension. A suitable text file with the extension ".txt" will be opened harmlessly in some editor, while the same file with the extension ".js" will generally be run if you try to open it.

(We do some file content sniffing to look for and reject unlabeled Windows executables, ie things which libmagic will report as type 'application/x-dosexec'. As you can see here, there are actually a lot of (sub)formats that map to this.)

We've historically added extensions one at a time as we run into them, usually when our commercial anti-spam system rejects one of them as being a virus (this time, several .pif files being rejected as 'W32/Mytob-C'). Possibly this is the wrong approach and we should find a master list somewhere to get almost all of this over with at once (perhaps starting from GMail's list of blocked file types). On the other hand, there's some benefit to passing up rejections, especially if you don't actually seem to need them. If we never see file types, well, why block them?

(I'm not completely convinced by this logic, by the way. But I'm lazy and also very aware that I could spend all my time building intricate anti-spam precautions of dubious actual benefit.)

People receiving email don't feel it should be their job to stop spam

There is a popular observation when people get spam, especially spam from places that specialize in sending email such as Sendgrid, and that is that these places are not infrequently pretty good about handling spam issues. Sometimes they have 'complain that this is spam' links right in the email headers (not Sendgrid, though), or similar things. But thinking that this is sufficient is a mistake, perhaps not in the short term but definitely in the long term (in my opinion).

What places that are merely 'good at responding to complaints' are really doing is making it the job of people receiving email to deal with spam. Unsurprisingly, not infrequently people are unhappy with this, either quietly or loudly. As a general rule, people do not want it to be their job to deal with spam; they want it to be your job (where 'you' is some combination of the people operating their mail system and the people responsible for sending email to them). That in practice it currently is their job, requiring a bunch of labour and a bunch of annoying workarounds and hacks, is something that people are not exactly pleased about. They consider this a flaw in the system, and it is.

(Spam in general is a fundamental hard problem, but spam from major mail sending providers is merely because they aren't interested in trying hard enough to stop it.)

Of course, people receiving email do not necessarily understand the situation in the way I've put it here. But we do know that they are unhappy to get spam (there are very few people who are happy to get it); even if they are 'happy' to be able to do something to make it go away, they would be happier to not have to deal with spam at all. The more work they have to do and the less certain that work is in making the spam go away, the more unhappy they are, until you reach the stage of someone like me.

PS: A great many things are 'making it the job of the receiver to deal with spam', including the very basic one of 'I think I will use GMail and live with its drawbacks because they have really good spam filtering'. Certainly not taking genuinely effective steps to stop spam senders and then waiting for the complaints to roll in is one of them; the mail sending place has effectively outsourced a significant part of its spam detection to the people receiving its email. If said people did nothing, the mail sending place would not know it was being used to send spam.

PPS: To cut off one possible reply in advance, a claim of 'if no one complains, clearly it wasn't spam' is demonstrably and obviously false and anyone advancing it as a defense is either morally vacuous or doing so in a cynical manipulation to deflect criticism. That marketing and advertising organizations love to make claims like this is one reason why a great many people hate them.

How to run a mail sending service that will probably never send spam

I have written any number of times before that mail sending services could take steps that would make sure almost no spam would be sent through them, but they don't bother (eg on Amazon, on modern mailing list services in general and earlier). However, I have not written down my view of these steps, partly because I have considered them obvious in the community in general. For various reasons, I now feel like writing these steps down. So here is an incomplete list of obvious steps to take that would mostly gut sending spam through such a service.

In no particular order:

• Charge people a decent amount of money for your service, possibly with a deposit up front. Don't have a free or a cheap tier, because it attracts the wrong sort of customer (Patrick McKenzie has written at length on how too-low or free pricing is a bad idea in SaaS in general).

• Force people to put their address lists on your service, not just funnel their email through in bulk sending. Forced uploads allow you to scan the address list in advance to look for known warning signs, such as definitely nonexistent domains or known-bad addresses that never accept your email.

• Require all email addresses submitted to you by a particular customer to be confirmed. The gold standard would be confirming separately for every alleged mailing list the customer sets up; the silver standard is confirming once when the customer first submits the address as part of any list and then assuming that the customer has the right to use that address in other lists. As part of requiring confirmation, provide an extra link that communicates to you 'I have never heard of these people and I do not know why they have my email address'. Even a moderate level of use of this link is a warning sign.

  It should go without saying that having more than a trace level of bounces or email rejections during confirmation should be a big warning sign.

  Probably the silver version is the most realistic, since these days customers may not have distinct 'mailing lists' as such, if they're using you to deliver event-based notifications to people's email and so on.

  (Even sending an initial notification email to people saying 'your address has been added to our system by <customer>' would be a step forward. These days a mail sending service could claim it was a GDPR requirement.)

• Run all submitted mailing list messages through all of the available free open source anti-spam and anti-virus systems, and perhaps at least one of the commercial ones. If any of the systems flag the message, don't send the email and surface this in an alert both to the customer and to your abuse handling team.

  (It's not a service to the customer to let them send out email that you know will trip spam alerts for some recipients. Legitimate customers will likely thank you for such a pre-check service, and may even want a way to submit draft messages to it.)

• Make it trivial for people to report unsolicited email and spam, and to 'unsubscribe'.
• Pay attention to bounces, SMTP rejections in general, unsubscribes, and spam complaints. Mine them for addresses to add to your list of warning addresses. Rejections after SMTP DATA are probably an especially bad warning sign, because they suggest it was content filtering that caused the rejection.

  (As part of this, you should obviously recognize and parse the various SMTP 4xx and 5xx messages that major email providers use when they're dealing with questionable email messages. But this is so obvious that I suspect that any mail sending SaaS that wants to be successful is already doing it.)

I'm assuming as a baseline that you will do things like accept bounces and replies and properly implementing SMTP. These days you may want SPF, DKIM, or DMARC in order to pacify various large email providers who are getting increasingly insistent on it, but that's more in the realm of 'competently operating a commercial service'.

I'm pretty confident that any mail sending service that implemented all of these would send almost no spam, and I'm reasonably confident that it would still have a business. But of course it wouldn't have a business that's as big as you'd get by not bothering to do some of these things (especially confirming email addresses), and it would cost more to operate, and you wouldn't have as many customers because a certain number of the more shady people would stay away (as would all of the cheap people).

My GDPR pessimism

The latest great hope of various people, more or less including myself, is that the European GDPR will come along and put an end to various sorts of annoying email marketing activities and other intrusive ad and marketing activities. Under the GDPR, so goes the theory, companies like Yubico and Red Hat will not be able to abuse email addresses they happen to have sitting around to send marketing email; in fact they may not even have those email addresses sitting around at all.

(At least for people in the EU. The further great hope of the GDPR is that many companies affected by it won't bother trying to tackle the near-impossible task of figuring out who's in the EU and who's not.)

I'd like to believe this, but I'm not sure that I do. I'm not basing this on any examination of the GDPR or on what people have written about it. Instead, my pessimism comes from the cynical version of the Golden Rule. My simple observation that regardless of what they say, governments very rarely actually kill off entire decent-sized industries and slap large fines on a wide variety of prosperous and perfectly normal corporations who are conducting business as usual. It might happen, but it seems much more likely that there will be delays and 'clarifications' and so on that in the end cause the GDPR to have little practical effect on this sort of activity. If there is change, I expect it to happen only very slowly, as countries slow-walk things like fines as much as possible in favour of 'consulting' and 'advising' and so on with companies.

(In other words, a lot of stern letters and not many other effects. And I expect companies to take advantage of this to stall as much as possible, and to plead implementation difficulties and other things that tragically mean they can't comply quite yet. It may all be very theatrical, in the 'security theater' sense.)

Partly I come by this pessimism by watching what's happened with Canada's theoretically relatively strong anti-spam law. One of the strong features of this law was that it created a private right of action, where you could start a civil case against violators and thus you didn't have to depend on the official regulator getting around to doing something. Since Canada is a loser-pays legal system, this was always going to be a reasonably risky activity, but then in 2017 this provision was quietly suspended, including the charming quote:

The Government supports a balanced approach that protects the interests of consumers while eliminating any unintended consequences for organizations that have legitimate reasons for communicating electronically with Canadians.

This provision has yet to be revived, and there have been no 2018 enforcement actions by the CRTC under CASL (at least none that appear in the CRTC's public records).

It's possible that the EU will be more aggressive and determined about the GDPR and violations of it than Canada has been about our lauded (at the time) anti-spam law, especially in today's climate with increased public concern about these sort of issues, but I'm not going to hold my breath.

PS: It turns out that there has been some activity on the CASL front (and, and, and, and) and there may be good news someday. But if so, it will probably be significantly later than the already slow timeline that CASL itself specified. Applications to the speed of GDPR are left as an exercise for the reader.

Yubico fails to care that people give you email addresses for specific purposes

A while back, Yubico had a little security issue that forced it to replace any number of Yubikey 4s, including mine. In order to do this, they required people to give them an email address so they could send you some necessary information; following my usual practice I gave them a tagged, individualized address. Today I received email to that address, received from the server of a domain called 'mktomail.com', that started out like this:

Subject: Passwordless authentication is here

Yubico scales across enterprise

Passwords are out. You're in!

The passswordless evolution of the FIDO U2F standard has arrived with FIDO2. [... marketing materials removed with prejudice ...]

You are receiving this email because you made a Yubico purchase or contacted Yubico.

I'm sorry, that's not how this works. In the normal course of events, people do not give you email addresses to do with as you will; people give you email addresses for specific purposes. In this case, I gave Yubico an email address to get a defective product fixed, but one might report a bug, contact product support, or perform other limited interactions with the company. These specific and limited purposes do not include 'receive unsolicited commercial marketing emails'.

Of course, the marketing department does not want to hear this. The marketing department wants to use every plausible address it can get its hands on. People these days vaguely get that you usually cannot buy addresses from other people without getting badly burned, but they keep thinking that other addresses are fair game, regardless of the purpose for which they were originally handed to the company.

Some of the time, the company supports the marketing department, as it did at Yubico, and these addresses get used outside of the purpose they were given to the company. At that point the company betrays the trust of the people who handed over their email addresses in good faith and pisses off some number of people who have interacted with the company in the past, some of which have actually bought their products. The results are predictable, as is the resulting form-letter evasion.

(When enough companies do this sort of thing for long enough, you get things like the EU's GDPR, which will likely make this conduct illegal. Sadly it is probably not illegal under Canada's anti-spam legislation, and anyway I expect Yubico to ignore the GDPR issues until they or someone else visible gets slapped with a nice fine for this sort of thing.)

Sadly I have no idea what is a viable alternative to Yubikeys, but at least we're not likely to buy any more any time soon.