Pineapple 101: Modules’ Review and Testing (Part 1)

0. What has a pineapple to do with hacking?

As you should know before buying it, pineapple is a wireless network hacking device developed by Hak5 which has “Modules” that automate certain attacks or steps in an attack like wifi client deauthentication, fake AP creation, dns spoof, cookie sniffing, etc. You may also know that it appeared in the TV show “Mr. Robot” as an almost magical device used to hack the FBI.

What you might not know is that there is little or no documentation at all about how the modules work, how to use them or how to write a new one. In this context we decided to investigate the inner workings of this device and write a guide to share with you folks.

In this guide we’ll be using the Pineapple Nano, but “It Should Work”™ in Tetra version. From now on, I’ll assume that you have followed up the setup guide and configured your device.

The first module we’ll be looking at is the “API Tokens” module. It’s not the funniest, not even the most useful, but I choose it first as it allows to explain how the inners of the pineapple modules work.

1. API Tokens

The API Tokens module allows us to control pineapple modules through a REST API, sending messages in JSON format.

{“system”:”notifications”,
“action”:”addNotification”,
“message”:”Hello pineapple”,
“apiToken”:”myToken123"}

First of all, we need to install the APITokens module. As this is the first module we’ll use lets take a look at how to install new modules:

• Open “Modules” in the left sidebar and go to “Manage modules”
• The module manager allows us to install new modules from pineapple repositories or remove already installed ones. It looks like this:

• Click on the “Get Modules from WiFiPineapple.com” button to see a list of available modules
• Look for the APITokens module and install it

You can choose internal storage or SD card if you have one

• We should see the recently installed module under the “Modules” tab. Now we have to generate a new token to use, lets call it “Test”:

• Once generated we should grab the token and save it in a safe place (Remember it allows to run any module in the pineapple)

The token is not completely shown,but double clicking selects it all

Now that we have our token, let’s use it to send a notification to the pineapple. Do you rememeber the first message example? Well it actually works, but we need to know how to send it. I’ll be using the command line tool “curl”, but you can use whatever tool you want as long as it allows you to send a HTTP POST request:

curl \
-X POST \
-H “Content-type: application/json” \
-d '{“system”:”notifications”,”action”:”addNotification”,”message”:”Hello Pineapple!”, “apiToken”:”myToken123"}' \
“http://172.16.42.1:1471/api/"
# If you’ve enabled https you have to use the following command
curl — ssl -k \
-X POST \
-H “Content-type: application/json” \
-d '{“system”:”notifications”,”action”:”addNotification”,”message”:”Hello Pineapple!”, “apiToken”:”myToken123"}' \
“https://172.16.42.1:1471/api/"

If everything went right we should see a response like this:

)]}’,
{“success”:true}

And the notification should appear in the dashboard:

Great! We can communicate with the pineapple, but how can we control the modules? Well, to know how to control the modules we need to understand the JSON we sent in the previous example:

• First we need to tell what kind of module we’ll be using and its name “system”:”notifications”. The kind of the module can be “system” or “module”
• Then we specify which action we want to perform with the selected module “action”:”addNotification”
• After that we have to specify the parameters for that action, in our example it was “message”:”Hello Pineapple!”
• Finally, we have to add our API Token to the JSON “apiToken”:”myToken123"

If you have read carefully there should be two things bothering you. The first one “How the heck do I know what is the kind of a module?”, this is the simplest to answer. The system ones are part of the pineapple’s “core” and there are only 4 of them:

• Notifications (The one we have used in the example)
• Authentication
• Modules
• Setup

Everything else is, surprisingly, a module kind of module.

The second thing you should be asking yourself is “How do I know what actions are available and what parameters is expecting?”. And sadly, to know which parameters are needed we have no choice rather than searching in the module source code.

As a quick tip to know what to look for, connect to the pineapple via our good old friend ssh and go to the /pineapple/module folder:

root@Pineapple:~# cd /pineapple/modules/
root@Pineapple:/pineapple/modules# ls
APITokens Configuration DWall EvilPortal KeyManager ModuleManager PineAP Profiling Responder SiteSurvey meterpreter tcpdump Advanced CursedScreech Dashboard Filters Logging Networking Pinegram Recon SSLsplit Tracking nmap wps Clients DNSMasqSpoof Deauth Help ModuleMaker Papers PortalAuth Reporting SignalStrength autossh p0f

Each folder is an installed module, let’s try to with the Clients module. Go to the module directory and enter the api folder:

root@Pineapple:/pineapple/modules# cd Clients/api/
root@Pineapple:/pineapple/modules/Clients/api# ls
module.php

The actions and parameters we can use for this module are inside the module.php file. This file exists in every module and contains a php class that extends SystemModule, this is mandatory for the pineapple’s engine to properly handle the modules. Take a look at the route() method:

Pay attention to the `$this->request->action`, that’s how the engine retrieves the `”action”` field in our JSON

