PineShock: Abusing Shellshock via a Pineapple

Hi All,

This time I will write my post in English since it’s directed at security folks. I got the idea of chaining the karma module of the pineapple with shellshock on the day of the advisory. I was giving a demo with the pineaple and noticed allot of systems called “mbp-*” which I guess where mac book pro’s. At the end of the day Trustedsec released a POC with a DHCP server which got me thinking. Since OSX was vulnerable I wanted to see if I could force them to join my network and own all those shiny Macbooks.

UPDATE: The OSX DHCP client is not vulnerable, still a nice attack to demonstrate the risk of automatically joining networks.

One problem, I don’t own a Macbook but I do have a spare machine with Ubuntu and an outdated version of Bash.

The process:

  1. Start karma module to force people to join the Wi-Fi.
  2. Once the machine joins wait for a DHCP request and send them the malicious DHCP-offer.
  3. Wait for a reverse shell and have fun!

The DHCP server of the Pineapple was disabled via:

uci set dhcp.lan.ignore=1
uci commit dhcp
/etc/init.d/dnsmasq restart

I used the metasploit module: exploit/unix/dhcp/bash_environment. Next I added an open Wi-Fi network to the Ubuntu machine. Since the machine was only used on secured networks I needed to add this. The standard Macbook is probably probing for various SSID’s without authentication.

free-wifi

After this the laptop automatically connected to the SSID, and a DCHP request was fired, the metasploit module sent a dhcp offer containing the same string in various DHCP options. The module uses the following options to deploy the payload:

  • DOMAINNAME
  • HOSTNAME
  • URL

dhcpoffer_anders

I noticed the Ubuntu machine does not trust one of the above options I think it was the domain name option but I am not sure. This means the other two DHCP options will be executed and we will receive two reverse shells once our payload is executed. The way the reverse shell is executed is via /etc/crontab, a new entry is added that needs to run immediately. First a sleep of a random duration then a telnet connection is set up to our machine on port 4444. After this the module takes over and cleans the crontab to ensure the machine does not keep connecting.

reverse_shell

Nice this seems to be going well 🙂 let’s look at our shell one more time just because it’s that much fun!

r00t

The evil thing about this attack is the fact that the user has no choice but to join my network, vulnerable machine’s will get owned.

 

UPDATE: I just received news that the DHCP client voor OS X is not vulnerable to shellshock. Unfortunately I did not know this and did not have a mac to test on. It still is a nice attack because of the user being forced to join the network. It’s just not that prevalent:P

If you have any questions, find me on Twitter:

12 Comments on PineShock: Abusing Shellshock via a Pineapple

  1. Sebastian
    October 2, 2014 at 4:35 pm

    cheeky!

    Reply
  2. Thomas
    October 3, 2014 at 7:18 am

    > “The standard Macbook is probably probing for various SSID’s without authentication.”

    This is, luckily, optional.

    Reply
    • Andrew Beard
      October 13, 2014 at 12:37 am

      It is optional, but with the Pineapple the system doesn’t have to be trying to join new unknown networks, it just needs to have previously joined at least one unauthenticated network in the past. The Pineapple will pretend to be that network and the system will connect. If you’ve ever connected to the wifi at an airport or a coffee shop there’s probably an “attwifi” or the like SSID that the Pineapple will pose as.

      Reply
      • rik
        October 13, 2014 at 6:40 pm

        It will not work if the OS is configured to not automatically join a network once it is available. From that point it’s up to the user.

        Reply
  3. John
    October 6, 2014 at 9:10 am

    Hi Rik,

    nice thing! Could you perhaps explain how you “connect” your Pineapple to Metasploit?

    Perhaps a little more detailed tutorial? That would be great!

    Thanks in advance!

    Reply
    • rik
      October 6, 2014 at 11:33 am

      This was done using a wired connection, i just connected my laptop to the pineapple. Could also be done via the Wi-Fi connection. DHCP is sent via broadcast so everyone on the network receives the request, and can respond to the request. I disabled the pineapple DHCP server so my metasploit DHCP server is always the first to respond.

      Reply
      • John
        October 8, 2014 at 9:48 am

        Thanks Rik!

        Reply
  4. mew
    November 5, 2014 at 8:37 am

    I’m a little bit stuck… I’m trying to adapt this to work on an existing wired local network. Shouldn’t be too much more difficult, right? I set up the module and run it, and metasploit seems like it’s working. It runs the DHCP server. I’m even getting address from the metasploit server on my victim VM! But, I look in syslong, and I see this:

    dhclient: suspect value in domain_name option – discarded

    Is that what you were talking about before? If so, how did you get around it? The exploit looks like it’s supposed to send the code two more times, once in hostname, and once in URL. I can see the domain name (not working. dhclient catches it) and URL parameters go through via wireshark, but I can’t see the Hostname parameter. And, it doesn’t work. If I netcat to my Kali VM on port 4444, metasploit responds, but that’s the only way I can get it to respond.

    Am I missing something here…?

    Thanks!

    Reply
    • rik
      November 6, 2014 at 8:06 pm

      maybe a stupid question but i have to ask: is your victim vm using a vulnerable bash version? What victim OS are you running? Could you share a screenshot of the DHCP offer? The module could be broken if that’s the case we can fix it.

      Reply
      • mew1033
        November 11, 2014 at 7:36 am

        Let me double check….
        Looks like bash is version: I’m pretty sure that’s vulnerable.

        Are you talking about the /var/log/syslog file? If so, here’s what I have:
        http://i.imgur.com/Y2jr5V3.png

        Reply
        • mew1033
          November 11, 2014 at 7:37 am

          Oops, forgot to post the version number. 🙂 It’s 4.2.24

          Reply
          • rik
            November 13, 2014 at 2:35 pm

            Try to verify if you are using a vulnerable dhclient (not every dhclient is vulnerable.) next to this check the dhcp offer by doing: “dhclient eth0 -v” The shellshock trigger is located in more then just the domain_name. Check bash by triggering the bug: “env X='() { :; }; echo “CVE-2014-6271 vulnerable”‘ bash -c id”. You could also check using Wireshark, this will allow you to look at all the dhcp options you malicious server is sending. If it is sending but not triggering try and copy the commands from the options and see if the payload is correct.

Leave a Reply

Your email address will not be published. Required fields are marked *