Perpetual IT

Microsoft’s Patch Tuesday announcement was bad enough, with six in-the-wild vulnerabilities patched, including one buried in the vestiges of Internet Explorer’s MSHTML web rendering code…

…and it’s been followed by Google’s latest Chrome security advisory, which includes a zero-day patch (CVE-2021-30551) to Chrome’s JavaScript engine amongst its 14 officially listed security fixes.

Like Mozilla, Google also lumps together other potential bugs it has found using generic bug-hunting techniques, listed as “Various fixes from internal audits, fuzzing and other initiatives.”

Fuzzing, in case you aren’t familiar with the concept, is an automated technique that probes for bugs by repeatedly confronting the software under test with input that has deliberately been modified to see whether the program chokes on it.

For example, a fuzzer might start with a known-good input file that you would expect to be processed correctly, without triggering any bugs, and progressively make a series of unusual or otherwise unlikely changes in the file, thus testing a program’s error-checking code much more broadly and deeply than hand-crafted files could manage.

Imagine that you had a compressed archive file, for instance, and you wanted to see how safely your decompression code would behave if the file were corrupted during a download, such as if a line-break character were accidentally inserted at some point.

With a fuzzer you could not only test for line-breaks at some points in the file, but at every possible point – and, better yet, you wouldn’t need to store all these slightly-modified input files for later, because you could automatically regenerate them on the fly every time you wanted to repeat the test.

Fuzzers may produce millions or even hundreds of millions of test inputs during a proving run, but only need to store the inputs that cause the program to misbehave, or more importantly to crash, so they can be used later on as time-saving starting points for human bug hunters.

Exploit in the wild

Google writes, of the zero-day bug, simply that “[we are] aware that an exploit for CVE-2021-30551 exists in the wild.”

This bug is listed as a “type confusion in V8“, where V8 is the part of Chrome that runs JavaScript code, and type confusion means that you can feed V8 one sort of data item but trick JavaScript into handling it as if it were something else, possibly bypassing security checks or running unauthorised code as a result.

For example, if your code is doing JavaScript calculations on a data object that has a memory block of 16 bytes allocated to it, but you can trick the JavaScript interpreter into thinking that you are working on an object that uses 1024 bytes of memory, you can probably end up sneakily writing data outside the official 16-byte allocation, thus pulling off a buffer overflow attack.

And, as you probably know, JavaScript security holes that can be triggered by JavaScript code embedded in a web page often result in RCE exploits, or remote code execution.

That’s because you’re relying on your browser’s JavaScript engine to keep control over what is essentially unknown and untrusted programming downloaded and executed automatically from an external source.

Google isn’t saying whether the CVE-2021-30551 bug can be used for full-on remote code execution – which, in the context of a browser, usually means that you are vulnerable to a drive-by download.

A drive-by means that merely viewing a website, without clicking on any popups or seeing any “Are you sure?” warnings, could allow crooks to run rogue code invisibly and implant malware on your computer.

However, CVE-2021-30551 only gets a High rating, with just one bug that isn’t in the wild (CVE-2021-30544) denoted Critical.

We’re guessing that the CVE-2021-30544 bug has been given a Critical rating because it could be exploited for RCE, but there’s no suggestion that anyone other than Google and the researchers that reported it know how to do that right now.

What to do?

Check your Chrome or Chromium version.

On Windows, Mac and Linux you should have 91.0.4472.101.

Click the three-dots icon, then go to Help > About Google Chrome – this will show you the version you have now, and check for an update while you’re about it.

For further information on updating Chrome, check the official Update Google Chrome page.

---

The cybersecurity buzz of the week is the intriguing – and highly unusual – aftermath of the Colonial Pipeline ransomware attack.

Colonial runs the largest American supply pipeline for refined petroleum products, capable of shifting about 500 million litres a day of various fuels, including gasoline (petrol), jet fuel, diesel and heating oil, between Texas and the North Eastern US.

