History

Browser UI spoofing attacks have been threatening users’ security ever since the early stage of the World Wide Web. Edward Felten described several UI spoofing attacks in a technical report written in 1996 (and revised in 1997). These attacks attempt to mimic portions of the browser UI in order to deceive the users into performing unsecure actions. The report mentioned three major browser components used for spoofing: the location line, the status line, and the browser’s menu bar.

Location line: These are commonly seen in phishing attacks, where the attacker uses a misleading URL to deceive the user. For example, www.bankofthevvest.com.

Status line: Since any website is allowed to set its own status line at the bottom of the window, an attacker could use the status line to trick the users into believing that they are browsing a benign site.

Menu bar: At the time of Felten’s report in 1997, websites have the option to hide the browser’s menu bar via Javascript. This gives the attacker the ability to create a bogus menu bar.

Another UI element that was not mentioned in Felten’s report was the location bar itself. Websites were allowed to create a pop-up window with its location bar disabled. An attacker may leverage this to craft an arbitrary URL to display at the top of the pop-up window.

Fast forward a few years to 2007, browser vendors have realized the problem with allowing Javascript access to browser UI elements (e.g., the location bar or the menu bar). Most browsers stopped granting script access sensitive UI elements, but unfortunately, the problem did not go away. Collin Jackson described a new breed of UI spoofing in his paper that does not not require script access to any browser UI elements, it was called the picture-in-picture attack.

The picture-in-picture attack works as follows (see diagram below):

1. User visits attacker’s site.
2. Attacker includes a picture that looks exactly like a pop-up window of paypal.com on her site.
3. User looks at the address bar, thinking it is the legitimate paypal.com, and proceeds with entering his credentials.

Attack Demo

Four years have passed since Collin’s picture-in-picture attack paper, and the attack has been largely ignored by the community. Various authentication mechanisms have been designed to continuously use pop-up windows to bootstrap security, putting many users at risk. To demonstrate the threat of picture-in-picture attack, I created a demo here, using Facebook’s login pop-up as an example (Currently, the attack only spoofs the UI of a Chrome pop-up using OS X).

To mimic a real pop-up window, I added the following features to the picture:

1. A text box is used to create an illusion of a location bar.
2. A text box and a password field are used to create the login box.
3. An event handler is attached to the top of the window to simulate the dragging effect of the window.
4. A separate image is used to create the loading screen.

Although it does not fully simulate a pop-up window, a motivated attacker could make the following additions to further enhance the quality of the attack:

1. Add scripts for resizing the window, and simulating the shadow effects of OS X(I used a cheap get-around for this in my demo).
2. Detect the browser type/version using standard user agent detection techniques and display different pop-up images accordingly.
3. Simulate as many clickable elements of a pop-up window as possible(with exception to maximize/minimize).

We haven't seen these attacks much yet in the wild. “Why not?” is an interesting question. Maybe they're too hard to pull off in practice, and maybe attackers have an easier time with simple phishing attacks. Nevertheless, picture-in-picture attack is a real threat and has to be stopped.

Lessons learned

For starters, it is never a good idea to authenticate the user through an attacker-controlled screen area. Web sites should use a new tab to authenticate their users, instead of using a pop-up window. However, this defense (by itself) is not enough to mitigate UI spoofing attacks for the same reason that a broken(or missing) lock icon cannot stop people from entering their credit card numbers. At the end of the day, we have to educate users to differentiate a UI spoofing attack, which in itself could be a challenging task.