Perpetual IT

Two weeks ago, we urged Apple users with recent hardware to grab the company’s second-ever Rapid Response patch.

As we pointed out at the time, this was an emergency bug fix to block off a web-browsing security hole that had apparently been used in real-world spyware attacks:

Component: WebKit Impact: Processing web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. Description: The issue was addressed with improved checks. CVE-2023-37450: an anonymous researcher

The next-best thing to zero-click attacks

Technically, code execution bugs that can be triggered by getting you to look at a web page that contains booby-trapped content don’t count as so-called zero-click attacks.

A true zero-click atack is where cybercriminals can take over your device simply because it’s turned on and connected to a network.

Well-known examples include the infamous Code Red and Slammer worms of the early 2000s that spread globally in just a few hours by finding new victim computers by themselves, or the legendary Morris Worm of 1988 that distributed itself worldwide almost as soon as its creator unleashed it.

Morris, author of the eponymous worm, apparently intended to limit the side-effects of his “experiment” by infecting each potential victim only once. But he added code that randomly and occasionally reinfected existing victims as an insurance policy against crashed or fake versions of the worm that might otherwise trick the worm into avoiding computers that seemed to be infectious but weren’t. Morris decided on purposely reinfecting computers 1/7th of the time, but that turned out to be far too aggressive. The worm therefore quickly overwhelmed the internet by infecting victims them over and over again until they were doing little other than attacking everyone else.

But a look-and-get-pwned attack, also known as a drive-by install, where merely looking at a web page can invisibly implant malware, even though you don’t click any additional buttons or approve any pop-ups, is the next-best thing for an attacker.

After all, your browser isn’t supposed to download and run any unauthorised programs unless and until you explicitly give it permission.

As you can imagine, crooks love to combine a look-and-get-pwned exploit with a second, kernel-level code execution bug to take over your computer or your phone entirely.

Browser-based exploits often give attackers limited results, such as malware that can only spy on your browsing (as bad as that is on its own), or that won’t keep running after your browser exits or your device reboots.

But if the malware the attackers execute via an initial browser hole is specifically coded to exploit the second bug in the chain, then they immediately escape from any limitations or sandboxing implemented in the browser app by taking over your entire device at the operating system level instead.

Typically, that means they can spy on every app you run, and even on the operating system itself, as well as installing their malware as an official part of your device’s startup procedure, thus invisibly and automatically surviving any precautionary reboots you might perform.

More in-the-wild iPhone malware holes

Apple has now pushed out full-sized system upgrades, complete with brand new version numbers, for every supported operating system version that the company supports.

After this latest update, you should see the following version numbers, as documented in the Apple security bulletins listed below:

As well as including a permanent fix for the abovementioned CVE-2023-37450 exploit (thus patching those who skipped the Rapid Response or who had older devices that weren’t eligible), these updates also deal with this listed bug:

Component: Kernel Impact: An app may be able to modify sensitive kernel state. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.7.1. Description: This issue was addressed with improved state management. CVE-2023-38606: Valentin Pashkov, Mikhail Vinogradov, Georgy Kucherin (@kucher1n), Leonid Bezvershenko (@bzvr_), and Boris Larin (@oct0xor) of Kaspersky

As in our write-up of Apple’s previous system-level updates at the end of June 2023, the two in-the-wild holes that made the list this time dealt with a WebKit bug and a kernel flaw, with the WebKit-level bug once again attributed to “an anonymous researcher” and the kernel-level bug once again attributed to Russian anti-virus outfit Kaspersky.

We’re therefore assuming that these patches related to the so-called Triangulation Trojan malware, first reported by Kasperky at the start of June 2023, after the company found that iPhones belonging to some of its own staff had been actively infected with spyware:

What to do?

Once again, we urge you to ensure that your Apple devices have downloaded (and then actually installed!) these updates as soon as you can.

Even though we always urge you to Patch early/Patch often, the fixes in these upgrades aren’t just there to close off theoretical holes.

Here, you’re shutting off cybersecurity flaws that attackers already know how to exploit.

Even if the crooks have only used them so far in a limited number of successful intrusions against older iPhones…

…why remain behind when you can jump ahead?

