A new phishing attack was recently disclosed at a security conference that circumvents the two-factor authentication schema deployed at many organizations. The attack uses a sophisticated way of tricking the user to authenticate with no impact to user interaction with the website. Once authenticated, the attacker will have the authorization tokens and cookies required to seamlessly act on behalf of the victim to issue anything from account modifications to password changes.
The tool is called Muraena and the seamlessness of it is that it acts like a middle-man by relaying legitimate requests to Dropbox while doing slight manipulations to trick the browser into believing the traffic is legitimate. In the scenario below, the tool was configured to work with Dropbox. Any user browsing to our internally hosted https://evil.test would think they were browsing Dropbox. An attacker could easily create a mutation of dropbox.com to trick the eye, but we decided to keep it obvious.
Below is what the victim will see when navigating to https://evil.test. This may not look exciting, but look at what happens when they sign in.
Notice how the flow is uninterrupted and normal. The only noticeable differences being the substitution of evil.test for every dropbox.com request. This functionality alone makes this tool extremely dangerous as it by-passed all browser security controls.
To understand how this works, a primer on HTTP headers is required. Below is a GET request which would be the first step in the process where the victim would navigate to what they believe is Dropbox.
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept-Encoding: gzip, deflate
HTTP/1.1 200 OK
Date: Fri, 14 Jun 2019 00:53:30 GMT
Content-Type: text/html; charset=utf-8
Set-Cookie: puc=; expires=Fri, 14 Jun 2019 00:53:30 GMT; httponly; Path=/; secure
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=15552000; includeSubDomains
If the server received a request to Dropbox.com but received unexpected header and body values, it would respond with an error. Muraena prevents that from occurring. Below is a detailed flow to help further understand how this works.
- User navigates to evil.test which they assume is dropbox.com
- Evil.test changes the headers and body content from the phishing domain (evil.test) to the real domain (dropbox.com). The following header and body content are replaced:
- Headers: query string, host, origin, referrer, cookie, x-headers
- Body: domain name, content length
- Response from Dropbox will come to evil.test
- The headers and body content again are modified but this time to values of evil.test. This essentially bypasses all existing security controls (HSTS, CSP, Framing, Anti Sniffing, XSS)
- HTTP 200 OK sent to user which means the request has succeeded
Once the victim is authenticated to Dropbox, the authentication records are sent to a secondary tool called Necrobrowser. This tool will take the authentication cookies and tokens to conduct authenticated requests on the attacker’s behalf. It could be used to change passwords, and even disable the two-factor. It can do this because Muraena sits between the victim and the web server (dropbox.com) while capturing everything in between (including the credentials used to authenticate).
The one caveat to this tool is that it requires thorough understanding of the web application to determine how each request and response is handled. The tool requires a customized configuration to identify which headers, parameters and body content needs to be modified for each request and response. Without this information, this tool would be not work as intended. This means that every site can be affected given an attacker takes the required time to configure the tool.
At Packetlabs, we invest time learning the ins and outs of these tools to incorporate them into our client phishing campaigns. We believe that every new attack that has the potential to affect our clients needs to be explored in order to help prevent a legitimate attack.