Introduction to Mallory Proxy

Although I have tried most of the proxies that allow to modify web traffic “on the air” such as burp or WebScarab, I recently discovered a pretty interesting, not only because of its developers and the context in which it was presented, but also because of its features and architecture. Mallory Proxy is a proxy developed by the computer security experts Intrepidus that was presented at the Black Hat 2010.

Mallory is developed in Python and shows a server side and a client interface for configuration and user interaction.

For those who want to try Mallory, the application shows basically has two options. The first is to follow the installation instructions and download and install both proxy sources and dependencies. The second is to download a VMWare image whose operating system is Ubuntu and that comes with both software and dependencies.

In my case I chose the first option in order to have a small sandbox environment to test the basic functions of this proxy, as I would do with any other proxy of the same type. I have to say that the installation is fairly well explained on the website of Mallory Proxy and does not involve any complication. In addition, the application includes an installation script that basically does all the steps without having to interact with it.

One of the features Mallory Proxy offers is the ability to act as a MiTM proxy over SSL connections among others. Mallory uses plugins, among which we can find the corresponding to SSL traffic handling, such as safe navigation through https. What I want to show is how easy it is for an attacker to obtain the access credentials of the users that connect to services without any security concern.

To do this, I will use an access point without authentication so anyone can connect his/her mobile device without password. This access point is connected to a router with a Debian operating system which has installed the proxy Mallory. The router offers wireless Internet, so that the victim will surf the Internet smoothly. The router acts as a gateway for the user devices and we have created rules in the router firewall that enable Mallory transparent mode.

Let’s see the essential steps for this test. The first is to launch the application. Accessing the route you can see in the following image, we execute the command:

root@rogue_router:/opt/mallory/current/src# python -p sslproto.SSLProtocol 
[*] [2012-11-29 01:12:47,395] INFO:Logging setup complete 
[*] [2012-11-29 01:12:47,408] INFO:ConfigRules.init: LOADING RULES. 
[*] [2012-11-29 01:12:47,413] INFO:ConfigRules.load_config: Rule Action String is:Debug 
[*] [2012-11-29 01:12:47,422] DEBUG:NetfilterTool: Instantiating object. 
Proto is sslproto.SSLProtocol 
[*] [2012-11-29 01:12:47,429] DEBUG:SSLProtocol: Initializing 
[*] [2012-11-29 01:12:47,434] INFO:Configuring command line protocol instance:  for port 443 
[*] [2012-11-29 01:12:47,431] INFO:plugin.http.ObjectEditor: starting XML RPC Server 
[*] [2012-11-29 01:12:47,445] INFO:RPCServer: add_remote_obj - adding remote object

The next thing to do is launching the user interface that we will use to configure the desired options and to interact with the captured traffic.

[*] [2012-11-29 01:25:18,004] INFO:Logging setup complete 

After that we have the following application window, where we have the basic configuration options and the traffic handled by the proxy. In the next image, we show the configuration options for the interfaces that we will use to perform the attack. In this case, we will use the eth2 interface for the attacks, and the interface as the outgoing interface to Internet.

The next image shows how to configure the plugins available at Mallory proxy.

Although you can see they are all activated, we are interested the one named “SSL BASE”. This plugin will allow us to obtain the user access credentials in clear text, not encrypted, of the users who fall into the trap.

Although of course we could go thru other settings and options of the application, we leave it for other posts as for this test we do not need to configure anything else. Now we only need to start capturing traffic without stopping it but automatically transfer it because all we want is to capture the access credentials of a potential victim. If we wanted to modify the packets captured by the proxy, we would unset the corresponding option that would allow us to change the values ​​of the TCP/UDP packet captured, as any other proxy of these characteristics would do.

At this point, we are ready to perform a MITM attack, so we will simulate the connection of a potential victim that connects from a smartphone web browser and visits a known social network website using https connection. Let’s see what happens…

The user enters the URL of the site that her/his wants to visit. The proxy captures the https traffic and it is at this time where the user must stasy alert, since the applications shows a certificate that is not considered valid by the browser:

If the user accepts the certificate, s/he will be in the hands of the attacker who will have access to all the transmitted information in clear, readable from the interface of the proxy. Among the captured data, the username and password that is accessing the web:

Keep in mind that if we access the certificate details they do seem correct, although as we mentioned it is not validated by the web browser. As you have seen is not difficult for a user with basic knowledge to install such traps to take advantage of people who do not have a minimum care when connecting to any Wi-Fi hotspot.