At least, that’s how much the pipeline can move if it’s not shut down, something that happened recently in the aftermath of a ransomware attack by a cybercrime gang known as DarkSide.

Even though law enforcement groups around the world urge ransomware victims not to pay up (as we know only too well, today’s ransomware payments directly fund tomorrow’s ransomware attacks), Colonial apparently decided to hand over what was then $4.4 million in bitcoins anyway.

We assume that the company hoped that the decryption tool promised by the blackmailers would help them unscramble the computers on the network faster than doing the job using conventional recovery tools, and thus get fuel flowing again sooner…

…but by many accounts the decryption tool was a dud, and didn’t speed things up at all.

No backsies with Bitcoin

At this point, whether you’ve ever been the victim of cryptocurrency extortion yourself or not, you’re probably thinking, “Ouch. No backsies with Bitcoin.”

Cryptocurrencies aren’t managed or regulated by any central authority such as a financial institution, so transferring cryptocoins to someone you don’t know and can’t identify is like handing over a suitcase full of cash to someone you’ve never met before and wouldn’t recognise again.

If you change your mind, or the seller doesn’t deliver the promised product, or the product turns out not to be fit for purpose, then the only way you’re going to get a refund is if the seller agrees to it.

There’s no clearing house who could reverse the transaction; no legal protection built into the process; no regulator or ombudsman to handle any appeal you might make; and, in all likelihood, there’s no easy or reliable way of identifying the seller even if there were a well-defined international process for settling cryptocurrency disputes.

Despite all that, however, the latest news is that the FBI – which can’t have been terribly happy with Colonial in the first place for paying anything at all to the DarkSide gang – has apparently managed to claw back 63.7 of the 75 bitcoins handed over by the beleaguered company.

Sadly, the value of Bitcoin has taken a tumble since last month, so even though 85% of the bitcoins involved in the blackmail payment were recovered, they’re now worth about 50% of what they cost when Colonial purchased them to do its deal with the criminals. What we can’t tell you is whether the FBI will hodl onto the recouped BTC in the hope of a price recovery, or cash out now in case the value falls further.

How was that possible?

That probably leaves you wondering, “How on earth was that possible, and if it could be done for Colonial, who paid up in the face of advice not to do so, why can’t it be done for everyone who has ever been blackmailed for cryptocoins by cybercrooks?”

The answer is that although most Bitcoin ownership is anonymous, and although there is no regulatory or baked-in way to force the reversal of unwanted or unlawful transactions…

…every Bitcoin payment ends up in someone’s Bitcoin wallet, and every wallet has a private key by means of which the contents of that wallet can be spent, i.e. transferred onwards to someone else’s Bitcoin wallet.

That’s because Bitcoin transactions are based on public-key cryptography, which you can think of as a lock that comes with two different keys, rather than just one: the first key secures the lock, but only the second key can open it up again.

The idea, greatly simplified, is that you can publish the first key, known unsurprisingly as the public key, so that anyone can “lock up” data for you; but as long as you keep the second key, the private key, to yourself (the hint is in the name!), then only you can ever unlock and view that data, whatever it might be.

And that, simplified yet further, is very loosely how BTC transations work: your Bitcoin wallet address, derived from your public key, can be used by anyone to “lock away” funds so that they “belong” to you.

But the public key can’t subsequently unlock those funds to spend them onwards. (Note, however, that the transactions by means of which bitcoins get spent don’t require a password or cryptographic key – the transaction ledger, or blockchain, is a matter of public record.)

In order to release the funds to pass them onto someone else, you need your own private key to “unlock” the bitcoins from your own wallet before you can transfer the contents to the Bitcoin wallet of the next person in the chain.

