Perpetual IT

2FA, HACKING, AND PATCHING

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

The Google Authenticator 2FA app has featured strongly in cybersecurity news stories lately, with Google adding a feature to let you backup your 2FA data into the cloud and then restore it onto other devices.

To explain, a 2FA (two-factor authentication) app is one of those programs that you run on your mobile phone or tablet to generate one-time login codes that help to secure your online accounts with more than just a password.

The problem with conventional passwords is that there are numerous ways that crooks can beg, steal, or borrow them.

There’s shoulder-surfing, where a rogue in your midst peeks over your shoulder while you’re typing it in; there’s inspired guesswork, where you’ve used a phrase that a crook can predict based on your personal interests; there’s phishing, where you are lured into handing over your password to an imposter; and there’s keylogging, where malware already implanted on your computer keeps track of what you type and secretly starts recording whenever you visit a website that looks interesting.

And because conventional passwords typically stay the same from login to login, crooks who figure out a password today can often simply use it over and over at their leisure, often for weeks, perhaps for months, and sometimes even for years.

So 2FA apps, with their one-time login codes, augment your regular password with an additional secret, usually a six-digit number, that changes every time.

Your phone as a second factor

The six-digit codes commonly generated by 2FA apps get calculated right on your phone, not on your laptop; they’re based on a “seed” or “starting key” that’s stored on your phone; and they’re protected by the lock code on your phone, not by any passwords you routinely type in on your laptop.

That way, crooks who beg, borrow or steal your regular password can’t simply jump straight in to your account.

Those attackers also need access to your phone, and they need to be able to unlock your phone to run the app and get the one-time code. (The codes are usually based on the data and time to the nearest half-minute, so they change every 30 seconds.)

Better yet, modern phones include tamper-proof secure storage chips (Apple calls theirs Secure Enclave; Google’s is known as Titan) that keep their secrets even if you manage to detach the chip and try to dig data out of it offline via miniature electrical probes, or by chemical etching combined with electron microscopy.

Of course, this “solution” brings with it a problem of its own, namely: how do you back up those all-important 2FA seeds in case you lose your phone, or buy a new one and want to switch over to it?

The dangerous way to back up seeds

Most online services require you to set up a 2FA code sequence for a new account by entering a 20-byte string of random data, which means laboriously typing in either 40 hexadecimal (base-16) characters, one for every half-byte, or by carefully entering 32 characters in base-32 encoding, which uses the characters A to Z and the six digits 234567 (zero and one are unused because they look like O-for-Oscar and I-for-India).

Except that you usually get the chance to avoid the hassle of manually tapping in your starting secret by scanning in a special sort of URL via a QR code instead.

These special 2FA URLs have the account name and the starting seed encoded into them, like this (we limited the seed here to 10 bytes, or 16 base-32 characters, to keep the URL short):

You can probably guess where this is going.

When you fire up your mobile phone camera to scan in 2FA codes of this sort, it’s tempting to snap a photo of the codes first, to use as a backup…

…but we urge you not to do that, because anyone who gets hold of those pictures later (for example from your cloud account, or because you forward it by mistake) will know your secret seed, and will trivially be able to generate the right sequence of six-digit codes.

How, therefore, to backup your 2FA data reliably without keeping plaintext copies of those pesky multi-byte secrets?

Google Authenticator on the case

Well, Google Authenticator recently, if belatedly, decided to start offering a 2FA “account sync” service so that you can back your 2FA code sequences up into the cloud, and later restore them to a new device, for example if you lose or replace your phone.

As one media outlet described it, “Google Authenticator adds a critical long-awaited feature after 13 years.”

But just how safely does this account sync data transfer take place?

Is your secret seed data encrypted in transit to Google’s cloud?

As you can imagine, the cloud upload part of transferring your 2FA secrets is indeed encrypted, because Google, like every security-conscious company out there, has used HTTPS-and-only-HTTPS for all its web-based traffic for several years now.

But can your 2FA accounts be encrypted with a passphrase that’s uniquely yours before they even leave your device?

That way, they can’t be intercepted (whether lawfully or not), subpoenaed, leaked, or stolen while they’re in cloud storage.

After all, another way of saying “in the cloud” is simply “saved onto someone else’s computer”.

Guess what?

Our indie-coder and cybersecurity-wrangling friends at @mysk_co, whom we have written about several times before on Naked Security, decided to find out.

What they reported doesn’t sound terribly encouraging.

Google has just updated its 2FA Authenticator app and added a much-needed feature: the ability to sync secrets across devices.

