Perpetual IT

Belgian cybersecurity researcher Polle Vanhoof just published a fascinating and well-written paper about an exploitable hole he found in the payment system used in some Nespresso prepaid coffee machines.

That’s actually much better news than it sounds.

Vanhoof disclosed the flaw back in September 2020; has publicly praised Nespresso in his writeup for its responsiveness in handling the issue; and waited until now to publish his article with Nespresso’s blessing:

 Responsible Disclosure to Nespresso 24 September 2020: Initial disclosure of findings to Nestlé Nespresso S.A 24 September 2020: The vendor was quick in communicating and setting up a meeting to discuss the vulnerability 09 October 2020: Full disclosure of technical details to vendor 02 February 2021: Nespresso confirmed they agreed with publishing this writeup

As we mentioned in yesterday’s article about how to handle data breaches, practising in advance how to respond promptly and honestly if things go wrong is vitally important, so we suggest that you take a leaf – or perhaps a bean – out of Nespresso’s playbook here.

Nespresso, it seems, already has mitigations that coffee vendors can use against this hack, given that it only works against older payment cards that were defeated cryptographically more than 10 years ago.

Nevertheless, shops that sell coffee (we are using this circumlocution to avoid the ambiguity of the Dutch word “coffeeshop”) from older Nespresso vending machines might want to read the article.

So too should anyone who is interested in learning more about smartcard hacking, more about how to write readable and enjoyable cybersecurity articles, or both.

How it works

Simply put, Vanhoof relied on the fact that many older Nespresso setups rely on what’s known as a stored-value wireless payment card, something that’s similar to but importantly different from a modern credit card.

Wireless in this case means that the card uses NFC, short for Near Field Communication, the same underlying technology that’s used by credit cards, many modern door security cards and almost all passports issued in the past 10 years.

When you wave an NFC card near an NFC reader, the electromagnetic emissions from the reader (which needs to be connected to a power supply) are enough to power up the card, because the antenna on the card is arranged in the form of a metal coil that generates electricity as it moves through a magnetic field.

There’s just enough electrical energy left over in the powered-up NFC card to conduct a brief, wireless exchange of cryptographic data with the NFC reader.

This means that NFC cards don’t need a battery so they can be small, flat, light and cheap.

If you take a single-journey trip on Dutch Railways, for example, your printed, flexible, cardboard ticket actually has an NFC chip called a Mifare Ultralight sandwiched inside it.

---

---

Stored value, in the case of the Nespresso cards, means that any credit left in the account is saved on the card itself, so that the system works on coffee machines with no internet connection.

As you can imagine, a stored-value card needs to be tamper-proof, or else the owner of the card could keep rewriting the amount of credit left, or changing any stored expiry date or other identifying data in the chip.

Strong cryptography can help with this, which is why modern mobile phone SIM cards and credit cards are extremely difficult – as good as impossible, in fact – to clone.

Unfortunately, as Venhoof discovered, older Nespresso cards are based on the Mifare Classic NFC chip, which uses strong-but-not-quite-strong-enough cryptography.

With just tiny amounts of electrical energy available for just a few milliseconds, NFC cards have to achieve a tricky balance of low power consumption with high cryptogtraphic strength, and in the Mifare Classic, this balance ended up tipped towards the attacker.

Instead of using a well-researched and publicly documented algorithm such as AES-128, the Mifare Classic used a stripped-down, proprietary 48-bit cipher known as Crypto1.

The cryptographic security of Crypto1 was demolished back in 2008 and 2009.

Key lengths of 48 bits just aren’t really good enough these days, because 2⁴⁸, which is the maximum number of different keys you can represent in 48 bits (about 300 million million), just isn’t a truly large number any more.

Indeed, the well-known 56-bit cipher DES, which has 256 times as many possible keys as a 48-bit cipher (because 2⁵⁶/2⁴⁸ = 2⁸ = 256), was replaced with AES way back in 2001 because 56-bit keys were already considered dangerously short by the late 1990s.

Worse still, researchers discovered that the digitial shredding-mixing-mincing-and-liquidising performed by the fast but comparatively simple Crypto1 algorithm was inadequate even to provide 48 bits of security.

A good encryption algorithm, regardless of its key length, should give no usable hints in its previous outputs as to what might come next, in the same way that a well-balanced roulette wheel that has turned up red 10 times in a row should be no more likely to produce red than black on the 11th, or any other, spin.

