Serious Security: Browser-in-the-browser attacks – watch out for windows that aren’t!

Researchers at threat intelligence company Group-IB just wrote an intriguing real-life story about an annoyingly simple but surprisingly effective phishing trick known as BitB, short for browser-in-the-browser.

You’ve probably heard of several types of X-in-the-Y attack before, notably MitM and MitB, short for manipulator-in-the-middle and manipulator-in-the-browser.

In a MitM attack, the attackers who want to trick you position themselves somewhere “in the middle” of the network, between your computer and the server you’re trying to reach.

(They might not literally be in the middle, either geographically or hop-wise, but MitM attackers are somewhere along the route, not right at either end.)

The idea is that instead of having to break into your computer, or into the server at the other end, they lure you into connecting to them instead (or deliberately manipulate your network path, which you can’t easily control once your packets exit from your own router), and then they pretend to be the other end – a malevolent proxy, if you like.

They pass your packets on to the official destination, snooping on them and perhaps fiddling with them on the way, then receive the official replies, which they can snoop on and tweak for a second time, and pass them back to you as though you’d connected end-to-end just as you expected.

If you’re not using end-to-end encryption such as HTTPS in order to protect both the confidentiality (no snooping!) and integrity (no tampering!) of the traffic, you are unlikely to notice, or even to be able to detect, that someone else has been steaming open your digital letters in transit, and then sealing them again up afterwards.

Attacking at one end

A MitB attack aims to work in a similar way, but to sidestep the problem caused by HTTPS, which makes a MitM attack much harder.

MitM attackers can’t readily interfere with traffic that’s encrypted with HTTPS: they can’t snoop on your data, because they don’t have the cryptographic keys used by each end to protect it; they can’t change the encrypted data, because the cryptographic verification at each end would then raise the alarm; and they can’t pretend to be the server you’re connecting to because they don’t have the cryptographic secret that the server uses to prove its identity.

An MitB attack therefore typically relies on sneaking malware onto the your computer first.

That’s generally more difficult than simply tapping into the network at some point, but it gives the attackers a huge advantage if they can manage it.

That’s because, if they can insert themselves right inside your browser, they get to see and to modify your network traffic before your browser encrypts it for sending, which cancels out any outbound HTTPS protection, and after your browser decrypts it on the way back, thus nullifying the encryption applied by the server to protect its replies.

What abour a BitB?

But what about a BitB attack?

Browser-in-the-browser is quite a mouthful, and the trickery involved doesn’t give cybercriminals anywhere near as much power as a MitM or a MitB hack, but the concept is forehead-slappingly simple, and if you’re in too much of a hurry, it’s surprisingly easy to fall for it.

The idea of a BitB attack is to create what looks like a popup browser window that was generated securely by the browser itself, but that is actually nothing more than a web page that was rendered in an existing browser window.

You might think that this sort of trickery would be doomed to fail, simply because any content in site X that pretends to be from site Y will show up in the browser itself as coming from a URL on site X.

One glance at the address bar will make it obvious that you’re being lied to, and that whatever you’re looking at is probably a phishing site.

Foe example, here’s a screenshot of the example.com website, taken in Firefox on a Mac:

If attackers lured you to a fake site, you might fall for the visuals if they copied the content closely, but the address bar would give away that you weren’t on the site you were looking for.

In a Browser-in-the-Browser scam, therefore, the attacker’s aim is to create a regular web page that looks like the web site and content you’re expecting, complete with the window decorations and the address bar, simulated as realistically as possible.

In a way, a BitB attack is more about art than it is about science, and it’s more about web design and managing expectations than it is about network hacking.

For example, if we create two screen-scraped image files that look like this…

…then HTML as simple as what you see below…

  <html>     <body>        <div>           <div><img src='./fake-top.png'></div>           <p>           <div><img src='./fake-bot.png'></div>        </div>     </body>  </html>  

…will create what looks like a browser window inside an existing browser window, like this:

In this very basic example, the three macOS buttons (close, minimise, maximise) at the top left won’t do anything, because they aren’t operating system buttons, they’re just pictures of buttons, and the address bar in what looks like a Firefox window can’t be clicked in or edited, because it too is just a screenshot.

But if we now add an IFRAME into the HTML we showed above, to suck in bogus content from a site that has nothing to do with example.com, like this…

  <html>     <body>        <div>           <div><img src='./fake-top.png' /></div>              <div><iframe src='https:/dodgy.test/phish.html' frameBorder=0 width=650 height=220></iframe></div>           <div><img src='./fake-bot.png' /></div>        </div>     </body>  </html>  

