Perpetual IT

Apple has just sent out two security advisories covering two zero-day security holes, namely:

• Apple Bulletin HT213219: Kernel code execution bug CVE-2022-22675. This update is for iOS and iPadOS, both of which go to version 15.4.1.
• Apple Bulletin HT213220: Kernel code execution bug CVE-2022-22675 and kernel data leakage bug CVE-2022-22674. This update is for macOS Monterey, which goes to version 12.3.1.

No earlier versions of iOS, iPadOS or macOS seem to be affected by these bugs – or, more precisely, no updates for older versions have been published yet.

Apple, as ever, isn’t saying anything about the platforms that didn’t get updates, so it’s impossible to say whether they’re immune and thus unaffected, affected but simply being ignored, or affected and still awaiting updates that will show up in a few days. (The last of these does happen from time to time.)

Intriguingly, Apple’s core Security Updates page at HT201222 reports that there are updates denoted tvOS 15.4.1 and watchOS 8.5.1, but Apple merely remarks that these updates have “no published CVE entries”.

There’s no detail about what types of security flaw, if any, were addressed in the Apple Watch and Apple TV patches, so we can’t tell you whether these updates have any common ground with the zero-day fixes for Apple’s phones, tablets, laptops and desktop computers.

Jailbreaking and spyware a possibility

Ominously, given the world’s collective fear of cyberattacks and global hacking right now, each of the CVE-numbered bugs mentioned above is accompanied by Apple’s vague-as-usual wording that says, “Apple is aware of a report that this issue may have been actively exploited.”

In one word, that means: Zero-day!

A zero-day, of course, is a security hole that the Bad Guys not only found first, but also figured out how to exploit before any patches were available. (In oither words, there were zero days you could have been patched ahead of the exploit, even if you were the world’s most proactive patcher.)

Also, as we’ve pointed out before, kernel code execution flaws – where an unauthorised app or chunk of injected code doesn’t just take over a single application, but potentially gets unsandboxed access to the entire running system – are the most broadly dangerous sort of bug on iPhones and iPads.

Apple’s mobile devices are locked down much more tightly by default than computers running macOS, and while you can increase security on macOS, you aren’t supposed to be able to reduce security on iOS and iPadOS to bypass those default restrictions.

So, malware that gets unauthorised access to a single iPhone or iPad app might be able to run off with important personal data specific to that app – all your photos, perhaps, or your text message history – but isn’t supposed to be able to mess with any other apps or data on the device.

But malware with kernel control pretty much has access-all-areas privileges, meaning that it could be used for a total jailbreak (the jargon term for bypassing Apple’s strict security controls).

Likewise, kernel code execution bugs could be used for general-purpose spyware that could peek into, and perhaps even manipulate, all aspects of your digital life, including location data, IMs and text messages, emails, browsing history, contacts, phone records, photos, and much more.

What to do?

Patch early, patch often!

Most Apple users go for automatic updating, but that doesn’t mean you automatically get the update right away.

Apple understandably spreads out the delivery of its updates to prevent every Apple device in the world trying to update at exactly the same moment, which would clog up the process and slow things down, on average, for everyone.

So, even if you have automatic updating turned on, check for yourself anyway, and jump to the head of the queue if you haven’t received the update yet!

Here’s how to check your update status, and get the updates right away if you don’t have them already:

• On your iPhone or iPad: Settings > General > Software Update
• On your Mac: Apple menu > About this Mac > Software Update…

Take care out there!

Yesterday, we wrote about a bug in the VMware Spring product, a project we described as “an open-source Java toolkit for building powerful Java apps, including cloud-based apps, without needing to write, manage, worry about, or even understand the ‘server’ part of the process yourself.”

But Spring is a huge project, with a vast number of components, so talking about “a vulnerability in Spring” is a bit like saying “I think there’s a bug in Windows”, or “I hope I don’t catch the Sickness disease”.

So, to make things a bit clearer, the bug we looked at yesterday is officially designated CVE-2022-22963, and its semi-official long name is Remote code execution in Spring Cloud Function by malicious Spring Expression

You might also see it referred to as Spring Expression Resource Access Vulnerability, sometimes written as SPEL Vulnerability“. (SPEL, also written SpEL, is itself short for “Spring Expression Language”, which is the technology abused when this bug is exploited.)

The CVE-2022-22963 bug exists in a Spring component called Spring Cloud Function, which is an optional module that you can use inside the Spring ecosystem to write your Spring code in what’s known as a functional style, where you strip back the code needed for data processing to a minimum.

