Apple patches 87 security holes – from iPhones and Macs to Windows

The latest raft of non-emergency Apple security updates are out, patching a total of 87 different CVE-rated software bugs across all Apple products and plaforms.

There are 10 security bulletins for this bunch of updates, as follows:

  • APPLE-SA-2022-03-14-1: iOS 15.4 and iPadOS 15.4 (HT213182)
  • APPLE-SA-2022-03-14-2: watchOS 8.5 (HT213193)
  • APPLE-SA-2022-03-14-3: tvOS 15.4 (HT213186)
  • APPLE-SA-2022-03-14-4: macOS Monterey 12.3 (HT213183)
  • APPLE-SA-2022-03-14-5: macOS Big Sur 11.6.5 (HT213184)
  • APPLE-SA-2022-03-14-6: Security Update 2022-003 Catalina (HT213185)
  • APPLE-SA-2022-03-14-7: Xcode 13.3 (HT213189)
  • APPLE-SA-2022-03-14-8: Logic Pro X 10.7.3 (HT213190)
  • APPLE-SA-2022-03-14-9: GarageBand 10.4.6 (HT213191)
  • APPLE-SA-2022-03-14-10: iTunes 12.12.3 for Windows (HT213188)

The current and two previous versions of macOS (Monterey, Big Sur and Catalina) all get updates, but only the latest versions of Apple’s mobile device operating systems (iOS, iPadOS, watchOS and tvOS) are supported in this round of fixes.

Note that if you’re using macOS Catalina, you won’t see a new three-number operating system version after the update; you’ll just get Security Update 2022-003 instead.

What’s fixed?

With 87 noteworthy bugs in the mix, there are plenty of security issues to choose from, including several that are listed with a warning that the bug might “lead to arbitrary code execution”, or even that it might be exploitable “to execute arbitrary code with kernel privileges”.

Three remote code execution bugs are listed in WebKit, the HTML rendering code that underlies all of Apple’s own web browsing code, including Safari, and that underlies all web browsing on App Store programs.

For App Store software, WebKit is not merely a de facto choice for Apple’s code but a de iure browser requirement for everyone, even Microsoft, Google and Mozilla: if you use your own HTML rendering engine instead of WebKit, your app will be rejected.

Those WebKit bugs are covered by four bug numbers (CVE-2022-22610, CVE-2022-22624, CVE-2022-22628 and CVE-2022-22629), found and responsibly disclosed by three different researchers from three different external companies.

They’re all described as flaws where “processing maliciously crafted web content may lead to code execution”, which means that simply looking at a web page, without clicking any links, using any menus, or approving any download actions, might be enough to implant malware on your computer or your phone.

There’s a similar and equally alarming set of bugs (including CVE-2022-22633, CVE-2022-22634, CVE-2022-22635 and CVE-2022-22636) in the document, audio and video viewing components on iPhones and iPads.

Those security holes could variously allow malware implantation (including with kernel privileges) or elevation of privilege, simply by presenting you with maliciously crafted PDFs or booby-trapped videos to look at.

Remember that a non-kernel code execution bug on a device such as an iPhone typically restricts the attacker to fossicking around in the data of the app that triggered the bug.

So, app-level compromise is often dangerous enough in its own right, but not as dramatically dangerous as a root-level or kernel-level compromise that lets one app snoop on all the others.

But if a moderately dangerous remote code execution bug, or RCE, is combined with an EoP, short for elevation-of-privilege exploit, then the attacker’s remotely triggered malware code may be able not only to get in, but also to move around on your device.

A two-pronged attack that takes and RCE-plus-EoP approach can therefore often evade the “each-app-is-cloistered-in-its-own-little-world” sandbox protection usually imposed by the operating system.

Information leakage

There were also numerous information leakage bugs found and fixed.

Some of these aren’t truly dangerous on their own, but are nevertheless a reminder that apps (including, as we’ve often reported before, the Lock Screen app!) may nevertheless not live up to the security promises you expect they’ll keep.

