Perpetual IT

Remember HAFNIUM?

Of course you do – it was the name behind a foursome of Exchange bugs that got patched in an emergency update early in March 2021.

Even though there was just a week to go until March 2021’s Patch Tuesday, Microsoft decided to issue what have become known as the “Hafnium fixes” in a so-called out-of-band update.

The fixes closed four security holes that could be chained together to produce an attack that has now been dubbed ProxyLogon.

Using the ProxyLogin trick, a cybercriminal outside your network could sneakily install malware onto your server without needing to go through any sort of authentication process or password check first.

“Out of band” is a metaphor borrowed from radio and network signalling, where it refers to a separate communication channel reserved for special data or commands in order to avoid to improve reliability. Usually, out-of-band data and commands are used to avoid to the dual risks that [a] the commands or urgent data might get missed if mingled with regular transmission, and [b] innocent data in regular transmission might dangerously be misrecognised as a command that was never actually issued. When referring to software updates, “out of band” simply means a patch or fix that unexpectedly arrives outside any pre-announced update schedule. Usually, that means it’s both urgent and important because it fixes a zero-day hole: a bug that attackers are already exploiting.

As we explained in a recent Serious Security article on Naked Security, a crook who can upload a file into a Windows server directory where web data is stored doesn’t merely get a chance to pollute your web server with fake content, as bad as that would be on its own.

By uploading a web file that doesn’t just contain HTML but also includes what’s called a server-side script…

…crooks can create a booby-trap on your server that will execute that server-side script whenever they later visit the URL of the file they uploaded.

Remote code execution

Using the ProxyLogon attack, crooks can turn the trick of uploading an arbitary file into a remote code execution exploit, where they can come back whenever they want and run code they uploaded earlier.

Even worse, the crooks don’t need to upload a single, specific command to run later, as harmful as that would be on its own.

By uploading what’s known as a webshell – a remotely executable command script that is programmed to run arbitrary additional commands provided at runtime – the crooks can come back whenever they want to execute whatever they want. (Read the boldfaced part of that sentence out aloud!)

Webshells provide attackers with same sort of general-purpose power as a local Command Prompt or a PowerShell window, but without requiring them to work their way past any firewall rules or logon prompts.

Life beyond HAFNIUM

Hafnium, as it happens, doesn’t refer to the attack described above, but merely to a specific gang of attackers who were using the ProxyLogon trick before Microsoft became aware of the bugs, and whose activities provoked the emergency patches.

Unfortunately, once news of the Hafnium attackers came out, interest in the epxloits they had been using surged.

Ready-to-use attack code was soon made public, so that anyone could exploit the ProxyLogon hole, and a spate of “me-too” cyberattacks followed.

The original Hafnium gang seems to have been interested in stealing data, presumably for industrial espionage, but some of the follow-up attackers had different ideas, such as the BlackKingdom gang, who used ProxyLogin to spread their ransomware.

Lead, follow, or get out of the way

Despite several weeks of urgent warnings, not least from Naked Security, where we’ve preached about patching in writing, via podcast and on video, there are still plenty of unpatched servers out there just waiting to get pwned.

And the ProxyLogon hole gets attackers directly onto your Exchange server, which is a target that almost certainly contains what crooks think of as “trophy data”, so that’s not a good thing.

So, the FBI decided to act, and to turn attack into defence.

The Feds went to court for a warrant that authorised them to “exploit” the webshells visible on unpatched servers themselves…

…and the remote code execution command they issued to those webshells was: DELETE THYSELF:

Many infected system owners successfully removed the webshells from thousands of computers. Others appeared unable to do so, and hundreds of such webshells persisted unmitigated. This operation removed one early hacking group’s remaining webshells which could have been used to maintain and escalate persistent, unauthorized access to U.S. networks. The FBI conducted the removal by issuing a command through the webshell to the server, which was designed to cause the server to delete only the webshell (identified by its unique file path).

