Category Archives: News

Android malware uses coronavirus for sextortion and ransomware combo

Late last week, researchers at network intelligence company DomainTools warned about an Android malware sample that caught our attention.

Like many other cyberthreats doing the rounds these days, the criminals have used the coronavirus pandemic as a lure, offering an intriguing if rather creepy app called COVID 19 TRACKER.

Catchy icon of the malware app

The app offers to “Track Real-Time Coronavirus Outbreak in your Street, City and State”, and says it will “Get Real-Time Statistics about Coronavirus outbreaks around you in over 100 countries.”

Main malware landing page when browsing from Android

To be precise, if you’re keeping your eye out for giveaway mistakes, it actually says outbreak aroud you, an error both of grammar and spelling that you can see below.

Sure, mainstream websites make spelling mistakes, too, but every clue helps, so keep your eyes open for errors that might be a telltale sign of crooks in a hurry.

As we’ve seen before in coronavirus-themed cybercrime, the criminals have added the logos of various legitimate and useful sources of information:

Left: Main malware landing page when browsing from Android
Right: Download button with fraudulent “certification” claims

This time, they’re claiming their app is “certified by” the US Department of Education, the World Health Organization (WHO), and the US Centers for Disease Control and Prevention (CDC).

(No, that’s not a typo above: the CDC runs its operations and research from numerous major locations, so its name is a plural.)

If you’re wondering why the feature to track coronavirus infections in more than 100 countries has what looks like a winner’s gold cup above it with the number “1” on it, it’s because the crooks have plundered various legitimate apps and brands to leech logos, layout ideas, icons and more to use in their code.

The marketing material that the crooks have crudely ripped off comes from the pages of an unrelated Google Play app that really does have a 4.4-star rating:

Left: ripped-off web site content repurposed by malware authors
Right: original marketing from unrelated Google Play app

What about the the app?

As you can see from the screenshot above, the “tracker app” doesn’t come from Google Play, because it wouldn’t get in.

Instead, you have to go off-market by downloading it directly from the crooks’ website by clicking their own [DOWNLOAD APK] button.

When you run the app for the first time, it asks for various permissions that might make you suspicious, but that don’t seem too outrageous, given that it’s supposed to keep you alerted about coronavirus cases as you move around.

In particular, the app wants to run in the background, to have lockscreen access, and to use Android’s accessibility features, as you see here:

Left: background permission is requested immediately
Right: clicking the [SCAN] button on the app screen demands you to grant more permissions first

Although the malware claims to need lockscreen access to give you an “instant alert when a coronavirus patient is near you”, that’s bogus for two reasons.

Firstly, even if the app is using the latest coronavirus stats, downloaded in real time, it has no way of determining the infectious status of any individual passing by, so it is false (and, indeed, creepy) to claim this as a “feature” at all.

Secondly, you don’t need “lockscreen access” to send notifcations to the lockscreen – that’s controlled by the user, who can choose from their phone’s settings what sort of notifications to show when the phone is locked.

In fact, the malware wants what’s called device admin rights, as you can see in the screenshot below.

This is a feature that Google describes in its own documenation as allowing “device administration features at the system level, [to] allow you to create security-aware apps that are useful in enterprise settings.”

Similarly, if this app were genuine, it wouldn’t need Accessiblity permissions, as it claims.

Those features are intended for use by software such as screen readers (which obviously need to access the screen content of other apps), and they’re tolerated on Google Play for security apps that can justify looking out for data such as web links in order to look for malicious sites.

The app claims that it needs Accessibility permissions by mentioning “active stats monitoring”, but a legitimate program would get its data by downloading and processing it itself, not by “sneaking a peek” and stealing it from other apps.

Left: malware demands device admin powers, though they aren’t needed for lockscreen notifications
Right: malware uses Accessibility functions to track your app usage

What happens next?

The real reasons why this malware wants to run in the background, monitor the other apps you are running, and intervene as a device administrator…

…are probably rather obvious, given the headline of this article.

Amongst other things, it tracks which app you have in the foreground and takes over control as soon as you try to use your phone for most of its normal features, including making calls, getting and sending messages, and accessing the Settings page.

And the Settings page is probably exactly where you will want to go as soon as a the malware kicks in, which is does within about a second of launching most apps:

The malware locks you out of most apps by quickly covering them entirely with a blackmail demand.
The demand mixes sextortion with ransomware.

As you can see, this one is a combination of sextortion and ransomware – you’re locked out of your device because of the persistent pop-over screen, but with a threat to leak personal videos and photos to your family as an added incentive to pay up.

