Perpetual IT

A PYTHON PERSPECTIVE VORTEX

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

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

READ THE TRANSCRIPT

It’s taken more than five years for justice to be served in this case, but the cops and the courts got there in the end.

The UK law enforcement office SEROCU, short for South East Regional Organised Crime Unit, this week reported the peculiar tale of one Ashley Liles, the literal Man in the Middle whom we referred to in the headline.

These days, we usually expand the jargon term MitM to mean Manipulator in the Middle, not merely to avoid the gendered term “man”, but also because many, if not most, MitM attacks these days are performed by machines.

Some techies have even adopted the name Machine in the Middle, but we prefer “manipulator” because we think it usefully decribes how this sort of attack works, and because (as this story shows) sometimes it really is man, and not a machine, in the middle.

MitM explained

A MitM attack depends on someone or something that can intercept messages sent to you, and modify them on the way through in order to deceive you.

The attacker typically also modifies your replies to the original sender, so that they don’t spot the deception, and get sucked into the trickery along with you.

As you can imagine, cryptography is one way to avoid MitM attacks, the idea being that if the data is encrypted before it’s sent, then whoever or whatever is in the middle can’t make sense of it at all.

The attacker would not only need to decrypt the messages from each end to figure out what they meant, but also to re-encrypt the modified messages correctly before passing them on, in order to avoid detection and maintain the treachery.

One classic, and fatal, MitM tale dates back to the late 1580s, when spymasters of England’s Queen Elizabeth I were able to intercept and manipulate secret correspondence from Mary, Queen of Scots.

Mary, who was Elizabeth’s cousin and political arch-rival, was at the time under strict house arrest; her secret messages were apparently smuggled in and out in beer barrels delivered to the castle where she was detained.

Fatally for Mary, Queen Bess’s spymasters were not only able to intercept and read Mary’s messages, but also to send falsified replies that lured Mary into putting sufficient details in writing to cook her own goose, as it were, revealing that she was aware of, and actively supported, a plot to have Elizabeth assassinated.

Mary was sentenced to death, and executed in 1587.

Fast forward to 2018

This time, fortunately, there were no assassination plans, and England abolished the death penalty in 1998.

But this 21st-century message interception crime was as audacious and as devious as it was simple.

A business in Oxford, England, just north of Sophos (we’re 15km downriver in Abingdon-on-Thames, in case you were wondering) was hit by ransomware in 2018.

By 2018, we had already entered the contemporary ransomware era, where criminals breaking into and blackmail entire companies at a time, asking for huge sums of money, instead of going after tens of thousands of individual computer owners for $300 each.

That’s when the now-convicted perpetrator went from being a Sysadmin-in-the-Affected-Business to a Man-in-the-Middle cybercriminal.

While working with both the company and the police to deal with the attack, the perpetrator, Ashely Liles, 28, turned on his colleagues by:

• Modifying email messages from the original crooks to his bosses, and editing the Bitcoin addreses listed for the blackmail payment. Liles was thereby hoping to intercept any payments that might be made.
• Spoofing messages from the original crooks to increase the pressure to pay up. We’re guessing that Liles used his insider knowledge to create worst-case scenarios that would be more believable than any threats that original attackers could have come up with.

It’s not clear from the police report exactly how Liles intended to cash out.

Perhaps he intended simply to run off with all the money and then act as though the encryption crook had cut-and-run and absconded with the cryptocoins themselves?

Perhaps he added his own markup to the fee and tried to negotiate the attackers’ demand down, in the hope of clearing a massive payday for himself while nevertheless acquiring the decryption key, becoming a hero in the “recovery” process, and thereby deflecting suspicion?

The flaw in the plan

As it happened, Liles’s dastardly plan was ruined by two things: the company didn’t pay up, so there were no Bitcoins for him to intercept, and his unauthorised fiddling in the company email system showed up in the system logs.

Police arrested Liles and searched his computer equipment for evidence, only to find that he’d wiped his computers, his phone and a bunch of USB drives a few days earlier.

Nevertheless, the cops recovered data from Liles’s not-as-blank-as-he-thought devices, linking him directly to what you can think of as a double extortion: trying to scam his employer, while at the same time scamming the scammers who were already scamming his employer.

Intriguingly, this case dragged on for five years, with Liles maintaining his innocence until suddenly deciding to plead guilty in a court hearing on 2023-05-17.

(Pleading guilty earns a reduced sentence, though under current regulations, the amount of “discount”, as it is rather strangely but officially known in England, decreases the longer the accused holds out before admitting they did it.)

What to do?