But researchers discovered that they could make inferences about what Crypto1 would do next if they could see the encrypted data so far.

The unequivocally named paper Dismantling MIFARE Classic, published by researchers from Radboud University in Nijmegen, The Netherlands in 2008, introduced an key-recovery hack against Crypto1 that could be completed within a second, and needed just 8MBytes of RAM to run.

Cloning and modifying cards

Vanhoof was able to resurrect this attack and adapt it to his Nespresso card in order both to extract the encrypted content – something that shouldn’t be possible without knowing the key up front, because the key can’t be physically read out of the card – and to rewrite the card’s contents undetectably.

In other words, he could not only clone a card and in theory turn one €5 card into 100 €5 cards, but also turn a €5 card into a €500 one.

As Vanhoof explains in the paper, he figured out very easily that the stored value in the card, for Dutch coffee machines at least, was a 3-byte unsigned integer representing the coffee credit left in cents.

Three bytes is 24 bits, and the biggest integer you can fit into 24 bits is 2²⁴-1 (the -1 is there because unsigned integer values start at zero, not at one).

That’s just over 16 million Euro cents, or more precisely, €167,772.15 – which is a lot, an awful lot, of coffee.

Amusingly, when Vanhoof tried a modified chip (with permission!) against a vending machine, it could only show eight characters, and truncated the amount displayed to a mere €67,772.15.

What to do?

• If you’re a wannabe hacker, don’t try this away from home. Unauthorised access for financial gain, even if it’s only a tiny amount, is quite rightly a serious criminal offence, no matter how easy it to do. (Heaving a brick through the window of a shop that sells coffee isn’t hard to do either, but you would not expect sympathy if charged in court just because “it was easy and no one bothered to stop me trying”.)
• If you’re a prepaid vendor of any product, don’t use Mifare Classic cards. Upgrade to newer cards, such as the Mifare Plus card, which can operate like a Classic card while using AES-128 internally.
• If you have an always-on internet connection, consider using online payment verification. If the card’s value is stored centrally rather than locally, the balance can’t altered just by rewriting it on the card.
• If you would like to learn more about NFC, read Vanhoof’s article. It’s an excellent and gentle introduction if you want to know how to get started in smartcard research.
• If you like to drink coffee, consider using a shop that makes it for you by hand. You get to enjoy the smell as the barista grinds and produces the drink, and you can typically pay with a regular credit card, or even using cash, which is very hard indeed to duplicate or modify.

---

Dr Jason R.C. Nurse is an Associate Professor in Cyber Security at the University of Kent, and a Visiting Academic at the University of Oxford. His research focuses on the socio-technical aspects of cyber security, privacy and trust.

Jason has channelled years of research into a concise, evidence-led framework that outlines the best ways to deal with the potential relationship damage that comes hand in hand with a cyberattack. (The full research paper can be accessed via arXiv.org.)

As part of the Sophos Evolve 2020 event, Jason joined Doug Aamoth, Sophos product marketing director, and Sara Eberle, senior director of public relations, to talk about his work.

If you missed the live session, watch the recording, and check out our key takeaways below:

Preparation is key

There’s a lot of focus on the technical response to a cyberattack, such and shoring up firewalls and improving endpoint protection, but when it comes to responding to a data breach, it’s also important to consider what you say publicly, and how you say it.

A cyberattack is always going to be an unwelcome surprise. But with the right preparations and a well-considered, helpful response, you can maintain the trust you’ve built with your customers.

An ounce of prevention, a pound of cure

Jason made it clear that putting the work in before a data breach occurs is crucial, but that many organizations overlook this preparatory stage.

To put out an effective response after a breach, you need to know in advance who your spokespeople will be, where your customers are based, which regulations apply, and how you’re going to talk to the public.

Your organisation’s list of spokespeople should be as short as possible – ideally just one or two people – so your message stays consistent and you don’t cause confusion.

It’s worth preparing draft responses for the media, shareholders, and customers, so you’re not scrambling for a statement if a breach occurs. This includes having a set of responses for a range of security incidents.

Jason has seen great success in organizations that hold regular rehearsals, which ensure everyone has a tight grasp of their responsibilities – including who they’re allowed to talk to and what they’re allowed to talk about.

To disclose, or not to disclose?

Honesty remains the best policy, unless the law requires you to keep a breach under wraps.