And if guarding against the Triangulation Trojan malware isn’t enough to convince you on its own, don’t forget that these updates also patch against numerous theoretical attacks that Apple and other Good Guys found proactively, including kernel-level code execution holes, elevation-of-privilege bugs, and data leakage flaws.

As always, head to to Settings > General > Software Update to check whether you’ve correctly received and installed this emergency patch, or to jump to the front of the queue and fetch it right away if you haven’t.

(Note. On older Macs, check for updates using About This Mac > Software Update… instead.)

If you’d been quietly chasing down cryptographic bugs in a proprietary police radio system since 2021, but you’d had to wait until the second half of 2023 to go public with your research, how would you deal with the reveal?

You’d probably do what researchers at boutique Dutch cybersecurity consultancy Midnight Blue did: line up a world tour of conference appearances in the US, Germany and Denmark (Black Hat, Usenix, DEF CON, CCC and ISC), and turn your findings into a BWAIN.

The word BWAIN, if you haven’t seen it before, is our very own jocular acronym that’s short for Bug With An Impressive Name, typically with its own logo, PR-friendly website and custom domain name.

(One notorious BWAIN, named after a legendary musical instrument, Orpheus’s Lyre, even had a theme tune, albeit played on a ukulele.)

Introducing TETRA:BURST

This research is dubbed TETRA:BURST, with the letter “A” stylised to look like a shattered radio transmission mast.

TETRA, if you’ve never heard of it before, is short for Terrestrial Trunked Radio, originally Trans-European Trunked Radio, and is widely used (outside North America, at least) by law enforcement, emergency services and some commercial organisations.

TETRA has featured on Naked Security before, when a Slovenian student received a criminal conviction for hacking the TETRA network in his own country after deciding that his vulnerability reports hadn’t been taken seriously enough:

Trunked radio needs fewer base stations and has a longer range than mobile phone networks, which helps in remote areas, and it supports both point-to-point and broadcast communications, desirable when co-ordinating law enforcement or rescue efforts.

The TETRA system, indeed, was standardised back in 1995, when the cryptographic world was very different.

Back then, cryptographic tools including the DES and RC4 ciphers, and the MD5 message digest algorithm, were still in widespread use, though all of them are now considered dangerously unsafe.

DES was superseded at the start of the 2000s because it uses encryption keys just 56 bits long.

Modern computers are sufficiently fast and cheap that determined cryptocrackers can fairly easily try out all possible 2⁵⁶ different keys (what’s known as a brute-force attack, for obvious reasons) against intercepted messages.

RC4, which is supposed to turn input data with recognisable patterns (even a text string of the same character repeated over and over) into random digital shredded cabbage, was found to have signficant imperfections.

These could be used to used to winkle out plaintext input by performing statistical analysis of ciphertext output.

MD5, which is supposed to produce a pseudorandom 16-byte message digest from any input file, thus generating unforgeable fingerprints for files of any size, turned out to be flawed, too.

Attackers can easily trick the algorithm into churning out the same fingerprint for two different files, annihilating its value as a tamper-detection tool.

End-to-end encryption for individual online transactions, which we now take for granted on the web thanks to secure HTTP (HTTPS, based on TLS, short for transport layer security), was both new and unusual back in 1995.

Transaction-based protection relied on the brand-new-at-the-time network-leve protocol known as SSL (secure sockets layer), now considered sufficiently insecure that you’ll struggle to find it in use anywhere online.

Party like it’s 1995

Unlike DES, RC4, MD5, SSL and friends, TETRA’s 1995-era encryption remains in widespread use to this day, but hasn’t received much research attention, apparently for two main reasons.

Firstly, even though it’s used around the world, it’s not an everyday service that pops up in all our lives in the way that mobile telephones and web commerce do.

Secondly, the underlying encryption algorithms are proprietary, guarded as trade secrets under strict non-disclosure agreements (NDAs), so it simply hasn’t had the levels of public mathematical scrutiny as unpatented, open-source encryption algorithms.

In contrast, cryptosystems such as AES (which replaced DES), SHA-256 (which replaced MD5), ChaCha20 (which replaced RC4), and various iterations of TLS (which replaced SSL) have all been analysed, dissected, discussed, hacked, attacked and critiqued in public for years, following what’s known in the trade as Kerckhoff’s Principle.

