Man in the Browser: Attack and Defense

A successful man in the browser attack is devastating: The attacker gets full control over your account and you have no idea it is happening. In this post, we discuss the attack, its impact, and why typical mitigations fall short. Finally, we toot our own horn a bit and show how Tozny addresses the threat.

What it is

A man in the browser attack, also known as browser pivoting, is where an attacker relays malicious web commands directly through a victim’s browser. It’s an extremely effective attack, very few mitigations are available, and those that are available are rarely implemented, leaving users and systems at risk.

Steps in a Typical Attack

To see this attack in action, watch this video of the penetration testing tool Cobolt Strike. It’s a great overview of a particular attack tool and how it can be used. A typical attack works like this:

  1. Compromise the victim by any typical means. A typical ATP approach is to send a  PDF with some kind of malware as the payload.
  2. Inject proxy code in the victim’s browser, e.g. using Cobalt Strike.
  3. Configure the attacker’s browser to send requests through the victim’s browser.
  4. Wait for the victim to log into a valuable asset, like their bank account.
  5. Perform any action on behalf of the authenticated victim, like initiate a transfer of funds.

Impact of Attacks

The impact of this attack is only limited by the authority of the target user. For instance, it can target someone with financial authority in a small business, and trigger a wire transaction to transfer the company’s savings out of the country. If the attacker is a systems administrator, it could be used to turn on or turn off services or even add the attacker as an authorized user.

In short, after the initial infection of a user’s system with malware, this is an extremely effective way for an attacker to elevate their privileges.

Typical Mitigations Fall Short

Most security breaks down when you can’t trust the user’s computer. Man in the browser attacks have two attributes that make them particularly effective:

  • They are pre-encryption: Today, all secure web sites use strong encryption, in the form of HTTPS, to protect user sessions. Although it has weaknesses, HTTPS is vital and extremely effective. However, this protocol relies on a trusted web browser. Since these attacks take place before the browser encrypts requests and after it decrypts requests, HTTPS is ineffective against this attack.
  • They are post-authentication: Two factor authentication doesn’t help. Neither do CAC cards, client-side certificates, or strong passwords. In fact, no form of authentication particularly helps since the attacker simply waits for the user to finish authenticating and takes over the authenticated session.

Many systems implement a type of risk-based “step up” authentication. That is, when the user performs a sensitive action, they are prompted to log in again. This is definitely helpful! If an attacker’s request triggers a “login” dialog, the user could become suspicious, but since the attacker can also modify what the user sees, they can make this login request look like anything: They can change “Type your password to authorize the transfer” to simply “Log in again to continue”.

Tozny’s Solution

Tozny isn’t just a login system. We also implement a protocol called “Out of band transaction verification”. It works like this:

  1. You log in with Tozny or with any other type of authentication.
  2. You (or an attacker!) initiate a risky transaction like a wire transfer.
  3. Your phone pops up with a notification with details of the transaction.  The details are important since you must verify specifically what you intended to do.
  4. You approve the transaction on your phone. Alternatively, if you didn’t initiate the transaction, you deny it and it does not go through.
  5. Since your phone has a direct secure connection with the site, the compromised browser is completely out of the loop. In fact, the attacker would have to target both the phone and the computer, making the attack significantly more complex.

Try out our online demo to see how elegantly this can be implemented. Feel free to drop us a line anytime if you’d like to to learn how you can easily integrate out of band transaction verification with your critical systems.