TL;DR: Don’t turn it on.

The new update allows users to sign in with their Google Account and sync 2FA secrets across their iOS and Android devices.… pic.twitter.com/a8hhelupZR

— Mysk 🇨🇦🇩🇪 (@mysk_co) April 26, 2023

As you can see above, @mysk_co claimed the following:

• Your 2FA account details, including seeds, were unencrypted inside their HTTPS network packets. In other words, once the transport-level encryption is stripped off after the upload arrives, your seeds are available to Google, and thus, by implication, to anyone with a search warrant for your data.
• There’s no passphrase option to encrypt your upload before it leaves your device. As the @mysc_co team point out, this feature is available when syncing information from Google Chrome, so it seems strange that the 2FA sync process doesn’t offer a similar user experience.

Here’s the concocted URL that they generated to set up a new 2FA account in the Google Authenticator app:

 otpauth://totp/Twitter@Apple?secret=6QYW4P6KWAFGCUWM&issuer=Amazon

And here’s a packet grab of the network traffic that Google Authenticator synced with the cloud, with the transport level security (TLS) encryption stripped off:

Note that the highlighted hexadecimal characters match the raw 10 bytes of data that correspond to the base-32 “secret” in the URL above:

 $ luax Lua 5.4.5 Copyright (C) 1994-2023 Lua.org, PUC-Rio __ ___( o)> \ <_. ) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Added Duck's favourite modules in package.preload{} > b32seed = '6QYW4P6KWAFGCUWM' > rawseed = base.unb32(b32seed) > rawseed:len() 10 > base.b16(rawseed) F4316E3FCAB00A6152CC

What to do?

We agree with @mysk_co’s suggestion, which is, “We recommend using the app without the new syncing feature for now.”

We’re pretty sure that Google will add a passphrase feature to the 2FA syncing feature soon, given that this feature already exists in the Chrome browser, as explained in Chrome’s own help pages:

Keep your info private

With a passphrase, you can use Google’s cloud to store and sync your Chrome data without letting Google read it. […] Passphrases are optional. Your synced data is always protected by encryption when it’s in transit.

If you’ve already synced your seeds, don’t panic (they weren’t shared with Google in a way that makes it easy for anyone else to snoop them out), but you will need to reset the 2FA sequences for any accounts you now decide you probably should have kept to yourself.

After all, you may have 2FA set up for online services such as bank accounts where the terms and conditions require you to keep all login credentials to yourself, including passwords and seeds, and never to share them with anyone, not even Google.

If you’re in the habit of snapping photos of the QR codes for your 2FA seeds anyway, without thinking too much about it, we recommend that you don’t.

As we like to say on Naked Security: If in doubt / Don’t give it out.

Data that you keep to yourself can’t leak, or get stolen, or subpoenaed, or shared onwards with third parties of any sort, whether deliberately or by mistake.

Update. Google has responded on Twitter to @mysk_co’s report by admitting that it intentionally released the 2FA account sync feature without so-called end-to-end encryption (E2EE), but claimed that the company has “plans to offer E2EE for Google Authenticator down the line.” The company also stated that “the option to use the app offline will remain an alternative for those who prefer to manage their backup strategy themselves”. [2023-04-26T18:37Z]

We’ll be honest, and admit that we hadn’t heard of the printer management software PaperCut until this week.

In fact, the first time we heard the name was in the context of cybercriminality and malware attacks, and we naively assumed that “PaperCut” was what we like to call a BWAIN.

A BWAIN is our satirical term for any Bug With An Impressive (and media-savvy) Name, like Heartbleed or Shellshock back in the day, and we thought that this one referred to a vulnerability or an exploit of some sort.

We’ll apologise, therefore, to the company PaperCut – the name is meant to be a metaphor for cutting back on your paper usage by helping you to manage, control and charge fairly for the printing resources in your business.

We’ll further point out that PaperCut iself is not putting out this vulnerability alert for PR reasons, because actively seeking media coverage for bugs in your own products is not something that companies usually go out of their way to do.

But hats off to PaperCut in this case, because the company really is trying to make sure that all its customers know about the importance of two vulnerabilities in its products that it patched last month, to the point that it’s put a green-striped shield at the top of its main web page that says, “Urgent security message for all NG/MF customers.”

We’ve seen companies that have admitted to unpatched zero-day vulnerabilities and data breaches in a less obvious fashion than this, which is why we’re saying “Good job” to the Papercut team for what cybersecurity jargon would probably praise with the orotund phrase an abundance of caution.

