Month: August 2020

We are only 5 weeks away from the anniversary of the birth of modern ransomware, Sept. 5, 2013. I mark that day as a turning point because it was the day anyone spotted the first sample of Cryptolocker.

That fledgling ransomware pioneered a new technology to extract wealth from victims, which, in past cyberattacks, had always been the hardest path to success. Money is inherently traceable and is difficult to obtain electronically if you are a criminal, but Cryptolocker had a new trick up its sleave. Bitcoin.

Here we are seven years later scratching our heads, still thinking about what to do to defend ourselves against ransomware. You would think in seven years we ought to have gotten better at deterring attackers from this type online crime.But, like almost everything in information security, ransomware is a complicated, and an attack that has only grown more complex, particularly in the last 10 months.

One measure of our success is to force the criminals to up their game, and if we are effective at this we should see a reduction in attacks or a shift to something else or new techniques. For example, when we got together to stop fake anti-virus from using shady credit card processors, criminals moved onto ransomware.

Based on this,  you could argue that we, as an industry, have been very successful at stopping ransomware. When ransomware was introduced it depended on infecting large numbers of innocent people and demanding $400-$1000 US dollars each to make money, causing widespread harm. These attacks were automated and were largely a numbers game. This is not how ransom attacks look today. Once again, the attackers shifted.

We have upped our security game with regard to patching and far more sophisticated endpoint security technologies which make mass infection not worth the effort, if you’ve got skill. Bypassing security tools is hard and if you hurt millions of people per month, vendors will be sure to make sure your attacks fail. Attackers need a bigger payoff to make it worth bypassing the security protections. Ideally they want it to be harder for security companies to get samples to analyze the latest bypass, extending its useful time as a tool of ill repute.

Drastically reducing the super low-hanging fruit like out-of-date Adobe Flash Player and abandoned versions of Oracle Java has also forced a shift and has kicked off a stratification in the malware operator ecosphere. “Script kiddies” will never go away, but the harm they cause is less than ever before and the risks they pose have been minimized by our improved hygiene. The response to this has been those with actual skills separating from the pack and upping their game.

Mass scale attacks are risky, so those with these skills began to develop far more sophisticated attacks, often taking pages from nation-state playbooks, but being just cautious enough to avoid activities that could potentially land them in prison. Because of these attacks require a higher caliber skill set more time is invested, the payoff needs to be much higher. .

The result is that average organizations, not just governments and defense contractors, now have human adversaries. This was not in most organizations’ plans. They were and are woefully unprepared for this new reality which has led to the deluge of news stories about ransom, extortion and data breaches.

One of the most significant of the recent innovations has been a concerted effort to bypass security tools. Because there is a human at the keyboard, the methods and tactics utilized differ in nearly every attack. If they can phish a password for an admin, they log into the security management console and simply turn everything off. If that doesn’t work, groups like Snatch have turned to booting into Windows “safe mode” where many security protections are disabled before launching their encryption routines. And, now, with Wasted Locker, we are seeing the depths of internal Windows behaviors like memory mapping and caching being abused to bypass behavioral anti-ransomware technologies.

These evasion techniques are rapidly changing and we don’t expect this to slow down. Humans are hand crafting artisanal malware and carefully deploying it at low volumes in an attempt to stay below the radar. They don’t just clobber everything in sight, they carefully select which systems to steal data from and only incapacitate your most valuable assets. This takes a bit of time which can be an advantage to defenders, if they are well prepared to hunt down the telltale signs.

If the door is even open a crack, they can and likely will get in. Exposed servers with remote desktop (RDP) enabled, administrators without multi-factor authentication for remote access, unpatched web servers or even these same issues at a trusted partner or service provider are enough to provide opportunity to take you down this well-trodden path.

If your tools succeed at blocking the initial attack, they will not just give up. They are humans and will find a way around any programmatic barrier. Humans are tenacious, we are creative and we don’t give up easily. To defend against this you need humans to sort the wheat from the chaff. Tactics change on a weekly basis and knowing the signs of your own tools turned against you is the key to early detection.

