Perpetual IT

At the start of this month, CVE-2021-42321 was technically an Exchange zero-day flaw.

This bug could be exploited for unauthorised remote code execution (RCE) on Microsoft Exchange 2016 and 2019, and was patched in the November 2021 Patch Tuesday updates.

Microsoft officially listed the bug with the words “Exploitation Detected”, meaning that someone, somewhere, was already using it to mount cyberttacks.

The silver lining, if there is such a thing for any zero-day hole, is that the attacker first needs to be authenticated (logged on, if you like) to the Exchange server.

This means that anyone in the position to exploit the CVE-2021-42321 vulnerability would almost certainly already either be logged on to the network itself or signed in to a user’s email account, which at least rules out anonymous, remote attacks mounted by just about anyone from just about anywhere.

Nevertheless, a bug of this sort still represents a critical security issue, because regular users aren’t supposed to be able to upload and run arbitrary programs on any of your network servers, least of all your mail server.

Although cybercriminals who can read your email are already a serious concern, crooks who can infiltrate the email server itself, without needing to be a sysadmin to start with, are a very much greater threat.

With control over the entire mail server, rather than just a single user’s email account, attackers could potentially implant malware to spy on all corporate email, in and out; send bogus emails in anyone’s name right from inside the organisation; implant RAM-scraping malware to watch for business secrets held only temporarily in memory, or to retreive temporary network passwords; snoop on network activity from a central location; and much more.

Check your patches

If you’re the sort of person who is conservative about patching, and likes to delay for a while to see if other people have problems first…

…we’re hoping that the “zero-day/already in the wild” tag on this bug encouraged you not to wait too long, and that you have already applied this month’s updates.

If you haven’t, don’t delay any longer.

For better or worse, a security researcher going by Janggggg (yes, with five Gs), also known as @testanull, has recently published a proof-of-concept (PoC) exploit for the CVE-2021-42321 hole.

By his own admission, his attack code (ironically published on Microsoft’s GitHub site) “just pop[s] mspaint.exe on the target”, meaning that the published exploit can’t directly be used to run arbitrary code.

But Janggggg has also provided a link to a “grey hat” tool that he says will help you to generate your own so-called shellcode (executable code masquerading as data) that can be embedded into the exploit in place of simply launching Microsoft Paint.

Bluntly, this means you can adapt Jangggg’s PoC so that instead of merely requesting it to do something, you can instruct it to do anything.

This is a good example of how Patch Tuesday is often followed by what is jocularly referred to as Weaponised Wednesday or Takeback Thursday, when security practioners scramble to reverse engineer the patch itself in order to get insights into what was fixed, and how.

This sort of patch analysis isn’t trivial, but it does frequently help researchers and attackers alike to “rediscover” the bug, and also to get helpful insights into how it might actively be exploited.

As you can imagine, finding and exploiting a security hole in any software product is much easier and quicker if you know where to start looking, in the same way that you’re much more likely to win at blackjack if you know which cards have already been dealt from the pack.

Often, the details of how a bug was patched – for example, new error-checking code added to detect and reject invalid input data – can provide a handy shortcut to understanding not only how the bug works, but also how to construct booby-trapped input that allows the vulnerable program to be taken over completely, instead of simply crashed.

What to do?

Patch at once!

To verify that your Exchange servers are safe against this and other known security holes, you can use Microsoft’s official Exchange Server HealthChecker PowerShell script.

This extensive script reports on numerous aspects of your Exchange configuration, including advising you about missing security updates.

Note. Microsoft added Exchange 2013 to the list of vulnerable versions on 2021-11-16, only to change its mind on 2021-11-17 and report that it had “removed Exchange Server 2013 from the Security Updates table as it is not affected by this vulnerability.”

The US Securities and Equities Commission (SEC) has just published a “Security Incident” submitted last week by Web services behemoth GoDaddy.

GoDaddy says that on 17 November 2021 it realised that there were cybercriminals in its network, kicked them out, and then set about trying to figure out when the crooks got in, and what they’d managed to do while they were inside.