Auguste Kerckhoff was a Dutch-born linguist who ended up as a professor of the German language in Paris.

He published a pair of seminal papers in the 1880s under the title Military Cryptography, in which he proposed that no cryptographic system should ever rely on what we now refer to as security through obscurity.

Simply put, if you need to keep the algorithm secret, as well as the decryption key for each message, you’re in deep trouble..

Your enemies will ultimately, and inevitably, get hold of that algorithm…

…and, unlike decryption keys, which can be changed at will, you’re stuck with the algorithm that uses those keys.

Use NDAs for commerce, not for crypto

Commercial NDAs are peculiarly purposeless for keeping cryptographic secrets, especially for successful products that end up with ever more partners signed up under NDA.

There are four obvious problems here, namely:

• More and more people officially get the opportunity to figure out exploitable bugs, which they will never disclose if they stick to the spirit of their NDA.
• More and more vendors get the chance to leak the algorithms anyway, if any one of them violates their NDA, whether by accident or design. As Benjamin Franklin, one of America’s best-known and well-remembered scientists, is supposed to have said, “Three people may keep a secret, if two of them are dead.”.
• Sooner or later, someone will see the algorithm legally without a binding NDA. That person is then free to disclose it without breaking the letter of the NDA, and without trampling on its spirit if they happen to agree with Kerckhoff’s Principle.
• Someone not under NDA will eventually figure out the algorithm by observation. Amusingly, if that is the right word, cryptographic reverse engineers can be pretty sure their analysis is correct by comparing the behaviour of their alleged implementation against the real thing. Even small inconsistencies are likely to result in wildly different cryptographic outputs, if the algorithm mixes, minces, shreds, diffuses and scrambles its input in a sufficiently pseudorandom way.

The Dutch researchers in this story took the last approach, legally acquiring a bunch of compliant TETRA devices and figuring out how they worked without using any information covered by NDA.

Apparently, they discovered five vulnerabilities that ended up with CVE numbers, dating back to 2022 because of the time involved in liaising with TETRA vendors on how to fix the issues: CVE-2022-24400 to CVE-2022-24404 inclusive.

Obviously, they’re now holding out on full details for maximum PR effect, with their first public paper scheduled for 2023-08-09 at the Black Hat 2023 conference in Las Vegas, USA.

What to do?

Advance information provided by the researchers is enough to remind us of three cryptographic must-follow rules right away:

• Don’t violate Kerckhoff’s Principle. Use NDAs or other legal instruments if you want to protect your intellectual property or to try to maximise your licensing fees. But never use “trade secrecy” in the hope of improving cryptographic security. Stick to trusted algorithms than have already survived serious public scrutiny.
• Don’t rely on data you can’t verify. CVE-2022-24401 relates to how TETRA base stations and handsets agree on how to encrypt each transmission so that each burst of data gets encrypted uniquely. This means you can’t work out the keys to unscramble old data, even if you’ve already intercepted it, or predict the keys for future data to snoop on it later in real time. TETRA apparently does its key setup based on timestamps transmitted by the base station, so a properly programmed base station should never repeat previous encryption keys. But there’s no data authentication process to prevent a rogue base station from sending out bogus timestamps and thereby tricking a targeted handset into either reusing keystream data from yesterday, or leaking in advance the keystream it will use tomorrow.
• Don’t built in backdoors or other deliberate weaknesses. CVE-2022-24402 covers a deliberate security downgrade trick that can be triggered in TETRA devices using the commercial-level encryption code (this apparently doesn’t apply to devices bought officially for law enforcement or first responder use). This exploit allegedly turns 80-bit encryption, where snoopers need to try 2⁸⁰ different decryption keys in a brute-force attack, into 32-bit encryption. Given that DES was banished more than 20 years ago for using 56-bit encryption, you can be sure that 32 bits of key is far too small for 2023.

Fortunately, it looks as though CVE-2022-24401 has already been quashed with firmware updates (assuming users have applied them).

As for the rest of the vulnerabilities…

…we’ll have to wait until the TETRA:BURST tour kicks off for full details and mitigations.

