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

Link to the post source

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  ▶

Link to the post source

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

Link to the post source

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.

Link to the post source

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.

Link to the post source

Researchers at Apple device management company Jamf recently published an intriguing paper entitled Fake Airplane Mode: A mobile tampering technique to maintain connectivity.

We’ll start with the good news: the tricks that Jamf discovered can’t magically be triggered remotely, for example merely by enticing you to a booby-trapped website.

Attackers need to implant rogue software onto your iPhone first in order to pull off a “fake airplane” attack.

The bad news, however, is that the software shenanigans used aren’t the typical tricks associated with malware or date exfiltration code.

That’s because “fake airplane” mode doesn’t itelf snoop on or try to steal private data belonging to other apps, but works simply by showing you what you hope to see, namely visual clues that imply that your device is offline even when it isn’t.

Given that even the App Store, Apple’s own compulsory walled garden for software downloads, isn’t immune to malware and potentially unwanted applications…

…you can imagine that determined scammers, cryptoconfidence tricksters and spyware peddlers might be keen to find a way to hide “fake airplane” treachery in otherwise unexceptionable looking apps in order to make it through the App Store verification process.

What you see is not necessarily what you get

As the Jamf researchers explain it, most users who are concerned not only about going offline temporarily, but also with checking that they really are disconnected from the internet, do something like this:

• Swipe up from the home screen to access the Control Center. Tapping on the aircraft icon typically turns the aircraft orange and all three radio communication icons (mobile, wireless and Bluetooth) grey:

• Try to browse to a popular site. Opening or refreshing a web page when airplane mode is successfully engaged typically produces a notification that explicitly says Turn off Airplane Mode or use Wi-Fi to Access Data:

At this point, a well-informed user would be inclined to accept not only that they had turned airplane mode on, but also that they had successfully cut the apps on their phone off from the internet.

Unfortunately, Jamf coders found a series of sneaky tricks by which they could separate appearance from reality.

Firstly, they figured out how to intercept the API (application programming interface) call triggered by tapping on the aircraft icon on the Control Center screen.

In this way, the apparent switch to airplane mode was recorded in the iPhone logs, yet the actual system call to turn it off in real life was hijacked to turn off Wi-Fi but not the mobile network, leaving an unexpected pathway off the phone for any app authorised to use mobile data.

Secondly, they reconfigured your browser (they used Safari in their tests, but we assume other apps, including alternative browsers, could be tricked in the same way) so that the app alone, rather than the entire device, was blocked from using mobile data connections.

In theory, the roguery of cutting off a specific app from the internet instead of the whole phone ought to be obvious, because a well-informed user would see a completely different warning when trying to browse to a known page:

This notification clearly implies that mobile data is turned on in general, but disabled specifically for Safari, in contrast to the warning shown above, where airplane mode is mentioned explicitly.

So, thirdly, the researchers figured out how to intercept the “mobile data is turned off” dialog, and simply to replace it with the more reassuring “airplane mode is on” notification instead.

The last possible giveaway facing the Jamf researchers was that with airplane mode artificially activated in the Control Center screen (thus correctly turning the aircraft icon orange), the mobile data connection icon (the broadcasting lollipop) would nevertheless remain green.

Fourthly, therefore, the researchers found a way to dim the mobile data icon to give the false impression that the option was disabled, and thus by implication turned off, even though it wasn’t.

What to do?

The good news is that the researchers only figured out how to misrepresent the state of your device’s connectivity when changes were made via the Control Centre swipe-up screen.

If you go directly to the Settings page, the tricks outline here are no longer enough, because the Airplane Mode setting, along with the resulting configuration forced on your Wi-Fi, Bluetooth and Mobile Data settings, can be correctly controlled and reliably checked:

We’re assuming, with enough effort and with sufficiently powerful malware already installed on your iPhone, that a determined attacker might be able to interfere even with the Settings page, but the Jamf team didn’t come up with a practicable way of doing this in their research.

So, if you ever need to use apps on your phone while being as certain as you can that it’s cut off from the internet, remember that a simple connection test with your browser might not be telling you the truth.

Check directly on the Settings page, rather than indirectly via Control Center or your browser.

Link to the post source

CELEBRATING THE TRUE CRYPTO BROS

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

Link to the post source

The US Federal Bureau of Investigation (FBI) has just published an official public service announcement headlined with with a very specific warning: Cybercriminals Targeting Victims through Mobile Beta-Testing Applications.