According to GoDaddy, the crooks – or the unauthorised third party, as the report refers to them:

• Had been active since 06 September 2021, a ten-week window.
• Acquired email addresses and customer numbers of 1,200,000 Managed WordPress (MWP) customers.
• Got access to all active MWP usernames and passwords for sFTP (secure FTP) and WordPress databases.
• Got access to SSL/TLS private keys belonging to some MWP users. (The report just says “a subset of active users”, rather than stating how many.)

Additionally, GoDaddy stated that default WordPress admin passwords, created when each account was opened, were accessed, too, though we’re hoping that few, if any, active users of the system had left this password unchanged after setting up their WordPress presence.

(Default starting passwords generally need to be sent to you somehow in cleartext, often via email, specifically so you can login for the first time to set up a proper password that you chose yourself.)

GoDaddy’s wording states that “sFTP […] passwords were exposed”, which makes it sound as though those passwords had been stored in plaintext form.

We’re assuming, if the passwords had been salted-hashed-and-stretched, as you might expect, that GoDaddy would have reported the breach by saying so, given that properly-hashed passwords, once stolen, still need to be cracked by the attackers, and with well-chosen passwords and a decent hashing process, that process can take weeks, months or years.

Indeed, researchers at WordFence, a company that focuses on WordPress security, say that they were able to read out their own sFTP password via the official MWP user interface, something that shouldn’t have been possible if the passwords were stored in a “non-reversible” hashed form.

What could have happened to affected websites?

GoDaddy has now reset all affected passwords, and says it’s in the process of replacing all potentially stolen web certificates with freshly generated ones.

GoDaddy is also in the process of contacting as many of the 1,200,000 affected users at it can. (Customers who can’t be contacted due to incorrect or outdated details may not actually receive GoDaddy’s alerts, but there’s not a lot GoDaddy can do about that.)

This is a useful response, and GoDaddy hasn’t dithered over getting it out, given that the breach was first spotted just five days ago.

(The company also issued an uncomplicated and unqualified apology, as well as saying that “we will learn from this incident and are already taking steps to strengthen our provisioning system with additional layers of protection”, which is a refreshing change from companies that start off by telling you how strong their protection was even before the incident.)

However, with ten weeks in hand before getting spotted, the criminals in this attack could have used the compromised sFTP passwords and web certificates to pull off further cybercrimes against MWP users.

In particular, crooks who know your sFTP password could, in theory, not only download the files that make up your site, thus stealing your core content, but also upload unauthorised additions to the site.

Those unauthorised website additions could include:

• Backdoored WordPress plugins to let the crooks sneak back in again even after your passwords are changed.
• Fake news that would embarrass your business if customers were to come across it.
• Malware directly targeting your site, such as cryptomining or data stealing code designed to run right on the server.
• Malware targeting visitors to your site, such as zombie malware to be served up as part of a phishing scam.

Also, crooks with a copy of your SSL/TLS private key could set up a fake site elsewhere, such as an investment scam or a phishing server, that not only claimed to be your site, but also actively “proved” that it was yours by using your very own web certificate.

What to do?

• Watch out for contact from GoDaddy about the incident. You might as well check that your contact details are correct so that if the company needs to send you an email, you’ll definitely receive it.
• Turn on 2FA if you haven’t already. In this case, the attackers apparently breached security using a vulnerability, but to get back into users’ accounts later using exfiltrated passwords is much harder if the password alone is not enough to complete the authentication process.
• Review all the files on your site, especially those in WordPress plugin and theme directories. By uploading booby-trapped plugins, the attackers may be able to get back into your account later, even after the all the original holes have been patched and stolen passwords changed.
• Review all accounts on your site. Another popular trick with cybercriminals is to create one or more new accounts, often using usernames that are carefully chosen to fit in with the existing names on your site, as a way of sneaking back in later.
• Be careful of anyone contacting you out of the blue and offering to “help” you to clean up. The attackers in this case made off with email addresses for all affected users, so those “offers” could be coming directly from them, or indeed from any other ambulance-chasing cybercrook out there who knows or guesses that you’re an MWP user.