This is a war, not a battle. To stay ahead you need to be vigilant and have the right people, the right training and the right tools. The days of loading security software on your endpoints, dusting off your hands and walking away are long gone.

The criminals have hybridized their attacks combining automation to find victims with a gap in their defenses and humans to creatively use existing tools from the victims own network against themselves. This business model  can net them millions of dollars per victim and cause uncountable additional damage.

Our defense needs to use the same approach. Computers, automation and tools are amazing, but combined with human intellect, pattern recognition and our ability to extrapolate from the past into the future they provide a formidable defense. Those that are having success at defending themselves almost always have the right mix of investment in people, training and tools.

No organization sets out to become a victim of cybercrime. But if there are security gaps in terms of misconfigurations, exposed assets or unaddressed vulnerabilities, it is likely that cyberattackers will find and exploit them, and it could be months or even longer before the victim finds out what’s happened. Sophos’ incident responders help businesses to identify, block and mitigate the impact of attacks. As a result, they see at first-hand how cybercrime affects victims.

Total security is a myth

The standard cybersecurity maxim is that defenders need to be right all the time, while an attacker only needs to be right once. This is a demoralising message for IT security teams and only partially true. You need layers of security that can break the attack chain in different places. This approach matters because attackers are becoming very skilled at disguising themselves to avoid arousing the suspicion of security teams and triggering detection.

They do this by, among other things, abusing legitimate IT tools to bypass security technologies, scan computers and move laterally through the network. In addition, they regularly compromise existing admin accounts so they can hide in plain sight. If they are stopped in their tracks, they will try something else.

This brings us to one of the most significant aspects of cyberattacks and one that victims often underestimate: you are not fighting code; you are fighting people.

Hands on keyboards

While the initial breach may be automated and possibly opportunistic, once the attacker has a foothold inside your network, it is often a person who operates the tools and attack and they are targeted and determined.

In one incident witnessed by incident responders, an adversary tried to compromise a victim through four different attack methods in the space of just 15 minutes. After all attempts were blocked, the attacker tried using the often-unprotected route of RDP, at which point they revealed the IP of the computer they were using and identified themselves to the security team. Game over.

The challenging thing for victims is that the frequent use of legitimate tools by attackers means IT security teams have to be extra vigilant about discovering whether or not these tools are being used for malicious purposes.

How long have attackers been in your network?

According to incident responders, most victims believe a breach happened just before the visible part of the attack, ie. ransomware, took place, when this is actually rarely the case. In fact, the attackers are likely to have been in the network for considerable time, hiding under the radar while scanning systems, installing backdoors, stealing information, and securing persistence so they can pick back up/resume? after a reboot. These are all security issues that victims will have to check for and mitigate to fully recover from an attack, adding pressure to an already stressful situation.

The part of the attack that most often alerts victims to the presence of an intruder is the launch of ransomware. This is the point at which the attacker has probably done everything they want to do in the victim’s network and is ready to break cover and make some noise. In other words, the implementation of ransomware generally marks the end of an attack not the beginning.

Rampant ransomware

Around 90% or so of the attacks seen by incident responders involve ransomware and the impact of the attacks are often devastating, particularly for organizations where there is real-world impact. This includes healthcare entities, where a successful attack means cancelled operations, lost X-rays, encrypted cancer scan results, and more.

Some victims feel they have no option but to pay the ransom, for example those whose online or otherwise accessible data backups have been deleted by attackers. Other organizations refuse to pay, no matter what the circumstances.  Some worry more about the reputational impact of stolen data being exposed than about paying for decryption keys. The ransomware itself ranges from the business-like and sophisticated to low grade and messy. Incident responders have learned that while all attacks are exhausting and intimidating for victims, they sometimes reveal mounting stress and anxiety on the part of the attackers too.

One example of this was an organization hit by the ransomware-as-a-service offering REvil/Sodinokibi. Overnight, the attackers encrypted 90% of the company’s servers and the business ground to a halt. The attackers had gained access to the company’s critical financial systems and took full advantage of this in their ransom demand communications.