As the DOJ pointed out in its press release, the Hafnium gang’s webshell installations used a different filename and path on every server they attacked.

The DOJ rather politely suggested that this “may have been more challenging for individual server owners to detect and eliminate than other webshells.”

What to do?

• Check whether you have any Exchange servers on your network. Even if you consider yourself to be a “full cloud” organisation these days, you may still have legacy servers on your own network that you’ve forgotten about. Those servers are never going to get patched unless you actively go looking for them.
• Check whether your servers are patched. Don’t leave it to chance, or assume that updates have been applied automatically.
• Check your network for indicators of compromise. Don’t just look for specific artifacts such as an individual filename that another victim may have reported, because the details vary from attack to attack. Use the most general threat-hunting techniques you can. Sophos has created a step-by-step guide to help you detect if you’ve been infiltrated.

If you’re infected, don’t wait for someone else to run the webshell for you, because it’s probably not going to be the FBI telling your server to disinfect itself.

---

Here’s another BWAIN, which is our shorthand for Bug With An Impressive Name.

That’s the abbreviation we use for bugs that end up with names, logos and even dedicated websites that are catchy, cool, fancy, important or dramatic, and sometimes even all of these at the same time.

Classic examples of the genre include:

• Heartbleed. The infamous server-side data-leakage bug in OpenSSL, the encryption library used by millions of web servers around the word.
• Orpheus’ Lyre. A flaw in the Kerberos authentication system used by Microsoft Windows and in various open source programs including Samba. This is the only BWAIN we can recall that had not only a logo but also a theme tune. (That’s a ukulele, in case you’re wondering, not an actual lyre.)
• BootHole. A bug in GRUB, pun intended, the most popular Linux bootloader.

This time, we’re talking about NAME:WRECK, a bunch of somewhat related bugs in the core DNS software used by several different operating systems.

This “bug cluster” features in a report released yesterday by researchers from Forescout and JSOF.

The nickname comes from the word “name” in DNS, combined with the fact all the bugs could theoretically let an attacker crash an affected device, or perhaps worse.

DNS, as you probably know, is short for domain name system, which converts names like nakedsecurity.sophos.com into IP numbers such as 192.0.66.200 [correct at 2021-04-13T16:20Z].

Technically, you can run a TCP/IP network stack without DNS, simply by referring to each device by its network number only.

But even the most limited and self-contained test networks quickly end up crying out for DNS, and if ever you want to hook up your device or devices to the internet, you can consider DNS support a must.

That’s why any TCP/IP device, no matter how tiny and resource-constrained it might be, and any operating system, no matter how much it might have been miniaturised, includes code for what’s known as DNS resolution or DNS lookup.

That code needs to know how to formulate DNS requests, which are compactly encoded binary network packets specified in RFC 1035, published way back in 1987 when every byte really mattered.

DNS lookup code also needs to know how to deconstruct the similarly formatted DNS replies that come back, even though that code didn’t create those packets in the first place, and doesn’t know whether it can trust the person who did.

As you probably know only too well, making sense of binary data, known as parsing in the jargon, is very easy to do badly.

The fact that a program can reliably parse billions of well-formed packets without a hitch doesn’t mean it won’t misbehave when faced with deliberately malformed packets that would never occur in regular use.

As the old joke goes: “A penetration tester walks into a bar and says, ‘4,294,967,297 beers, please’, just to see how good the bartender is.”

The devil’s in the details

The NAME:WRECK report isn’t just one bug or one vulnerability, and all of them date back to last year except for one.

Fortunately, they are all patched (at least one has had an update out for nearly a year already) but together they constitute a worthwhile reminder that even in the modern age, programmers continue to make old-school coding mistakes.

The vulnerabilities that have been lumped together under the NAME:WRECK “brand” were found in three different operating systems.

Two were low-level operating systems, often known as RTOSes (short for real-time operating systems) dedicated to internet-of-things (IoT) devices, namely Nucleus NET from Siemens and NetX from Microsoft.