The Feds didn’t go as far as naming any specific vendors or services here, but one of the main reasons that crooks go down the “beta-testing” route is to lure users of Apple iPhones into installing software that didn’t come from the App Store.

(We’re guessing that explicitly naming Apple would not only be a bit unfair, but might also give a false sense of security to anyone who doesn’t have an Apple-branded phone, because the general lessons to be learned here apply to all types of mobile phone, and even, by extension, to all sorts of software on all sorts of device.)

Using rarity and privilege as a lure

Some iPhone users feel secure against malware, spyware, rogueware and scamware simply because Apple insists that iPhone (and iPad apps, for that matter) must be acquired from the App Store.

Android users start out in a similar world, with installs allowed by default only from Google Play, but they have the option to go “off-market” if they want, and fetch apps from unofficial sources.

In contrast, even iPhone apps that are 100% free must be submitted by the vendor to the App Store to become available for download, and downloaded by the user from the App Store for installation.

But there are at least two ways to get what amount to unofficial apps, or at least “unendorsed by Apple apps”, onto an iPhone.

One is to use Apple’s Mobile Device Management (MDM) system, which is officially intended for companies that want to deploy proprietary, non-public, corporate apps onto company-supplied or company-managed devices.

Another is to sign up for Apple’s TestFlight service, which lets you offer pre-release software for trial by a maximum of 10,000 users as part of your beta-testing program.

Alpha software, after the first Greek letter, is an old-school jargon name for code that is still in its first stages of development: typically very rough and ready, more of a proof-of-concept than a real app.

Beta software, after the second Greek letter, usually refers to a software product that’s past that first stage, but is not yet fully debugged, isn’t yet recommended for everyday use, and is therefore available only in a limited release.

Convincing victims to “join the club”

As it happens, both MDM enrollment and beta-test signup require active agreement from the owner of the device.

That’s because enrolling your device into MDM gives lots of control to your corporate IT team, such as giving them the right to wipe your phone if they want.

(Phones under MDM can be wiped remotely without your consent on the grounds that if your phone were stolen, a consent request from IT would play into the hands of the thief, who would simply say, “No” to the request, and would also be alerted that the theft had been reported.)

Similarly, beta-level software exposes you to greater risk, not only because it’s expected still to contain plenty of bugs, but also because beta software is generally expected to collect much more information than a finished app, as part of tracking down any faulty behaviour.

That, of course, raises the questions, “Why would anyone willingly agree to submit to MDM by someone who wasn’t their employer and had no reason to be able to manage their device remotely, or to install beta-quality software if they weren’t knowingly part of the development process?”

The answer, in the case of the cybercrime that the FBI are warning about here, is that these MDM/Beta scammers aren’t aiming to sign up everyone, or even just anyone.

Most of them have take a leaf out of the romance scammers’ playbooks, where their goal is not to lure in 1,000,000 potential victims, sign up 1% of them, and hit each of them up abrpuptly for $10 or $100 each.

These scammers aim to identify 100s or 1000s of potential victims, actively befriend 10s or 100s of them, and then lure them, under the guise of being trusted friends, into parting with $10,000 or more each, often engaging with them regularly and personally over an extended period of time

Indeed, a lot ot these MDM/Beta scammers start in just the same way as romance scammers: by “meeting” victims on online dating sites using fake profiles, and by building up a friendship and an apparent sense of mutual trust.

Then, instead of drawing their victims into a relationship based on love and emotional affection, they initiate a relationship based more directly on money, usually based on the lure of a cryptocurrency “investment” that isn’t open to just anyone.

At this point, the crooks have already created a believable reason why the app you need to download and install isn’t in the App Store, where everyone would be able to see it.

Its suspicious deployment method, via MDM or TestFlight, is re-explained by the criminals as a sign that it’s something special; an opportunity that’s a privilege to participate in.

Money goes in but “earnings” never come out

You’re probably familiar with how this sort of scam plays out: the app shows data from a legitimate-looking but utterly bogus backend system.

The bogus investments always seem to keep on going up; trading volumes always look healthy; and (in at least some of these scams) you can even make withdrawals, assuming that you want to test that it isn’t just a one-way system.

As you can imagine, any withdrawals you’re allowed as a “test” of an scam site’s legitimacy will be kept well within the amount you’ve already put in (so you’re really only getting a bit of your own money back), or won’t actually be paid out for real (they’ll be converted into “reinvestments” with appealing but fake “rewards” and “bonuses” to keep you on the hook).