This is the second insider threat we’ve written about this month, so we’ll repeat the advice we gave before:

• Divide and conquer. Try to avoid situations where individual sysadmins have unfettered access to everything. This makes it harder for rogue employees to concoct and execute “insider” cybercrimes without co-opting other people into their plans, and thus risking early exposure.
• Keep immutable logs. In this case, Liles was apparently unable to remove the evidence showing that someone had tampered with other people’s email, which led to his arrest. Make it as hard as you can for anyone, whether insider or outsider, to tamper with your official cyberhistory.
• Always measure, never assume. Get independent, objective confirmation of security claims. The vast majority of sysadmins are honest, unlike Ashley Liles, but few of them are 100% right all the time.
  

  ---

  ALWAYS MEASURE, NEVER ASSUME

  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?

  Take a look at Sophos Managed Detection and Response:
  24/7 threat hunting, detection, and response  ▶

  ---

  LEARN MORE ABOUT RESPONDING TO ATTACKS

  Once more unto the breach, dear friends, once more!

  Peter Mackenzie, Director of Incident Response at Sophos, talks about real-life cybercrime fighting in a session that will alarm, amuse and educate you, all in equal measure. (Full transcript available.)

  Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.

  ---

Public source code repositories, from Sourceforge to GitHub, from the Linux Kernel Archives to ReactOS.org, from PHP Packagist to the Python Package Index, better known as PyPI, are a fantastic source (sorry!) of free operating systems, applications, programming libraries, and developers’ toolkits that have done computer science and software engineering a world of good.

Most software projects need “helper” code that isn’t a fundamental part of the problem that the project itself is trying to solve, such as utility functions for writing to the system log, producing colourful output, uploading status reports to a web service, creating backup archives of old data, and so on.

In cases like that, you can save time (and benefit for free from other people’s expertise) by searching for a package that already exists in one of the many available repositories, and hooking that external package into your own tree of source code.

In the other direction, if you’re working on a project of your own that includes some useful utilities you couldn’t find anywhere else, you might feel inclined to offer something to the community in return by packaging up your code and making it available for free to everyone else.

The cost of free

As you’re no doubt aware, however, community source code repositories bring with them a number of cybersecurity challenges:

• Popular packages that suddenly vanish. Sometimes, packages that a well-meaning programmer has donated to the community become so popular that they become a critical part of thousands or even hundreds of thousands of bigger projects that take them for granted. But if the original programmer decides to withdraw from the community and to delete their projects (which they have every right to do if they have no formal contractual obligations to anyone who’s chosen to rely on them), the side-effects can be temporarily disastrous, as other people’s projects suddenly “update” to a state in which a necessary part of their code is missing.
• Projects that get actively hijacked for evil. Cybercriminals who guess, steal or buy passwords to other people’s projects can inject malware into the code, and anyone who already trusts the once-innocent package will unwittingly infect themselves (and perhaps their own customers) with malware if they download the rogue “update” automatically. Crooks can even take over old projects using social engineering trickery, by joining the project and being really helpful for a while, until the original maintainer decides to trust them with upload access.
• Rogue packages that masquerade as innocent ones. Crooks regularly upload packages that have names that are sufficiently close to well-known projects that other users download and use them by mistake, in an attack jocularly known as typosquatting. (The same trick works for websites, hoping that a user who mistypes a URL even slightly will end up on a bogus look-alike site instead.) The crooks generally clone the genuine package first, so it still performs all the functions of the original, but with some additional malicious behaviour buried deep in the code.
• Petulant behaviour by so-called “researchers”. We’ve sadly had to write about this sort of probably-legal-but-ethically-dubious behaviour several times. Examples include a US PhD student and their supervisor who deliberately uploaded fake patches to the Linux kernel as part of an unauthorised experiment that the core Linux team were left to sort out, and a self-serving “expert” with the nickname Supply Chain Risks who uploaded a booby-trapped fake project to the PyPI repository as a reminder of the risk of so-called supply chain attacks. SC Risks then followed up their proof-of-concept “research” package with a further 3950 packages, leaving the PyPI team to find and delete them all.

Rogue uploaders

Unfortunately, PyPI seems to have been hammered by a bunch of rogue, automated uploads over the past weekend.

The team has, perhaps understandably, not yet given any details of how the attack was carried out, but the site temporarily blocked anyone new from joining up, and blocked existing users from creating new projects:

New user and new project name registration on PyPI is temporarily suspended. The volume of malicious users and malicious projects being created on the index in the past week has outpaced our ability to respond to it in a timely fashion, especially with multiple PyPI administrators on leave.