If you choose not to disclose a breach publicly, there’s every chance that it will come to light later on. Always remember that people may find your organisation’s data in underground criminal markets.

Don’t play the victim

When you’re hit by a cyberattack it can be tempting to say you are the victim, because technically you are a victim.

But that story isn’t going to sit well with many people. As Jason explained: when people choose to trust you with their data, you’re taking on the responsibility to protect that information.

Make sure it’s clear that you understand the real-world impacts of a breach, and that you’re taking the breach seriously.

Jason said it’s hugely important to take responsibility and clearly outline what you plan to do next. Make it clear how are you going to address the breach and how you intend to to reduce its impact as far as you can.

This could include highlighting extra security measures your organisation will be adding, or, simpler still, taking the opportunity to remind customers to set more robust passwords.

Be fast, clear and factual

Here are some of Jason and Sara’s top tips for ensuring your response to a potential data breach is comprehensive and reassuring:

• Respond quickly. You only have one opportunity to make a first impression. If you’re properly prepared, it’s far easier to give a prompt response that’s also measured and accurate.
• Deliver a clear message. Don’t use jargon when you address your customers and shareholders. Direct, empathetic communication is far more effective.
• Use a single source. Stories can quickly get muddled across news sites and social media. With a single, up-to-date statement direct from your organization’s CEO, or someone of a similar executive status, you can get your message across clearly.
• Take responsibility. Shareholders, customers and the media don’t take kindly to organisations that won’t own up to their mistakes.
• Share the lessons. Setting out a clear action plan will go a long way to reassure your shareholders and customers, and to preserve the relationships you’ve worked so hard to build.

Want to dive deeper?

If you’re interested into delving deeper into Jason’s framework and how it could help your organization prepare for a potential breach, you can access the full research paper via arXiv.org.

---

Here’s our latest Naked Security Live talk, where we answer the thorny question, “What if my password manager gets hacked?”

We often recommend password managers, as we did last week in our article Cybersecurity tips for university students.

We especially recommend password managers for people who would otherwise be inclined to take risky shortcuts, such as using the same password on every site (please don’t do that!)…

…but we also have to admit that a password manager is pretty much like putting all your eggs in one basket: if you drop the basket, you could lose everything in one go.

Watch now to hear our advice on how to deal with this dilemma:

[embedded content]

Watch directly on YouTube if the video won’t play here.
Click the Settings cog to speed up playback or show subtitles.

Don’t forget that these talks are streamed weekly on our Facebook page, where you can catch us live every Friday.

We’re normally on air some time between 18:00 and 19:00 in the UK (late morning/early afternoon in North America).

Just keep an eye on the @NakedSecurity Twitter feed or check our Facebook page on Fridays to find out the time we’ll be live.

---

Not long ago, we wrote on Naked Security about a new-kid-on-the-block malware service called Buer Loader.

The easiest way to explain what the Buer Loader gang were up to was simply to say, “Buer Loader is basically a new competitor to Emotet.”

If you’ve followed the history of malware in recent years, you will definitely have heard of Emotet, and you’ll have a very good idea of what happens next to Emotet victims if the malware breaches their defences.

That’s because “what happens next” could be anything – pretty much anything at all off the cybercrime menu – because Emotet is what’s known as a bot or zombie.

A bot is malware that regularly and quietly calls home to one or more command-and-control servers operated by the crooks, and fetches instructions on what to do next. (You’ll often see the term “command-and-control” abbreviated to C&C or just C2.)

Some botherders – the jargon name given to the crooks in charge of a network of zombies, known colloquially as a botnet – use the zombie computers that they control for their own immediate criminal purposes.

Botnet-triggered criminality includes: sending mass spam deliveries ; launching distributed denial of service (DDoS) attacks against companies or service providers; perpetrating click fraud involving millions of legitimate-looking ad clicks; and much more.

Emotet’s not your everyday botnet

The Emotet crew, however, generally play the game a bit differently.

They typically use the zombies under their control as a sort of content delivery network for other cybercriminals, offering what amounts to a pay-to-play service for malware distribution.

The Emotet gang does the tricky work of building booby-trapped documents or web links, picking enticing email themes based on hot topics of the day, and tricking victims into infecting themselves…

…and then sells on access to infected computers to other cybercriminals so that those crooks don’t have to do any of the initial legwork themselves.