SING US A CYBERSECURITY SONG

Why your Mac’s calendar app says it’s JUL 17. One patch, one line, one file. Careful with that {axe,file}, Eugene. Storm season for Microsoft. When typos make you sing for joy.

With Doug Aamoth and Paul Ducklin. Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

Early disclaimer: this isn’t quite the mother of all data breaches, nor even perhaps a younger cousin, so you can stand down from Blue Alert right away.

As far as we can tell, only names, email addresses and employers were leaked in the wrongly shared document.

But what names they were!

The leaked list apparently made up a handy email Who’s Who list of global cybersecurity experts from intelligence agencies, law enforcement groups, and serving military staff.

Threat intelligence company Recorded Future and German news site Der Spiegel have listed a wide range of victims, including the NSA, FBI and the US Cyber Command in America, the German BSI (Federal Office for Information Security), the UK’s National Cybersecurity Centre…

…and we could go on.

Other countries with affected government ministries apparently include, in no particular order: Taiwan, Lithuania, Israel, the Netherlands, Poland, Saudi Arabia, Qatar, France, the United Arab Emirates, Japan, Estonia, Turkey, Czechia, Egypt, Colombia, Ukraine, and Slovakia.

Der Spiegel suggests that numerous big German companies were affected, too, including BMW, Allianz, Mercedes-Benz, and Deutsche Telekom.

A total of about 5600 names, emails and organisational affiliations were leaked in all.

How did the leak happen?

It helps to remember that Virus Total is all about sample sharing, where anyone in the world (whether they’re paying Virus Total customers or not) can upload suspicious files in order to achieve two prompt outcomes:

• Scan the files for malware using dozens of participating products. (Sophos is one.) Note that this not a way to compare detection rates or to “test” products, because only one small component in each product is used, namely its pre-execution, file-based, anti-malware scanner. But it’s a very quick and convenient way of disambiguating the many different detection names for common malware families that different products inevitably end up with.
• Share uploaded files swiftly and securely with participating vendors. Any company whose product is in the detection mix can download new samples, whether they already detected them or not, for further analysis and research. Sample sharing schemes in the early days of anti-malware research typically relied on PGP encryption scripts and closed mailing lists, but Virus Total’s account-based secure download system is much simpler, speedier and more scalable than that.

In fact, in those early days of malware detection and prevention, most samples were so-called executable files, or programs, which rarely if ever contained personally identifiable information.

Even though helpfully sharing a malware-infected sample of a proprietary program might ultimately attract a complaint from the vendor on copyright grounds, that sort of objection was easily resolved simply by deleting the file later on, given that file wasn’t supposed to be kept secret, merely to be licensed properly.

(In real life, few vendors minded, given the the files were never shared widely, rarely formed a complete application installation, and anyway were being shared specifically for malware analysis purposes, not for piracy.)

Non-executable files containing malware were rarely shared, and could easily and automatically be identified if you tried to share one by mistake because they lacked the tell-tale starting bytes of a typical program file.

In case you’re wondering, DOS and Windows .EXE files have, from the earliest days of MS-DOS onwards, started with the text characters MZ, which come out as 77 90 in decimal and as 0x4D 0x5A in hexadecimal. This makes EXEs easy to recognise, and all non-EXEs similarly quick to spot. And in case you’re wondering why MZ was chosen, the answer is that those are the initials of Microsoft programmer Mark Zbikowski, who came up with the file format in the first place. For what it’s worth, and as an additional fun fact, memory blocks allocated by DOS all started with the byte M, except for the very last one in the list, which was flagged with Z.

Data files with added code

In 1995, the first Microsoft Word virus appeared, dubbed Concept because that’s exactly what it was, albeit an unhelpful one.

From then on, an significant proportion of active malware samples have been files that consist primarily of private data, but with unauthorised malware code added later in the form of scripts or programming macros.

Technically, there are ways to purge such files of most of their personal information first, such as overwriting every numeric cell in a spreadsheet with the value 42, or replacing every printable non-space character in a document with X or x, but even that sort of pre-processing is prone to trouble.