The third was FreeBSD, widely used as both a mainstream server operating system and as an operating system for embedded devices. (As the name suggests, FreeBSD is available for free, like Linux, but it uses a much more easy-going and liberal open source licence.)

Parsing errors and randomness problems

Six of the bugs involved parsing errors, where the data sent back in DNS replies was carelessly processed, leading to buffer overflows.

Some of these could be exploited to cause the DNS lookup code to read data where it shouldn’t, causing a crash, or denial of service) (DoS).

Others could be exploited not just to read from the wrong place but to write to the wrong place as well, leading to remote code execution (RCE).

RCE generally means that an attacker can quietly inject malware into your computer simply by sending rogue packets, without needing to login first or to know any kind of password.

One bug involved a loop limit bug, where the code added no bytes to a text string, decided that the string wasn’t full yet, and went back for more, vainly adding zero bytes over and over again for ever and ever, in the hope that the string would eventually get longer.

The last bug involved poor randomness, where one-time random numbers added as transaction identifiers into DNS replies were not random enough.

As a result, attackers could create fake DNS replies that would pass muster and perform DNS poisoning on the local device’s stored list of known DNS replies.

By feeding an internet device a list of server names and fake IP numbers, criminals could trick that device into visiting imposter sites, replacing the real IP numbers of well-known servers with IP numbers controlled by the crooks.

The bugs were:

CVE identifier OS Type of error Outcome
-------------- ----------- ---------------- -------------
CVE-2020-7461 FreeBSD Buffer overwrite RCE
CVE-2020-15795 Nucleus NET Buffer overwrite RCE
CVE-2020-27009 Nucleus NET Buffer overwrite RCE
CVE-2020-27736 Nucleus NET Buffer overread Crash/DoS CVE-2020-27737 Nucleus NET Buffer overread Crash/DoS
CVE-2020-27738 Nucleus NET Buffer overread Crash/DoS
CVE-2021-25677 Nucleus NET Poor randomness DNS poisoning
[NOT ISSUED] NetX Infinite loop Hang/DoS

The NAME:WRECK report includes a ninth bug, though this one was actually found back in 2016 by researchers at Exodus Intelligence. Somehow, that bug never received a CVE identifier at the time, but one has been issued retrosepctively, namely CVE-2016-20009. That bug was a buffer overwrite in WindRiver’s IPNet software, apparently leading to remote code execution. We’re not sure if it was ever fixed, or if it’s still exploitable in current IPNet versions. If you are a WindRiver user, we recommend consulting the Exodus report for further details to help you work out if you are vulnerable.

What to do?

As so often, patching is the cure in this case.

Regular FreeBSD users will almost certainly have updated their laptops and servers by now, and almost certainly don’t need to worry.

However, if you have an embedded device based on FreeBSD, you may want to contact the maker of the device for confirmation that the patch has been included in the current device firmware.

Given the media interest in this report, devlopers using Nucleus NET or NetX in their products should consider publishing a note for their customers to say whether their devices are vulnerable or not.

Programmers interested in the sort of the low-level coding errors that led to these bugs might want to take a look at the Forescout/JSOF report, which gives six practical examples of the coding blunders to look for!

---

An iPhone and Android app called NHS COVID-19 is the official iPhone and Android coronavirus contact tracing software for the vast majority of the population of Great Britain.

(England and Wales have standardised on NHS COVID-19, but Scotland has gone down a different path with an app of its own.)

Today also marks the first day of slightly more liberal lockdown rules in England, with non-essential shops allowed to open for the first time this year, and outdoor alcohol and food service permitted at pubs and eateries.

Indeed, much of England is so excited about this newfound demi-freedom that some hairdressers and barbers took bookings from one minute past midnight this morning, just to give regular customers the chance of being first in.

Apparently, the government was keen to have an updated version of the NHS COVID-19 app ready in time, with added (though optional) location tracking features that would allow users to share their location logs with the health service.

We’re guessing that the government thought that a voluntary feed of location data might help with planning for reducing the risk of a new wave of coronavirus infections as the current British lockdown eases.