Once you’re infected, you can’t access Settings (where you can, in fact, kill off and uninstall the malware), in an attack reminiscent of Reveton, one of the earliest mobile phone “screen locker” ransomware variants that was widespread back in 2012.

Ironically, the malware is careful not to block your browser, even though you could use it to go online and look for advice on how to clean up.

That’s because the malware itself relies on the browser to load its own “here is how it works” page, hosted on the free data-sharing site Pastebin:

Instructions for how much to pay and whom to contact

How to clean up

Fortunately, at least in our experiments with this sample, the malware was fairly easy to remove by hand.

Our files were left intact, with the malware relying on its rapid pop-over screen as its way of keeping you locked out of your device, and as far as we can tell, the threat to reveal your personal data to friends and family if you don’t pay is entirely empty.

In other words, if you can remove the app so it no longer interferes with your phone usage, then you’re essentially home free.

A quick fix is offered by the fact that the crooks were lazy, and hardcoded the unlock code into their app:

Hardcoded unlock PIN in the malware

When we typed in the 10-digit code 4865083501 where you see enter decryption code in the blackmail page shown above, the malware stopped blocking our access to other apps.

Note, however, that the unlock code doesn’t actually stop the malware and uninstall it!

(The crooks handily left logging code in their app, so we could use the Android development tool adb logcat to watch the app continuing to abuse its Accessibility permissions to track apps as we used them, even after we’d entered the unlock code.)

But after entering the unlock code, we were able to access the Settings page, remove the malware’s device admin rights and uninstall it.

We used Settings > Apps and notifications > See all N apps to reach the App info page, where we located the Coronavirus Tracker app:

Left: the top-level App info page
Right: the malware shows up as “Coronavirus Tracker”

We tapped on the malware entry to open up its own App info page, where we used the system’s Uninstall button to get to the Deactivate & uninstall option, by which the system will demote the app from its device admin role (which prevents regular uninstallation) and then remove it:

Left: the [Uninstall] button on the system App info page
Right: uninstalling from here lets you remove device admin and the app in one go

We also tried rebooting our phone in Safe Mode, where most background apps don’t run, to see if we could remove the malware without relying on the unlock code – even though we know the right code for this sample, it might be different in other variants of the malware.

Also, there is something unappealing about trying to remove the malware while it’s still active and keeping track of what you’re up to on the device.

On our phone, Safe Mode is activated by holding the power button until the reboot menu appears, then holding down the power off icon for a second or two until the Safe Mode menu appears.

After a reboot, the text Safe mode appeared at bottom left of the screen; the malware didn’t launch; and we could use the same procedure as we did above to locate, deactivate and uninstall the malware.

What to do?

Not all mobile malware is this easy to get rid of, and most ransomware these days no longer just locks your device but also scrambles your files so that they need decrypting, too.

And many crooks have learned not to take shortcuts with their passwords, so it’s unusual to find an unlock key right there in the malware code.

So, your best bet is not to let your Android get infected in the first place.

  • Stick to Google Play. It’s not perfect, but it would almost certainly never have admitted this app, not only because of its coronavirus theme, but also because of its blatant abuse of permissions.
  • Use a third-party anti-virus in addition to the standard built-in protection. Sophos Intercept X for Mobile is free, and it will not only block malware from running in the first place, wherever you download it from, but also keep you away from risky websites to start with.
  • Never believe an app’s own propaganda. In this case, the crooks simply stole a marketing history from an existing app and claimed it as their own, complete with a positive review rating. On-site reviews are largely meaningless – they could have come from anywhere, and probably did. If you need advice, ask someone you actually know and trust.
  • Don’t grant permissions to an app unless it genuinely needs them. Decently-behaved apps generally still work, albeit with limited features, even if you withold some permissions, so this malware’s trick of demanding unreasonable permissions before it runs at all should be considered suspicious.

Oh, in case it makes you feel better, the total amount that the crooks have received into the Bitcoin address shown in the Pastebin page above…

…is zero.


VMware patches virtualisation bugs

Virtualisation company VMware patched two bugs this week that affected a large proportion of its client-side virtual machines (VMs).

VMware made its name offering server virtualisation products that recreate server hardware in software, allowing admins to run many virtual servers on the same physical box at once. Most ‘type one’ server hypervisors, including VMware’s, run directly on the bare metal instead of an installed operating system.

