Perpetual IT

Dear Naked Security readers,

Firstly, thank you for your interest, your time, and your contributions to the Naked Security community. Your invaluable engagement and expertise have helped improve cybersecurity for everyone.

We have recently added the extensive catalog of Naked Security articles to the Sophos News blog platform, enabling us to provide all Sophos security research, insights, and intelligence in a single location.

We are redirecting articles from Naked Security to Sophos News and you can continue to access the Naked Security article library whenever you need it.

As adversary behaviors evolve, we’re seeing increased demand for deep threat research to help defenders keep pace with today’s fast-changing, innovative attacks. In response, we’re increasing our content focus on proprietary research by our Sophos X-Ops team.

Sophos X-Ops is a cross-functional team of more than 500 threat intelligence and security experts with visibility into attacker behaviors and other important topics including ransomware attacker trends, cluster attacks, software vulnerabilities, supply chain attacks, zero days, and much more. You can find their articles in the Security Operations, Threat Research and AI Research sections of this blog.

We’re extremely proud of Naked Security’s contributions to the security community over the last decade. Paul Ducklin will continue to share his security expertise on X (formerly Twitter), Facebook, Instagram, and LinkedIn. 

If you don’t already, we invite you to subscribe to receive our Sophos News blog email (sign-up at the bottom of this page) and follow Sophos X-Ops on X (Twitter) and Mastodon.

Whether you’re a threat hunter, security administrator, IT/security generalist, home user or more, we know you will find Sophos X-Ops a valuable resource.

Thank you for your support.

Sophos

US food delivery compeny PurFoods, which trades as Mom’s Meals, has just admitted to a cyberintrusion that took place from 2023-01-16 to 2023-02-22.

The company stated officially that:

[The] cyberattack […] included the encryption of certain files in our network.

Because the investigation identified the presence of tools that could be used for data exfiltration (the unauthorized transfer of data), we can’t rule out the possibility that data was taken from one of our file servers.

PurFoods says it has contacted everyone whose was affected, or at least everyone whose data appeared in one or more of the scrambled files, which we assume are the files that the company thinks the attackers would have stolen, if indeed any data was exfiltrated.

What’s at risk

The company didn’t say how many people were caught up in this incident, but a recent report on IT news site The Register puts the total at more than 1,200,000 individuals.

PurFoods listed those affected as:

Clients of PurFoods who received one or more meal deliveries, as well as some current and former employees and independent contractors.

The information in the files included date of birth, driver’s license/state identification number, financial account information, payment card information, medical record number, Medicare and/or Medicaid identification, health information, treatment information, diagnosis code, meal category and/or cost, health insurance information, and patient ID number.

Social Security numbers [SSNs] were involved for less than 1% of the [individuals], most of which are internal to PurFoods.

We’re guessing that the company didn’t collect SSNs for customers, though we’d expect them to need SSN data for employees, which is why the at-risk SSNs are listed as “internal”.

But if you’re wondering why a food delivery company would need to collect customers’ medical details, including health and treatment information…

…well, we wondered that, too.

It seems that the company specialises in providing meals for people with specific dietary needs, such as those with diabetes, kidney problems and other medical conditions, for whom food ingredients need to be chosen carefully.

Mom’s Meals therefore needs medical details for some, if not all, of its customers, and that data was mixed in with plenty of other personally identifiable information (PII) that may now be in the hands of cybercriminals.

What to do?

If you’re one of the more than a million affected customers:

• Consider replacing your payment card if yours was listed as possibly stolen. Most banks will issue new payment cards promptly, thus automatically invalidating your old card and making the old card details useless to anyone who has them now or buys them up later on the dark web.
• Watch your statements carefully. You should do this anyway, so that you spot anomalies as soon as you can, but it’s worth keeping a closer eye on what’s happening with your financial accounts if there’s evidence you might be at a greater-than-usual risk of identity theft or card abuse.
• Consider implementing a credit freeze. This adds an extra layer of authorisation from you that’s needed before anything in your credit report can be released to anyone. This makes it harder for crooks to acquire loans, credit cards and the like in your name (although this obviously makes it harder – and thus takes longer – for you to get a new loan, credit card or mortgage, too). Unfortunately, activating a credit freeze means you need to send a large amount of PII, including a copy of your photo ID and your SSN, to one of three main credit bureaus.