The doubly bitter end, for many victims, comes when they decide to cash out forever, and the scammers realise they can’t keep the victim inside the fraud pyramid any longer.

Many of these scammers then turn threatening as well as dishonest, telling you that the government has frozen your account; that you owe some sort of tax on your capital gains; and that because the account is frozen, you can’t just have the tax amount witheld from your withdrawal.

You have to make good the tax payment first, typically at the rate of 20%, to get out of trouble with the law.

Only then will you get your “investment” out, and because the “government” is involved, there’s a time limit that can’t be argued with.

“Borrow from your family and friends,” the scammers may say, becoming ever-more menacing about how badly things will turn out if you don’t pay the “government” its share in the time allowed.

At this point, of course, the 20% “tax” is being calculated not merely on the money you actually put in so far, but on the fake “investment growth”, plus the made-up “rewards” and “bonuses” that you have “accrued” along the way.

Some desperate victims may end up paying in as much again at the end as they did along the way.

Whether victims decide to pay in that final 20% or not, one thing is certain: nothing ever comes back from the crooks.

Everything paid in vanishes forever.

What to do?

As SophosLabs researcher Jagadeesh Chandraiah has warned in a detailed report that he published last year:

[These] scams continue to flourish through the combination of social engineering, cryptocurrency, and fake applications. These scams are well-organised, and skilled in identifying and exploiting vulnerable users based on their situation, interests, and level of technical ability. Those who get pulled into the scam have lost tens of thousands of dollars.

To stay clear of online scammers who lure you into trusting relationships with the express purpose of defrauding you, typically over weeks or months, here are our Top Tips:

• Take your time when online talk in a developing friendship turns to money. Don’t be swayed by the fact that your new “friend” happens to have a lot in common with you. That needn’t be down to serendipity or because you have found a genuine chum. The other person could simply have read your own online profiles carefully in advance.
• Never give administrative control over your phone to someone with no genuine reason to have it. Never click [Trust] on a dialog that asks you to enrol in remote management unless it’s from your employer, and your employer looks after or owns your device.
• Don’t be fooled by circumstances that imply approval from Apple. The fact that an app is registered for beta testing with TestFlight doesn’t mean it’s officially vetted and approved by Apple. In fact, it’s the opposite: TestFlight apps aren’t in the App Store yet, because they’re still being developed and could contain bugs, accidentally or deliberately. If anything, you need to trust the developers of a TestFlight app even more than vendors of regular apps, because you’re letting them run experimental code on your device.
• Don’t be deceived by messaging inside the app itself. Don’t let icons, names and text messages inside an app trick you into assuming it has the credibility it claims. Don’t believe investment results simply because the app shows you what you want to see. (If I show you a picture of a pot of gold, that doesn’t mean I own a pot of gold!)
• Listen openly to your friends and family if they try to warn you. Criminals who use dating apps and friendships as a lure think nothing of deliberately setting you against your family as part of their scams. They may even proactively “warn” you not to let potentially “jealous” friends and family in on your investment “secret”. Don’t let the scammers drive a wedge between you and your family as well as between you and your money.

YOU MIGHT ALSO LIKE:

Link to the post source

It’s been a while since we’ve written about card skimmers, which used to play a big part in global cybercrime.

These days, many if not most cyber-breach and cybercrime stories revolve around ransomware, the darkweb and the cloud, or some unholy combination of the three.

In ransomware attacks, the criminals don’t actually need to approach the scene of the crime in person, and their payoffs are extracted online, typically using pseudoanonymous technologies such as the darkweb and cryptocoins.

And in some cloud-based cybercrimes, notably those generally referred to as supply-chain attacks, the criminals don’t even need to access your network at all.

If they can find a third party to whom you regularly upload precious data, or from whom you routinely download trusted software, then they can go after that third party instead, and do the damage there.

In recent cyberextortion attacks, dozens of major brand names have been blackmailed over stolen employee and customer data, even though that data was stolen indirectly.

In the MOVEit attacks, for instance, the data was stolen from service providers such as payroll processing companies, who had used buggy file transfer software to accept supposedly-secure uploads from their own customers.

Unbeknownst to both the companies that ultimately got blackmailed and to the payroll processing services they used, the MOVEIt file transfer software allowed crooks to perform unauthorised downloads of stored data as well.

In-your-face cybercrime

Credit card skimming, in contrast, is a much more in-your-face crime, both for its perpetrators and their victims.

Card skimmers aim at leeching the private information that’s critical to your bank card, at the very moment that you use the card.

