Two weeks ago, we published Pineapple 101: Modules’ Review and Testing (Part 1). We did a quick review about the Pineapple and we analyzed 3 modules. The API Token module, which allows users to control the Pineapple through a REST Api. The PineAP module, which allows users to create fake open access point. And finally, DNSMasq Spoof, a good module to create a fake DNS server, and redirect some domains and subdomains to our custom fake page. Now, we continue with our review about this “hacking fruit”, the Pineapple. This time we are going to analyze 3 modules more.

4. Dwall

The Dwall module provides us a local HTTP proxy that we can use to sniff the following information:

HTTP URLs

Cookies

Data (the content of HTTP POST)

Images

It does not require any additional configuration. We only need to activate PineAP, (You can go back to our previous post to check how to use it) and wait for clients. To enable it, we have to follow the following steps:

Click the “Enable” button. Click the “Start Listening” button. Now, Dwall is running!.

It looks like this:

This module sounds awesome but… the first problem is that all information is mixed!. We cannot identify the data (cookie, URL, etc.) owner.

Now, let’s go to see what we can do with the sniffed data:

In the URLs panel, we can “spy” all visited websites, and try to find GET parameters, like emails, usernames and session tokens:

In the Cookies panel, we can find all clients’ cookies. We can try to find some sensitive information, like usernames or sessions Ids. A lot of websites save the user’s password in a cookie (think about a bad implementation of “remember” function), so we can try to get some password from them:

In the Data panel, we are going to find, all POST parameters. We can try to find usernames and password.

And the last one, the Images panel. It shows us all images browsed by the clients, this panel is not very useful, but maybe it could be the most funny.

Finally, we can say that Dwall module is very good to sniff traffic, but we can only sniff non-encrypted HTTP traffic. So, how can we sniff HTTPS? To do that we’ll need another module, let’s check it out.

5. SSLsplit

Like Dwall, the main objective of this module, is to create a proxy, and sniff all HTTP and HTTPS traffic. It works using a custom SSL/TLS certificate to send to the browser (like BURP or Owasp ZAP). In this way, the module will be able to decrypt and sniff all traffic between the browser and the proxy.

Now we understand what we can do with this module, let’s test it. If this is the first time that we use it, before starting the module, we need to do two things. First, we need to install the dependencies, clicking the button “Not installed” (in red). After that, we need to generate the SSL certificate. To do that we have to click the button “Not generated” (in red). After installing the dependencies and generating the certificate, we will get two green buttons:

We can make it start during the boot process using the option “Start on boot”, this is a useful option, if we want to use the Pineapple with a battery and go around to get some “clients”.

Now, we can start the module by clicking the “Start” button. (Remember to enable the PineAP module, to allow clients to connect to the fake access point) .

This module has got a panel called “Configuration”. It contains all necessary “iptables redirects” to get the module work. We do not need to change anything there.

Now, we have all configured and the module is sniffing the traffic. Let’s see what happens in the victim’s browser when s/he tries to visit a HTTPS site:

We can observe that the browser warns the victim about the invalid certificate. However, if the victim is not secure-wise or if s/he deliberately accepts our certificate the browser will show the site. Remember that, if the website implements HSTS, and the victim has browsed the website before, the browser will not allow her/him to continue. In this case, we decided to continue, and the website is shown:

Well, we tested the module, but where is all sniffed data? We have to return to the Pineapple and check the Output panel, where we can find all the sniffed data:

Remember check the “Auto-refresh” options, to avoid, clicking in “Refresh Log” button each time

Another interesting section where we can find the sniffed data is the History panel. In there place, we can find the history of all sniffed traffic separated by date and time:

SSLsplit is the most useful MitM module for the Pineapple, but we can find some issues using it. First of all, it is nice to sniff the HTTPS traffic, but compared with Dwall, inspecting the output is a mess, because Dwall has got many panels with the intention of separate the data (URLs, cookies, POST), and this module only has got all requests in a txt file. Other problem, or I must say, the other big “enemy”, is the SSL Pining. If we want to sniff some traffic from mobile devices like Android cellphones, most of applications implement SSL Pining. This kind of applications, before establishing the data exchange, they check the server certificate comparing with the certificate built-in inside the application. So this module will not work for applications that uses SSL Pinning, but it will work for the mobile browser. And finally, the “nemesis” of this module is HSTS. All sites that implement HSTS, and they have been loaded in the client’s browser before start the module, could not be accessed, because the browser remember the first certificate, and compare all next certificates with that. A good solution to this problem, would be use SSLstrip2, we can use it in console, but we do not have an official module for this.