The company also has another strand to its business, though: ‘type two’ hypervisors that enable people to run guest operating systems in virtual machines (VMs) on their client devices, too. These let you run Windows or Linux on a Mac, for example. They work differently, running on top of the client operating system as applications, meaning that you don’t have to replace your core operating system to run VMs.

Finally, its desktop virtualisation system, called Horizon, puts the whole desktop environment on a server so that users can access it from anywhere.

Between them, these bugs affect all of these services in some way. CVE-2020-3950, which VMware gives as a CVSS v3 store of 7.3, affects version 11 of Fusion, its type 2 hypervisor for Macs. It’s a privilege elevation vulnerability stemming from the improper use of setuid binaries (setuid is a *nix tool that lets users run certain programs with elevated privileges). It also affects two other programs for the Mac: Versions 5 and prior of the Horizon client that lets Mac users log into virtual Horizon desktops, and version 11 and prior of the Virtual Machine Remote Console that lets Mac users access remote virtual machines.

CVE-2020-3951 is less dire, getting a CVSS v3 score of 3.2 and a low severity ranking (that comes from VMware, as the National Vulnerability Database entry hadn’t been updated at press time). It’s a denial of service vulnerability in Cortado ThinPrint, a third-party software tool that VMware integrates natively into virtual machines to give them printing functionality.

This bug affects version 15 of the VMware Workstation type 2 hypervisor for Windows, along with version 5 and prior of the Windows Horizon client. It’s a heap overflow problem that allows a non-administrative VM user to “create a denial-of-service condition of the ThinPrint service”.

Last week’s bugs

This is the second advisory in five days for VMware, which announced three other bugs on 12 March. These included a critical flaw, CVE-2020-3947, which affected Workstation on all platforms and the Fusion Mac software. This use-after-free flaw could enable code execution on the host computer from the guest OS, it said.

The other two bugs were ranked important. There was a privilege elevation in the Horizon, VMRC, and Workstation clients on Windows, ranked important (CVE-2019-5543, CVSS v3 7.3), which allowed a local system user to run commands as any user. Another bug in ThinPrint, ranked important (CVE-2020-3948, CVSS v3 7.8) also allowed a privilege elevation that could give non-administrative users root access on Linux VMs.


Latest Naked Security podcast

Slack fixes account-stealing bug

Slack has fixed a bug that allowed attackers to hijack user accounts by tampering with their HTTP sessions. The flaw could have allowed attackers to pilfer users’ cookies, giving them full account access. They could also have automated those attacks at scale, said the researcher who discovered it, Evan Custodio.

The bug uses a sneaky trick called HTTP smuggling, which takes advantage of how back-end servers process requests using this protocol. Browsers use HTTP to ask web servers for pages and other resources. Those requests generally go through multiple servers. A front-end proxy server might send it to one of several back-end servers, for example. The front-end server often serves as a clearinghouse for requests from different browsers, meaning that different peoples’ sessions with web applications mingle in the same traffic stream.

The problem lies in the way that HTTP communications announce themselves. This announcement, known as an HTTP header, has to tell the server where the request ends. It does this in one of two ways.

The first uses a Content-Length header that tells the server how many bytes long the request is. The second uses a Transfer-Encoding: chunked header. This tells the server that the content comes in chunks, which end with a zero-sized chunk.

An HTTP request is only supposed to use one of these headers, but HTTP smuggling attacks use both of them to confuse the front-end and back-end servers. The idea is to make each server process the request differently.

Custodio discovered that Slack was susceptible to a variant of the HTTP smuggling attack called CLTE, in which the front-end server uses the Content-Length header while the back-end server uses the Transfer-Encoding one. Each header specifies a different amount of content to process, causing the front-end server to process more content than the back-end one.

The part of the content that the back-end server ignores is the malicious content. It still sees this content, but the attack causes it to interpret that text as the start of the next HTTP request, enabling the attacker to replace the next request’s legitimate header with their malicious one. Because the front-end server blends requests from different people in the same stream, this lets them affect someone else’s communications with the back-end server.

The researcher worked out a way to steal a user’s session data using this technique. He used the CLTE flaw to attach a malicious HTTP GET request that caused a 301 redirect error. Slack used the malicious URL as the redirect location.

Because this GET request replaces the header of a victim’s own HTTP request, it redirects that victim’s traffic to the malicious URL, Custodio explained, giving an attacker access to their session cookies (effectively owning their account). He added:

[…] it is my opinion that this is a severe critical vulnerability that could lead to a massive data breach of a majority of customer data. With this attack it would be trivial for a bad actor to create bots that consistantly [sic] issue this attack, jump onto the victim session and steal all possible data within reach.