Patched, but not necessarily updated

The problem, it seems, is a pair of bugs dubbed CVE-2023-27350 and CVE-2023-27351 that were patched by PaperCut at the end of March 2023.

The first bug is described by PaperCut as follows:

The [CVE-2023-27350 vulnerability potentially] allows for an unauthenticated attacker to get Remote Code Execution (RCE) on a PaperCut Application Server. This could be done remotely and without the need to log in.

So, even if your PaperCut application server isn’t directly reachable over the internet, an attacker who already had a basic foothold in your network, for example as a guest user on someone’s infected laptop, could exploit this bug to pivot, or move laterally (which are fancy jargon words for “make the jump”), to a more privileged and powerful position inside your business.

The second bug doesn’t hand over remote code execution powers, but it does allow attackers to scrape out personally identifiable information that could be useful for subsequent social engineering attacks against both your company as a whole, and your staff as individuals:

The [CVE-2023-27351 vulnerability] allows for an unauthenticated attacker to potentially pull information about a user stored within PaperCut MF or NG – including usernames, full names, email addresses, office/department info and any card numbers associated with the user. The attacker can also retrieve the hashed passwords for internal PaperCut-created users only […]. This could be done remotely and without the need to log in.

Although patches have been out for almost a month already, it seems that not all customers have applied these patches, and cybercrooks have apparently started using the first of these bugs in real-life attacks.

PaperCut says that it was first alerted to an attack against an unpatched server at 2023-04-17T17:30Z, and has now worked through its logs and suggests that the earliest attack so far known happened four days before that, at 2023-04-13T15:29Z.

In other words, if you patched before 2023-04-13 (the Thursday before last at the time of writing), you’d almost certainly have been ahead of the criminals, but if you haven’t patched yet, you really need to.

PaperCut notes that it is trying hard “to compile a list of unpatched PaperCut MF/NG servers that have ports open on the public internet”, and then going out of its way to try to contact those obviously-at-risk customers.

But PaperCut can’t scan your internal networks in order to warn you about unpatched servers that aren’t visible across the internet.

You will need to do that yourself, in order to ensure that you haven’t left loopholes through which attackers who have already hacked into your network “just a bit” can extend their rogue access to “quite a lot”.

What to do?

• Read PaperCut’s detailed summary of which products are affected, and how to update them.
• If you have PaperCut MF or PaperCut NG, you need to make sure you have one of the following versions installed: 20.1.7, 21.2.11, or 22.0.9.
• If you think you might be at risk, because you use these products and you hadn’t patched before 2023-04-13, when the first so-far-known exploits showed up, check out PaperCut’s FAQs to help you look for known Indicators of Compromise (IoCs).

Remember, of course, that the IoCs shared by PaperCut are, of necessity, limited to those they’ve already seen in attacks they already know about, so absence of evidence isn’t evidence of absence.

If you’re unsure of what to look for, or how to look for it, consider getting a Managed Detection and Response (MDR) team in to help you.

Short of time or expertise to take care of cybersecurity threat response? Worried that cybersecurity will end up distracting you from all the other things you need to do?

Learn more about Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response  ▶

If you’re a Google Chrome or Microsoft Edge browser fan, you’re probably getting updates automatically and you’re probably up to date already.

However…

…just in case you’ve missed any updates recently, we suggest you go and check right now, because the Chromium browser core, on which both Edge and Chrome are based, has patched not one but two zero-day remote code execution (RCE) bugs recently.

Google is keeping the details of these bugs quiet for the time being, presumably because they’re easy to exploit if you know exactly where to look.

After all, a needle is easy to find even in a giant haystack if someone tells you which bale it’s in before you start.

Browser-based security vulnerabilities that lead to remote code execution are always worth taking seriously, especially if they’re already known to, and in use by, cybercriminals.

And zero-days, by definition, are bugs that the Bad Guys found first, so that there were zero days on which you could have patched proactively.

RCE considered harmful

RCE means just what it says: someone outside your network, outside your household, outside your company – perhaps even on the other side of the world – can tell your device, “Run this program of my choosing, in the way I tell you to, without giving anything away to any users who are currently logged in.”

Usually, when you’re browsing and a remote website tries to foist potentially risky content on you, you will at least receive some sort of warning, such as a Do you want to download this file? dialog or a popup asking you Are you really sure (Yes/No)?

Sometimes, depending on the browser settings that you’ve chosen, or based on restrictions that have been applied for you by your IT sysadmins, you might even get a notification along the lines of, Sorry, that option/file/download isn't allowed.

