Background

Following on from the previous Post (Blue for the Pineapple…). I now want to introduce the Anti-Pineapple! Your probably asking the question “How do you create an Anti-Pineapple?” The answer is quite simple; by conducting a review of the security measures installed on the Pineapple device itself; it should be quite easy to create a list of possible scenarios and counter-measures.



In the previous post we covered hacking the firmware image to get access to the source-code. However this is no longer necessary, as most of it is now available on github:

git clone https://github.com/WiFiPineapple/web-interface.git

By analysing the source-code, it becomes immediately obvious that there is no defensive code, no input validation, and for a Web-Application there is no session security, or cross site request forgery protection.

As a quick example; there are multiple uses of the following line:

<form action='$_SERVER[php_self]' method= 'post'>

Now, readers/developers familiar with PHP and code reviews will know this use of the $_SERVER[php_self] tag is vulnerable to Cross Site Scripting (XSS) as it uses the entire URL specified by the user. So by simply adding XSS into the URL, the PHP will execute our injected code on the POST-back.

Very crude example:

<form method="POST" action="<?php echo $_SERVER['PHP_SELF']; ?>">

<input type="text" name="username" />

<input type="submit" value="Submit" />

</form>

http://www.example.com/index.php/<script>alert("xss")</script>

Becomes:

<form action='$_SERVER[php_self]' method= 'post'>

<script>alert("xss")</script> <"">

<input type="text" name="username" />

<input type="submit" value="Submit" />

</form>

Recommended solutions are to use one of the following alternatives:

change the form action to:<form action=’#’,

replace $_SERVER[php_self] with $_SERVER[‘SCRIPT_NAME’]

to encapsulate the variable with htmlentities()

As the code has been copied and pasted several times (used as a template) and community developers have copied chunks of the code for their plugins, insecure variables and functions are repeatedly used throughout the code. This is nothing new, as security testers often do not code defensively or securely when their releasing Proof of Concepts (PoCs). As the majority of the community appear to be students or fresh post-graduates, security is most likely something was not necessarily taught to them when they started to learn programming. So knowing data is not validated! How can we exploit this to inject our own code…. if you know how its quite simple?

Using an automated PHP Scanning Program RIPS-Scanner (http://sourceforge.net/projects/rips-scanner/), to scan for further potential vulnerabilities, revealed the following class types and number of vulnerabilities:

Command Execution 19 Local File Includes 1 File Manipulation 7 Cross Site Scripting 16

Injecting Malicious Code

Manually Injecting Code onto the Pineapple

The pineapple is essentially its own device, and when clients associate they are connected to the pineapples private local network (not necessarily with internet access). A user knowingly connected to a pineapple could browse to the Pineapple web interface http://172.16.42.1:1471 and start messing with the configuration (assuming the default credentials root:pineapplesareyummy have not been changed). But this is rather a manual process… there must be an automatic way of attacking the Pineapple…… And what if a clever user has changed the default username and/or password? Read on…..

Automatically Injecting Code onto the Pineapple

The following section can only be conducted from a Linux or similar UNIX based Operating System (including some Android Smart Phones).

The main status page pages/status.php (redirected from index.php) holds information about the Pineapples current state, what SSIDs from Beacon Frames it sees and what clients are connected. More interestingly there is a “detailed report” section for viewing the details of an individuals connection. By reviewing the PHP code, this information is grabbed from various binaries on the system (stadump, airodump, iwlist etc) the outputted data is then grep’ed, awk’ed or even se’ed to only grab and display the relevant bits of information a Pineapple Operator may find useful. Here lies the problem: that there is no data sanitation or validation, therefor a Unix user can inject code by broadcasting a Beacon Frame for the following SSID (SSIDs are limited upto 32 maximum characters): <script>alert(“PWNED”)</script> Using the TPLink WR703N and airbase-ng PoC:

$ airbase-ng -e '<script>alert("PWNED!")</script>' -c 6 -v wlan0

-e = sets the SSID

-c =sets the channel

-v = verbose mode

Evidence:

Since the Pineapple has no session protection, or Cross Site Request Forgery (CSRF) protection we can use JavaScript to post commands to the pineapple (running as root) through a malicious SSID. Though this requires some additional coding, and is made much easier when the pineapple is connected to the internet (via tethering or Internet Connection Sharing). We can use a JavaScript redirection and a short URL (6 characters) to successfully trick the pineapple into visiting a website hosting our malicious JavaScript payload .

The advanced page pages/advanced.php has a handy “execute command” function, by posting the following command via CSRF we are erasing the memory and rebooting the device. When its rebooting there is no memory to reboot, thus effectively rendering the Pineapple device into a brick!

mtd erase firmware;reboot

Where is the Anti-Pineapple Code?

As the Anti-Pineapple PoC code is destructive to current Pineapple Owners, we have decided not to release any public exploit code. We would like to confess that only 1x poor Pineapple was harmed during our research/experiment. Note: We were able to re-flash the firmware, and bring our little Pineapple back into operation.

If you want to build the Anti-Pineapple, there should be enough information in this blog post for you to create your own, or even an Anti-Pineapple Infusion 🙂 .

Related articles