If you’re a company that handles vital PII of this sort:

• Act immediately when any anomalies are detected in your network. In this attack, the criminals were apparently inside the PurFoods network for more than a month, but were only spotted after they’d got as far as scrambling files, presumably as a basis for extorting money from the company.
• Consider using a Managed Detection and Response (MDR) service if you can’t keep up on your own. Good threat hunting tools not only search for and prevent the activation of malware, but also help you to detect weak spots in your network such as unprotected or unpatched computers, and to identify and isolate behaviour that’s commonly seen in the build-up to a full-blown attack. Having threat hunting experts on hand all the time makes it much more likely that you’ll spot any danger signals before it’s too late.
• Be as quick and as transparent as you can in any data breach notifications. Despite the suggestion that this was a two-pronged steal-data-and-then-scramble-it attack, known in the jargon as double extortion, PurFoods hasn’t made it clear what really happened, even though the company tooks several months to investigate and publish its report. For example, we still don’t know whether the company received any blackmail demands, whether there was any “negotiation” with the attackers, or whether any money changed hands in return for hushing up the incident or for buying back decryption keys to recover the scrambled files.

According to the data in the latest Sophos Active Adversary report, the median average dwell time in ransomware attacks (the time it takes between the crooks first breaking into your network and getting themselves into a position to compromise all your files in one simultaneous strike) is now down to just five days.

That means that if your company does get “chosen” by ransomware criminals for their next money-grabbing attack, there’s a better than 50% chance that you’ll have less than a week to spot the crooks sneaking around getting ready for your network doomsday event.

Worse still, the final hammer blow unleashed by ransomware attackers is likely to be at a deeply inconvenient time for your own IT team, with the file-scrambling denouement typically unleashed between 21:00 and 06:00 (9pm to 6am) in your local timezone.

To counter-paraphrase Mr Miagi of Karate Kid fame: Best way to avoid punch is to be there all the time, monitoring and reacting as soon as you can.

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?

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

HOW MANY CRYPTOGRAPHERS?

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

The venerable RAR program, short for Roshal’s Archiver after its original creator, has been popular in file sharing and software distribution circles for decades, not least because of its built-in error recovery and file reconstruction features.

Early internet users will remember, with little fondness, the days when large file transfers were shipped either as compressed archives split across multiple floppy disks, or uploaded to size-conscious online forums as a series of modestly-sized chunks that were first compressed to save space and then expanded into an ASCII-only text-encoded form.

If one floppy went missing or wouldn’t read back properly, or if one chunk of a 12-part archive upload got deleted from the server by mistake, you were out of luck.

RAR, or WinRAR in its contemporary Windows form, helped to deal with this problem by offering so-called recovery volumes.

These stored error correction data such that multi-part archives could be recovered automatically and completely even if one entire chunk (or more, depending on how much recovery information was kept) ended up lost or irretrievable.

Keeping a spare wheel in the boot/trunk

Apparently, RAR archives up to and including version 4 used so-called parity correction; newer versions use a computationally more complex but more powerful error correction system known as Reed-Solomon codes.

Parity-based correction relies on the XOR operation, which we’ll denote here with the symbol ⊕ (a plus sign inside a circle).

XOR is short for exclusive OR, which denotes “either X is true or Y is true, but not both at the same time”, thus following this truth table, which we construct by assuming that X and Y can only have the values 0 (false) or 1 (true):