Custodio posted the discovery via Slack’s HackerOne bug bounty program in November, and Slack fixed it in 24 hours. He won a $6,500 bounty and got the go-ahead to make it public on 11 March.


Latest Naked Security podcast

Tor browser fixes bug that allows JavaScript to run when disabled

The Tor browser has fixed a bug that could have allowed JavaScript to execute on websites even when users think they’ve disabled it for maximum anonymity.

The Tor Project revealed the issue in the release notes for version 9.0.6, initially suggesting users manually disable JavaScript for the time being if the issue bothered them.

That was subsequently revised after the NoScript extension – used by Tor to control the execution of JavaScript, Java, Flash and other plugins – was updated to version 11.0.17.

Whether the issue matters depends on how users have configured Tor to treat JavaScript.

Tor’s ‘standard’ setting enabled JavaScript by default, which users can upgrade to either ‘safer’, which disables JavaScript on non-HTTPS sites, or ‘safest’, which disables JavaScript completely.

Each setting has its pros and cons. Leaving JavaScript enabled opens users to the hypothetical risk that their anonymity might be compromised, for example using a vulnerability in the underlying Firefox browser.

There have been a small number of reports of this happening, for example in 2013, and again in 2016 when Mozilla issued a patch to fix a real-world JavaScript attack aimed at Tor by a government. On the other hand, many websites rely on JavaScript and disabling it can cause them to break, or at least work less well.

The new upgrade alert is urgent for anyone using Tor in the ‘safest’ setting. In short, the bug might in some circumstances allow JavaScript to continue to function even though this setting disallows that. Tor release notes advise that the extension will normally update automatically:

Noscript 11.0.17 should solve this issue. Automatic updates of Noscript are enabled by default, so you should get this fix automatically.

Why not just use NoScript to whitelist JavaScript on trusted sites, as is the case when used with non-Tor browsers?

Users can’t do this in Tor because doing so might make things even less secure – the act of enabling JavaScript only on some websites could itself become an inadvertent cookie used to fingerprint users as they pop up around the web.

That means that for everyone using Tor, JavaScript is either on or off with no ambiguous ‘on sometimes’ halfway house.

Things could be worse. Last year, a problem with digital signatures caused Firefox and Tor to temporarily stop trusting lots of add-ons, including NoScript. Unsure of what was going on, cautious users who understood NoScript’s importance had stopped using Tor until the problem was fixed.


Latest Naked Security podcast

Microsoft patches wormable Windows 10 ‘SMBGhost’ flaw

What’s the difference between a scheduled security update and one that’s out-of-band?

In the case of the critical Windows 10 Server Message Block (SMB) vulnerability (CVE-2020-0796) left unpatched in March’s otherwise bumper Windows Patch Tuesday update, the answer is two days.

That’s how long it took Microsoft to change its mind about releasing a fix after news of the remote code execution (RCE) flaw leaked in now-deleted vendor posts and word spread to customers. It even gained a nickname – ‘SMBGhost’ – in honour of its elusive status.

It wasn’t simply that word had slipped out about an unpatched flaw but the seriousness of the flaw itself, with one of the leaked advisories describing it as ‘wormable,’ in other words able to spread very rapidly.

Seeing double

To a lot of people, that sounded eerily similar to the wormable SMBv1 vulnerability exploited by the global WannaCry and the NotPetya attacks in 2017.

The SMB protocol is widely used to connect printers and network file sharing, so the possibility of a repeat alarmed admins. As Microsoft said:

To exploit the vulnerability against an SMB Server, an unauthenticated attacker could send a specially crafted packet to a targeted SMBv3 Server.

(There’s more on possible exploit scenarios in the detailed analysis from SophosLabs.)

After initially suggesting partial workarounds – disabling SMBv3.1.1 compression on servers and blocking port 445 using firewalls – Microsoft has now issued a patch, KB4451762.

That’s good news because blocking port 445 would be a last resort, as it’s used by other bits of Windows plus things like Azure file storage. These also didn’t do much for desktop computers.

The issue only affects 32/64-bit Windows 10 and Server versions 1903 and 1909 because earlier versions don’t support the affected SMBv3.1.1.

It’s unlikely the flaw is being exploited in real-world attacks yet, but that could change at any time. There are bound to be some servers that won’t receive the patch in the coming weeks.

Those will be at risk of a serious compromise. The solution is to make haste and patch now.


Latest Naked Security podcast

go top