Firstly, numerous malware families sneakily store at least some of their own needed data as added information in the personal part of such files, so that trying to bowdlerise, redact or rewrite the sensitive, “unsharable” parts of the file causes the malware to stop working, or to behave differently.

This rather ruins the purpose of collecting a real-life sample in the first place.

Secondly, reliably redacting all personal information inside complex, mulitpart files is effectively an unsolvable problem in its own right.

Even apparently sanitised files may nevertheless leak personal data if you aren’t careful, especially if you’re trying to redact files stored in proprietary formats for which you have little or no offical documentation.

In short, any upload system that accepts files of arbitrary type, including programs, scripts, configuration data, documents, spreadsheets, images, videos, audio and many more…

…introduces the risk that every now and then, without meaning to, someone with the best will in the world will inadvertently share a file that should never have been released, not even on the basis of working for the greater good of all.

Right file, wrong place

And that’s exactly what happened here.

A file containing a structured list of some 5600 names, email addresses and cybersecurity affiliations of Virus Total customers was uploaded to Virus Total’s scanning-and-sharing service by mistake…

…by an employee inside Virus Total.

This really does appear to have been an innocent mistake that inadvertently shared the file with exactly the wrong people.

And before you say to yourself, “What were they thinking?”…

…ask yourself how many different file upload services your own company uses for various purposes, and whether you would back yourself never to put the right file in the wrong place yourself.

After all, many companies use numerous different outsourced services for different parts of their business workflow these days, so you might have completely different web upload portals for your vacation requests, expense claims, timesheets, travel requests, pension contributions, training courses, source code checkins, sales reports and more.

If you’ve ever sent the right email to the wrong person (and you have!), you should assume that uploading the right file to the wrong place is the sort of mistake that you, too, could make, leaving you asking yourself, “What was I thinking?”

What to do?

Here are three tips, all of which are digital lifestyle changes rather that settings or checkboxes you can simply turn on.

It’s unpopular advice, but logging out from online accounts whenever you aren’t actually using them is a great way to start.

That won’t necessarily stop you uploading to sites that are open to anonymous users, like Virus Total (downloads require a logged-in account, but uploads don’t).

But it greatly reduces your risk of unintentionally interacting with other sites, even if all you do is inadvertently like a social media post by mistake, when you didn’t want to.

If you’re in the IT team, consider putting controls on which users can send what sorts of file to whom.

You could consider using firewall upload rules to limit which file types can be sent to what sites, or activating various data loss prevention policies in your endpoint security software to warn users when they look like sending something somewhere they shouldn’t.

And if you’re not in IT, don’t take it personally if you one day find your upload freedoms restricted by order of the security team.

After all, you’ll always get a second chance to send a file that wouldn’t go out the first time, but you never get the chance to unsend a file that wasn’t supposed to go out at all.

We’re willing to bet that the Google employee who uploaded the wrong file in this incident would much rather be sitting down right now to negotiate with the IT department about having overly strict upload restrictions relaxed…

…than sitting down to explain to the security team why they uploaded the right file to the wrong place.

As Pink Floyd might have sung, in their early days, “Careful with that file, Eugene!”

At the tail-end of last week, Microsoft published a report entitled Analysis of Storm-0558 techniques for unauthorized email access.

In this rather dramatic document, the company’s security team revealed the background to a previously unexplained hack in which data including email text, attachments and more were accessed:

from approximately 25 organizations, including government agencies and related consumer accounts in the public cloud.

The bad news, even though only 25 organisations were apparently attacked, is that this cybercrime may nevertheless have affected a large number of individuals, givem that some US government bodies employ anywhere from tens to hundreds of thousands of people.

The good news, at least for the vast majority of us who weren’t exposed, is that the tricks and bypasses used in the attack were specific enough that Microsft threat hunters were able to track them down reliably, so the final total of 25 organisations does indeed seem to be a complete hit-list.

Simply put, if you haven’t yet heard directly from Microsoft about being a part of this hack (the company has obviously not published a list of victims), then you may as well assume you’re in the clear.

Better yet, if better is the right word here, the attack relied on two security failings in Microsoft’s back-end operations, meaning that both vulnerabilities could be fixed “in house”, without pushing out any client-side software or configuration updates.

That means there aren’t any critical patches that you need to rush out and install yourself.