If X=0 and Y=0 then X ⊕ Y = 0 (two falses make a false)
If X=1 and Y=0 then X ⊕ Y = 1 (one can be true, but not both)
If X=0 and Y=1 then X ⊕ Y = 1 (one can be true, but not both)
If X=1 and Y=1 then X ⊕ Y = 0 (it's got to be one or other)

The XOR function works a bit like the question, “Would you like coffee or tea?”

If you say “yes”, you then have to choose coffee alone, or choose tea alone, because you can’t have one cup of each.

As you can work out from the truth table above, XOR has the convenient characteristics that X ⊕ 0 = X, and X ⊕ X = 0.

Now imagine that you have three data chunks labelled A, B, and C, and you compute a fourth chunk P by XORing A and B and C together, so that P = (A ⊕ B ⊕ C).

Given the truth table above, and given that XOR is what’s known as commutative, meaning that the order of the values in a calculation can be swapped around if you like, so that X ⊕ Y = Y ⊕ Z, or A ⊕ B ⊕ C = C ⊕ B ⊕ A = B ⊕ C ⊕ A and so on, we can see that:

A ⊕ B ⊕ C ⊕ P = A ⊕ B ⊕ C ⊕ (A ⊕ B ⊕ C) = (A⊕A) ⊕ (B⊕B) ⊕ (C⊕C) = 0 ⊕ 0 ⊕ 0 = 0

Now look what happens if any one of A, B or C is lost:

A ⊕ B ⊕ P = A ⊕ B ⊕ (A ⊕ B ⊕ C) = (A⊕A) ⊕ (B⊕B) ⊕ C = 0 ⊕ 0 ⊕ C = C <--the missing chunk returns! A ⊕ C ⊕ P = A ⊕ C ⊕ (A ⊕ B ⊕ C) = (A⊕A) ⊕ (C⊕C) ⊕ B = 0 ⊕ 0 ⊕ B = B <--the missing chunk returns! B ⊕ C ⊕ P = B ⊕ C ⊕ (A ⊕ B ⊕ C) = (B⊕B) ⊕ (C⊕C) ⊕ A = 0 ⊕ 0 ⊕ A = A <--the missing chunk returns!

Also, if P is lost, we can ignore it because we can compute A ⊕ B ⊕ C anyway.

Simply put, having the parity data chunk P means we can always reconstruct any missing chunk, regardless of which one it is.

The error recovery error

Well, after what we assume is many years unnoticed, a bug now dubbed CVE-2023-40477 has surfaced in WinRAR.

This bug can be triggered (ironically, perhaps) when the product makes use of this data recovery system.

As far as we can see, a booby-trapped parity data chunk inserted into an archive can trick the WinRAR code into writing data outside of the memory area allocated to it.

This leads to an exploitable buffer overflow vulnerability.

Data written where it doesn’t belong ends up being treated as program code that gets executed, rather than as plain old data to be used in the dearchiving process.

This bug didn’t get a 10/10 severity score on the CVSS “danger scale”, clocking in at 7.8/10 on the grounds that the vulnerability can’t be exploited without some sort of assistance from the user who’s being targeted.

Bug the second

Interestingly, a second security bug was patched in the latest WinRAR release, and although this one sounds less troublesome than the CVE-2023-40477 flaw mentioned above, TechCrunch suggests that it has been exploited in real life via booby-trapped archives “posted on at least eight public forums [covering] a wide range of trading, investment, and cryptocurrency-related subjects.”

We can’t find a CVE number for this one, but WinRAR describes it simply as:

 WinRAR could start a wrong file after a user double- clicked an item in a specially crafted archive.

In other words, a user who opened up an archive and decided to look at an apparently innocent file inside it (a README text file, for example, or a harmless-looking image) might unexpectedly launch some other file from the archive instead, such as an executable script or program.

That’s a bit like receiving an email containing a safe-looking attachment along with a risky-looking one, deciding to start by investigating only the safe-looking one, but unknowingly firing up the risky file instead.

From what we can tell, and in another irony, this bug existed in WinRAR’s code for unpacking ZIP files, not in the code for processing its very own RAR file format.

Two-faced ZIP files have been a cybersecurity problem for years, because the index of files and directories in any ZIP archive appears twice, once in a series of data blocks interleaved throughout the file, and then again in a single chunk of data at the end. Code that verifies files based on one index but extracts and uses them based on the other, without checking that the two indices are consistent, has led to numerous exploitable vulnerabilites over the years. We don’t know whether this double-index issue is the root cause of the recent WinRAR bug, but it’s a reminder that unpacking archive files can be a complex and error-prone process which needs careful attention to security, even at the cost of extra processing and reduced performance.

What to do?

If you’re a WinRAR user, make sure you’re on the latest version, which is 6.23 at the time of writing [2023-08-23T16:30Z]

Apparently, there’s no automatic update system in the WinRAR software, so you need to download the new installer and run it yourself to replace an old version.

If you’re a programmer, remember to review legacy code that’s still in your software but looked upon as “retired” or “no longer recommended for new users”.

As far as we can see, WinRAR doesn’t generate old-style recovery data any more, and has used smarter error correction algotithms since version 5, but for reasons of backwards compatibility still processes old-style files if they’re presented.

Remember that when attackers create booby-trapped files hoping to trip up your software, they’re generally not using your software to create those files anyway, so testing your own input routines only against files that your own output routines originally created is never enough.

If you haven’t considered fuzzing, a jargon term that refers to a testing technique in which millions of permuted, malformed and deliberately incorrect inputs are presented to your software while monitoring it for misbehaviour…

…then now might be the time to think about it.

Good fuzzers not only run your code over and over again, but also try to adapt the tweaks, hacks and modifications they make to their fake input data so that as much of your code as possible gets tried out.

This helps you get what’s known as good code coverage during testing, including forcing your program down rare and unsual code paths that hardly ever get triggered in regular use, and where unexplored vulnerabilities may have lurked unnoticed for years.

A trio of researchers split between Italy and the UK have recently published a paper about cryptographic insecurities they found in a widely-known smart light bulb.

The researchers seem to have chosen their target device, the TP-Link Tapo L530E, on the basis that it is “currently [the] best seller on Amazon Italy,” so we don’t know how other smart bulbs stack up, but their report has plenty to teach us anyway.

The researchers say that:

We dutifully contacted TP-Link via their Vulnerability Research Program (VRP), reporting all four vulnerabilities we found.

They acknowledged all of them and informed us that they started working on fixes both at the app and at the bulb firmware levels, planning to release them in due course.

For better or for worse (the authors of the paper don’t say whether any disclosure dates were agreed with TP-Link, so we don’t know how long the company has been working on its patches), the researchers have now revealed how their attacks work, albeit without providing any copy-and-pastable attack code for wannabe home-hackers to exploit at will.

We therefore thought that the paper was worth looking into.

Wireless setup

Like many so-called “smart” devices, the Tapo L530E is designed so it can be set up quickly and easily over Wi-Fi.

Although wireless-based configuration is common even for battery-powered devices that can be charged and set up via built-in USB ports, such as cameras and bike accessories, light bulbs generally don’t have USB ports, not least for space and safety reasons, given that they’re designed to be plugged into and left in a mains light socket.

By turning a Tapo L530E light bulb on and off repeatedly at the wall switch for one second at a time, you can force it into setup mode (apparently, the bulb automatically blinks three times to tell you when it’s ready for configuration).

Like most automatically configurable devices, this causes the smart bulb to turn itself into a Wi-Fi access point with an easy-to-recognise network name of the form Tapo Bulb XXXX, where the X’s form a string of digits.

You then connect to that temporary access point, which isn’t password protected, from an app on your smartphone.

Then you tell the bulb how to connect both to your password-protected home Wi-Fi network and to your TP-Link cloud account in future, after which the bulb’s firmware can reboot and connect itself up to the internet, allowing you to manage it from the app on your phone.

The bulb can join home network, which means means you can contact it directly over via your own Wi-Fi when you’re at home, even if your ISP is offline at the time.

And the bulb can connect over the internet to your cloud account, so you can also send commands to it indirectly via your cloud account while you’re on the road, for example to turn lights on and off if you’re late getting back in order to give the impression that there’s someone at home.

Beware imposters

You can probably guess where this is going.

If the app on your phone doesn’t have any cryptographically strong way of figuring out that it really has connected to a genuine light bulb when you go through the setup process…

…then a nearby attacker who just happens to start up a fake Tapo Bulb XXXX access point at the right moment could lure you into sending those important setup secrets to their “imposter bulb” device instead of to the real thing, thus capturing both your Wi-Fi password and your TP-Link account details.

The good news is that the researchers noticed that both the Tapo app and the L530E firmware included a basic safety check to help the app and your bulbs to find each other retliably, thus reducing the risk that the app would blurt out your passwords when it shouldn’t.

But the bad news is that protocol used for this are you really a light bulb? exchange was clearly designed to avoid mistakes rather than to prevent attacks.

Loosely put, the app locates any light bulbs on its network by broadcasting special UDP packets to port 20002 and seeing which devices reply, if any.

To help any listening light bulbs decide that an are you there? request came from the Tapo app, rather than from some other unknown product or service that just happens to use port 20002 as well, the request includes what’s known in the jargon as a keyed hash.

The I am here! reply from the light bulb includes the same sort of keyed checksum to help the app filter out unexpected and unwantwed UDP replies.

Simply put, the keyed hash is a checksum based not only on the data in the UDP packet but also some additional key bytes that are folded into the checksum as well.

Unfortunately, the Tapo protocol uses fixed key bytes for its checksum, with the same “key” hard-wired into the app and into the firmware of every Tapo bulb.

In other words, once someone has decompiled either the app, or the light bulb firmware, or both, and recovered this “key”, you should assume that anybody and everybody will know what it is, making those are you there?/I am here! messages trivial to forge.

Worse, the researchers found that they didn’t need to decompile anything, because this not-so-secret “key” is only 32 bits long, which means that by setting your own Tapo bulb into setup mode and then feeding it are you there? messages using all 2³² possible checksum keys, you’ll eventually hit on the right key by what’s known as brute force.

That’s the cryptographic equivalent of spinning the dials to try every combination on a bike lock, say from 000 to 999, until you get lucky and the lock pops open. (On average, you’ll open the lock after trying half the possible combinations, but it will never take you more than 1000 goes.)

In fact, they didn’t need to send 2³² messages from the app to a light bulb to crack the key.

By capturing just one known-genuine message with a valid keyed hash in it, they could then test all possible keys offline until they produced a message that had the same keyed hash as the one they’d saved.

That means the brute force attack could proceed at CPU speed, not merely at Wi-Fi network packet speed, and the researchers state that “in our setup, the brute force attack always succeeded in 140 minutes on average.”

(We’re assuming they tried it repeatedly just to test that their cracking code was working correctly, although with a hard-wired key shared by all Tapo bulbs, just their first crack would have been enough.)

As long as you’ll speak securely, I don’t care you who are

The next cryptographic problem turned up in the next stage of the light bulb setup process, and was a similar sort of mistake.

After accepting a light bulb as genuine based on a keyed-hash-that-doesn’t-actually-have-a-key, the app agrees on a session key to encrypt its traffic with the “genuine” bulb…

…but once again has no way of checking whether the key agreement took place with a real bulb or an imposter.

Agreeing on a session key is important, because it ensures that no one else on the network can snoop on the Wi-Fi and Tapo passwords when they are subsequently sent from the Tapo app to what it thinks is a Tapo light bulb.

But having no verification process for the key agreement itself is a bit like connecting to a website over HTTPS, and then not bothering to perform even the most basic check on the web certificate that it sends back: your traffic will be secure in transit, but could nevertheless be going straight into the hands of a crook.

The Tapo app identifies itself to the light bulb (or what it thinks is a light bulb) by sending it an RSA public key, which the other end uses to encrypt a randomly generated AES key to secure the data exchanged during the session.

But the light bulb device doesn’t provide any sort of identification, not even a checksum with a hard-wired 32-bit key, back to the Tapo app.

So, the app has no choice but to accept the session key without knowing whether it came from a real light bulb or an imposter device.

The combined outcome of these two flaws is that an attacker on your network could first convince you that their rogue access point was a genuine light bulb waiting to be configured, and thus lure you to the wrong place, and then convince you to to send it an encrypted copy of your own Wi-Fi and Tapo passwords.

Ironically, those leaked passwords really would be secure against everyone… except the imposter with the rogue access point.

Number-used-once that’s used over and over

Unfortunately, there’s more.

When we said above that “those leaked passwords really would be secure,” that wasn’t entirely correct.

The session key that’s established during the key agreement process we described earlier isn’t handled correctly, because the programmers made a blunder in their use of AES.

When the app encrypts each request that it sends to a light bulb, it uses an encryption mode called AES-128-CBC.

We won’t explain CBC (cipher-block chaining) here, but we’ll just mention that CBC mode is designed so that if you encrypt the same chunk of data more than once (such as repeated requests to turn light on and turn light off, where the raw data in the request is the same each time), you don’t get the same output every time.

If every light on and light off request came out identically, then once an attacker had guessed what a turn it off packet looked like, they could not only recognise those packets in future without decrypting them, but also replay those same packets without needing to know how to encrypt them in the first place.

As it happens, CBC-based encryption effectively relies on “seeding” the encryption process for each chunk of data by first mixing a unique, randomly-chosen block of data into the encryption process, thus creating a unique sequence of encrypted data in the rest of the chunk.

This “seed” data is known in the jargon an IV, short for initialisation vector, and although it isn’t meant to be secret, it does need to be unpredictably different every time.

Simply put: same key + unique IV = unique ciphertext output, but same key + same IV = predictable encryption.

The TP-Link coders, unfortunately, generated an IV at the same time that they created their AES session key, and then used the same IV over and over again for every subsequent data packet, even when previous data was repeated exactly.

That’s a cryptographic no-no.

Did I send six packets, or only five?

The last cryptographic problem that the researchers found is one that could still harm security even if the initialisation vector problem were fixed, namely that old messages, whether an attacker knows what they mean or not, can be played back later as if they were new.

Typically, this type of replay attack is handled in cryptographic protocols by some sort of sequence number, or timestamp, or both, that’s included in each data packet in order to limit its validity.

Like the date on a train ticket that will give you away if you try to use it two days in a row, even if the ticket itself never gets cancelled by a ticket machine or punched by a ticket inspector, sequence numbers and timestamps in data packets serve two important purposes.

Firstly, attackers can’t record traffic today and easily play it back later and potentially create havoc.

Secondly, buggy code that sends requests repeatedly by mistake, for example due to dropped replies or missing network acknowledgements, can reliably be detected and controlled.

What to do?

If you’re a Tapo light bulb user, keep your eyes open for firmware updates from TP-Link that address these issues.

If you’re a programmer responsible for securing network traffic and network-based product setups, read through the research paper to ensure that you haven’t made any similar mistakes.

Remember the following rules:

• Cryptography isn’t only about secrecy. Encryption is just one part of the cryptological “holy trinity” of confidentiality (encrypt it), authenticity (verify who’s at the other end), and integrity (make sure no one tampered with it along the way).
• Ensure any one-time keys or IVs are truly unique. The common jargon term nonce, used for for this sort of data, is short for number used once, a word that clearly reminds you that IVs must never be re-used.
• Protect against replay attacks. This is a special aspect of ensuring the authenticity and integrity we mentioned above. An attacker should not be able to capture a request you’re making now and blindly replay it later without getting spotted. Remember that an attacker doesn’t need to be able to understand a message if they can replay it and potentially create havoc.