The first ransom demand for $3 million USD arrived within a day. The accompanying note sought to justify the cost by listing the company’s various income streams, the fact that it was eligible for a loan from a named bank, the potential costs of the impact of the ransomware, and the monthly repayments if the company took out a loan from the bank to pay the ransom. The note also pointed out that the company’s tax declaration did not seem to fully match its actual revenues. None of this achieved the desired result since the business, which didn’t have anti-ransomware insurance in place, declined to pay.

Matters escalated quickly. Further emails with threats poured in and started to target individual employees with details of their personnel records. Then the whole company received an email exhorting them to persuade their senior executives to pay the ransom, which by then stood at $8 million USD. Finally, the attackers started to phone the by then worn out IT team, telling them to read their email and pay.

The victim never paid. They restored what they could and took the hit as the attackers dumped three loads of company data online. The company is still in business.

The challenge of rebuilding

Incident responders note that many victims struggle to understand how ransomware moves through the organization. There is a general assumption that it spreads outwards in all directions when in fact it is strategically deployed to a pre-selected list of machines. Further, the attackers don’t just target documents and other data, they get as close as they can to ‘bricking’ the machines without actually doing so. They leave just enough capability for the victim to be able to boot the machines and see the ransom note.

What this means for victims is that recovery doesn’t begin with restoring backups and then addressing what else the attackers accessed or stole. It often starts with the significant challenge of rebuilding all the affected machines and the difficult task of identifying where the adversary launched the attack from and whether they still remain inside the network.

Building a better security guard

As attacks become stealthier and better at abusing legitimate tools and processes, the value to victims of human-led threat hunting is clear. Threat hunting complements the advanced algorithms of next generation security software with 24/7 human expertise that can evaluate the nuances of an attack in a way software can’t.

It’s like having CCTV: cameras alone can record and may deter a crime, but they can’t actively stop it. It’s the security guard watching the CCTV live who can take action. Too many IT security teams still turn up to work one morning to discover what has been done to them, rather than to learn what could have happened, but didn’t.

It’s a lot easier to change a ransomware’s appearance (or obfuscate its code) than to change its underlying goals or behavior. After all, ransomware must necessarily reveal its intent when it strikes. But there are behavioral traits that ransomware routinely exhibits that security software can use to decide whether the program is malicious. Some traits – such as the successive encryption of documents – are hard for attackers to change.

The author of the WastedLocker ransomware cleverly constructed a sequence of maneuvers meant to confuse and evade behavior based anti-ransomware solutions. We’ll discuss some of those tricks below, but it’s also worth mentioning that a code analysis we’ve performed on WastedLocker shows something else we didn’t expect: some of the specific techniques WastedLocker ransomware employs to obfuscate its code and perform certain tasks mirror the subroutines we’ve seen previously used by another ransomware, Bitpaymer, and in the Dridex trojan – too closely to have been a coincidence, in our opinion.

Evasion takes center stage

Ransomware creators are acutely aware that network or endpoint security controls pose a fatal threat to any operation, so they’ve developed a fixation on building complex logic for detecting and subverting those controls. Modern ransomware spends an inordinate amount of time attempting to thwart security controls.

Most of the advancements we observe in ransomware development can be categorized as survival skills, so the malware remains undetected just long enough to encrypt the target’s files. Survival demands that static and dynamic endpoint protection struggle to make a determination about a file based on the appearance of its code, and that behavioral detection tools are thwarted in their efforts to determine the root cause of the malicious behavior.

Many malware families employ code obfuscation techniques, like runtime packers, as a way to thwart analysis, but a few have taken this a step further. Bitpaymer, for example, uses a unique method that calls Windows API functions using a hash of the function call, rather than the call itself. WastedLocker appears to have adopted this technique and that adds an additional layer of obfuscation by doing the entire thing in memory, where it’s harder for a behavioral detection to catch it.

Over the years, ransomware file system behaviors have, largely, remained consistent. (This year’s Ryuk and REvil attacks exhibit the same file system behaviors as CryptoLocker from 2013, for example.) Ransomware defenses based on behavior monitoring are typically tailored to detect this universal telltale activity. Now that things have changed a bit, the tactics we use to detect this behavior will have to change as well.