In practice, you can’t split up the funds in a wallet before you make a payment. If you have, say, 4 bitcoins in your wallet, you have to spend them all at once. But you can split them between multiple recipients. so you can pay me, say, BTC0.5 and pay BTC3.5 back to yourself, less the transaction fees that pay for the work done by the BTC community to approve the transaction, a process known as “mining”. Also, although all transactions end up in a wallet, not all wallets can actually be spent. If the wallet’s owner has lost the private key, or has destroyed it on purpose (known as “burning” cryptocurrency), then recovering the missing key by brute force is computationally unfeasible and the funds in that wallet are essentially locked up forever.

Follow the chain

So, if the FBI were able to get hold of the private key of the Bitcoin wallet or wallets where Colonial’s ransom payment ended up, then it could simply transfer those funds to itself (assuming that it had permission from a court to do so, of course), whether it knew who owned those wallets or not.

(We said “wallet or wallets” above because cybercrooks often make haste to split incoming payments many different ways into numerous different wallets, precisely to make following the chain of transactions more complex and troublesome.)

And that is what seems to have happened in this case.

Exactly how the FBI managed to get hold of the relevant private keys is part of its tradecraft that it understandably hasn’t explained, but the Department of Justice (DOJ) press release says:

As alleged in the supporting affidavit, by reviewing the Bitcoin public ledger, law enforcement was able to track multiple transfers of bitcoin and identify that approximately 63.7 bitcoins, representing the proceeds of the victim’s ransom payment, had been transferred to a specific address, for which the FBI has the “private key,” or the rough equivalent of a password needed to access assets accessible from the specific Bitcoin address. This bitcoin represents proceeds traceable to a computer intrusion and property involved in money laundering and may be seized pursuant to criminal and civil forfeiture statutes.

Why doesn’t this happen every time?

Of course, this raises the question, “Why doesn’t law enforcement do this for everyone who ever gets scammed by crooks?”

The answer is that it’s simply not always possible: loosely speaking, the recipient of the criminal transaction needs to make some sort of operational blunder; and the organisation trying to track down the errant bitcoins typically needs to put in a lot of effort as well as enjoying at least a little bit of good luck.

Bitcoin private keys are usually not only kept private, but also stored in encrypted form so that you need a password to unlock the private key before you can begin to unlock the funds secured by that private key. (You can think of the private key as a bank ATM card, and the top-level decryption key as the PIN that you need before the card can actually be used to do anthing.)

Here are some of the ways a law enforcement team like the FBI, trying to recover criminalised bitcoins, might end up with the cryptographic data they need to do the job.

Don’t forget, however, that cybercrooks themselves can use any or all of these techniques to steal legitimately owned cryptocoins from you – and the crooks don’t have the complexity of applying to a court for formal legal approval first:

• Implant a spyware tool on your computer to search for files and record keystrokes. With a bit of luck, implanted spyware might not only be able to exfiltrate your private key, but also figure out the password needed to unlock it. Offline cryptocurrency wallets and private keys of this sort are known in the trade as “cold wallets”, because they’re not meant to be accessible online.
• Work with a cryptocurrency exchange to access data stored there. Some cryptocurrency fans keep at least some of their funds in what are known as “hot wallets”, meaning that they trust a third party that runs a cryptocoin trading site with their private key so that they can quickly buy and sell cryptocoins online. Legitimate exchanges can and will work with law enforcement if required by warrant, and if the exchange has your wallet and your private key, it can hand them over. (Also, the exchange could get hacked, or, if the exchange itself is crooked, run off with your cryptocurrency itself.)
• Hit the jackpot by subverting an insider. One or more people inside the DarkSide ransomware crew would have had access to the ill-gotten funds, so the FBI could have acquired the intelligence it needed from them. Similarly, if you tell other people your cryptocoin passwords, they could sell you out or simply steal the funds themselves, in much the same way that they could make phantom withdrawals from your bank account if you told them the PIN of our ATM card.

What to do?

Although it’s a relief that FBI recovered a large chunk of the funds in this case, possibly at least in part because of poor tradecraft on the part of the crooks, it’s not so great to lose cryptocoins of your own – or, for that matter, to lose any private data or encryption keys you meant to keep to yourself.

Our tips, therefore, are:

