Bypassing 2 Factor Authentication With Cookies!

[RedX]

If you have two-factor authentication (2FA) enabled on your account, you can’t be compromised, right?

Well, not exactly. As technology advances, so do the attackers. Phishing attacks have become more sophisticated and attackers are finding ways to bypass 2FA. The reason why is because of the delicious cookies stored in your browser. Session cookies are a way to show the server that the user has already authenticated. This includes passing the 2FA challenge. Your browser can use these cookie until it’s passed its sell-by date (Sorry). Once the cookie has expired, you will be asked to re-authenticate.

It depends on the application, but some may have stronger restrictions than others.

These include:

• A single use cookie.
• Restricted by IP, device or some sort of fingerprint.
• Linked to another element which validates the cookie (Anti-Spoofing).

This isn’t the case for all though and this is what attackers are exploiting. Services like Outlook, Gmail and social networking platforms all allow the cookie to be reused. The attacker just needs a way of extracting them.

To show you how it works, I’m going to be using a browser extension called EditThisCookie: http://www.editthiscookie.com/

You don’t need a fancy extension to be able to see and view your cookies. If you hit F12 in your browser (developer), you can see the cookies being used under Application > Storage.

The problem is, you don’t have an easy way to extract them. Sure, you can copy and paste but this is long winded and is prone to errors. This is where Cookie Editors make life easier. With EditThisCooke, we can simply export and import cookies into different browsers.

Using Outlook.com as an example. We first login to our account.

Once our password is entered, we approve the MFA prompt.

And now we are in. Below you can see that I’m using two browsers. On the left, I have logged into Outlook using Chrome. On the right, you can see that I’m not logged into Outlook and are using Firefox. Remember that cookies are browser specific.

With EditThisCookie, I can export my Outlook cookie from Chrome…

…and import them into Firefox. As you can see, I’m still not logged in.

Once imported, I hit the Outlook site again and I’m logged in. This is because Firefox used my imported cookie to prove that I have already authenticated.

Once imported, I hit the Outlook site again and I’m logged in. This is because Firefox used my imported cookie to show that I have already authenticated.

This was done on the same device however, this also works if I used another. If I exported the cookie on device 1 and imported them into device 2, I would get the same result (Application dependent).

This is basically what attackers are now exploiting. You may be thinking, how are they going to get access to my device though?

The answer is they are not trying to. Although I’m sure this could be achieved, it’s pretty low risk. An attacker could extract the cookie using some sort of script or Rubber Ducky but it’s unlikely. Instead, they are wanting you to come to them.

This is where EvilGinx2 comes into play: https://github.com/kgretzky/evilginx2

EvilGinx2 is a proxy/phishing tool which can extract your session cookie. It does this by creating a Phishing site and which tricks you into entering your credentials, including the 2FA challenge.

https://breakdev.org/evilginx-2-next...ng-2fa-tokens/

EvilGinx2 is a proxy/phishing tool which can extract your session cookie. It does this by creating a Phishing site and which tricks you into entering your credentials, including the 2FA challenge.

Once the user has been fooled, Evilginx saves the token, allowing the attacker to extract and import it into their browser of choice. This whole process defeats the 2FA prompts as the server read the cookie and assume the user has already been authenticated. As I mentioned above, some application has restriction on cookies. The benefit of Evilginx is that the source of the authentication will be the Evilginx server. Meaning, the attack could use a browser on the server itself and bypass any IP and device restrictions. Remember, the session cookie would record the source as the Evilginx server and not your client.

The develop created the video below to explain how it works.

So, what can you do to protect against this type of attack?

Well, the one flaw with this attack is that the DNS record will have to be convincing in order to trick todays users. The attacker will look to host Evilginx on a web server that is accessible to all. This will require the attacker to setup an external IP and DNS record. Because of this, they won’t be able to use any of Microsofts official domains. This goes for Google and any other site which has a Phishlet. Attackers will have to use techniques described in my past post: https://ctrlaltdel.blog/2019/07/11/h...hishers-phish/

https://breakdev.org/evilginx-2-next...ng-2fa-tokens/

The simplest way to fight this is by education. Now that attackers are using HTTPS to seem genuine, we will really need to be checking the URL before entering our credentials.

Hope this article helpful for you. Thank You.