Examples include

  • A FaceTime bug where you could end up sharing audio and video without realising (CVE-2022-22643).
  • A MediaRemote bug (CVE-2022-22670) that could let rogue apps figure out what other software you’ve already installed.
  • A Preferences flaw (CVE-2022-22609) by which an attacker could recover the security settings you’ve chosen for other apps.
  • An ironic Sandbox security hole that could violate your privacy by leaking the privacy settings you’ve chosen for various apps (CVE-2022-22600).
  • A sneaky pair of bugs in the macOS Login Window (CVE-2022-22647 and CVE-2022-22656) that could let someone see what your screen looked like just before you logged out, or even let them bypass the login window and get in directly as you.

Windows, too

Note that there’s also an update for iTunes on Windows (for Windows 10 and later).

This update closes a number of remote code execution bugs, including not only the abovementioned WebKit holes, but also various related image-handling bugs that could allow a booby-trapped file to take over your computer even if all you did was look at it.

What to do?

Here’s how to check for and get the updates 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…
  • On Windows: iTunes > Help > Check for Updates (if you installed iTunes from the Microsoft Store, use Microsoft Store > Library > Get updates instead)

Don’t delay. Do it today!

The version numbers (or the designations of the installed security updates) that you should look for after you’ve updated are listed at the top of the article.


Happy #PiDay – even if you aren’t in North America!

As almost everyone who doesn’t live in North America knows…

…American dates are weird!

Those of us who care about these things use YYYY-MM-DD, because writing 2022-03-14 is undoubtedly the easiest way of avoiding ambiguity in dates, given that the four-digit part is obviously the year, and everyone who writes the year at the start inevitably follows it with the month and then the day.

No one who would deliberately lead off with the year would ever dare to use the format YYYY-DD-MM, because that would be absurd: putting the year first means the years sort textually and tidily into chronological order, so it wouldn’t make sense to ruin that handy feature by using anything other than YYYY-MM-DD to make the entire date field sort alphabetically.

And no one, truly no one, would ever use just two digits for the year, given the palaver that beset us around Y2K, so you can rule out YY-MM-DD without further thought.

When we say dates out loud , however, we usually say the year at the end (or casually leave the listener to infer that we mean whatever-year-we-are-in-right-now, or possibly the one just past or just about to arrive, assuming we’re close to the start of January or near the end of December).

As a result, many countries, sadly incuding the UK, still routinely use DD/MM/YYYY for dates, and then rather casually tolerate DD/MM/YY as well, as though the millennium bug had never been a thing.

And a few countries – you know who you are, and you know that this habit of yours is odder than ounces (fluid or avoirdupois), madder than miles, and clumsier even than cubic inches! – stick resolutely to MM/DD/YY, so that everything about their dates is confusing and ambiguous.

The happy side of MM/DD/YY

But one delightful thing that you do get from this peculiar transatlantic habit is that the 14th day of March in any year gets shortened to 3/14, and if you imagine that slash as if it were a decimal separator and not a division sign…

…you get PI DAY!

Today is Pi Day because 3.14 is pretty jolly close to the value of Pi, which is a very handy number indeed.

Pi tells you how exactly much longer it is to walk all the way around a circle than simply walking across it – this comes in handy when building wheels, designing gears, or turning this way and that at a consistent rate.

What’s in a name?

Why the letter π, which is a lower-case P in Greek, you wonder?

Wouldn’t c (or C), short for circumference, be a more obvious English abbreviation? (Back when the abbreviation π came in, during the early 1700s, we knew that light had a finite speed, but c was first used to denote the speed of light only in the late 1800s, so we didn’t then need c for that purpose.)

Apparently, π is simply short for perimeter, an English word that was adopted from the Greek περίμετρος, and which conveniently therefore starts with π in Greek and the equivalent p in English.

If you’re interested, the quickest way to “know” Pi to seven significant digits is in the form 355/113, which comes out at 3.14159290 (and a bit), a mere 0.0000085% higher than the more precise 3.14159265 (and a bit).

If you went to primary school before calculators came out, you probably learned 22/7 (a handy Commonwealth alternative for celebrating Pi day, being the 22nd of July), which gives you 3.14285714, too high by just 0.04%.