By the way, we’re hoping, if GoDaddy was indeed storing sFTP passwords in plaintext, that it will stop doing so at once, and contact all its MWP customers to explain what it is now doing instead.

Remember when people used to upload their SSH keys onto Github and similar code sharing sites by mistake?

Two years ago, we wrote about the fact that incautious software developers had uploaded hundreds of thousands of private access control keys, entirely unintentionally, along with source code files that they did intend to make public.

Typically, this sort of blunder happens because Linux and Unix computers don’t display directories or filenames that start with a dot character (period, full stop, ASCII 46, hexadecimal 0x2E) by default.

It’s easy to forget that these “hidden” files and directories exist at all, given that you rarely notice they’re there.

One of the super-important “hidden” directories for Unix users is .ssh, which is usually invisible.

So a plain directory listing might look like this:

$ ls -lR
.:
total 4
drwxr-xr-x 2 lua lua 4096 2021-11-18 20:52 lua-utils/ ./lua-utils:
total 32
-rw-r--r-- 1 lua lua 5107 2021-11-18 20:45 args.lua
-rw-r--r-- 1 lua lua 12384 2021-11-18 20:45 base.lua
-rw-r--r-- 1 lua lua 4628 2021-11-18 20:45 socks5.lua

Blindly packaging all these files into an archive for uploading to your favourite public repository seems pretty harmless, given that all the files in the lua account are supposed to be public.

But if you insist that the file listing utility shows you all files (add the option -a for all to the ls command), including hidden files starting with a dot, you might have a directory tree that looks like this instead:

$ ls -alR
.:
total 28
drwxr-xr-x 4 lua lua 4096 2021-11-18 20:46 ./
drwxr-xr-x 27 lua lua 16384 2021-11-18 20:42 ../
drwxr-xr-x 2 lua lua 4096 2021-11-18 20:44 .ssh/
drwxr-xr-x 2 lua lua 4096 2021-11-18 20:52 lua-utils/ ./.ssh:
total 16
drwxr-xr-x 2 lua lua 4096 2021-11-18 20:44 ./
drwxr-xr-x 4 lua lua 4096 2021-11-18 20:46 ../
-r-------- 1 lua lua 74 2021-11-18 20:45 id_rsa
-rw------- 1 lua lua 1993 2021-11-18 20:45 known_hosts ./lua-utils:
total 40
drwxr-xr-x 2 lua lua 4096 2021-11-18 20:52 ./
drwxr-xr-x 4 lua lua 4096 2021-11-18 20:46 ../
-rw-r--r-- 1 lua lua 5107 2021-11-18 20:45 args.lua
-rw-r--r-- 1 lua lua 12384 2021-11-18 20:45 base.lua
-rw-r--r-- 1 lua lua 4628 2021-11-18 20:45 socks5.lua

As you can see, the full directory tree includes a hidden .ssh directory that includes a file called id_rsa, which is a private key file typically containing the login credentials for one or more online servers that you connect to regularly:

$ cat .ssh/id_rsa -----BEGIN RSA PRIVATE KEY----- [. . . .] -----END RSA PRIVATE KEY-----

Did I include 6 files, or only 5?

Of course, if your packaging tool archives and upload all files, not merely the “unhidden” ones, you would inadvertently have included your own private SSH login keys along with your public source code.

Ironically, the id_rsa file might even contain your access key for the very source code repository in which the keyfile is now publicly and searchably sitting.

Faced with this dilemma, many upload sites now go out of their way to find, warn and remove files of this sort, which simply shouldn’t be made public.

But a typical Unix or Linux computer will have hundreds or thousands of hidden files in any busy user’s directory tree, and while only a few of these are as critical as your SSH keys, there many be hundreds, or even thousands, of hidden files that reveal vital secret information about you, your accounts, or your online activities.

Uploading any one of these files by mistake could be harmful to your cyberhealth.

Searches, commands, documents and browsing data