6. EvilPortal

Our last module!. We have analyzed two MitM module, but the last one is not about MitM, it is about “social engineering” and “phishing”. The evil portal module, provides us with a captive portal for all clients in the Pineapple. All new connections through the PineAp, will be redirected to the captive portal, even if the user writes an URL directly in the browser. The clients will not be able to reach internet until they “accept” the captive portal. After accepting it, they will be redirected to the original URL. Thinking in the real world, this module could be useful to simulate an open network from a shop or company, and try to get some credentials.

Now that we understand what this module does, let’s go and configure it. The module has got five interesting areas:

Controls area allows us to start the module, and activate the start boot option, if we want to plug the Pineapple and start this module, for example connect it to a battery and go around the neighborhood.

area allows us to start the module, and activate the start boot option, if we want to plug the Pineapple and start this module, for example connect it to a battery and go around the neighborhood. Evil Portal Messages area shows some “interesting” messages, like when a new client accepts the captive portal.

area shows some “interesting” messages, like when a new client accepts the captive portal. White List area, allows us to input IPs, to avoid the captive portal, and reach internet immediately after that the client connect. For example we can use this area, to input our control device’s IP, to avoid the captive portal in the device that we use to control the Pineapple.

area, allows us to input IPs, to avoid the captive portal, and reach internet immediately after that the client connect. For example we can use this area, to input our control device’s IP, to avoid the captive portal in the device that we use to control the Pineapple. Authorized Clients area shows all IPs authorized to reach internet, because they accepted the captive portal.

area shows all IPs authorized to reach internet, because they accepted the captive portal. The last area, Workbench, is the most important, it allows us to create the captive portal! Let’s go through it.

First of all, we have to create a portal. After that, we can edit, delete or activate it.

We can only have one activated portal

If we click on the portal’s name, we can edit it. We have two important files inside the portal, “index.php” and “MyPortal.php”:

The file called “index.php” contains the captive portal itself. It contains some PHP code, and HTML code. Here we can place our own HTML code, for example we can create a “Coffee page”, like if our wireless network would be from a coffee shop, and request for specific credentials, like Google or Facebook.

The most important things in our “index.php” file are:

Do not delete the two first lines of PHP code.

Do not delete the Javascript code.

Do not delete the hidden input inside the form.

The form must go (through POST) to “/captiveportal/index.php”.

Let’s check an example of the “index.php” file:

<?php

$destination = "http://". $_SERVER['HTTP_HOST'] . $_SERVER['HTTP_URI'] . "";

?> <HTML>

<HEAD>

<title>Starbucks WiFi</title>

<script type="text/javascript">

function redirect() {

setTimeout(function()

{window.location = "/captiveportal

/index.php";},100);

}

</script>

</HEAD>

<BODY>

<center>

<h1>Free Wifi</h1>

<form method="POST" action="/captiveportal/index.php"

onsubmit="redirect()">

<input type="hidden" name="target" value="

<?=$destination?>">

<button type="submit">Accept & Connect using your

google account</button>

<p>I agree to the Terms of Service and have

reviewed the Google Privacy Policy</p>

</form>

</center>

</BODY>

</HTML>

After the changes, we can save the page. Now we need to edit the second file, “MyPortal.php”. It contains a PHP class, we only are interesting in change the “handleAuthorization” method. In this method, we can get the POST data and save it into a txt file, using $_POST array and fopen function, for example:

<?php namespace evilportal; class MyPortal extends Portal

{ public function handleAuthorization()

{

// Call parent to handle basic authorization first

parent::handleAuthorization(); // Check for other form data here $username = $_POST[“username”];

$password = $_POST[“password”];

$myfile = fopen(“output.txt”, “w”);

fwrite($myfile, $username . “-” . $password);

fclose($myfile);

}

Well, we have finished our captive portal, let’s test it. We have created a open network called “Starbucks WiFi”. Now we are going to connect using a mobile device:

The operative system alert us about the captive portal.

Now, we are going to connect using a laptop and try to browse some site., why not www.medium.com?. Voilà!, We got the captive portal!

Finally we can say that this is a useful module, but it has got some problems. First of all when the client accepts the captive portal, it does not redirect to the requested page. And second, if the client tries to access to some HTTPS page using “https” in the URL, the captive portal will not be shown, and the request will be allowed.

Next steps

This is the second part of our review, we are working in the part 3 that will contain our analysis of how to create modules, and new modules for the community.

For comments, input, feedback, etc.: Emiliano, Maxi