• Don’t put all your cryptocoins in hot wallets. When you entrust your savings or your wage payments to a bank, you are doing so with years of regulatory scrutiny and protection to back you up. In the cryptocurrency world, however, you are largely on your own if something goes wrong. Don’t keep more than you can afford to lose in a hot wallet.
• Don’t keep all your data online all the time. Ironically, perhaps, one important defence against ransomware in the first place is to maintain an offline backup, ideally one that is also off-site. Keeping your cryptocoins, as well as any truly private or critical data, offline – is a similarly useful precaution.
• Don’t expect to keep a secret such as a Bitcoin password or ATM PIN if you tell it to other people. As Benjamin Franklin is supposed to have said, “Three people can keep a secret, if two of them are dead.” Remember: If in doubt, don’t give it out.
• Don’t expect to get your money back like Colonial did. You need to think of cryptocoin recovery as a rare exception, not as a common rule. As explained above, it typically requires a high-profile case, plus strong operational intelligence, plus a bit of plain old luck, for law enforcement to achieve a result like this.

---

LEARN MORE: SEXTORTION, A CRYPTOCOIN SCAM YOU MIGHT FACE YOURSELF

A video from our What to do When… series on the Naked Security YouTube channel.

[embedded content]

(Watch directly on YouTube if the video won’t play here.)

Don’t fall for this porn scam – even if your password’s in the subject!

---

The US Department of Justice (DOJ) just announced that it has charged a 55-year-old Latvian woman, who went by the moniker of Max, with malware-writing crimes.

Max, whose real name is apparently Alla Witte, is the sixth of seven defendants listed in the DOJ’s indictment, along with ten other unknown individuals identified only as CC8 to CC17. (CC is short for co-conspirator.)

At the moment, the names of the other six defendants have been redacted from the document, so that Witte is the only one whose name has been publicly released.

(In the indictment, filed in August 2020, Witte was identified as a “national of Russia”, but the headline of the DOJ’s latest press release describes her as Latvian.)

Witte was apparently living in Suriname in South America at the time of the alleged offences, but was arrested in Miami, Florida, in February 2021, presumably while attempting to enter the US.

The indictment, which runs to 61 double-spaced pages, tells a fascinating story of how the Trickbot Group, as the DOJ refers to this cybergang, operated and evolved over a five-year period from late 2015 to the middle of 2020.

Also documented in the indictment is a laundry list of attempted financial thefts from so-called “co-operating witnesses” – eleven US companies that have come forward to help establish the nature and extent of the criminality attempted by the Trickbot Group.

The fradulent transactions attempted against those 11 companies alone add up to $6.2 million, but the DOJ says that the Trickbot malware has infected millions of computers worldwide in the broadest possible way, hitting individuals, businesses and organisations including hospitals, schools, public utilities and governments.

Trojan, zombie and worm…

Trickbot is probably best known for being what’s called a banking Trojan, malware that deliberately snoops on your computer while you’re performing financial transactions in order to steal your personal information and prey on your account.

But Trickbot, as the name suggests, also acted as a bot, or zombie, malware that regularly calls home to servers operated by the criminals in order to fetch instructions on what to do next.

Trickbot would also go hunting for other computers to to infect on your network, acting as what’s known as a virus or worm, in order to increase its foothold and improve its yield.

As you probably know, almost all bots or zombies include a function by which they can install and activate additional malware, and the Trickbot Group took particular advantage of this “feature” in its own code by using existing Trickbot infections not only to go after your bank accounts but also to launch ransomware attacks on your network.

As the indictment explains, the Trickbot Group stands accused of conspiring to:

• Infect victims’ computers with Trickbot malware designed to capture victims’ online banking login credentials.
• Obtain and harvest other personal identification information, including credit cards, emails, passwords, dates of birth, social security numbers, and addresses.
• Infect other computers networked with the initial victim computer;
• Use the captured login credentials to fraudulently gain unauthorized access to victims’ online accounts at financial institutions.
• Steal funds from victims’ bank accounts and launder those funds using US and foreign beneficiary bank accounts provided and controlled by conspirators.
• Infect victims’ computers with ransomware.