The zero-days that weren’t

Zero-days, as you know, are security holes that the Bad Guys found first and figured out how to exploit, thus leaving no days available during which even the keenest and best-informed security teams could have patched in advance of the attacks.

Technically, therefore, these two Storm-0558 holes can be considered zero-days, because the crooks busily exploited the bugs before Microsoft was able to deal with the vulnerabilities involved.

However, given that Microsoft carefully avoided the word “zero-day” in its own coverage, and given that fixing the holes didn’t require all of us to download patches, you’ll see that we referred to them in the headline above as semi-zero days, and we’ll leave the description at that.

Nevertheless, the nature of the two interconnected security problems in this case is a vital reminder of three things, namely that:

• Applied cryptography is hard.
• Security segmentation is hard.
• Threat hunting is hard.

The first signs of evildoing showed crooks sneaking into victims’ Exchange data via Outlook Web Access (OWA), using illicitly acquired authentication tokens.

Typically, an authentication token is a temporary web cookie, specific to each online service you use, that the service sends to your browser once you’ve proved your identity to a satisfactory standard.

To establish your identity strongly at the start of a session, you might need to enter a password and a one-time 2FA code, to present a cryptographic “passkey” device such as a Yubikey, or to unlock and insert a smart card into a reader.

Thereafter, the authentication cookie issued to your browser acts as a short-term pass so that you don’t need to enter your password, or to present your security device, over and over again for every single interaction you have with the site.

You can think of the initial login process like presenting your passport at an airline check-in desk, and the authentication token as the boarding card that lets you into the airport and onto the plane for one specific flight.

Sometimes you might be required to reaffirm your identity by showing your passport again, such as just before you get on the plane, but often showing the boarding card alone will be enough for you affirm your “right to be there” as you make your way around the airside parts of the airport.

Likely explanations aren’t always right

When crooks start showing up with someone else’s authentication token in the HTTP headers of their web requests, one of the most likely explanations is that the criminals have already implanted malware on the victim’s computer.

If that malware is designed to spy on the victim’s network traffic, it typically gets to see the underlying data after it’s been prepared for use, but before it’s been encrypted and send out.

That means the crooks can snoop on and steal vital private browsing data, including authentication tokens.

Generally speaking, attackers can’t sniff out authentication tokens as they travel across the internet any more, as they commonly could until about 2010. That’s because every reputable online service these days requires that traffic to and from logged-on users must travel via HTTPS, and only via HTTPS, short for secure HTTP.
HTTPS uses TLS, short for transport layer security, which does what its name suggests. All data is strongly encrypted as it leaves your browser but before it gets onto the network, and isn’t decrypted it until it reaches the intended server at the other end. The same end-to-end data scrambling process happens in reverse for the data that the server sends back in its replies, even if you try to retrieve data that doesn’t exist and all the server needs to tell you is a perfunctory 404 Page not found.

Fortunately, Microsoft threat hunters soon realised that the fraudulent email interactions weren’t down to a problem triggered at the client side of the network connection, an assumption that would have sent the victim organisations off on 25 separate wild goose chases looking for malware that wasn’t there.

The next-most-likely explanation is one that in theory is easier to fix (because it can be fixed for everyone in one go), but in practice is more alarming for customers, namely that the crooks have somehow compromised the process of creating authentication tokens in the first place.

One way to do this would be to hack into the servers that generate them and to implant a backdoor to produce a valid token without checking the user’s identity first.

Another way, which is apparently what Microsoft originally investigated, is that the attackers were able to steal enough data from the authentication servers to generate fraudulent but valid-looking authentication tokens for themselves.

This implied that the attackers had managed to steal one of the cryptographic signing keys that the authentication server uses to stamp a “seal of validity” into the tokens it issues, to make it as good-as-impossible for anyone to create a fake token that would pass muster.

By using a secure private key to add a digital signature to every access token issued, an authentication server makes it easy for any other server in the ecosystem to check the validity of the tokens that they receive. That way, the authentication server can even work reliably across different networks and services without ever needing to share (and regularly to update) a leakable list of actual, known-good tokens.

A hack that wasn’t supposed to work