Memory tricks may thwart behavior monitoring

Before diving into the tricks, you need to know that ransomware defenses based on behavior monitoring typically implement a minifilter driver. Minifilter drivers are kernel drivers that attach to the file system stack. Minifilters filter I/O operations in order to keep an eye on everything that happens to files. For example, the well-known Process Monitor utility from Sysinternals uses a minifilter driver to create a real-time log of file system activity. Most anti-ransomware solutions use a similar approach to keep an eye on what happens to files.

WastedLocker uses a trick to make it harder for behavior based anti-ransomware solutions to keep track of what is going on: using memory-mapped I/O to encrypt a file. Although it is unnecessary for ransomware to access documents as a memory-mapped file (MMF), the method is more common nowadays, as Maze and Clop also employ the same tactic.

This technique allows the ransomware to transparently encrypt cached documents in memory, without causing additional disk I/O. For behavior monitoring, this may be a problem. Tools used to monitor disk writes may not notice that ransomware is accessing a cached document, because the data is served from memory instead of from disk.

But the kicker here is that WastedLocker is closing the file once it has mapped a file in memory. You’d think this would result in an error, but the trick actually works because the Windows Cache Manager also opens a handle to the file once a file is mapped into memory.

Cache Manager’s lazy writer

The Cache Manager is a kernel component that sits between the file system and the Memory Manager. If a process accesses the mapped memory, the memory manager will issue a page fault and the Cache Manager will read the necessary data from disk into memory. The more memory is accessed, the more pages will be read from the disk into memory via so-called paging I/O.

The Memory Manager also keeps any eye on memory that has been modified, so-called dirty pages. If a process encrypts the mapped memory, the memory manager knows which pages need to be written back to disk. This writing is done by the Cache Manager’s Lazy Writer.

The Cache Manager implements a write-back cache with lazy write. This means that dirty pages are allowed to accumulate for a short time and are then flushed to disk all at once, reducing the overall number of disk I/O operations. This also means that the writing is not done in the context of the process but in the context of the system (PID 4). It’s this aspect that can be troublesome for anti-ransomware solutions, as it becomes harder for an anti-ransomware tool to determine which process wrote to the file.

Complications

The WastedLocker ransomware closes its file handle right after it has mapped the file into memory as can be seen in the following screenshot:

Closing the file handle right after the file has been mapped into memory is allowed as the documentation states:

Mapped views of a file mapping object maintain internal references to the object, and a file mapping object does not close until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile and close the file mapping object handle by calling CloseHandle. These functions can be called in any order.

Anti-ransomware solutions that correlate activity based on CreateFile and CloseFile operations will miss all the disk I/O performed by the Cache Manager in response to mapped memory operations. This can be observed by the following screenshot:

Ultimately, the Cache Manager will release its internal handle to the memory-mapped file. This may happen after a few minutes, but we have observed that the Cache Manager closes the handle only after several hours.

(For more information on the Windows Cache Manager, refer to Windows Internals, Part 2.)

Code evolution from an unexpected source

Interestingly, an analysis of the WastedLocker code gave rise to a hypothesis that it may be an evolutionary descendent of Bitpaymer. Analysts familiar with both found noteworthy similarities (possibly even rewritten code) that seem to be more than a coincidence.

• Abuse of Alternate Data Streams (ADS)

Both Bitpaymer and WastedLocker abuse ADS in the same way: The malware finds a clean system file, copies itself to the clean file’s ADS, and then executes itself as a service component of the clean file. This makes it appear that the clean file is the source of the ransomware behavior. They both accomplish this using the same technique: They reset the privileges of the targeted system file using icacls.exe in order to add the ADS component, and then copy the clean system file to the %APPDATA% folder.

• Customized API resolving method

Bitpaymer uses custom API resolve functions to call Windows APIs using a hash value, rather than the API function’s name. The same code was also used by Dridex malware, and was consistently seen in many earlier Bitpaymer variants. With WastedLocker, the author did a major upgrade to the codebase by removing these functions. Instead, it calls the Windows API directly in memory.