For example, if you want a web service to convert a SKU into a product name, a functional approach would let you program that as a simple function that took the SKU as an input, returned the name as an output, and didn’t need to concern itself with any of the surrounding details of how to receive the input, or how to return the result to the caller.

Unfortunately, by adding a special HTTP header to the request sent into the Spring Cloud Function module (the very code that saved you from writing code to process the request!), an attacker could trick the server into running a program of their choice.

This sort of vulnerability is known as Remote Code Execution (RCE), which is a jargon term that means just what is says: someone from the outside, perhaps even on the other side of the world, can trick your computer into running a program of their choice, without the usual warnings or popups you would expect before inviting untrusted code into your network.

RCEs are always a serious issue, even if they’re hard to exploit or rely on a non-default configuration of the service being attacked.

After all, the ability to force someone else to run code they didn’t choose themselves often means that an attacker could quietly implant malware without needing to figure out a way to login first.

Worse still, proof-of-concept (PoC) exploits showing how to abuse CVE-2022-22963 are readily available online, so that wannabe cybercriminals can simply copy-and-paste existing code to get started with an attack.

Fortunately, patching against the CVE-2022-22963 bug is easy: if you use the Spring Cloud Function module anywhere in your Spring-based ecosystem, upgrade to version 3.1.7 or 3.2.3, depending on which of the two officially supported branches of Spring Cloud Function you have.

For official information, see the Spring team’s CVE Report and its own vulnerability assessment.

There’s not just one bug… there are two of them

Unfortunately, there’s another Spring-based vulnerability in the news at the same time.

The second bug can also lead to remote code execution, so it could also be a vector for attackers to implant malware onto unpatched servers, but the bug is in a different part of the Spring code, and patching against the Spring Cloud Function hole won’t stop this one.

This other bug is officially CVE-2022-22965, and some cybersecurity wags have confusingly (and regrettably, in our opinion) dubbed this one “Spring4Shell”, presumably trying to hype up the story by connecting it to the infamous Log4Shell vulnerability of late last year.

Given that we already have several names for the bug we discussed at the top of this article, and given that these two bugs have hit the news at the same time, there’s a lot of confusion just from having two bugs to talk about…

…and that confusion hasn’t been helped by the name “Spring4Shell”, which suggests some sort of technical connection with Log4J, the Java product that gave us the bug dubbed Log4Shell, even though Log4J and Spring are completely different and unrelated software projects.

Furthermore, in the jargon, any rogue code that’s deliberately injected during an RCE exploit is generically known as “shellcode”.

Similarly, using RCE to run an arbitrary program on someone else’s computer is generically known as “getting a shell”, because a shell, in Unix terminology, is a general-purpose command-line program specifically designed to help you run any other programs you like, and even to create scripts or batch files that are programs in their own right.

In other words, adding the moniker “Shell” to any vulnerability name – as, indeed, we saw during the Log4Shell saga – is likely to cause unnecessary confusion.

Anyway, the CVE-2022-22965 vulnerability is found in the Spring Framework product, and the good news is that it, too, has been patched.

Patching this hole means upgrading to Spring Framework 5.2.20 or 5.3.18. (There are two parallel tracks of the product, a 5.2 and a 5.3 flavour; update to the latest release of the variant you’re using.)

According to the Spring team, there’s also a Spring product bundle known as Spring Boot, which includes the Spring Framework component; the team has therefore also published updated Spring Boot versions numbered 2.5.12 and 2.6.6 that include the updated Spring Framework patches.

What to do?

Here’s what we recommend, for reasons both of cybersecurity and of clarity:

• When referring to either or both of these bugs, always include the CVE bug numbers. The whole idea of CVE bug identifiers is that they are unique, and, being semi-randomly assigned strings of digits, don’t bring any confusing linguistic baggage into the discussion.
• When referring to these bugs, also refer explicitly to Spring Cloud Function or Spring Framework as appropriate. Those are the names of the components you need to update, and the names you will find in VMWare Spring‘s own security advisories, so they add a touch of plain-English clarity rather than sowing extra confusion.
• Try to avoid the name “Spring4Shell” if you can. If you must state this name, as we have rather obviously needed to do here, be sure to include it for information purposes, rather than using it as a reference name for the bug. We’ve already seen both bugs referred to by this confusing-in-its-own-right name. Yes, the name is catchy, but it’s leading to misinformation we could do without.
• Patch early, patch often! Even if you think the risk of these bugs to your specific Spring setup is small, the excitement around these bugs is high right now, so why be behind when you could be ahead?