But a browser RCE bug generally means that simply by looking at a web page, without clicking any buttons or seeing any warnings, you might provide attackerswith a security loophole through which they could trick your browser into running rogue program code without so much as a by-your-leave.

Common ways that this sort of security hole can be triggered include: booby-trapped HTML content; deliberately malconstructed JavaScript code; and malformed images or other multimedia files that the browser chokes on while trying to prepare the content for display.

For example, if an image appeared to need only a few kilobytes of memory, but later turned out to include megabytes of pixel data, you’d hope your browser would reliably detect this anomaly, and not try to stuff those megabytes of pixels into kilobytes of memory space.

That would cause what’s known as a buffer overflow, corrupting system memory in a way that a well-prepared attacker might be able to predict and exploit for harm.

Likewise, if JavaScript code arrived that told your browser, “Here’s a string representing a time and date that I want to you remember for later,” you’d hope that your browser would only ever allow that data to be treated as a block of text.

But if the JavaScript system could later be tricked into using that very same data block as if it were a memory address (in C or C++ terminology, a pointer) that denoted where the program should go next, a well-prepared attacker might be able to trick the browser into treating what arrived as harmless data as a remotely-supplied mini-program to be executed.

In the jargon, that’s known as shellcode, from time-honoured Unix terminology in which code refers to a sequence of program instructions, and shell is the general name for a control prompt where you can run a sequence of commands of your choice.

Imagine opening the Terminal app on a Mac, or a PowerShell prompt on Windows – that’s the sort of power that cybercriminal typically gets over you and your network if they’re able to use an RCE hole to pop a shell, as it’s jocularly called in the trade, on your device.

Worse still, a “popped” remote shell of this sort generally runs entirely in the background, invisible to anyone currently sitting in front of the computer, so there are few or no tell-tale signs that a rogue operator is poking around and exploiting your device behind your back.

A two-pack of zero-days

When we gave our RCE examples above, we didn’t choose booby-trapped image files and rogue JavaScript code by chance.

We highlighted those as examples because the two zero-day Chrome bugs fixed in the past few days are as follows:

• CVE-2023-2033: Type confusion in V8 in Google Chrome prior to 112.0.5615.121. A remote attacker could potentially exploit heap corruption via a crafted HTML page. Chromium security severity: High.
• CVE-2023-2136: Integer overflow in Skia in Google Chrome prior to 112.0.5615.137. A remote attacker who had compromised the renderer process could potentially perform a sandbox escape via a crafted HTML page. Chromium security severity: High.

In case you’re wondering, V8 is the name of Chromium’s open-source JavaScript engine, where JavaScript embedded into web pages gets processed.

And Skia is an open-source graphics library created by Google and used in Chromium to turn HTML commands and any embedded graphical content into the on-screen pixels that represent the visual form of the page. (The process of turning HTML into on-screen graphics is known in the jargon as rendering a page.)

A type confusion bug is one that works similarly to the text-treated-as-a-pointer example we presented above: a chunk of data that ought to be handled under one set of security rules inside the JavaScript process ends up being used in an unsafe way.

That’s a bit like getting a guest pass at the reception desk of a building, then finding that if you hold up the pass with your thumb in just the right place to obscure the “I am only a guest” label, you can trick the security guards inside the building into letting you go where you shouldn’t, and doing things you’re not supposed to.

And an integer overflow is where an arithmetic calculation goes awry because the numbers got too big, in the same sort of way that the time wraps round once or twice a day on your clock.

When you put an analog clock forward an hour from, say, 10-past-12 o’clock, the time wraps around to 10-past-1 o’clock, because the clock face is only marked from 1 to 12; similarly, when a digital clock gets to midnight, it flips back from 23:59 to 00:00, because it can’t count as far as 24.

What to do?

Wouldn’t it be handy if there were a single version number you could check for in every Chromium-based browser, and on every supported platform?

Sadly, there isn’t, so we’ve reported whay we found below.

At the time of writing [2023-04-24T16:00Z], the official laptop versions of Chrome seem to be: 112.0.5615.137 or 112.0.5615.138 for Windows, 112.0.5615.137 for Mac, and 112.0.5615.165 for Linux.

Anything at or later than those numbers will include patches for the two zero-days above.

Edge on your laptop should be 112.0.1722.58 or later.

Unfortunately, Chrome and Edge on Android (we just updated ours) still seem to be 112.0.5615.136 and 111.0.1661.59 respectively, so we can only advise you to keep your eye out for updates over the next few days.