While we re-group over the weekend, new user and new project registration is temporarily suspended. [2023-05-20T16:02:00Z]

We’re guessing that the attackers were using automated tools to flood the site with rogue packages, presumably hoping that if they tried hard enough, some of the malicious content would escape notice and get left behind even after the site’s cleanup efforts, thus completing what you might call an Security Bypass Attack…

…or perhaps that the site administrators would feel compelled to take the entire site offline to sort it out, thus causing a Denial of Service Attack, or DoS.

The good news is that in just over 24 hours, the team got on top of the problem, and was able to announce, “Suspension has been lifted.”

In other words, even though PyPI was not 100% functional over the weekend, there was no true denial of service against the site or its millions of users.

What to do?

• Don’t choose a repository package just because the name looks right. Check that you really are downloading the right module from the right publisher. Even legitimate modules sometimes have names that clash, compete or confuse.
• Don’t blindly download package updates into your own development or build systems. Test and review everything you download before you approve it for use. Remember that packages typically include update-time scripts that run when you do the update, so malware infections could be delivered via the update process itself, not as part of the package source code that gets left behind afterwards.
• Don’t make it easy for attackers to get into your own packages. Choose proper passwords, use 2FA whenever you can, and don’t blindly trust newcomers to your project as soon as they start angling to get maintainer access, no matter how keen you are to hand the reins to someone else.
• Don’t be a you-know-what. As this story reminds us all, volunteers in the open source community have enough trouble with genuine cybercriminals without having to deal with “researchers” who conduct proof-of-concept attacks for their own benefit, whether for academic purposes or for bragging rights (or both).

In November 2022, we wrote about a multi-country takedown against a Cybercrime-as-a-Service (CaaS) system known as iSpoof.

Although iSpoof advertised openly for business on a non-darkweb site, reachable with a regular browser via a non-onion domain name, and even though using its services might technically have been legal in your country (if you’re a lawyer, we’d love to hear your opinion on that issue once you’ve seen the historical website screenshots below)…

…a UK court had no doubt that the iSpoof system was implemented with life-ruining, money-draining malfeasance in mind.

The site’s kingpin, Tejay Fletcher, 35, of London, was given a prison sentence of well over a decade to reflect that fact.

Show any number you like

Until November 2022, when the domain was taken down after a seizure warrant was issued to US law enforcement, the site’s main page looked something like this:

You can show any number you wish on call display, essentially faking your caller ID.

And an explanatory section further down the page made it pretty clear that the service wasn’t merely there to enhance your own privacy, but to help you mislead the people you were calling:

Get the ability to change what someone sees on their caller ID display when they receive a phone call from you. They’ll never know it was you! You can pick any number you want before you call. Your opposite will be thinking you’re someone else. It’s easy and works on every phone worldwide!

In case you were still in any doubt about how you could use iSpoof to help you rip off unsuspecting victims, here’s the site’s own marketing video, provided courtesy of the Metropolitan Police (better known as “the Met”) in London, UK:

As you will see below, and in our previous coverage of this story, iSpoof users weren’t actually anonymous at all.

More than 50,000 users of the service have been identified already, with close to 200 people already arrested and under investigation in the UK alone.

Pretend to be a bank…

Simply put, if you signed up for iSpoof’s service, no matter how technical or non-technical you were, you could immediately start placing calls that would show up on victims’ phones as if those calls were coming from a company that they already trusted.

As the Metropolitan Police put it:

Users of iSpoof, who had to pay to use its services, posed as representatives of banks including Barclays, Santander, HSBC, Lloyds and Halifax [well-known British banks], pretending to warn of suspicious activity on their accounts.

Scammers would encourage the unsuspecting members of the public to disclose security information such as one-time passcodes to obtain their money.

The total reported loss from those targeted via iSpoof is £48 million in the UK alone, with average loss believed to be £10,000. Because fraud is vastly under reported, the full amount is believed to be much higher.

In the 12 months until August 2022 around 10 million fraudulent calls were made globally via iSpoof, with around 3.5 million of those made in the UK.

Interestingly, the Met says that about 10% of those UK calls (about 350,000 in all), made to 200,000 different potential victims, lasted more than a minute, suggesting a surprisingly high success rate for scammers who used the iSpoof service to give their bogus calls a fraudulent air of legitimacy.

When calls arrive from a number you’re inclined to trust – for example, a number you use sufficiently often that you’ve added it into your own contact list so it comes up with an identifier of your choice, such as Credit Card Company, rather than something generic-looking such as +44.121.496.0149…

…you’re unsurprisingly more likely to trust the caller implicitly before you hear what they’ve got to say.