Microsoft ultimately determined that the rogue access tokens in the Storm-0558 attack were legitimately signed, which seemed to suggest that someone had indeed pinched a company singing key…

…but they weren’t actually the right sort of tokens at all.

Corporate accounts are supposed to be authenticated in the cloud using Azure Active Directory (AD) tokens, but these fake attack tokens were signed with what’s known as an MSA key, short for Microsoft consumer account.

Loosely speaking, the crooks were minting fake authentication tokens that passed Microsoft’s security checks, yet those tokens were signed as if for a user logging into a personal Outlook.com account instead of for a corporate user logging into a corporate account.

In one word, “What?!!?!”

Apparently, the crooks weren’t able to steal a corporate-level signing key, only a consumer-level one (that’s not a disparagement of consumer-level users, merely a wise cryptographic precaution to divide-and-separate the two parts of the ecosystem).

But having pulled off this first semi-zero day, namely acquiring a Microsoft cryptographic secret without being noticed, the crooks apparently found a second semi-zero day by means of which they could pass off an access token signed with a consumer-account key that should have signalled “this key does not belong here” as if it were an Azure AD-signed token instead.

In other words, even though the crooks were stuck with the wrong sort of signing key for the attack they had planned, they nevertheless found a way to bypass the divide-and-separate security measures that were supposed to stop their stolen key from working.

More bad-and-good news

The bad news for Microsoft is that this isn’t the only time the company has been found wanting in respect of signing key security in the past year.

The latest Patch Tuesday, indeed, saw Microsoft belatedly offering up blocklist protection against a bunch of rogue, malware-infected Windows kernel drivers that Redmond itself has signed under the aegis of its Windows Hardware Developer Program.

The good news is that, because the crooks were using corporate-style access tokens signed with a consumer-style cryptographic key, their rogue authentication credentials could reliably be threat-hunted once Microsoft’s security team knew what to look for.

In jargon-rich language, Microsoft notes that:

The use of an incorrect key to sign the requests allowed our investigation teams to see all actor access requests which followed this pattern across both our enterprise and consumer systems.

Use of the incorrect key to sign this scope of assertions was an obvious indicator of the actor activity as no Microsoft system signs tokens in this way.

In plainer English, the downside of the fact that no one at Microsoft knew about this in advance (thus preventing it from being patched proactively) led, ironically, to the upside that no one at Microsoft had ever tried to write code to work that way.

And that, in turn, meant that the rogue behaviour in this attack could be used as a reliable, unique IoC, or indicator of compromise.

That, we assume, is why Microsoft now feels confident to state that it has tracked down every instance where these double-semi-zero day holes were exploited, and thus that its 25-strong list of affected customers is an exhaustive one.

What to do?

If you haven’t been contacted by Microsoft about this, then we think you can be confident you weren’t affected.

And because the security remedies have been applied inside Microsoft’s own cloud service (namely, disowning any stolen MSA signing keys and closing the loophole allowing “the wrong sort of key” to be used for corporate authentication), you don’t need to scramble to install any patches yourself.

However, if you are a programmer, a quality assurance practioner, a red teamer/blue teamer, or otherwise involved in IT, please remind yourself of the three points we made at the top of this article:

• Applied cryptography is hard. You don’t just need to choose the right algorithms, and to implement them securely. You also need to use them correctly, and to manage any cryptographic keys that the system relies upon with suitable long-term care.
• Security segmentation is hard. Even when you think you’ve split a complex part of your ecosystem into two or more parts, as Microsoft did here, you need to make sure that the separation really does work as you expect. Probe and test the security of the separation yourself, because if you don’t test it, the crooks certainly will.
• Threat hunting is hard. The first and most obvious explanation isn’t always the right one, or might not be the only one. Don’t stop hunting when you have your first plausible explanation. Keep going until you have not only identified the actual exploits used in the current attack, but also discovered as many other potentially related causes as you can, so you can patch them proactively.

To quote a well-known phrase (and the fact that it’s true means we aren’t worried about it being s cliche): Cybersecurity is a journey, not a destination.

Short of time or expertise to take care of cybersecurity threat hunting? Worried that cybersecurity will end up distracting you from all the other things you need to do?

Learn more about Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response  ▶