Likewise, on iOS, our just-updated versions of Chrome and Edge show up respectively as 112.0.5615.70 and 112.0.1722.49, so we assume those versions will soon get updated to ensure both these zero-days are patched.

• Chrome on your laptop. Visiting the URL chrome://settings/help should show you the current version, then check for any missed updates, and attempt to get you up-to-date if you weren’t already.
• Chrome on iOS. The URL chrome://version will show your current version. Go to the App Store app and tap on your account picture at the top right to see if any updates are available that still need to be installed. You can use Update all to do them all at once, or update apps individually from the list below if you prefer.
• Chrome on Android. The URL chrome://version will show your current version. The three-dots menu should show an up-arrow if there is a Chrome update you don’t have yet. You will need to sign into your Google Play account to get the update.
• Edge on your laptop. Visiting the URL edge://settings/help should show you the current version, then check for any missed updates, and attempt to get you up-to-date if you weren’t already.
• Edge on iOS. The URL edge://version will show your current version. Go to the App Store app and tap on your account picture at the top right to see if any updates are available that still need to be installed. You can use Update all to do them all at once, or update apps individually if you prefer.
• Edge on Android. The URL edge://version will show your current version. Open the Google Play app and tap on your account blob at the top right. Go into the Manage apps & device screen to look for any pending updates. You can use Update all to do them all at once, or tap through into See details to update them individually.

Logging software has made cyberinsecurity headlines many times before, notably in the case of the Apache Log4J bug known as Log4Shell that ruined Christmas for many sysadmins at the end of 2021.

The Log4Shell hole was a security flaw in the logging process itself, and boiled down to the fact that many logfile systems allow you to write what almost amount to “mini-programs” right in the middle of the text that you want to log, in order to make your logfiles “smarter” and easier to read.

For example, if you asked Log4J to log the text I AM DUCK, Log4J would do just that.

But if you included the special markup characters ${...}, then by choosing carefully what you inserted between the squiggly brackets, you could as good as tell the logging server, “Don’t log these actual characters; instead, treat them as a mini-program to run for me, and insert the answer that comes back.”

So by choosing just the right sort of booby-trapped data for a server to log, such as a sneakily constructed email address or a fake surname, you could maybe, just maybe, send program commands to the logger disguised as plain old text.

Because flexibility! Because convenience! But not because security!

This time round

This time round, the logging-related bug we’re warning you about is CVE-2023-20864, a security hole in VMWare’s Aria Operations for Logs product (AOfL, which used to be known as vRealize Log Insight).

The bad news is that VMWare has given this bug a CVSS “security danger” score of 9.8/10, presumably because the flaw can be abused for what’s known as remote code execution (RCE), even by network users who haven’t yet logged into (or who don’t have an account on) the AOfL system.

RCE refers to the type of security hole we described in the Log4Shell example above, and it means exactly what it says: a remote attacker can send over a chunk of what’s supposed to be plain old data, but that ends up being handled by the system as one or more programmatic commands.

Simply put, the attacker gets to run a program of their own choice, in a fashion of their own choosing, almost as though they’d phoned up a sysadmin and said, “Please login using your own account, open a terminal window, and then run the following sequence of commands for me, without question.”

The good news in this case, as far as we can tell, is that the bug can’t be triggered simply by abusing the logging process via booby-trapped data sent to any server that just happens to keep logs (which is pretty much every server ever).

Instead, the bug is in the AOfL “log insight” service itself, so the attacker would need access to the part of your network where the AOfL services actually run.

We’re assuming that most networks where AOfL is used don’t have their AOfL services opened up to anyone and everyone on the internet, so this bug is unlikely to be directly accessible and triggerable by the world at large.

That’s less dramatic than Log4Shell, where the bug could, in theory at least, be triggered by network traffic sent to almost any server on the network that happened to make use of the Log4J logging code, including systems such as web servers that were supposed to be publicly accessible.

What to do?

• Patch as soon as you can. Affected versions apparently include VMware Aria Operations for Logs 8.10.2, which needs to be updated to 8.12; and an older product flavour known as VMware Cloud Foundation version 4.x, which needs updating to version 4.5 first, and then upgrading to VMware Aria Operations for Logs 8.12.
• If you can’t patch, cut down access to your AOfL services as much as you can. Even if this is slightly inconvenient to your IT operations team, it can greatly reduce the risk that a crook who already has a foothold somewhere in your network can reach and abuse your AOfL services, and thereby increase and extend their unauthorised access.