According to the BBC, however, this new version was blocked by both Apple and Google, and won’t be available either in the App Store or through Google Play.

(To be clear, the old version remains online for download and will keep working fine if you have it installed – the app itself hasn’t been banned or thrown out.)

Exposure notifications

The NHS COVID-19 app relies on a feature added to both iOS and Android known as Exposure Notifications, jointly created by Apple and Google:

On April 10, 2020 Google and Apple announced a joint effort to enable the use of Bluetooth technology to help governments and health agencies reduce the spread of COVID-19 through contact tracing, with user privacy and security core to the design.

Whether you love or hate Apple or Google (or feel a bit of both emotions for both companies), their combined goal in building this application programming interface (API) was laudable, given that it was neeeded quickly and globally, and given that privacy should always be coded in right from the start, even, perhaps especially, if you’re in a hurry.

On the principle that the best way to avoid losing data is not to acquire it in the first place, the API was specifically designed to avoid collecting or sharing personal data about contacts, infections and location.

As Apple’s and Google’s joint FAQ explains:

• The Exposure Notifications System does not share location data from the user’s device with the Public Health Authority, Apple, or Google.
• Random Bluetooth identifiers rotate every 10-20 minutes, to help prevent tracking.
• Exposure notifications are only done on the user’s device.
• In addition people who test positive are not identified by the system to other users, or to Apple or Google.
• The system is only used to assist contact tracing efforts by public health authorities.

Additionally, Exposure Notifications support can be turned off centrally for all apps, regardless of each app’s individual setting.

As a simple and easily-enforced additional requirement,the mobile phone juggernauts also clearly stated (our emphasis) that “[t]here will be restrictions on the data that apps can collect when using the API, including not being able to request access to location services, and restrictions on how data can be used.”

We assume that this is a sensible precaution to stop what’s known as feature creep taking hold in health authority apps.

In other words, you’re not allowed to have location-aware features of any sort in apps that use the Exposure Notifications API, no matter that your location collection is soft opt-in (e.g. collects data by default but requests permission before reading any of it back in for use) or even hard opt-in (e.g. doesn’t collect data at all until you ask it to start doing so).

This, is seems, is what has kept the new NHS COVID-19 app out of Apple’s and Google’s online stores.

An app that contains code that tries to use both the Location permission and the Exposure Notification permission is not only clearly non-compliant but also easy for Apple’s and Google’s app verification systems to detect automatically.

What to do?

This is more of a “what did they expect?” moment for the developers of the NHS COVID-19 app than a reason to start panicing about your pandemic privacy.

But it is a fantastic reminder to review what permissions you have already granted, perhaps without even realising it, to apps that you have already decided to install on your phone.

After all, there’s not much point in worrying about a government app that might ask you if you want to share personal tracking data with your health service…

…if you are going to let other apps read your location in detail whenever they like, including apps with names such as Totally Not Free Fleeceware Compass App That Is Inferior To The Builtin One Yet Costs $149.99 After Three Days Even If You Uninstall It After Just Three Minutes In Frustration At How Useless It Is.

Fleeceware, by the way, is the name we use to describe apps that that you almost certainly want to stay away from because they are designed to seduce you, often with exaggerated claims and hundreds or thousands of fake 5-star reviews, into signing up for a short “free” trial that automatically rolls over into a paid subscription after as little as 48 hours if you aren’t careful.

So, please take this opportunity to read our 5 top mobile privacy tips:

And watch our Naked Security Live video:

[embedded content]

---

The annual Pwn2Own contest features live hacking where top cybersecurity researchers duke it out under time pressure for huge cash prizes.

Their quest: to prove that the exploits they claim to have discovered really do work under real-life conditions.

Indeed, Pwn2Own is a bug bounty program with a twist.

The end result is still responsible disclosure, where the affected vendor gets a chance to fix any flaws before they are made public, but the bug hunters don’t just submit their bug descriptions with a list of instructions for the vendor to follow and investigate.