Why not 3, or 4, or something more “natural”?

But why does Pi come out at close to 3.14, instead of, say, 3, or 4, or something easier to remember and more natural, in the mathematical sense of a whole number?

The simple answer is the unexplanatory, pop-psychology-sounding remark that “the value of Pi is what it is”.

Of course, you can get a quick idea of why Pi is a fair bit less than 4, and probably a touch bigger than 3, simply by imagining how long it would take you to walk round a square field that measures one {mile, furlong, hectometer, football field, whatever unit you like} along each side…

…compared to walking around a circle that passes just outside that square, or around a circle that passes just inside it.

Here’s a diagram of what we mean.

We want to compare the distance round the blue circle, denoted P below, to the distance around the red outer square (which is obviously longer than P), and to the distance around the green inner square (clearly shorter than P).

As you can see, the perimeter of the outer square is just four times the length of each side; so the perimeter is 4.

So the περίμετρος of the circle – its circumference, to use the Latin word, or π to abbreviate the Greek one – must be less than 4.

And the length of each side of the inner square – to work this out for yourself, you can use Pythogoras’s theorem, as shown above – is 1/√2, which is slightly more than 7/10, or 0.707106781 (and-a-bit), in fact, so its perimeter is slightly more than 2.8.

From that alone, therefore, we know that 2.8 < π < 4, which narrows things down a bit already…

…and by using polygons with more and more sides in our diagram, rather than squares, we could produce better and better approximations of non-curved figures that home in more and more closely on π from above and below, corralling it into an ever-narrower range of possible values.

You never get there

As you probably know, however, π is an irrational number – which means not that it is crazy or weird, but simply that it can’t be written as a ratio, in the way that we can exactly represent 0.142857142857 recurring as 1/7, or 0.2 as 2/10, or 1/5 in its simplest form.

Of course, even though we can never print out a complete decimal expansion of π, that hasn’t stopped computer scientists from seeing how far they can get.

The current record is close to 63 trillion decimal digits, which took Swiss academics more than 100 days on a “computer” (we are using the word very loosely here!) that was apparently equipped with 1024 gigabytes of RAM and more than 600,000 gigabytes of disk space.

In case you’re wondering, the exact number of digits computed was 62,831,853,071,796.

If that number looks kind of familiar, try dividing it by 2, which gives you 31,415,926,535,898.

Look familiar?

Happy #PiDay!

PS. The cybersecurity connection here is this: never assume that apparently impracticable or difficult calculations, whether that’s churning out Pi to ever more decimal places, or cracking passwords and cryptographic codes, will retain their difficulty forever. Computation speeds only ever get faster. Memory size only ever increases. Disk space only ever goes up.


Cryptocoin ATMs ruled illegal – “Shut down at once”, says regulator

Ever wanted or needed to buy or sell cryptocoins on a whim, without going online?

Ever felt like cashing in 100,000 Satoshis or so at 3am to treat your party buddies to a kebab-fest on the way home from a big night out?

Well, if you live in the UK, you can’t easily do any of those things any more.

Last Friday, the UK’s FCA, short for Financial Conduct Authority, published an official bulletin entitled: Warning on illegal crypto ATMs operating in the UK.

You might think that would leave a bunch of legal ATMs online, but the FCA says that there are, in fact, no correctly registered cryptocurrency ATMs anywhere in the country, and thus that they must all shut down at once, or else:

Crypto ATMs offering cryptoasset exchange services in the UK must be registered with [the FCA] and comply with UK Money Laundering Regulations (MLR). None of the cryptoasset firms registered with us have been approved to offer crypto ATM services, meaning that any of them operating in the UK are doing so illegally and consumers should not be using them.

“Unregulated and high-risk”

It’s not clear whether the primary concern of the FCA is specifially that unscrupulous operators could make it easy for criminals to cash out significant cryptocurrency payments untraceably.

After all, if you’re buying or selling cryptocoins via an existing payment card account or mobile phone payment system, from an ATM in a shopping centre, you’d think that the operation would be at least as trackable as any transaction involving a non-cryptocurrency account, such as a big-money purchase in a department store or luxury brand shop.