After all, the system that transmits away the caller’s number to the recipient before the call is even answered is known in the jargon as Caller ID, or Calling Line Identification (CLI) outside North America.

It’s not any sort of ID

Those magic words ID and identification shouldn’t really be there, because a technically savvy caller (or a completely non-technical caller who was using the iSpoof service) could insert any number they liked when initiating the call.

In other words, Caller ID not only tells you nothing about the person using the phone that’s calling you, but also tells you nothing trustworthy about the number of the phone that’s calling you.

Caller ID “identifies” the caller and the calling number no more reliably that the return address that’s printed on the back of a snail-mail envelope, or the Reply-To address that’s in the headers of any emails you receive.

All those “identifications” can be chosen by the originator of the communication, and can say pretty much anything that the sender or caller chooses.

They should really be called What the Caller Wants you to Think, Which Could Be a Pack of Lies, rather than being referred to as an ID or an identification.

And there was an awful lot of lying going on, thanks to iSpoof, with the Met claiming:

Before it was shut down in November 2022, iSpoof was constantly growing. 700 new users were registering with the site every week and it was earning on average £80,000 per week. At the point of closure it had 59,000 registered users.

The website offered a number of packages for users who would buy, in Bitcoin, the number of minutes they wanted to use the software for to make calls.

The site raked in loads of profit, according to the Met:

iSpoof made just over £3 million with Fletcher profiting around £1.7-£1.9 million from running and enabling fraudsters to ruin victim’s lives. He lived an extravagant lifestyle, owning a Range Rover worth £60,000 and a Lamborghini Urus worth £230,000. He regularly went on holiday, with trips to Jamaica, Malta and Turkey in 2022 alone.

Earlier in 2023, Fletcher pleaded guilty to the offences of making or supplying articles for use in fraud, encouraging or assisting the commission of an offence, possessing criminal property and transferring criminal property.

Last week he was given a prison sentence of 13 years and 4 months; 169 other people in the UK “have now been arrested on suspicion of using iSpoof [and] remain under police investigation.”

What to do?

• TIP 1. Treat Caller ID as nothing more than a hint.

The most important thing to remember (and to explain to any friends and family you think might be vulnerable to this sort of scam) is this: THE CALLER’S NUMBER THAT SHOWS UP ON YOUR PHONE BEFORE YOU ANSWER PROVES NOTHING.

• TIP 2. Always initiate official calls yourself, using a number you can trust.

If you genuinely need to contact an organisation such as your bank by phone, make sure that you initiate the call, and use a number than you worked out for yourself.

For example, look at a recent official bank statement, check the back of your bank card, or even visit a branch and ask a staff member face-to-face for the official number that you should call in future emergencies.

• TIP 3. Be there for vulnerable friends and family.

Make sure that friends and family whom you think could be vulnerable to being sweet-talked (or browbeaten, confused and intimidated) by scammers, no matter how they’re first contacted, know that they can and should turn to you for advice before agreeing to anything over the phone.

And if anyone asks them to do something that’s clearly an intrusion of their personal digital space, such as installing Teamviewer to let them onto the computer, reading out a secret access code off the screen, or telling them a personal identification number or password…

…make sure they know it’s OK simply to hang up without saying a single word further, and getting in touch with you to check the facts first.

Remember that zipped-lipped but super-fast update that Apple pushed out three weeks ago, on 2023-05-01?

That update was the very first in Apple’s newfangled Rapid Security Response process, whereby the company can push out critical patches for key system components without going through a full-size operating system update that takes you to a new version number.

As we pondered in the Naked Securirty podcast that week:

Apple have just introduced “Rapid Security Responses.” People are reporting that they take seconds to download and require one super-quick reboot. [But] as for being tight-lipped [about the update], they are zipped-lipped. Absolutely no information what it was about. But it was nice and quick!

Good for some

Unfortunately, these new Rapid Security Responses were only available for the very latest version of macOS (currently Ventura) and the latest iOS/iPadOS (currently on version 16), which left users of older Macs and iDevices, as well as owners of Apple Watches and Apple TVs, in the dark.

Apple’s description of the new rapid patches implied that they’d typically deal with zero-day bugs that affected core software such as the Safari browser, and WebKit, which is the web rendering engine that every browser is obliged to use on iPhones and iPads.

Technically, you could create an iPhone or iPad browser app that used the Chromium engine, as Chrome and Edge do, or the Gecko engine, as Mozilla’s browsers do, but Apple wouldn’t let it into the App Store if you did.