In summary, and to help you find definitive update information from the Spring team:

• CVE-2022-22963: Remote code execution in Spring Cloud Function by malicious Spring Expression. Upgrade Spring Cloud Function to version 3.1.6 or 3.2.2.
• CVE-2022-22965: Spring Framework RCE via Data Binding on JDK 9+. Upgrade Spring Framework to version 5.2.20 or 5.3.18.
• Spring Boot package. Upgrading to Spring Boot version 2.5.12 or 2.6.6 is a convenient way of getting the latest Spring Framework module, which is bundled into the latest Spring Boot package.

LISTEN NOW

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

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

VMware Spring is a open-source Java toolkit for building powerful Java apps, including cloud-based apps, without needing to write, manage, worry about, or even understand the “server” part of the process yourself.

If you’ve heard the term serveless computing, then this is the sort of programming environment it refers to: the overall system isn’t serverless (no client-server or cloud solution could be, after all), but the programmers responsible for the data processing code can pretend that there aren’t any servers when designing and coding their apps.

Simply put, you let the surrounding ecosystem do the server-centric stuff of accepting network traffic, setting up TLS connewctions, parsing HTTP requests, extracting input headers and data, deciding who’s asking for what from whom, calling the right “serverless code” (that’s where you come in!), packaging up the results, and sending them back over the network to the initiator of the request.

You write the code that receives inputs and computes results from it, without needing to worry whether the input originated locally, arrived via your own LAN, or came in over the internet.

You don’t need to worry about, or even care, what sort of server your code is running on: it could be a server of your own, set up and managed by your colleagues in IT; or a cloud instance hosted and executing on a popular cloud service provider; or both.

Spring Cloud Function

Part of the Spring ecosystem is a set of components called Spring Cloud by wich you can hook Spring code straight into well-known cloud services from Alibaba, Amazon, Azure, Netflix and many more.

And there’s a subcomponent in Spring Cloud called Spring Cloud Function that lets you do so-called “functional” serveless programming, where you write the Java functions that get called when specific web requests come in, without worrying how the surrounding Spring system figured out that your function was the right one to call.

Unfortunately, there is a dangerous bug dubbed CVE-2022-22963, also known as the Spring Expression Resource Access Vulnerability, in the Spring Cloud Function component.

If the person calling your Java function via the web (to look up a username in a database, for example, or to check if a specific SKU is in stock) inserts a specific HTTP header into their web request, and if that header contains Spring code structured in the right way…

…then the code in that header gets executed on the server, right inside the Spring Cloud server world.

In other words, unauthenticated, uncomplicated remote code execution (RCE).

The code that an attacker could abuse in this way uses a feature called Spring Expression Language, or SpEL for short, so you will also see this bug referred to as the SPEL vulnerability.

PoCs available

Proof-of-concept (PoC) code is already readily available on the internet showing how to inject unauthorised Java code into inbound Spring Cloud Function requests, and how to use that code to run an unwanted program.

The PoCs we’ve seen so far have all simply popped up a calculator app, that being more than enough to prove the point, but it looks as though any command already installed on the server could easily be launched.

This includes remotely triggering web downloader programs such as curl, launching command shells such as bash, or indeed doing both of those in sequence as a way of quietly and quickly implanting malware.

What to do?

If you use the Spring Cloud Function module in any of your services, update immediately to version 3.1.7 or 3.2.3, depending on whether you have the 3.1 or the 3,2 flavour of the module.

Note that VMware’s official advisory for this bug states that Spring Cloud Function modules below version 3 are affected, but are no longer supported; you will therefore need to switch to one of the version 3 flavours to get the needed patch.

If you use Spring in your business but someone else hosts and delivers the Spring Cloud framework for you, please check with them to find out if they’ve patched.

Tomorrow is 31 March 2022, and the last day of March is World Backup Day…

…which is a good time for us to remind you of a little saying that we like.

You’ll have heard it before if you listen to the Naked Security Podcast; if so, here it is again, because it’s advice that never gets old:

The only backup you will ever regret is the one you didn’t make.

Try saying that out loud to yourself every time you find yourself thinking, “Should I make a copy of my (thesis, source code, tax documentation, visa application, mortgage files, insurance claim, job offer) now, or should I leave it until (tomorrow, the weekend, year-end, never)?”