The last of these activities – running a ransomware operation using zombified Trickbot computers to inject and initiate the attack – is where Witte is said to have been involved.

According to the indictment, she seems to have joined the Trickbot Group fairly recently, starting in late 2018.

Amongst other things, Witte is alleged to have “provided code to the Trickbot Group to operate and deploy the Trickbot ransomware module.”

She is also said to have “provided code […] for a web panel used to access victim data stored in a database,” where others in the Trickbot group could look up zombies currently active in the Trickbot botnet, and access data such as credit card details already stolen from infected victims.

What to do?

• If you’re a contract programmer, don’t be tempted to take on coding jobs that you aren’t sure about. You could end up getting sucked into a world where you oughtn’t, and probably don’t want, to be. (The indictment details how Trickbot co-conspirators discussed rewording their “job ads” to sound less obviously criminal so that their postings wouldn’t get banned.)
• If you’re looking to work from home, never hand over your CV (resume) or fill in job applications for companies whose legal provenance you aren’t absolutely certain about. Gangs like the Trickbot Group rely on recruiting “assistants”, disparagingly known as money mules, who are willing to process funds through their personal accounts without asking too many questions about where the money came from. If you do this and get caught, it’s possible that you will end up in prison and almost certain that you will end up out of pocket.
• Consider an anti-virus that includes network filtering and exploit prevention as well as traditional malware blocking. Malware like Trickbot uses a variety of techniques to operate, including making regular outgoing web requests for new instructions, actively interfering with software such as your browser in order to steal data from it, and attempting to copy itself across your network. Security software that offers what’s known as defence in depth can protect you against any and all of these tricks, giving you multiple ways to find and block cyberthreats.

---

[06’13”] Duck’s “breathtaking” hairstyle.   [08’26”] Apple patches a raft of serious security holes.   [18’36”] Police arrest eight suspects in an online scamming ring.   [31’36”] We explain how WhatsApp messages from hacked accounts are helping cybercrooks bypass 2FA.   [37’36”] Oh! No! of the week.

With Kimberly Truong, Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

---

WHERE TO FIND THE PODCAST ONLINE

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at tips@sophos.com, or simply leave us a comment below.

We’ve seen several news stories talking up some great new features in Apple’s latest software update for iOS, which was released yesterday.

However, we’re much more interested in the security patches that arrived in the update to iOS 14.6, because Apple fixed 38 significant bugs, covered by 43 different CVE bug numbers.

For what it’s worth, the update to macOS Big Sur 11.4 shared many of those bugs with iOS, as well as adding a raft of its own, with 58 significant bugs patched, covered by 73 different CVE bug numbers.

Perhaps even more importantly, one of the Big Sur bugs that was patched, now dubbed CVE-2021-30713, is a security flaw that is already known to criminals and has already and quietly been exploited in the wild.

In fact, this exploit was only recently reported to Apple after lurking unnoticed in Mac malware known as XCCSET that dates back to last year.

Ironically, this bug exists in a system component called TCC, short for Transparency Consent and Control, a part of macOS that is supposed to make sure that apps don’t do things they aren’t supposed to.

According to security researchers at Mac management software company Jamf, this bug provides a sneaky way for a simple AppleScript utility with no special permissions at all to “leech off” the permissions of an an already-installed app.

Usually, malware that blindly ran an AppleScript utility to record your screen would cause a giveaway security warning to pop up asking you if you wanted to let the malware go ahead.

Unless and until you clicked through into the Security & Privacy page in System Preferences, and manually approved the malware by adding it to the list of apps allowed to record your screen, the cybercrooks would be out of luck.

Jamf researchers, however, realised that by judiciously inserting the malicious screenshotting AppleScript utility into the application directory of software that already had Screen Recording permissions…