Notoriously, card skimmers don’t just go after data stored on the card itself but also after the PIN that serves as your second factor of authentication.

Whether your card has an easily-cloned magnetic strip, or a secure chip that’s can’t be cloned, or both, your PIN is never stored on or in the actual card.

Skimming criminals therefore typically use miniature hidden cameras to snoop out your PIN live as you type it in.

Ironically, perhaps, bank cash machines, better known as ATMs, make a perfect location for card skimming equipment.

ATMs almost always grab onto your card mechanically and draw it right into the machine, out of sight and reach.

(Apparently, that’s for two main reasons: firstly because that process tends to slice off slice off any rogue wires soldered onto the card that might connect it to the outside world while it’s in use, and secondly because it allows the bank to confiscate the card if it thinks that it might have been stolen.)

In other words, adding a fake magstripe reader to an ATM is generally more effective than doing the same thing on any tap-to-pay or chip-and-PIN terminal, where the full magstripe never passes into or over the reader.

Also, ATMs always ask for your PIN, and often have plenty of convenient surface features where a tiny camera can be hidden in plain sight.

When security precautions have the opposite effect

In another irony, well-lit bank lobbies that aim to provide reassuring surroundings are sometimes a better place for card skimmers than dimly-lit ATMs on side-streets.

In one case that we recall, the ATM lobby in an downtown building that served mulitple banks had been fitted with an after-hours “security” door to make customers feel safer.

The door was meant to prevent just anyone from hanging out amongst the ATMs all night long, because would-be ATM users had to swipe a bank card of some sort at the entrance to get initial access.

Rather than improving security, however, this made matters worse, because the crooks simply fitted a hidden card reader to the door itself, thus leeching the data from cards of all banks before any customers reached the actual ATMs.

Furthermore, the crooks were able to use a hidden camera in the lobby, rather than glued onto any specific ATM, to watch out for users’ PINs.

Like the abovementioned MOVEit attacks, where companies had their trophy data stolen without their own computers being accessed at all, these crooks recovered ATM card data and matching PINs for multiple different banks without physically touching a single ATM.

In another case we know of, the crooks secretly filmed PINs at an ATM on a bank’s own premises by placing their surveillance camera not on the ATM itself, which staff were trained to check regularly, but at the bottom of a corporate brochure holder on the wall alongside the cash machine.

Staff, it seemed, inadvertently assisted the criminals by dutifully refilling the brochure holder every time it ran low on marketing material, providing literal cover for the hidden compartment at the bottom where the spy camera hardware was tucked away.

Skimmers still in business

Well, ATM skimming is still very much a cybercrime-in-progress, as reported over the weekend by the Brisbane police in Queensland, Australia, where three men were arrested recently for a range of skimming-related offences.

The bust seems to have gone down something like this:

• 2023-07-31: Skimming devices found in an intercepted postal package. It looks as though the package was addressed to a non-existent person, presumably giving the residents at the delivery address plausible deniability if they were raided when the parcel arrived.
• 2023-08-02: Compromised ATM reported to police by a local bank. As mentioned above, financial insitutions regularly sweep their cash machines for signs of tampering or stuck-on parts. Skimming devices are typically made to order, typically 3D-moulded out of plastic to fit closely over specific models of ATM, and adorned with any words, symbols or brand marks needed to match the ATM they’re going to be attached to.
• 2023-08-03: Cybercrime detectives on watch noticed two men approaching the compromised ATM. We’re assuming that the bank deliberately took the comrpmised ATM out of service, thus not only preventing customers from actively being skimmed, but also suggesting to the crooks that if they wanted to retrieve the skimmer, they should act quickly before the ATM was visited for “repair” and the device found and confiscated.

After a short but swift foot-chase through Brisbane’s popular Queen Street Mall, the fleeing suspects were apprehended and arrested.

With a search warrant now in hand for the delivery address on the intercepted package, the cops paid a visit and allege that they found “two pin-hole cameras and several fraudulent identification items, including bank cards, and images of a licence and passport.”

The cameras, say the police, were hidden inside bank-branded ATM parts.

Also, according to the cops, one of the fake IDs recovered in the raid just happened to match the name on the intercepted package containing skimming devices.

That’s when the third suspect was arrested.

What to do?

To get an idea of what to look out for on suspicious ATMs, why not watch selected video footage from the bust, as posted by the Queensland Police?