Dozens of popular utilities, for example, retain hidden “history” files that record the last N searches, or the last M documents, or the last P commands you ran, just in case you want to go back quickly to a recent command or document later on.

Often, these history files go back days, week, or even longer – and your command shell history in particular is apt to unwanted copies of your password, “remembered” accidentally when you got out of synch with the password prompt and put in your password at the command prompt by mistake.

Well, reporters over at UK IT news site El Reg, officially The Register, today wrote up a warning that they received from a reader who had just noticed that thousands of copies of Firefox browser cookie files, called cookies.sqlite, could be found on GitHub.

Many Firefox users will never have seen this file, especially on Linux computers, because it’s stashed by default under a directory called .mozilla/firefox, where it’s unlikely to show up during routine browsing of your local files, thanks to the dot at the start of the application-specific directory name .mozilla.

We repeated the experiment, and we immediately found more than 4400 instances of files with that name, with the most recent being just a few hours old.

We didn’t dig too deeply into the files that showed up, even though they’re now a matter of public record, because we suspect that none of the users who had uploaded them intended to do so.

But we were able to open up and scroll briefly through the samples we looked at (.sqlite files are self-contained databases for the popular SQLite toolkit, widely used by a range of applications – it’s very popular on iOS and Android for its compact code size), and they had clear evidence of recent browsing behaviour and site logins.

Of course, cookies.sqlite is just one sensitive file from one popular application, but it’s a bad choice of a private file to upload, because it typically contains personalised informtation about your private browsing habits.

Most importantly, your cookie database may include authentication tokens that let you back into your favourite websites without logging in again next time you visit.

If you are in the habit of telling websites to “remember me for X days” so you don’t need to put in your username, password and 2FA code every morning, it’s a fair guess that the secret string of jumbled text characters that lets you back in next time is stored as a web cookie. Therefore crook who finds your cookie file may be able to copy your personal “login bypass” code and masquerade as you inside your account.

What to do?

• When you’re uploading files for public use, make absolutely certain which files you’ve included in your bundle. Windows famously suppresses file extensions by default, making it hard to be sure which types of file you’ve selected. As shown above, Linux and Unix famously suppress “hidden” files that start with a dot.
• Where possible, get someone else to review your upload before you click [OK]. If you’re uploading your own code, for example, you’re probably feeling relieved and euphoric that your next release is out, or happy that the bugs you’ve been working on are now finally fixed. Reviewing your own uploads is like proofreading your own articles: you know what they are supposed to look like, so mistakes that stick out obviously to other people will often evade your notice entirely.
• Get in the habit of clearing your browser cookies regularly. The longer you leave it, the more personalised data about your browsing your cookie file will contain. Ideally, set up your browser to clear cookies and web data automatically on exit. That way you don’t have to remember to keep doing it by hand. It’s a small inconvenience for big peace of mind.
• Log out from sites as soon as you’ve finished using them. Yes, this is inconvenient, because you have to log back in, and enter your 2FA code, frequently. But when you formally tell a site like GitHub, or YouTube, or Facebook, that you’ve logged out, your current browser authentication tokens are automatically invalidated and therefore become useless to anyone who stumbles across them later on.
• Download your own uploads as soon as they’re public. If you regularly upload files to public repositories where others can fetch them, make a habit of downloading your own uploads (use a different browser, a different username or even a different computer if you can), as if you were an inquisitive member of the public. Review the contents of what you just downloaded, using a tool that you know shows you everything in the download, whatever its extension or filename. If you don’t check for rogue files, crooks are liekly to do it for for you.

Be aware before you share!

[00’52”] Fun Fact: The dawn of the transistor
[01’37”] Emotet malware: “The report of my death was an exaggeration”
[08’26”] FBI email hack spreads fake security alerts
[15’19”] Tech history: Why tubes are valves, and valves are tubes
[16’44”] Samba update patches plaintext password plundering
[22’24”] The hijackable self-driving robot suitcase
[30’22”] Oh! No! A virtual-versus-real monitor mixup

With Paul Ducklin and Doug Aamoth. 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 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.