The competitors are faced with a standardised, patched, vanilla configuration of the system they’re targeting, set up for them on hardware they didn’t choose theselves, and they have just 30 minutes in which to complete their attack during the competition.

That means there is very little time to adjust, adapt, rethink and rewrite code during the timed part of the event itself, so this really is a showcase for meticulous research, scrupulous preparation, careful rehearsal…

…mixed with a dash of je ne sais quoi and a dose of plain old luck.

The “plain old luck” factor exists because the participants do their demonstrations one after another over three days, with the order chosen randomly just before the competition starts.

If two teams show up with the same exploit, and both of those exploits succeed within the allotted time, then the winner isn’t the one who can prove they found it first during their research phase, but the one who just happened to get the earlier demonstration slot in the draw.

Clearly, the earlier the slot you draw, the less likely you are to get scooped by someone else who just happened to have found the same bug as you.

Greetz from Texas

Traditionally, the North American Pwn2Own event has taken place alongside the annual CanSecWest security conference held in Vancouver, Canada, but this year the official host city was Austin, Texas.

For obvious reasons, the actual hacking teams were distributed all over the world, rather than all travelling to meet in one place.

The full results for 2021 can be found on the Pwn2Own blog, including those who tried but failed, or those who tried but didn’t win any money because some part of their exploit chain was already known.

In some cases, competitors lost out because their exploits had been reported to the vendor before the competition by someone else, but not yet publicly disclosed; in other cases, they lost out simply through the bad luck of drawing a later slot in the competition than other participants who had brought along and exploited the same bugs.

We’ve listed the money-winning entries below – note that this year’s prize money totalled a very healthy $1.21 million!

The prize hierarchy looked like this:

• $200k for code execution on a server or messaging platform
• $100k for code execution via a browser
• $40k for breaking out of a virtualised guest OS into the host OS
• $40k for “getting root” (more properly, SYSTEM) on Windows 10
• $30k for “getting root” on Linux

In case you are wondering, EoP below is short for elevation of privilege, which means exactly what it says: it doesn’t get you into a system in the first place, but it does gets you up to superpower level once you’re in.

Particpant Platform Pwnership level Prize
---------------------------- ------------------ ---------------- --------
DEVCORE Microsoft Exchange Server takeover $200,000 'OV’ Microsoft Teams Remote code exec $200,000
Daan Keuper/Thijs Alkemade Zoom Messenger Remote code exec $200,000
Bruno Keith/Niklas Baumstark Chrome and Edge Remote code exec $100,000
Jack Dates Apple Safari Kernel code exec $100,000
Jack Dates Parallels Desktop Escape to host $40,000
Sunjoo Park Parallels Desktop Escape to host $40,000
Dao Lao Parallels Desktop Escape to host $40,000
Benajmin McBride Parallels Desktop Escape to host $40,000
Team Viettel Windows 10 EoP to SYSTEM $40,000
Tao Yan Windows 10 EoP to SYSTEM $40,000 'z3r09’ Windows 10 EoP to SYSTEM $40,000
Marcin Wiazowski Windows 10 EoP to SYSTEM $40,000
Ryota Shiga Ubuntu Desktop EoP to root $30,000
Manfred Paul Ubuntu Desktop EoP to root $30,000
Vincent Dehors Ubuntu Desktop EoP to root $30,000 ================= TOTAL $1,210,000

Interestingly, there was a tenth product that was attacked in the competition, but that doesn’t show up in the list above because it remained unpwned within the allotted time: Oracle’s VirtualBox virtualisation software.

See you next year!

Congratulations to everyone who took part…

…and good news for all the rest of us, because all the bugs that were painstakingly uncovered, understood and used in the attacks above – and note that many attacks required a number of different exploits to be unleashed in a specfic sequence – will now all be fixed.

To learn more about vulnerabilities and how attackers chain them together for more devastating results, listen to our Understanding Vulnerabilities podcast below:

---