The change it has improved the efficiency of the malware execution without spending much time in computing the hash and calling the API dynamically. Since this custom API Resolve function gets called in every single API call, the similar-behaving function code looked totally different during analysis.

Both ransomware use a similar User Account Controls bypass technique to elevate the clean, hijacked process to run the ransomware code (using the ADS technique, above). Bitpaymer adds a .cmd file to the registry key (“HKCUSoftwareClassesmscfileshellopencommand”), such that, when an elevated eventvwr.exe file is executed, it checks the registry key (by default) and that, in turn, executes the .cmd file that runs the ransomware binary. With WastedLocker, it uses winsat.exe and winmm.dll to run the ransomware binary (ADS component) by patching the winmm.dll.

Bitpaymer has slowly over time improved the encryption method it uses. Initial variants of Bitpaymer use an RC4 key for encrypting the file content, and it further encrypts the RC4 key using a 1024-bit RSA public key. But later variants of Bitpaymer (as well as current versions of WastedLocker) made some improvements by using AES 256 bit CBC mode for encrypting the files, along with a 4096-bit RSA public key. Both these ransomware also encodes the key information with Base64, and stores the encoded key in the ransom note.

Both customize the ransom note for each of the victim by adding the organization name in the ransom note. WastedLocker also adds the organization name to the ransom note file name as a prefix.

• Similar style of command line arguments

