Can we trust web browsers to protect us, even if they say “https?” Not with the novel BitB attack, which fakes popup SSO windows to phish away credentials for Google, Facebook and Microsoft, et al.
We’ve had it beaten into our brains: Before you go wily-nily clicking on a page, check the URL. First things first, the tried-and-usually-but-not-always-true advice goes, check that the site’s URL shows “https,” indicating that the site is secured with TLS/SSL encryption.
If only it were that easy to avoid phishing sites. In reality, URL reliability hasn’t been absolute for a long time, given things like homograph attacks that swap in similar-looking characters in order to create new, identical-looking but malicious URLs, as well as DNS hijacking, in which Domain Name System (DNS) queries are subverted.
Now, there’s one more way to trick targets into coughing up sensitive info, with a coding ruse that’s invisible to the naked eye. The novel phishing technique, described last week by a penetration tester and security researcher who goes by the handle mr.d0x, is called a browser-in-the-browser (BitB) attack.
The novel method takes advantage of third-party single sign-on (SSO) options embedded on websites that issue popup windows for authentication, such as “Sign in with Google,” Facebook, Apple or Microsoft.
The researcher used Canva as an example: In the log-in window for Canva shown below, the popup asks users to authenticate via their Google account.
It’s Easy to Fabricate an Identical, Malicious Popup
These days, SSO popups are a routine way to authenticate when you sign in.
But according to mr.d0x’s post, completely fabricating a malicious version of a popup window is a snap: It’s “quite simple” using basic HTML/CSS, the researcher said. The concocted popups simulate a browser window within the browser, spoofing a legitimate domain and making it possible to stage convincing phishing attacks.
“Combine the window design with an iframe pointing to the malicious server hosting the phishing page, and [it’s] basically indistinguishable,” mr.d0x wrote. The report provided an image, included below, that shows a side-by-side of a fake window next to the real window.
“Very few people would notice the slight differences between the two,” according to the report.
Hovering Over Links: Another Easily Fooled Security Safeguard
The writeup pointed to how HTML for a link generally looks, as in this sample:
“If an onclick event that returns false is added, then hovering over the link will continue to show the website in the href attribute but when the link is clicked then the href attribute is ignored,” the researcher explained.
“We can use this knowledge to make the pop-up window appear more realistic,” they said, providing this visually undetectable HTML trick:
<a href=”https://gmail.com” onclick=”return launchWindow();”>Google</a>
// Launch the fake authentication window
return false; // This will make sure the href attribute is ignored
All the More Reason for MFA
Thus does the BitB technique undercut both the fact that a URL contains the “https” encryption designation as a trustworthy site, as well as the hover-over-it security check.
“With this technique we are now able to up our phishing game,” the researcher concluded.
Granted, a target user would still need to land on a threat actor’s website for the malicious popup window to be displayed. But once the fly has landed in the spider’s web, there’s nothing alarming to make them struggle against the idea of handing over SSO credentials.
“Once landed on the attacker-owned website, the user will be at ease as they type their credentials away on what appears to be the legitimate website (because the trustworthy URL says so),” mr.d0x wrote.
But there are other security checks that the BitB attack would have to overcome: namely, those that don’t rely on the fallibility of human eyeballs. Password managers, for example, probably wouldn’t autofill credentials into a fake BitB popup because software wouldn’t interpret the as a real browser window.
Lucas Budman, CEO of passwordless workforce identity management firm TruU, said that with these attacks, it’s just a matter of time before people fork over their passwords to the wrong person, thereby relegating multifactor authentication (MFA) to “a single factor as the password is already compromised.”
Budman told Threatpost on Monday that password reuse makes it particularly dangerous, including sites that aren’t MFA-enabled.
“As long as username/password is used, even with 2FA, it is completely vulnerable to such attacks,” he said via email. “As bad actors get more sophisticated with their attacks, the move to passwordless MFA is more critical now than ever. Eliminate the attack vector by eliminating the password with password-less MFA.”
By passwordless MFA, he is, of course, referring to ditching passwords or other knowledge-based secrets in favor of providing a secure proof of identity through a registered device or token. GitHub, for one, made a move on this front in May 2021, when it added support for FIDO2 security keys for Git over SSH in order to fend off account hijacking and further its plan to stick a fork in the security bane of passwords.
The portable FIDO2 fobs are used for SSH authentication to secure Git operations and to forestall the misery that unfurls when private keys accidentally get lost or pilfered, when malware tries to initiate requests without user approval or when researchers come up with newfangled ways to bamboozle eyeballs – BitB being a case in point.