At Christmas 2019, for example, Emotet hitched a ride on the newsworthy coat-tails of climate activist Greta Thunberg, with subject lines such as:

Please help save the planet
Greta
Friends help
Support Greta Thunberg - Time Person of the Year 2019
Greta Thunberg
the biggest demonstration
Demonstration 2019 

If you opened the document, you’d see a cleverly-worded “warning”, apparently a message from Word itself:

The “warning”, of course, is not generated by Word but is merely a page in the booby-trapped document, and the content you’re asked to enable is a Word macro – essentially a miniature app embedded in the document.

The macros used by Emotet documents are the opening gambit in the malware attack, and they initiate the next stage of the infection, typically launching a heavily disguised PowerShell command (or even a chain of disguised commands) to download and implant the Emotet malware program itself.

Once you’re infected with Emotet malware, worse is almost certain to follow if you don’t act quickly.

Back in 2019, SophosLabs researchers published a series of papers on the various stages of an Emotet attack, noting:

Emotet-infected machines routinely get infected with other financially-focused credential hijacking malware, including Qbot, Dridex, Ursnif/Gozi, Gootkit, IcedID, Azorult, Trickbot, or ransomware payloads including Ryuk, BitPaymer, and GandCrab.

Simply put, an typical Emotet infection starts badly, then gets worse, and then gets even worse than that.

The takedown

With that history in mind, we were pleased to read last week’s announcement from Europol about a co-ordinated, multinational takedown effort against the network intrastructure used by the Emotet gang:

WORLD’S MOST DANGEROUS MALWARE EMOTET DISRUPTED THROUGH GLOBAL ACTION

Law enforcement and judicial authorities worldwide have this week disrupted one of most significant botnets of the past decade: EMOTET. Investigators have now taken control of its infrastructure in an international coordinated action.

This operation is the result of a collaborative effort between authorities in the Netherlands, Germany, the United States, the United Kingdom, France, Lithuania, Canada and Ukraine, with international activity coordinated by Europol and Eurojust.

That’s the good news.

The bad news is that cybercrime, to borrow a metaphor often applied to nature, abhors a vacuum, so that when one gang of cybercrooks gets shut down, others inevitably move in to try to fill the hole. (Don’t forget the rival Buer Loader gang we mentioned at the start of the article.)

Worse still, unless and until the Emotet crooks themselves are arrested and convicted, there’s every chance they’ll rebuild their illegal infrastruture and return to reclaim their own vacuum.

In fact, almost exactly a year ago, in February 2020, the Emotet crew went quiet for several months, apparently of their own accord…

…and yet, on 17 July 2020, their own special brand of booby-trapped documents once again began to appear in bulk in our spamtraps, and Emotet was back, just like that.

As SophosLabs Senior Threat Researcher Richard Cohen said at the time:

We’ve talked a lot about Emotet in the past, including showing its malware ecosystem, and providing a series of deep-dive 101s, not forgetting showing the authors venting their frustration at Sophos. [Editor’s note. The malware authors embedded a foul-mouthed anti-Sophos insult into their malware code.]

But then in February 2020, Emotet ceased production – its botnets stopped activity, and the waves of spam campaigns went silent. This isn’t the first time it’s vanished off the radar, only to rise again months later – and that’s exactly what we saw [in the middle of July 2020].

What to do?

Let’s all give our congratulations to Europol and its partners for this takedown.

But let’s also remember that it’s not yet “game over” for the Emotet malware and its ilk…

…because cybersecurity is a journey, not a destination.

For advice on how to stay safe against Emotet and other malware using similar techniques, read our article Fighting Emotet – lessons from the front line:

---

Bug hunter Tavis Ormandy of Google’s Project Zero just discovered a dangerous bug in the GNU Privacy Guard team’s libgcrypt encryption software.

The libgcrypt library is an open-source toolkit that anyone can use, but it’s probably best known as the encryption library used by the GNU Privacy Guard team’s own widely deployed GnuPG software (that’s the package you are using when you run the command gpg or gpg2).

GnuPG is included and used for digital security in many Linux distributions:

gpg is the OpenPGP-only version of the GNU Privacy Guard (GnuPG). It is a tool to provide digital encryption and signing services using the OpenPGP standard. gpg features complete key management and all bells and whistles you can expect from a decent OpenPGP implementation.

In theory, this vulnerability could lead to what’s known as RCE, short for Remote code Execution, because the bug can be triggered simply by sending libgcrypt a block of booby-trapped data to decrypt.

