Phishing attacks that bypass 2-factor authentication are now easier to execute
- 04 June, 2019 02:00
Penetration testers and attackers have a new tool in their arsenal that can be used to automate phishing attacks in a way that defeats two-factor authentication (2FA) and is not easy to detect and block. The tool makes such attacks much easier to deploy, so organisations should adapt their anti-phishing training accordingly.
The new toolkit was presented earlier this month at the Hack in the Box conference in Amsterdam and was released on GitHub after a few days. It has two components: A transparent reverse-proxy called Muraena and a Docker container for automating headless Chromium instances called NecroBrowser.
A man-in-the-middle type of attack
Traditional phishing attacks that most people are familiar with consist of fake login pages hosted on attacker-controlled web servers and served from custom domains whose names are similar to those of the targeted websites. However, such static attacks are not effective against online services that use two-factor authentication, because there is no interaction with the legitimate websites to trigger the generation of one-time-use codes. Without those codes, attackers can't log in with the phished credentials.
To overcome 2FA, attackers need to have their phishing websites function as proxies, forwarding requests on victims' behalf to the legitimate websites and delivering back responses in real time. The final goal is not to obtain only usernames and passwords, but active session tokens known as session cookies that the real websites associate with logged-in accounts. These session cookies can be placed inside a browser to access the accounts they're associated with directly without the need to authenticate.
This proxy-based technique is not new and has been known for a long time, but setting up such an attack required technical knowledge and involved configuring multiple independent tools such as the NGINX web server to run as reverse-proxy. Then the attacker needed to manually abuse the stolen session cookies before they expire. Furthermore, some websites use technologies like Subresource Integrity (SRI) and Content Security Policy (CSP) to prevent proxying, and some even block automated browsers based on headers.
Muraena and NecroBrowser were created to defeat those protections and automate most of the process. This means launching phishing attacks that can defeat 2FA can now be done by a larger number of attackers. The tools were created by researchers Michele Orru, a former core developer of the Browser Exploitation Framework Project (BeEF), and Giuseppe Trotta, a member of the Bettercap project.
How do Muraena and NecroBrowser work?
Muraena is written in the Go programming language, which means that it can be compiled and run on any platform where Go is available. Once deployed, the attacker can configure their phishing domain and obtain a legitimate certificate for it--for example, by using the non-profit Let's Encrypt certificate authority.
The tool contains a minimal web server that acts as reverse-proxy and a crawler that automatically determines which resources to proxy from the legitimate website. The proxy transparently rewrites requests received from the victim before passing them on.
The crawler automatically generates a JSON configuration file, which can then be tweaked manually to bypass various defences on more complex websites. The package includes example configuration files for Google, GitHub and Dropbox.
Once a victim lands on a phishing site powered by Muraena, the login process works exactly as on the real website. The user is asked for their 2FA code. After they provide it and authentication is completed, the proxy steals the session cookie.
The session token is normally stored by the browser inside a file and is served on subsequent requests. This allows the website to automatically provide that browser with access to an account for a certain amount of time -- session length -- without asking for the login password again. Muraena can automatically pass the collected session cookies to its second component, the NecroBrowser, which can immediately start abusing them.
NecroBrowser is a microservice that can be controlled through an API and configured to perform actions through Chromium headless instances running inside Docker containers. Depending on the available server resources, an attacker can spawn tens or hundreds of such containers simultaneously, each with a session cookie stolen from a victim.
The actions performed by the zombie browser instances can be fully automated. For example, depending on the type of account, that could mean taking screenshots of emails, initiating password resets, uploading rogue keys to GitHub or adding rogue forwarding addresses to mailboxes. The browser instances could also be used to gather information about contacts and friends on social networks and even to send phishing messages to those friends in a worm-like attack.
How to protect against automated phishing attacks
Unfortunately, few technical solutions completely block such phishing attacks on the server side. Muraena was developed to show that techniques such as SRI and CSP have a limited effect and can be bypassed in an automated manner. Furthermore, the tool shows that 2FA is not a bulletproof solution.
Proxy based phishing can’t defeat some 2FA implementations, however—those that use USB hardware tokens with support for the Universal 2nd Factor (U2F) standard. That's because those USB tokens establish a cryptographically verified connection to the legitimate website through the browser, which does not go through the attacker's reverse-proxy. Meanwhile, solutions that are based on codes received over SMS or generated by mobile authenticator apps are vulnerable, because the victims have to manually input them, and they might do so on the phishing websites.
Another technical solution can be a browser extension that checks if the user is inputting their credentials on the correct website. Google developed such an extension for Chrome called Password Alert that warns users if they attempt to enter their Google credentials on any website that does not belong to Google.
Training users to be vigilant and to make sure they are authenticating on the correct website with the correct domain name remains very important. The presence of an TLS/SSL indicator and a valid certificate are not enough to consider a website is legitimate because certificates can now be easily obtained for free, so most phishing sites will be HTTPS-enabled.