…you’d have to admit that the resulting visual content looks exactly like a standalone browser window, even though it’s actually a web page inside another browser window.

The text content and the clickable link you see below were downloaded from the dodgy.test HTTPS link in the HTML file above, which contained this HTML code:

  <html>     <body style='font-family:sans-serif'>        <div style='width:530px;margin:2em;padding:0em 1em 1em 1em;'>           <h1>Example Domain</h1>             <p>This window is a simulacrum of the real website,           but it did not come from the URL shown above.           It looks as though it might have, though, doesn't it?             <p><a href='https://dodgy.test/phish.click'>Bogus information...</a>        </div>     </body>  </html>  

The graphical content topping and tailing the HTML text makes it look as though the HTML really did come from example.com, thanks to the screenshot of the address bar at the top:

The artifice is obvious if you view the bogus window on a different operating system, such as Linux, because you get a Linux-like Firefox window with a Mac-like “window” inside it.

The fake “window dressing” components really do stand out as the images they really are:

Would you fall for it?

If you’ve ever taken screenshots of apps, and then opened the screenshots later in your photo viewer, we’re willing to bet that at some point you’ve tricked yourself into treating the app’s picture as if it were a running copy of the app itself.

We’ll wager that you’ve clicked on or tapped in an app-in-an-app image at least one in your life, and found yourself wondering why the app wasn’t working. (OK, maybe you haven’t, but we certainly have, to the point of genuine confusion.)

Of course, if you click on an app screenshot inside a photo browser, you’re at very little risk, because the clicks or taps simply won’t do what you expect – indeed, you may end up editing or scribbling lines on the image instead.

But when it comes to a browser-in-the-browser “artwork attack” instead, misdirected clicks or taps in a simulated window can be dangerous, because you’re still in an active browser window, where JavaScript is in play, and where links still work…

…you’re just not in the browser window you thought, and you’re not on the website you thought, either.

Worse still, any JavaScript running in the active browser window (which came from the original imposter site you visited) can simulate some of the expected behaviour of a genuine browser popup window in order to add realism, such as dragging it, resizing it, and more.

As we said at the start, if you’re waiting for a real popup window, and you see something that looks like a popup window, complete with realistic browser buttons plus an address bar that matches what you were expecting, and you’re in a bit of a hurry…

…we can fully understand how you might misrecognise the fake window as a real one.

Steam Games targeted

In the Group-IB research we mentioned above, the real-world BinB attack that the researchers came aross used Steam Games as a lure.

A legitimate looking site, albeit one you’d never heard of before, would offer you a chance to win places at an upcoming gaming tournament, for example…

…and when the site said it was popping up a separate browser window containing a Steam login page, it really presented a browser-in-the-browser bogus window instead.

The researchers noted that the attackers didn’t just use BitB trickery to go for usernames and passwords, but also tried to simulate Steam Guard popups asking for two-factor authentication codes, too.

Fortunately, the screenshots presented by Group-IB showed that the criminals they happened upon in this case weren’t terribly careful about the art-and-design aspects of their scammery, so most users probably spotted the fakery.

But even a well-informed user in a hurry, or someone using a browser or operating system they weren’t familiar with, such as at a friend’s house, might not have noticed the inaccuracies.

Also, more fastidious criminals would almost certainly come up with more realistic fake content, in the same way that not all email scammers make spelling mistakes in their messages, thus potentially leading more people into giving away their access credentials.

What to do?

Here are three tips:

• Browser-in-the-Browser windows aren’t real browser windows. Although they may seem like operating system level windows, with buttons and icons that look just like the real deal, they don’t behave like operating system windows. They behave like web pages, because that’s what they are. If you’re suspicous, try dragging the suspect window outside the main browser window that contains it. A real browser window will behave independently, so you can move it outside and beyond the original browser window. A fake browser window will be “imprisoned” inside the real window it’s shown in, even if the attacker has used JavaScript to try to simulate as much genuine-looking behaviour as possible. This will quickly give away that it’s part of a web page, not a true window in its own right.
• Examine suspect windows carefully. Realistically mocking up the look and feel of an operating system window inside a web page is easy to do badly, but difficult to do well. Take those extra few seconds to look for telltale signs of fakery and inconsistency.
• If in doubt, don’t give it out. Be suspicious of sites you’ve never heard of, and that you have no reason to trust, that suddenly want you to login via a third-party site.

Never be in a hurry, because taking your time will make you much less likely to see what you think is there instead of what seeing what actually is there.

In three words: Stop. Think. Connect.

Featured image of photo of app window containing image of photo of Magritte’s “La Trahison des Images” created via Wikipedia.