The good news about backups seems to be that more and more companies are taking the matter seriously, and not only making backups that remain intact after disaster strikes, but also recovering succesfully when needed.

We’re saying that because, in our State of Ransomware 2021 Survey, 57% of companies who had the misfortune to get hit by ransomware (about one-third of those who responded) were able to recover their data and get their business running again via their backups.

The bad news about backups, however, is that we still had 32% of ransomware respondents who were stuck with paying the criminals instead, which not only increased the cost of getting their business on its feet again, but didn’t work reliably anyway.

One-third of those in our survey who paid the ransom nevertheless ended up losing more than half their data, because even crooks who claim to “specialise” in ransomware and extortion don’t seem to know how to get the restoration part of the process right. A backup that you can’t reliably restore on demand isn’t a backup. It isn’t even a talisman. It gives you nothing but a false sense of security.

What about the rest of us?

So, what about home users, hobbyists and small businesses?

If even big companies with IT departments, sysadmins and security operations teams have trouble doing backups correctly, what hope do the rest of us have?

The good news is that useful backups don’t have to consume a lot of time and money.

Even if you don’t regularly backup every data file you’ve ever created…

…you can still give yourself reasonable security against a total data disaster by identifying the most important files you have, and making a point of looking after them well.

Losing your wedding photos or that video of your daughter’s first steps would be disappointing, but it wouldn’t stop you getting on with your digital life.

But losing data such as scans of your ID documents, which might be vital in getting back into compromised accounts, or taxation files that you’re obliged by law to keep for so many years, could land you in trouble.

So here are our tips for home users and small businesses for World Backup Day:

1. DECIDE WHICH DATA IS CRITICAL, AND PROTECT IT PROPERLY

It’s OK to decide that you aren’t going to back up everything all the time, but you should make a list of the data you need to keep safe, and a rota that lets you keep track of when you last backed it up. If you have a process you use to ensure you pay the household bills regularly, use that system to keep on top of your backups, too. You don’t need a high-tech system: even just adding a visible weekly check-box to the calendar in your kitchen wall is a good way to do it.

2. REMEMBER THE 3-2-1 PRINCIPLE

The 3-2-1 rule suggests having at least three copies of your data, including the master copy; using two different types of backup, so that if one fails, it’s less likely the other will be similarly affected; and keeping one of them offline, and preferably offsite, so you can get at it even if you’re locked out of your home or office.

3. DON’T LEAVE BACKUPS WHERE CYBERCROOKS CAN FIND THEM

Many people keep backups so they are always online, such as in a live cloud storage account or on a network-attached storage (NAS) device. But if your backups are accessible online, they’re also accessible to any crooks who compromise your account or your network. Indeed, ransomware crooks make a point of searching for online backups and wiping them out as part of the attack, hoping to force you into paying up.

Remember the 3-2-1 rule: think of online snapshots and real-time backups as just one of the two backup types you keep, and make sure you always have at least one other backup that’s offline. Whether you’re at home or at work, remember to unplug offline backup devices and put them somewhere safe unless you are in the process of backing up or restoring, and remember to logout explicitly from cloud backup accounts when you aren’t using them.

4. DON’T MAKE BACKUPS THAT EVERYONE CAN READ

Encrypt your backups so that if they’re lost or stolen, the thief can’t simply read out all your precious data for themselves. Windows has BitLocker, Macs have FileVault, and Linux has LUKS and cryptsetup, which can be used to create encrypted drives and partitions.

There are also numerous archiving tools, some free and open source, that can create encrypted backup files, such as WinZip and 7-Zip.

Note that FileVault and BitLocker are proprietary to Apple and Microsoft respectively, so you will need a matching operating system setup to restore your data. Also, BitLocker for removable drives isn’t available on home-user Windows versions. You’ll need to upgrade to Windows Pro for that.

5. LEARN HOW TO DO THE “RESTORE” PART OF THE PROCESS

We’ve helped numerous people over the years who made backups regularly and carefully, but weren’t able to get back the files they wanted when they needed to.

Ironically, none of these cases happened because the user forgot or lost their decryption password – they simply weren’t well-practised enough in using the restore process to do it reliably, or even at all. Don’t be one of those people!

BONUS TIP. DON’T PUT IT OFF UNTIL TOMORROW

We’ll finish as we started: The only backup you will ever regret is the one you didn’t make.

We published this article on the afternoon before World Backup Day specifically so you could get a backup done the night before!