Create account

R
2012d
To protect against phishing attacks, online platform providers implement a two-factor authentication process on their websites. But now, hackers can bypass this protection more easily. Two tools have been developed to automate the process and launch hundreds of attacks at a time.

Traditional phishing attacks consist in creating fake hosted login pages on web servers against them by the attacker and whose domain names are similar to those of the target websites.

Traditional phishing attacks consist of creating fake login pages hosted on web servers controlled by the attacker and whose domain names are similar to those of targeted websites. (Credit: Christiaan Colen / Flickr)
Intrusion testers and hackers have been able to add to their arsenal a method that automates phishing attacks, thwarts two-factor authentication (2FA) and is, in addition, not easy to detect and block. This toolkit was presented last month at the Hack in the Box conference in Amsterdam and was released on GitHub a few days later. It has two components: a transparent reverse-proxy called Muraena and a Docker container - called NecroBrowser - to automate Headless Chromium instances.

Traditional phishing attacks consist of creating fake login pages hosted on web servers controlled by the attacker and whose domain names are similar to those of targeted websites. However, such static attacks are not effective against online services that use two-factor authentication. In this case, there is no interaction with legitimate websites to trigger the generation of single-use codes. Without these codes, attackers cannot connect with phishing credentials.

A type of attack that is not new but much easier to launch
To overcome 2FA, attackers must ensure that their phishing websites operate as proxy servers, forwarding requests on behalf of victims to legitimate websites and providing real-time responses. The ultimate goal is not only to obtain usernames and passwords, but also session cookies that real websites associate with connected accounts. The latter can be placed inside a browser to directly access the accounts to which they are associated without having to authenticate themselves.

This proxy technique is not new and has been known for a long time, but the implementation of such an attack required technical knowledge and involved the configuration of multiple independent tools such as the NGINX web server to operate in reverse-proxy. Then, the attacker had to manually compromise the stolen session cookies before they expired. In addition, some websites use technologies such as Subresource Integrity (SRI) and Content Security Policy (CSP) to prevent proxying, and some even block automatic browsers based on headers.

A tool for creating a phishing site under Go
Muraena and NecroBrowser were created to overcome these protections and automate most of the process. This means that more attackers can now launch phishing attacks that can bypass 2FA. The tools were created by researchers Michele Orru, former developer of the Browser Exploitation Framework Project (BeEF), and Giuseppe Trotta, member of the Bettercap project.

Muraena is written in the Go programming language, which means it can be compiled and executed on any platform where Go is available. Once deployed, the attacker can configure his phishing domain and obtain a legitimate certificate for it, for example by using the Let's Encrypt certification authority. The tool contains a minimal web server that acts as a reverse-proxy and a crawler that automatically determines proxy resources from the legitimate website. The agent transparently rewrites the requests received from the victim before forwarding them. The crawler automatically generates a JSON configuration file, which can then be manually modified to bypass various defenses on more complex websites. The package includes sample configuration files for Google, GitHub and Dropbox.

Once a victim lands on a phishing site powered by Muraena, the connection process works exactly as on the real website. The user is prompted to enter his 2FA code. Once it has been provided and authentication is complete, the proxy steals the session cookie. The latter is normally stored by the browser inside a file and is used for subsequent requests. This allows the website to automatically provide this browser with access to an account for a period of time -- session duration -- without having to ask for the login password again. Muraena can automatically transmit the collected session cookies to its second component, the NecroBrowser, which can immediately start compromising them.

Generate hundreds of containers simultaneously
NecroBrowser is a microservice that can be controlled via an API and configured to perform actions via Chromium Headless instances running in Docker containers. Depending on the resources available on the server, a hacker may generate tens or hundreds of these containers simultaneously, each with a session cookie stolen from a victim.

Actions performed by instances of the zombie browser can be fully automated. For example, depending on the type of account, this may mean taking screenshots of emails, initiating password resets, uploading malicious keys to GitHub or adding malicious addresses to email boxes. Browser instances can also be used to collect information about contacts and friends on social networks and even to send phishing messages to these friends in a worm attack.

A big problem for few solutions
And unfortunately, few technical solutions completely block such server-side phishing attacks. Muraena was developed to show that techniques such as SRI and CSP have a limited effect and can be bypassed automatically. In addition, the tool shows that the 2FA is not a foolproof solution.

However, this type of proxy phishing cannot defeat some 2FA implementations. Those using USB hardware tokens with Universal 2nd Factor (U2F) support. This is because these USB tokens establish a cryptographically verified connection to the legitimate website through the browser, which does not pass through the attacker's reverse-proxy. In addition, solutions based on codes received by SMS or generated by mobile authentication applications are vulnerable, as victims have to enter them manually.

Vigilance is required
Another technical solution can be a browser extension that checks if the user enters his or her credentials on the right website. Google has developed such an extension for Chrome called Password Alert that alerts users if they try to enter their Google credentials on a website that does not belong to Google.

Training users to be vigilant and ensure that they authenticate themselves on the right website with the right domain name remains very important. The presence of a TLS/SSL indicator and a valid certificate are not sufficient to consider a website legitimate because certificates can now be easily obtained free of charge, so most phishing sites will be HTTPS compliant.
R
replied 2012d
Solutions : The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP.

Header type Response header
Forbidden header name no
SyntaxSection
X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
0
Disables XSS filtering.
1
Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
1; mode=block
Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
1; report=<reporting-URI> (Chromium only)
Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
ExampleSection
Block pages from loading when they detect reflected XSS attacks:

X-XSS-Protection: 1; mode=block
PHP

header("X-XSS-Protection: 1; mode=block");
Apache (.htaccess)

<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
Nginx

add_header "X-XSS-Protection" "1; mode=block";