The skimming hardware components appear at the end, after some bodycam footage of the suspects getting overhauled and nabbed in the foot-chase, complete with the sound of handcuffs clicking shut:

The police didn’t put any known objects in with the skimming panels for a sense of scale, but we’re guessing that the blue plastic panels you will see, inside one of which is hidden what looks like an off-the-shelf embedded system-on-chip motherboard, are designed to sit alongside the slot into which you insert your ATM card.

We’re guessing that the two-tone blue matches the bank’s own colour scheme, with the yellow arrow pointing at the card slot.

As mentioned above, skimming devices are often made to order to match the current branding of the bank and the ATMs that the crooks are targeting, thus making them harder to spot than some of the the generic, beige-coloured panels that we’ve seen in the past, like this one from a Queensland Police bust back in 2012:

Or advice is:

• Don’t be shy to inspect ATM hardware and your surroundings closely. Put your eyes right up to the surface if you’re not certain whether any particular part really belongs.
• Always cover the keypad fully when entering your PIN. Do this even when you’re inside a bank and there’s apparently no one else around.
• Grab hold and give it a wiggle if you’re not sure. Look out for parts that don’t quite fit properly, that don’t match the original design, or that are apparently not part of the original ATM’s construction.
• If you see something, say something. Don’t enter your PIN. Recover your card, walk away quietly, and contact your local police or call the bank concerned. Use a number from your card or a previous statement, or at worst a contact number shown on the ATM’s own screen. Don’t call any numbers attached to or displayed next to the ATM, because the crooks could have put them there themselves.

As always, look before you leap..

Link to the post source

It’s taken nearly ten years, but the US Department of Justice (DOJ) has just announced the court-approved seizure of a web domain called LolekHosted.net that was allegedly connected to a wide range of crimeware-as-a-service activities.

The DOJ also charged a 36-year-old Polish man named Artur Karol Grabowski in connection with running the service, but his current whereabouts are unknown.

In the DOJ’s blunt words, “Grabowski remains a fugitive.”

The downed site is still technically online, but now presents a warning notice to visitors:

Bulletproof hosting

Sites of this sort are known in the jargon as bulletproof hosts, whose operators like to claim that they will not only shift around online to resist takedown efforts, but also shield their “customers” from identification even if their assets do get seized.

Indeed, the DOJ alleges that:

Grabowski allegedly facilitated the criminal activities of LolekHosted clients by allowing clients to register accounts using false information, not maintaining Internet Protocol (IP) address logs of client servers, frequently changing the IP addresses of client servers, ignoring abuse complaints made by third parties against clients, and notifying clients of legal inquiries received from law enforcement.

Cybercrime activities allegedly enabled by LolekHosted include: ransomware attacks; system penetration attempts via what’s known as brute force attacks (for example, where attackers try logging into thousands of different servers with millions of different passwords each); and phishing.

As you probably know, ransomware criminals typically use anonymous darkweb hosts for contact purposes when they’re “negotiating” their blackmail payoffs.

Those darkweb servers are usually hosted in the largely anonymous Tor network, with server names ending in .onion.

So-called onion addresses aren’t part of the regular internet domain name system (DNS), so they can’t be looked up or traced using conventional tools, and they require ransomware victims to to setup and use a special Tor-enabled browser to access them pseudoanonymously.

In the build-up to an attack, however, and even while the attack is under way, ransomware crooks often need innocently-styled URLs on the regular “brightweb”.

For example, attackers often set up legitimate-looking sites as download repositories for their malware and hacking tools, as jumping-off points for mounting attacks, and as upload servers to which they can exfiltrate stolen files without arousing immediate suspicion.

According to the DOJ, Grabowski’s customers included numerous affiliates of the notorious NetWalker ransomware gang, with LoledHosted servers implicated in:

approximately 50 NetWalker ransomware attacks on victims located all over the world, including in the Middle District of Florida [where Grabowski is being charged]. Specifically, clients used the servers of LolekHosted as intermediaries when gaining unauthorized access to victim networks, and to store hacking tools and data stolen from victims.

What next?

If caught and convicted, the DOJ says that it is seeking a to recover a whopping $21,500,000 in forfeited funds from Grabowski, a sum that the DOJ claims matches the proceeds of the criminal activities with which he has been charged.

We don’t know what happens if Grabowski gets caught and won’t or can’t come up with the money, but the DOJ also points out that the maximum jail-time penalty he faces if convicted on all charges (for all that maxiumum sentences are rarely imposed) comes to 45 years.

Link to the post source