The FCA does, however, seem concerned that these devices could make it easier for vulnerable individuals to get suckered into cryptocurrency scams, by lowering the barrier of entry to acquiring cryptocoins in the first place:

We are concerned about crypto ATM machines operating in the UK and will therefore be contacting the operators instructing that the machines be shut down or face further action.

Since we published the list of unregistered crypto firms that may have been continuing to conduct business, a recent assessment found that 110 are no longer operational.

We regularly warn consumers that cryptoassets are unregulated and high-risk which means people are very unlikely to have any protection if things go wrong, so people should be prepared to lose all their money if they choose to invest in them.

Whereas online cryptocoin exchanges can demand some sort of document-based signup process, such as requiring new purchasers to upload scans of personal identification first (we’re not going to discuss the pros and cons of that approach here, merely to mention it), it’s hard to see how a cryptocoin ATM conveniently placed in a local shopping centre could usefully conduct much of a “know your customer” process up front.

The cryptocoin ATM could snap a photo of you in front of the machine, of course, and no doubt does so for its own sake anyway, but rules are rules, and regulations are regulations, and whatever hoops a registered ATM operator in the UK needs to jump through to ensure they are licensed correctly…

…it seems that no one has yet jumped those hoops correctly.

According to the BBC, there were fewer than 100 cryptcoin ATMs operating in Britain last week anyway, but we’re guessing that the number is zero now.

Here’s the closest device to Sophos HQ that we’re aware of (we made a quick trip to check its status during our lunchbreak); you can see that this one is still powered up, but dutifully spurning customers:


Alleged Kaseya ransomware attacker arrives in Texas for trial

In cybersecurity history, the US Independence Day weekend of 2021 is not remembered for the restful and relaxing summer celebrations that you’d usually associate with the Fourth of July.

Instead, it’s remembered as the weekend of the infamous Kaseya ransomware attack.

This was ransomware-with-a-difference, and the difference was the ultimate scale of the attack and the size of the side-effects.

In a typical attack against company X, vital files and data on X’s network get scrambled by the cybercriminals, disrupting X’s computer systems – often including laptops, servers and network services alike – and bringing business operations to a crushing halt.

Then comes a blackmail demand for Y dollars in Bitcoin, where Y is often in the hundreds-of-thousands range, and sometimes in the millions: “Give us the money and we’ll get your data back for you.”

Paying up gets you nothing more than a promise

Of course, the criminals don’t actually do the time-consuming work of recovering the files they just encrypted (and even if they offered to put in the hard yards for you, you almost certainly wouldn’t want them back onto your network anyway).

The huge sum you’re paying doesn’t actually get your data back – it just offers you a promise of recovering it, by supplying the passwords needed to unscramble your ruined files.

That’s why the Sophos 2020 State of Ransomware Survey told us that the median cost of recovering from a ransomware attack amongst companies that had their own backups, and didn’t need to pay extortion money to the crooks, was close to $750,000…

…while the median cost for those who had no choice but to pay up (or perhaps who thought that paying the crooks would somehow short-circuit the traditional complexity of disaster recovery) was almost exactly twice as much, at just under $1,500,000.

You’re paying the ransom merely for the hope of recovering data you might otherwise have lost forever, not for actually finalising the process of recovering it.

Another vital, and yet more depressing, statistic to remember comes from the Sophos 2021 Ransomware report, where our survey found that about 1/3 of respondents got hit, and about 1/3 ended up having to pay money to the crooks.

(Thanks to the 2020 data, of course, victims would know in advance that paying up would almost certainly be more expensive, so we’re assuming they simply had no choice, faced with the dilemma of, “Do a deal with the devil, or watch the whole business implode and cost everyone their jobs”.)

Here, we found that, of those who paid to get decryption passwords, half of them lost at least a third of their data anyway.

Even more dramatically, one third of them lost at least half of their data, and a doubly-damaged 4% of respondents paid up and recovered nothing at all – nil, zilch, nada, not a single sausage:

Kaseya’s megaransom

