Skip links

This browser-in-browser attack is perfect for phishing

A novel way of tricking people out of their passwords has left us wondering if there’s a need to rethink how much we trust our web browsers to protect us and to accelerate efforts to close web security gaps.

Earlier this week, an infosec researcher known as mr.d0x described a browser-in-the-browser (BitB) attack. It’s a way to steal login credentials by simulating the little browser windows that Google, Microsoft, and other authentication service providers pop up that ask you for your username and password to continue. You’ve probably seen these windows: you click on something like a “Sign in with Microsoft” button on a website, and popup appears asking for your credentials to access your account or profile.

Services like Google Sign-In will display a Google URL in the popup window navigation bar, which offers some reassurance that the login service is actually coming from a trusted company and not an unknown one. And bypassing defenses built into the user’s browser to fool them into trusting a malicious page tends to be difficult in the absence of an exploitable vulnerability, thanks to browser security mechanisms including Content Security Policy settings and the Same-origin policy security model.

However, there are methods like clickjacking or user-interface redressing that alter the appearance of browsers and web pages to dupe people in ways that bypass security controls. A clickjacking attack might, for example, interpose a transparent element over a web page button so that a user’s click event gets hijacked for some nefarious purpose.

The BitB attack extends this technique by creating an entirely fabricated browser window, including trust signals like a locked padlock icon and a known (but faked) URL. You think you’re seeing a real popup window, but it’s actually just faked within the page, and ready to capture your credentials.

Replicating the entire window design using basic HTML/CSS is quite simple

“Fortunately for us, replicating the entire window design using basic HTML/CSS is quite simple,” explains mr.d0x. “Combine the window design with an iframe pointing to the malicious server hosting the phishing page, and it’s basically indistinguishable.”

This technique, says mr.d0x, makes phishing more effective. Victims would still need to visit a compromised or malicious website to generate the popup but thereafter will be more likely to submit credentials because nothing looks amiss.

There are limitations to this approach because while it may deceive people, it’s unlikely to fool other software. Password managers, for example, probably wouldn’t autofill credentials into a BitB window because they wouldn’t see it as a real browser window.

Nonetheless, BitB has raised concern among some security researchers as a way to exploit the insecurity of the ad ecosystem. Pointing to research published last year by Adalytics indicating that 70 percent of top publisher websites fail to sandbox the iframes used to serve ads, ad fraud researcher Augustine Fou told The Register that he worries BitB will be used by those serving malvertising, or malicious ads.

“Malicious code can come in through the ad in the iframe but because the iframe is not secured, it can be injected into the parent page,” he explained. That is to say, a bad ad could cause a BitB popup to appear on the page, asking for someone’s username and password to harvest.

Adalytics’ researcher and founder Krzysztof Franaszek told The Register this is a plausible attack vector. Asked how it might be done, he replied, “The simple answer is: you would create an ad creative that has a JS payload. When the ad loads on an end user device, and detects that the iframe it’s loading inside isn’t sandboxed, it would trigger a pop-out window that looks like a login page.”

“The more complex/in-depth answer is that ad networks/exchanges like Google scan and filter creatives, and there are other companies that try to monitor those creatives for malicious code as well,” he added.

Eliya Stein, a researcher at ad security biz Confiant, told The Register that while his firm’s data indicates about half of all iframes are unsandboxed and that a friendly frame – not cross-origin – pushing malicious JavaScript is a plausible hypothetical attack, it’s not one that fits well into the economic model of malvertising.

“Even though this type of attack is possible, I don’t think that it’s necessarily the most lucrative path forward for malvertising,” explained Stein. “Malvertising attacks, they kind of need to be high impact and appeal to the least common denominator. And I think that’s the reason why the most disruptive and impactful malvertising attacks that we’ve generally seen are forced redirections – a full screen pop up or a full screen forced redirection – and these things are usually immediately monetizable.”

A fake login modal, he said, isn’t immediately going to generate cash. Once you get someone’s credentials you then have to have a process to sell those credentials or use them to get data, rather than getting paid by duped ad firms.

We’ve seen a lot of phishing attacks on fake crypto sites that spawn this modal using CSS

Stein, however, suggested BitB is similar to ways in which attackers have tried to obtain access to cryptocurrency wallets like MetaMask. “We’ve seen a lot of phishing attacks on fake crypto sites that spawn this modal using CSS,” he said. “So it’s not the real MetaMask but it looks a lot like it and it tries to get you to interact somehow, to enter your seed phrase or complete some kind of transaction.”

The challenge of monetizing BitB may make it suboptimal for defrauding advertisers but it nonetheless has security implications given that America’s Cybersecurity and Infrastructure Security Agency considers malicious code delivered via ad systems a threat to US networks [PDF].

While Stein said the supply-side platforms (SSPs) that serve ads have security systems that scans for malicious code and there are other mitigating factors related to how publishers configure their websites, both Fou and Franaszek indicated that ad ecosystem security is often lacking and there are ways to craft malicious code to hide from scanners.

“You configure the JavaScript to only trigger its real behavior like in 45 or 60 days in the future,” explained Franaszek, “or when the ad loads from a specific IP address.”

Fou said weak SSPs provide the way in. “That’s the loophole,” he said, “that allows the malicious ads to get into the system. The malicious code only activates when it detects motion, orientation change, touch, or IP address. … so it is extremely hard for scanners to see this in the wild.” ®