And because the App Store is the one-and-only “walled garden” source of apps for Apple’s mobile devices, that’s that: it’s the WebKit way, or no way.

The reason that critical WebKit bugs tend to be more dangerous than bugs in many other applications is that browsers quite intentionally spend their time fetching content from anywhere and everywhere on the internet.

Browsers then process these untrusted files, supplied remotely by other people’s web servers, convert them into viewable, clickable content, and display them as web pages you can interact with.

You expect that your browser will actively warn you, and explicitly request permission, before performing actions that are considered potentially dangerous, such as activating your webcam, reading in files already stored on your device, or installing new software.

But you also expect content that’s not considered directly dangerous, such as images to be displayed, videos to be shown, audio files to be played, and so on, to be processed and presented to you automatically.

Simply put, merely visiting a web page shouldn’t put you at risk of having malware implanted on your device, your data stolen, your passwords sniffed out, your digital life subjected to spyware, or any malfeasance of that sort.

Unless there’s a bug

Unless, of course, there’s a bug in WebKit (or perhaps several bugs that can be strategically combined), so that merely by preparing a deliberately booby-trapped image file, or video, or JavaScript popup, your browser could be tricked into doing something it shouldn’t.

If cybercriminals, or spyware sellers, or jailbreakers, or the security services of a government that doesn’t like you, or indeed anyone with your worst interests at heart, uncovers an exploitable bug of this sort, they may be able to compromise the cybersecurity of your entire device…

…simply by luring you to an otherwise innocent-looking website that ought to be perfectly safe to visit.

Well, Apple just followed up its latest Rapid Security Resonse patches with full-on updates for all its supported products, and inamongst the security bulletins for those patches, we’ve finally found out what those Rapid Responses were there to fix.

Two zero-days:

• CVE-2023-28204: WebKit. An out-of-bounds read was addressed with improved input validation. Processing web content may disclose sensitive information. Apple is aware of a report that this issue may have been actively exploited.
• CVE-2023-32373: WebKit. A use-after-free issue was addressed with improved memory management. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Generally speaking, when two zero-days of this sort show up at the same time in WebKit, it’s a good bet that they’ve been combined by criminals to create a two-step takeover attack.

Bugs that corrupt memory by overwriting data that shouldn’t be touched (e.g. CVE-2023-32373) are always bad, but modern operating systems include many runtime protections that aim to stop such bugs being exploited to take control of the buggy program.

For example, if the operating system randomly chooses where programs and data end up in memory, cybercriminals often can’t do much more than crash the vulnerable program, because they can’t predict how the code they’re attacking is laid out in memory.

But with precise information about what’s where, a crude, “crashtastic” exploit can sometimes be turned into a “crash-and-keep-control” exploit: what’s known by the self-descriptive name of a remote code execution hole.

Of course, bugs that let attackers read from memory locations that they’re not supposed (e.g. CVE-2023-28204) can not only lead directly to data leakage and data theft exploits, but also lead indirectly to “crash-and-keep-control” attacks, by revealing secrets about the memory layout inside a program and making it easier to take over.

Intriguingly, there’s a third zero-day patched in the latest updates, but this one apparently wasn’t fixed in the Rapid Security Response.

• CVE-2023-32409: WebKit. The issue was addressed with improved bounds checks. A remote attacker may be able to break out of Web Content sandbox. Apple is aware of a report that this issue may have been actively exploited.

As you can imagine, combining these three zero-days would be the equivalent of a home run to an attacker: the first bug reveals the secrets needed to exploit the second bug reliably, and the second bug allows code to be implanted to exploit the third…

…at which point, the attacker has not merely taken over the “walled garden” of your current web page, but grabbed control of your entire browser, or worse.

What to do?

Make sure you’re patched! (Go to Settings > General > Software Update.)

Even devices that already received a Rapid Security Response at the start of March 2023 have a zero-day still to be patched.

And all platforms have received many other security fixes for bugs that could be exploited for attacks as varied as: bypassing privacy preferences; accessing private data from the lockscreen; reading your location information without permission; spying on network traffic from other apps; and more.

After updating, you should see the following version numbers:

• watchOS: now at version 9.5
• tvOS: now at version 16.5
• iOS 15 and iPadOS 15: now at version 15.7.6
• iOS 16 and iPadOS 16: now at version 16.5
• macOS Big Sur: now at 11.7.7
• macOS Monterey: now at 12.6.6
• macOS Ventura: now at 13.4

Important note: if you have macOS Big Sur or macOS Monterey, those all-important WebKit patches aren’t bundled in with the operating system version update but are supplied in a separate update package called Safari 16.5.

Have fun!