…they could then launch their AppleScript under the assumed authority of the so-called “donor” app and take screenshots covertly without any warnings popping up.

The researchers used Zoom as the “donor” app in their research article, but noted that the average Mac user is likely to have numerous screenshot-ready programs already installed, such as Discord, WhatsApp, Slack, WeChat, TeamViewer and many others. This trick is not limited to Screen Recording permissions, either, so other installed apps could be “piggybacked” too. This means that an attacker could invisibly acquire unauthorised access to other permissions such as Location Services, Photos, Camera, Microphone, and files and folders that would otherwise be off-limits.

Other potentially serious bugs that are shared between iOS/iPadOS and macOS, and therefore necessitate that you patch your iDevices as well as your Macs, include:

• RCE bugs in the handling of audio, image and 3D-modelling files. RCE is short for remote code execution, and it typically denotes a security flaw that can be triggered by an attacker who simply sends you a file to look at, without needing to login to your system first. RCE bugs in handling image or audio files are particularly dangerous because those files are commonly used in web pages, where your browser reads them in and processes them automatically even if all you do is look at a website.
• RCE, cross-site scripting and data leakage bugs in WebKit. Webkit is Apple’s core web browsing engine, used whenever you open the Safari browser. In fact,on mobile devices, Apple requires all browsers to use WebKit, even those that usually provide their own web engines. Additionally, WebKit is commonly used by non-browser apps as a convenient way of displaying rich content such as manuals and help files. As a result, RCE bugs in WebKit may have far-reaching consequences and can’t be sidestepped simply by avoiding the use of Safari.
• RCE and data leakage bugs in the kernel. Getting unauthorised kernel-level access is one of the ultimate prizes in a hacking attack, for the simple reason that the kernel controls the rest of the system. This includes determining which programs get to run, regulating access to memory and devices such as the camera and microphone, deciding which programs are allowed to open what files, and even keeping control over the Administrator account (root on Apple systems) itself.
• An RCE bug in Apple’s network security code. This bug apparently exists in Apple’s implementation of TLS, short for transport layer security, the protocol that makes HTTPS possible and puts the padlock in your browser’s address bar. Apple says simply that “processing a maliciously crafted certificate may lead to arbitrary code execution.” What this seems to mean is that simply by browsing to a URL that starts with https://, a booby-trapped server could trick your iPhone or Mac into installing malware right at the very start of the connection process, before any web content even shows up.

Big Sur also gets patches against a whole raft of serious bugs, including RCE, in the smbx software, which is installed on Macs so that they can connect to Microsoft networks. (The letters SMB are short for Server Message Block, the original name for Microsoft’s file sharing protocol.)

Apple’s mobile platforms don’t include Microsoft-compatible networking code, so they aren’t affected by the smbx bugs, but iOS does get a patch for a Wi-Fi bug dubbed CVE-2021-30667 and explained with the words: “an attacker in WiFi range may be able to force a client to use a less secure authentication mechanism.”

We’re not sure what that means, but given that iPhones haven’t supported the old and insecure WEP protocol at all for many years, and that most iPhone wireless connections use WPA2…

…the only step down from there is “no encryption at all”.

What to do?

On iDevices, go to Settings > General > Software Update.

On a Mac, it’s Apple menu > System Preferences > Software Update.

If you’re already up to date, then the updater will say so; if not, it will offer you an immediate opportunity to catch up.

The latest versions to look out for at the time of this article [2021-05-25T12:00Z] are: iOS/iPadOS 14.6, watchOS 7.5 and macOS 11.4.

If you’re still using macOS 10.14 or 10.15 (Mojave or Catalina by name), you’ll be offered updates specific to those versions, and you’ll need to get Safari 14.1.1 as a separate update. (On Big Sur the new version of Safari is included in the main update.)

There isn’t an iOS 12 update this time, so that version stays at 12.5.3.

And, no, we didn’t forget our mantra: Patch early, patch often, because why be behind when you could be ahead?

---