Unfortunately, the Kaseya incident didn’t follow the usual pattern we described above, where company X gets attacked, company X’s files get scrambled, and company X gets blackmailed.

Kaseya makes and sells IT management tools that can, amongst other things, distribute software updates.

The cybercriminals in this case used Kaseya’s software in what’s known as a supply-chain attack.

In other words, the crooks used Kaseya’s infrastructure to disseminate and detonate ransomware infections on Kaseya’s customers’ computers, combining two security weaknesses to spread their malware much more widely than if they had attacked Kaseya alone.

The first security hole was CVE-2021-30116, a previously unknown bug that allowed an attacker without a password to access Kaseya’s system administration tools and inject unauthorised programs into the next update bundle pushed out to clients. The second security hole was that the criminals deliberately installed their malicious “update” into a special directory on those clients that was deliberately designated by Kaseya as exempt from local malware scanning. As a result, victims unknowingly downloaded tainted “updates” from Kaseya, and then unknowingly installed malware on their own computers in a location where their existing security software had been instructed not to look.

Ultimately, it seems as though the criminals ended up being too successful, with so many victims were affected that the attackers apparently decided that it wasn’t worth trying to blackmail them one-by-one.

As we said at the time:

In the end, it almost felt as though the gang behind the Kaseya infiltration succeeed too well, drawing concerted attention in the aftermath of the attack.

Indeed, the crooks decided to go all-in by offering a “one size fits all” decryptor – a sort of global site licence, if you like; an all-you-can-eat file unscrambling buffet – for a one-off collective payment.

The plan might even have worked, if the criminals hadn’t set the fee at a jaw-dropping $70,000,000, though whether they seriously hoped to get paid in full, or simply wanted to rub the world’s noses in the mess, we may never know.

Alleged perpetrators identified

In this case, the wheels of justice started turning both quickly and effectively.

In November 2021, the US Department of Justice (DOJ) announced that it had seized more than $6 million in assets from a still-at-large Russian suspect called Yevgeniy Polyanin, and that Polish authorities had arrested a Ukrainian suspect called Yaroslav Vasinskyi when he crossed the border into Poland:

Poland has an extradition treaty with the US, and Vasinskyi has now been sent to Texas, where he has made his first appearance in a US court, accused of being responsible for the Kaseya attack:

In the alleged attack against Kaseya, Vasinskyi caused the deployment of malicious Sodinokibi/REvil code throughout [sic] a Kaseya product that caused the Kaseya production functionality to deploy REvil ransomware to “endpoints” on Kaseya customer networks. After the remote access to Kaseya endpoints was established, the ransomware was executed on those computers, which resulted in the encryption of data on computers of organizations around the world that used Kaseya software.

Through the deployment of Sodinokibi/REvil ransomware, the defendant allegedly left electronic notes in the form of a text file on the victims’ computers. The notes included a web address leading to an open-source privacy network known as Tor, as well as the link to a publicly accessible website address the victims could visit to recover their files. Upon visiting either website, victims were given a ransom demand and provided a virtual currency address to use to pay the ransom. If a victim paid the ransom, the defendant provided the decryption key and the victim then was able to access their files. If a victim did not pay the ransom, the defendant typically posted the victim’s stolen data or claimed they sold the stolen data to third parties, and victims remained unable to access their files.

Vasinskyi is charged with conspiracy to commit fraud and related activity in connection with computers, damage to protected computers, and conspiracy to commit money laundering.

As the DOJ points out, following common practice in its press releases, the maximum theoretical penalty that the accused faces is an absurd 115 years in prison, though, in reality, maximum sentences are rarely imposed.



S3 Ep73: Ransomware with a difference, dirty Linux pipes, and much more [Podcast]

LISTEN NOW

What do ransomware blackmailers ask for when they don’t want money? Why did Firefox get two updates in three days? How did Adafruit get hoist by the petard of “shadow IT”? And what’s with those dirty Linux pipes?

Register for the cyberinsurance event mentioned in the podcast:
https://events.sophos.com/cyberinsurance

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

With Paul Ducklin and Chester Wisniewski.

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.


go top