WastedLocker can perform certain operations when its main executable is launched using specific arguments, as did some earlier versions of BitPaymer. Both malware use numbers as arguments and the numbers they both use to indicate the operation the malware is supposed to perform are the same (eg., -1 indicates the main/initial execution, -2 issues a command to copy the malware and run it using ADS, and -3 indicates that it will begin the file encryption process.

While none of these alone, or even in combination, is enough to definitively say that, for instance, the same creator was responsible for both ransomware, the number of similarities is so striking as to raise questions about whether the malware author(s) of Bitpaymer and WastedLocker are connected in some collaborative way.

Reference IoC

Sample: BCDAC1A2B67E2B47F8129814DCA3BCF7D55404757EB09F1C3103F57DA3153EC8

 

Technical support scams are among the most pervasive forms of Internet-powered fraud. Preying primarily on less sophisticated computer, tablet and smartphone users, tech support scammers use fear and misinformation to convince their targets that they have become the victim of some sort of malware and coerce them into purchasing unneeded (and sometimes damaging) software and services to “protect” themselves.

A common method of catching less educated device users is the use of fraudulent web “advertising”— in the form of pop-up windows or redirected web pages that attempt to emulate system alerts. A class of these fake error websites makes it more difficult to get away, using HTML and JavaScript that take advantage of design bugs in the browser’s code. This type of bug is often referred to as a Browser Lock (browlock) bug. 

Browser developers, including Mozilla, have made fixes in the past to prevent such abuses.  However, we’ve recently found a Browser Lock bug that overcomes those efforts. The bug, CVE-2020-15654, was reported by SophosLabs to Mozilla and fixed in Firefox version 79. In this report, we’ll analyze three types of Browser Lock bugs that have specifically affected the Firefox browser, what Firefox programmatic internals made them possible, and how they were fixed.

Raising the (false) alarm

Browser Lock bugs are in themselves not severe security vulnerabilities. They only have a temporary, superficial effect on the browser when exploited, and can be easily remedied by an advanced user. But their persistence may convince less sophisticated users that the alerts they present are real—and lead to an actual compromise security, aided and abetted by them.

The classic fake error website—the simple pop-up window—is mostly effective in ensnaring the less computer-literate. But those with slightly more experience are more attuned to the dangers of internet fraud —those who realize they did not actually win a new car for being the one millionth visitor to a website, or that the person seeking their help transferring a fortune in return for a cut is not really a Nigerian prince—will more instinctively be skeptical of them. They might reflexively attempt to get rid of the fake error page, by either navigating away or closing the browser.

If they manage to make it go away, they will be quick to dismiss it as bogus despite the alarming content of the fake error. But if they can’t, they may be less sure that the alert isn’t real. That’s where Browser Lock bugs come in. They’re not really new as a class of scam—some versions have been around for years.

The Deceptive Custom Cursor bug

One of the oldest tricks scammers use to fool victims is the abuse of the “CSS cursor” feature in browsers—commonly known as the “Evil Cursor” attack. The CSS cursor property allows for a web developer to modify the way the user’s mouse cursor appears while it is within the confines of the web page. A custom image (up to 128×128 in size, in the case of Firefox) can be defined in the CSS property to serve as the mouse cursor instead of the default one:

The same CSS property can be used to control the cursor’s “hotspot”—the exact (x,y) coordinates for the offset inside the custom cursor image where mouse clicks should be registered. The origin point (0,0) is the top-left corner. In the typical cursor (such as shown in the picture above), the hotspot is meant to be at the pointy tip of the cursor.
The flexibility in being able to design the cursor image to appear as we wish, coupled with the ability to define an arbitrary hotspot for it, is a ripe feature for malicious actors: it’s easy to define a custom cursor whose mouse clicks register elsewhere than it appears to point to.

The classic Evil Cursor attack employed a large custom cursor image with the appearance of a typical cursor at the top-left corner of the image, but with the hotspot point at the bottom-right corner of the image. This way, attempting to click the Back button, Address bar, or the window’s Close (X) button will result in a dud click that does nothing, resulting in an illusion of a Browser Lock.

 

This bug was reported and addressed in Mozilla Bug 1445844, back in 2018.
In the fix issued for this bug, the primary addition introduced to the browser’s source code is the function ShouldBlockCustomCursor:

As the name suggests, this function implements logic to help the browser determine whether the custom cursor definition should be honored or not, given the current position of the cursor on the screen.

The following are the terms and variables used in the function above:

The portion of the browser window where the current web page is displayed, usually everything just below the address bar and the various toolbars, is referred to here as “frame” and is returned by topLevel->PresShell()->GetRootFrame().
Throughout the function, the frame is treated as a two-dimensional plane, with its origin point (0,0) being the top-left corner of the frame.

Variable point is the current (x,y) coordinates of the custom cursor’s hotspot on the frame’s plane. e.g. this value would be (0,0) when the custom cursor’s hotspot is pointed at the top-left corner of the page.

Variable size is the width and height measurement of the custom cursor image, e.g. 128×128.

Variable cursorRect is a rectangle on the frame’s plane. The rectangle represents the area of the custom cursor image, with its dimensions being size, and its base top-left corner being the value of point, normalized to a hotspot of (0,0). In other words, a “correction” is made for the sake of this calculation if the custom cursor’s hotspot is set to anything other than (0,0).
This means that if the custom cursor image dimensions are 128×128 and its hotspot is set to (110,120), cursorRect will be a 128×128 rectangle with the base top-left corner being point, except shifted 110 points leftwards, and 120 points upwards.

Finally, the function checks if cursorRect is fully within the frame’s plane.
If the custom cursor’s hotspot has been defined as anything other than (0,0), and the current cursor position is sufficiently close to the X=0 or Y=0 lines (the left and upper borders of the frame), cursorRect would end up occupying negative (x,y) coordinates, and therefore not fully within the plane.
In that case, the function returns true, meaning the custom cursor is “blocked”, and the default cursor is used instead.

Infinite Downloads of Blobs bug

Another Browser Lock type of bug was reported and addressed in Mozilla Bug 1438214, also in 2018.
The original reporter encountered the bug in a live fake error website. A simplified version of the offending JavaScript code is:

function download() {
    var b = new Blob;
    var o = URL.createObjectURL(b);

    var l = document.createElement("a");
    l.href = o;
    l.click();
}

while (true) download();

Essentially the code above is endlessly creating and triggering the downloading of Blob objects using Anchor (<a>) elements.

From the look of it, it’s evident that this is a Denial of Service type of bug, because it’s never-ending and will surely cause heavy CPU usage in the browser to the point of causing the page to become unresponsive.
A scenario where a web page causes the browser to become unresponsive and does not allow the user to (easily) browse away, can essentially be considered a Browser Lock bug.
However, since browsers are designed to run any arbitrary script given to them by a website, they have long been taking into account the possibility of scripts (whether intentionally or not) overloading and freezing the page.
In Firefox, a “Process Hang Monitor” was introduced to counter this problem. When this monitor detects that a page is unresponsive, it will pop up the following bar just above the page:

 

This bar, also known as the “Slow Script Dialog”, gives the user the option to stop JavaScript execution, (hopefully) resolving the unresponsiveness.

What sets this specific bug apart, is that in affected versions, the yellow bar never pops up after the page is loaded, despite it being totally unresponsive.
It turns out that each Blob download action leads internally to a CPU and memory heavy IPC message being broadcasted to all processes of the browser, most importantly the main firefox.exe process.
With the IPC messages reaching the main process and burdening its resources too, the Denial of Service condition is spread to it, and the yellow bar feature which is partially implemented in the main process is prevented from functioning as designed, resulting in a Browser Lock.

The fix employed by Mozilla was to simply remove the code responsible for IPC broadcasting of Blob downloads. The code had already become redundant due to previous browser updates, so it was not needed.

Deceptive Custom Cursor bug returns – CVE-2020-15654

Earlier this year, we encountered a live fake error website that caused a Browser Lock effect on the latest version of Firefox at the time.
The website consisted of a moderately sized HTML file containing JavaScript code and a CSS file.
Since Browser Locking is clearly an undesirable condition that likely points to a bug present in the browser’s code, we started investigating the web page in order to find the root cause, so that ideally it can be reported and fixed by Mozilla.
Here’s how visiting this fake error website looks in action:

Shortly after the web page is loaded (around the 4 seconds mark), you can see the mouse cursor suddenly gets jerked to the upper-left while also simultaneously changing its appearance, from a crosshair type to a typical cursor type.
This is the moment when a custom cursor image is loaded. The sudden movement is due to the upper-left offset of the cursor inside the custom cursor image, in line with the original Deceptive Custom Cursor exploits.

The blue circles that appear in the video denote a left mouse click. They show that after the web page is fully loaded, the location of the clicks is no longer synchronized with the mouse cursor—when the user tries to click a button, the actual click is on something else.  

Another thing we see is that the right side of the screen is seemingly inaccessible by the mouse pointer. In fact, when the cursor appears to be stuck and cannot be moved further to the right, the actual cursor hotspot is at the rightmost position. This effect only happens when the browser is in full screen mode.

Lastly, when the yellow “A web page is slowing down your browser” bar appears, it can be seen that its buttons are also covered by the deceptive custom cursor effect and appear to be un-clickable.

Bypassing the old fix

It’s obvious from observing the browser’s behavior that this page made use of the deceptive custom cursor method. But as we noted before, the deceptive custom cursor bug is well-known and was supposed to have been fixed back in 2018— and therefore, it should not be reproducible in new Firefox versions. So, what went wrong here?

We know that with the previously discussed fix applied, the function ShouldBlockCustomCursor would be regularly called to check and mitigate deceptive custom cursors, but it’s clearly not working as intended in this case.
To see what was going wrong, we ran the browser under a debugging session, attached to the Web Content process that corresponds to the relevant page (each tab has its own Web Content process), and set a breakpoint in the function:

With this setup, we visited the offending page, moving and clicking the mouse around, to find that the function is not being called at all.
Somehow the flow to the function is prevented. For reference, this is how the backtrace looks when the function is called in a legitimate flow, when the mitigation is working as intended:

Here we can see the chain of function calls that end up triggering the mitigation function:
Upon moving the mouse, the parent process (the main firefox.exe process) sends a RealMouseMoveEvent message with event type eMouseMove to the page’s Web Content process.
On the Web Content process’s side, this message is eventually received and processing begins in NS_ProcessNextEvent.
From the low-level messaging interface between “Parent” and “Child” (ipc::MessageChannel), the event bubbles up to the higher-level PresShell (Presentation Shell) interface.
In EventStateManager::PreHandleEvent, specific handling of eMouseMove begins. From there, functions that deal with cursors, and specifically custom cursors (if applicable), are called. Among them is ShouldBlockCustomCursor.

The source code responsible for calling the first function shown in the backtrace above (NS_ProcessNextEvent) in that same context is the following message loop function:

void MessagePump::Run(MessagePump::Delegate* aDelegate) {
  ...

  for (;;) {
    ...

    // This will either sleep or process an event.
    NS_ProcessNextEvent(thisThread, true);
  }

  ...
}

Going back to the debugger, setting up a breakpoint in NS_ProcessNextEvent and reloading the page, shows no hit on that function either. A typical Web Content process in the middle of a browsing session should see this function called pretty much non-stop.
So the reason ShouldBlockCustomCursor does not run is not the result of some cursor-related trickery that a clever attacker discovered and is using to bypass the mitigation. In fact, even the most low-level message loop mechanism is not functioning – IPC messages are not being received and processed.

The reason for this failure is hinted by the eventual appearance of the familiar yellow bar, signaling that the page is unresponsive. Upon inspecting the JavaScript code in the page, it turned out that the reason for this hang-up is a simple endless loop in the code.

Why would a JavaScript endless loop code cause the halting of the most basic message loop processing in the Web Content process? JavaScript code that runs within a web page, is executed in its Web Content process. Not only that, but it’s also executing in the same thread, named “Web Content”, where the relevant message loop is running.
So while JavaScript code is busy running, events such as “Mouse Move” are not dispatched, rendering the old Deceptive Custom Cursor mitigation obsolete. Thus, a “Browser Lock” effect can be achieved despite the old fix.

The new fix

After analyzing the bug, we reported our findings to Mozilla. Mozilla were quick to create and push a fix to their codebase, which went live in Firefox 79. The bug was assigned CVE-2020-15654: Custom cursor can overlay user interface.

The patch consists of just two lines of code added to nsGlobalWindowInner::ShowSlowScriptDialog, the function responsible for popping up the yellow bar:

// Override the cursor to something that we're sure the user can see.
SetCursor(NS_LITERAL_CSTRING("auto"), IgnoreErrors());

The code above simply sets the CSS cursor property to keyword auto (the default cursor), overriding any previous value. Since custom cursors are set up using this CSS property, any custom cursor configuration is now deactivated.  Now when the Process Hang Monitor is triggered and the yellow bar we mentioned earlier appears, the mouse cursor is reset to the default one. The user is then able to easily escape the web page – by interacting with the browser’s buttons and navigating away as one would normally do.

The reason this fix works—and isn’t overwhelmed by the browser being busy with running JavaScript code, as the last fix was—is that the new fix’s code is not called by the message loop mechanism. Instead, it’s called from a JavaScript engine interrupt callback:

The JavaScript engine is designed to periodically interrupt JavaScript execution and allow for these callbacks to be invoked. By inserting interrupt checks into JIT compiled code, the engine ensures that the callbacks occur even in the midst of endless loops. The backtrace pictured above is an example of such an instance.

One of these aforementioned interrupt callbacks is XPCJSContext::InterruptCallback, which serves as the basis for the Process Hang Monitor mechanism. Every time this function runs, it calculates the time elapsed since the last completed NS_ProcessNextEvent call.
As mentioned before, in the case of the malicious web page in question, the message loop mechanism becomes “stuck” and NS_ProcessNextEvent calls do not complete. After some time of this, the “time elapsed” timer exceeds a timeout, and springs the yellow bar into action by invoking nsGlobalWindowInner::ShowSlowScriptDialog, the same function containing the newly introduced fix.

With this bug being fixed, the overall security posture of Firefox against Browser Lock bugs is improved, but it is hardly the end of such bugs in this, or other, web browsers. The good news is that the tech support scammers who set up these fake error websites bugs rarely innovate, and are generally not sophisticated enough to discover and make use of such bugs.

That doesn’t mean that less sophisticated users won’t still fall for these malicious sites, even if they can easily navigate away from them. The best way to prevent people from falling victim to these scams will continue to be raising awareness to them.