In other words, a program that used libgcrypt to decrypt and check the integrity of data submitted from outside the network – ironically, something you might do to see if you should trust the data in the first place – could be tricked into running an arbitrary fragment of malware code hidden away inside that data.

Ormandy didn’t come up with a working RCE proof-of-concept exploit for this bug, because he didn’t need to on this occasion.

As he pointed out in his bug report:

There is a heap buffer overflow in libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs. […]

I believe this is easily exploitable, the overflowed buffer is immediately adjacent to a function pointer that is immediately called after the overflow.

Just showing that he could provoke a crash was enough to prove his point, and Ormandy was able to do this via the gpg program, which relies on the libgcrypt library for its cryptographic functions.

Do not pass GO

In C programming terminology, function pointer is a jargon term for “a stored memory address that tells the software where to go next”.

A bug that can be abused to overflow a designated memory buffer and thereby modify a nearby function pointer will almost inevitably affect the future behaviour of the running program and divert its execution, typically causing it to crash.

With sufficient trial and error, however, attackers may be able to figure out how to alter the flow of execution in the buggy program so that instead of crashing uncontrollably, the code gets tricked into running machine code instructions provided by the attackers themselves.

Booby-trapped data that diverts a buggy program into treating some of that data as code to be executed is known as shellcode, a jargon word that means “malicious program code that’s infiltrated under the disguise of being harmless data”.

Think of the function pointer like a CHANCE card in a game of Monopoly that instructs you to Advance to GO, collect $200. Imagine that you pick up the card and are happily preparing to make the specified move, but that when you show the card to your fellow players, it has inexplicably been swapped out by some sleight-of-hand. To your astonishment, it now says Go directly to Jail – Do not pass Go, do not collect $200, and that’s what happens instead.

Slowcoaches might be safe

Ironically, perhaps, operating systems, products and sysadmin teams that are slow off the mark when it comes to updates may very well have missed out on this bug entirely.

The vulnerability was introduced in version 1.9.0 of the library, which only came out on 2021-01-19, less than two weeks before Ormandy filed his bug report.

But the good news for those of us who did get 1.9.0 within the last few days is that the GNU Privacy Guard team fixed this bug almost immediately, releasing version 1.9.1.

If your Linux distribution was sufficiently on the ball to have upgraded to 1.9.0 within the past two weeks, it’s likely that it will also already have updated to 1.9.1 – check your distro’s changelog for details.

Our distro, for example, has this recent entry:

 [Slackware-current] ChangeLog for x86_64 Fri Jan 29 20:26:57 UTC 2021 n/libgcrypt-1.9.1-x86_64-1.txz: Upgraded. This update fixes a serious security issue present only in libgcrypt-1.9.0. Everyone should be sure to update this package as soon as possible. For more information, see: https://lists.gnupg.org/pipermail/gnupg-announce/2021q1/000456.html (* Security fix *)

The second piece of good news is that libgcrypt isn’t as widely used as other open-source cryptographic libraries such as OpenSSL and LibreSSL, so fewer third-party programs rely on it.

The third piece of good news is that most third-party software that uses libgcrypt seems to use the shared library (what Windows would call a DLL) that’s provided by your distro, rather than compiling a copy of the libgcrypt code into the product itself.

In other words, even if you have affected software on your computer, just upgrading the central copy of libgcrypt in your distro’s system directories may well be enough to be enough to neutralise the bug.

Nevertheless, the average Linux system almost certainly includes numerous apps that are potentially affected by this bug.

A brief though incomplete list of software on our own system that uses libgcrypt includes: Akonadi, Audacity, FFmpeg, Geeqie, the GPG suite itself, numerous KDE tools, Qemu, the RPM Package Manager and Wireshark. (Most of these rely on the libgcrypt shared library, and can therefore now implicitly be considered patched on our computer.)

Checking your version

Assuming that you have the GPG tools installed , including gpg2 and libgcrypt, try this:

$ gpg2 --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.1 <--- SHARED LIBRARY VERSION IS SHOWN HERE
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Home: /home/yourname/.gnupg
Supported algorithms:
Pubkey: RSA, [...]
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES [...]
Hash: SHA1, RIPEMD160, SHA256 [...]
Compression: Uncompressed, ZIP, ZLIB [...]
$ 

---