There we have the available actions, now we just need the parameters. Take a look at the kickClient() method:

Here we can see that it access the $this->request->mac parameter, that’s how we know that it expects the mac address of the client to disconnect. Now, take a look at the getClientData() method:

Here we don’t see anything like $this->request->parameter, that’s because it doesn’t expect any parameters.

Well, now that we know how this module works, is time to use it. First identify the clients connected to the pineapple with the getClientData action:

curl — ssl -k \
-X POST \
-H “Content-type: application/json” \
-d ‘{“module”:”Clients”,”action”:”getClientData”, “apiToken”:”myToken123"}’ \
“https://172.16.42.1:1471/api/
# Output formatted and added some comments
{
  “clients” : {
    “stations” : { # Stations connected
      “30:a8:db:xx:xx:xx” : “5970”
    },
    “dhcp” : { # DHCP asigned IPs
      “30:a8:db:xx:xx:xx” : [“172.16.42.223”, “android-d37xxxxxxxxxxxxx”],
      “” : []
    },
    “arp” : { # ARP table, may take some time to get updated
      “30:a8:db:xx:xx:xx” : “172.16.42.223”,
    },
    “ssids” : []
  }
}

Now, we’ll try to disconnect the client with kickClient:

curl — ssl -k \
-X POST \
-H “Content-type: application/json” \
-d ‘{“module”:”Clients”,”action”:”kickClient”, “mac”:”30:a8:db:xx:xx:xx”, “apiToken”:”myToken123"}’ \
“https://172.16.42.1:1471/api/"
)]}’,
{“success”:true}

Now we understand the modules internals. But not only that, understanding the API Tokens allows us to build our own bash scripts combining different modules and launch them automatically or on demand, something we’ll be using at the end of this guide.

2. PineAP

The PineAP module is used to create fake Access Points and allow client connections. This module can launch two different Man-in-the-Middle and phishing attacks: KARMA attack and Evil Twin, as you can see in the linked posts these attacks require a long and complex setup using aircrack-ng suite and hostapd or other tools that mix them.

PineAP simplifies those attacks, but has a lot of possible configurations that we need to understand:

• Allow Associations: Allows clients to connect to our fake APs. What it does in low level is to respond to Association Request Frames from clients
• Log Probes: Logs “Probe Requests” from clients (Even without “Allow Associations” enabled)
• Log Associations: Logs “Association Requests” from clients.
• PineAP Daemon: Enables or disables the module
• Capture SSIDs to Pool: Looks for SSIDs and adds them to the pool
• Beacon Response: After a client sends a Probe Request the pineapple will send specific Beacon Frames for that client
• Broadcast SSID Pool: Self explanatory
• Beacon Response Interval: The frecuency at which the pineapple will send the Beacon Response Frames
• Broadcast SSID Pool Interval: The frecuency at which the pineapple will broadcast the SSIDs in the pool
• Source MAC: The MAC of our fake AP. It’s used when Beacon Response is enabled
• Target MAC: The MAC of our target. It’s used to filter the target when Beacon Response is enabled
• SSID Pool: SSIDs to broadcast

Additionally, we have to configure filters to allow/deny which clients can connect and to which SSIDs. For example, to allow all clients to connect to the “PineTest” AP we have to configure the filters like this:

It’s mandatory to have some filtering, if we don’t have it nobody will be able to connect

Note: To use this module and allow internet access to clients is mandatory to plug in an extra adapter and configure it in “Networking” or keep the pineapple connected to a computer and follow this instructions to share internet connection.

Once everything is configured we just need a victim. This may take some time, so better take a cup of coffee… Or two…

Hooray! A victim connected to our “Totally not a fake AP”, we can see it in the Clients module:

3. DNSMasq Spoof

The DNSMasq Spoof module provides us our own local DNS server.

This may be useful in case we have a local server we want to access as, lets say “www.example.com”. We just need to add the proper record to the DNSMasq configuration.

To do this go to the DNSMasq module, add the records you want and click save:

The record format is “IP [hostname]”

Now when we access “www.example.com” it’ll be resolved to 172.16.42.42:

This is amazingly useful! But it’s time to take off the white hat and put on the black one, what would happen if we use a tastier hostname?

We’ll clone the gmail sign in form with HTTrack and serve it using python’s SimpleHTTPServer. Then we configure DNSMasq to redirect google related sites to our custom gmail sign in form.

The hostnames in the DNSMasq configuration are the following:

Now, everyone connected to the fake AP or Evil Twin we created using PineAP will be redirected to our fake login form when they try to access any of the configured sites (google.com, gmail.com, www.google.com, www.gmail.com). We just need to wait for our victim to enter gmail, hope you still have some of that coffee.

And the result is:

Next steps

As this is the first part of our review, we have been working in the part 2 that will contain our review and analysis of the rest of modules which are working well for pineapple devices. Will publish the second part next week.

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