It’s extremely difficult to prevent attacks when there are no trustworthy pixels on the screen, especially if a user doesn’t realize that none of what they’re seeing can be trusted. Unfortunately for the browsing public, the HTML5 Fullscreen API can deliver this power to an attacker.

Today, an attacking website can enter full-screen with a user-gesture which may be as simple as the user clicking anywhere or tapping any key. A common threat pattern is to abuse the browser’s APIs to perform a tech scam attack, in which a user is convinced to call a phone number staffed by the attacker.

As in other hybrid web/phone attacks, the attacker then either directly asks the victim for money, or entices them to run “remote control” software to grant the attacker control of the victim’s PC to steal credentials or install malware.

Attackers show text in a black box near the top-center of the window to try to confuse the user so they don’t see the hint that the browser is now in full-screen mode and the user must hit the Escape key to exit. They make the attack even harder to escape using the Pointer Lock API (which hides the mouse pointer) and the Keyboard Lock API (so exiting fullscreen requires that the user hold the Escape key). They increase the urgency with animation and even a computerized voice explaining that the user’s machine is under attack and they should call immediately to avoid damage.

If a user even manages to get out of full-screen mode, any keystroke or click re-enters the fullscreen mode. Attempting to close the tab with the [x] will result in the OnBeforeUnload dialog box where the user must see and press the Leave button.

I built a harmless test page demonstrating some of these techniques.

Making matters even scarier, the attack site may deliver JavaScript which, while (harmlessly) loaded into the browser cache, causes the system’s real security software to pop up a toast indicating that an attack is underway.

What’s a normal human to do in the face of this attack? One response might be to turn off the power to the computer in the hopes that it will just go away. That might work, at the expense of losing anything that hadn’t been saved, but it might not, if the user accidentally just “sleeps” the device or if the browser’s crash recovery brings the attack site back after the computer reboots.

I recently noticed that the MalwareBytes extension attempts to detect “browser locker” scam sites like these by watching the exercise of certain web-platform APIs. While blocking APIs entirely could have site-compat impact, it might be a reasonable thing to do on the often-hostile web.

Punditry

In my opinion, browsers are much too eager to enter and reenter fullscreen – if a user exits full-screen deliberately, I think we shouldn’t allow the site to regain it without a more explicit user-interaction (e.g. a permission bubble). And browser vendors probably ought to be smarter by paying attention, for example, automatically denying full-screen on sites where the user isn’t a regular visitor.

URL Reputation services like Google Safe Browsing and Microsoft SmartScreen do allow blocking of known tech scam sites, but there are just so so many of them.

-Eric

PS: It’s tempting to think: Can’t we just go after the bad guys on the other end of the phone? The might work, but it’s not a slam dunk.

Some attackers have built their scams in a loosely-coupled way with plausible deniability at the point where the scam enters “the real world”, where they basically outsource the job of taking money to a company unrelated to the site that scared the user into making the call. Add to that the ability to pivot between overseas call centers within hours and you’ve basically gotten back to the “spam” problem – you can take down, at best, a tiny fraction of a percent of the attackers.

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ Microsoft 2001-2012, and 2018-, working on Office, IE, and Edge. Now a GPM for Microsoft Defender. My words are my own, I do not speak for any other entity. View more posts