A new method for network tunnelling: tundeep

September 10th, 2013

I’ve been frustrated during several pen tests lately at the lack of a tool to tunnel through a network in the way that I want to.

Consider the following network:

[Attacker (eth0)]

Once we’ve compromised VICTIM1 we have a number of current choices to tunnel deeper into the network. As far as I’m aware, these are:

  1. Metasploit’s ‘autoroute’ module.
    Advantages: This is a great tool that does exactly what I want. It tunnels traffic through the victim so that the attacker appears to be on the victim’s network.
    Disadvantages: Works great, but only works from within metasploit. No use for running external tools, scans, or layer 2 protocols. Metasploit Pro has a VPN tunneling feature that looks ideal although not all of us can afford it 😉
  2. Metasploit’s portfwd module/iptables/simpleproxy.
    Advantages: Quick and easy
    Disadvantages: Only forwards specified single layer 3 UDP/TCP ports, and each port must be forwarded individually.
  3. Proxychains/ssh -D SOCKS tunnelling.
    Advantages: This is my current preferred method wherever possible. Easy and reasonably flexible
    Disadvantages: Proxychains is a hack in itself, and only supports layer 3 TCP.
  4. Implement a VPN server and set up bridging on your victim.
    Advantages: Will do exactly what we want
    Disadvantages: Disastrous idea, requires config and install on victim, possibly reboot or interface reconfiguration/bridging, very unstealthy

Currently, my preferred method is a mixture of the above depending on the scenario. What I’ve always wanted though, is a method to bring up a local interface on the remote network, that I can interact with as if I was directly connected, running any tools I wish including ARP scans and poisoning.

Introducing TUNDEEP… [Get tundeep now]

For the next release I’m planning compression mode, packet mangling, and a code cleanup as well as any bug fixes that arise.

Automatic Kinetic Watch Winder

June 11th, 2013

I had some spare time a while back and so rather than buying an automatic watch winder for a watch that I rarely wear, I decided to build a USB powered one myself. Certain types of watches require movement through wear to keep them ticking. If you wear the watch daily, this shouldn’t be a problem but missing a day or two will cause the watch to stop – annoying if you don’t wear it regularly.

Watch Automatic Kinetic Winder

Watch Automatic Kinetic Winder

The project was a relatively simple hack, I have an arduino chip connected up with a bare minimum circuit. I have two mini motors attached to off-center drilled metal coins causing them to vibrate when active. The arduino simply sets pin 13 high for 1.5 seconds and then low for an hour. The pin output opens and closes a transistor which provides necessary amplification to drive the two mini motors.

The code as follows:

int pin = 13;
int vibrate = 1500; //1.5s*1000
int sleep = 3600; //60s * 60m
int sleep_loop = 1000;
int sleep_ctr = 0;

// the setup routine runs once when you press reset:
void setup() {
  // initialize the digital pin as an output.
  pinMode(pin, OUTPUT);

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(pin, HIGH);   // turn the pin on (HIGH is the voltage level)
  delay(vibrate);               // wait for a second
  digitalWrite(pin, LOW);    // turn the pin off by making the voltage LOW
  for (sleep_ctr = 0; sleep_ctr < sleep_loop; sleep_ctr++)
    delay(sleep);               // wait for 3.6s * 1000 (1h)
Watch Automatic Kinetic Winder

Watch Automatic Kinetic Winder

Wireless Exploit Device Code

April 26th, 2013

The wireless network service exploiter that was written for the Automatic Wireless Hacking Station is as follows. This is of course to be used for research and testing purposes only, and not for anything illegal.

Update: You can download the code here.

This tool runs fake HTTP, POP3, and IMAP servers as well as their SSL counterparts. It is part of the wireless MITM device for usage in situations without internet connectivity. It dynamically handles SSL certificate generation, logs GPS co-ordinates if they’re available in /run/gpsdata and logs any credentials to a sqlite3 database. It will respond to the iDevice and Blackberry internet connectivity test and it can also optionally deliver a message to any POP3 victims.

Fully Automatic Wireless Hacking Station

April 26th, 2013

This article describes a working all-in-one standalone mobile wireless attack station that can perform MITM type attacks on clients automatically and without any internet access or other external connectivity or influence.

In laypersons terms; this portable battery powered device can automatically entice wireless devices to connect to it, be that iPhones/iPads, Androids and other phones or laptops and PCs. Most devices will connect to it automatically without the user even realizing. The device will provide a fake network running fake email and web servers and using some network trickery, will capture the hostname, username and password of any attempted connection and log it, along with the GPS co-ordinates of where the details were captured. This device could be used to hijack corporate and personal email logins, facebook logins, and so on.

HTTPS ActiveSync

Messing around with airbase-ng, part of the aircrack-ng suite over the last few months and researching wireless client vulnerabilities has led to an interesting proof of concept project. There are several weaknesses within the current wireless technologies in widespread use. First however, an explanation of the project. The project description was to launch a wireless man in the middle (MITM) attack, without having another end to connect the victim to. We need to create a MITM attack without having any internet access. Such an attack could theoretically be used on the tube, in locked down buildings, on the move, and so on, and without the use of a mobile data card. Built on top of a modified raspberry pwn release, although any Linux distribution would have been suitable, I have set my wireless device with a power output of 30dBm and started the following automated process:

Firstly, an airbase instance on my rtl8187 card as follows;

/usr/local/sbin/airbase-ng -c 3 wlan0 –essids “/root/pen/code/scripts/essids” -P -C 60 -I 60 -vv|grep –line-buffered  “directed probe request”|tee /run/probes

This starts an access point on channel 3, beaconing the SSIDs contained within /root/pen/code/scripts/essids as well as any probe requests that the access point may receive from clients looking to connect to an access point. Now, in a little more detail, regular ‘non-hidden’ access points will broadcast ‘beacons’ which are pieces of data that specify the SSID (wireless network name) as well as the supported encryption types and so on. These beacons are usually sent every 100msec. Wireless clients will send probe packets, containing the SSIDs of all wireless networks that they have stored, and asking if any of them are here.

Raspberry Pi

Raspberry Pi

The -P switch to airbase-ng will have airbase respond to all probes saying “yes, that’s me” at which point assuming the encryption or lack thereof matches the stored profile, the client will attempt to associate. Mid way through building this test however, Apple released IOS 6, and one of the changes seems that the iPhone will now only send out broadcast probes rather than directed probes, rendering the -P feature useless against them. The broadcast probe is where the device sends out a “is anyone there?” probe, and waits to see which access points reply. Most iPhones however have connected at some point to a wireless hotspot, and so the SSIDs I chose for the essids file are “Boingo Hotspot”, “BTOpenzone” and “BTWiFi” in the UK. I believe that “attwifi” is a popular one in the US.

Read the rest of this entry »

Raspberry Pwn

October 15th, 2012

I’ve recently acquired two Raspberry Pi boards along with power supplies and a nice case. I was attracted by the price and the processing power/RAM vs power consumption. The first thing I was interested to install was the Raspberry Pwn release. I wouldn’t call it a distro as such, it’s more of a script that just downloads tools that most pen testers would download themselves at some point. The Raspberry Pwn site advises that it is not compatible with ‘Raspbian’ which is the newer release shown on the Raspberry Pi site, although I couldn’t see a reason why. I downloaded the installer and ran it manually line by line some time ago, and I remember it running correctly and without issue. There were a few changes to the aptitude installs to address missing packages and I also gave up trying to download the exploitdb through SVN at the end of the script as it seems to be permanently down. I also downloaded aircrack, dnsmasq, compat-wireless, mdk3-v6, nmap, mitmproxy, reaver, and sqlmap.

[nggallery id=3]
Read the rest of this entry »

Robot Line Follower

October 12th, 2012

So I’ve had my eyes on the Pololu robot for some time. Here’s a video of it automatically following a track!

Having done that, I decided to add line following ability to the larger robot. It’s quite a simple circuit and fits in nicely with my arduino experimentation. I have a strip of high power LEDs with a pot to trim the brightness. Underneath that, I have 5 light sensitive resistors, reasonably well spaced apart and separated by card. The theory here is that the light sensitive resistor  that is over the black line will have less resistance than the others, and using that, we can work out whether we need to move more to the left or the right.

[nggallery id=2]


Pololu with XBEE Manual ControlThe 5 analog inputs are fed to the Arduino chip, which converts them to digital output and passes it to the board over USB serial. From there we can write a simple algorithm to control movement.

I then decided to go ahead and test the new XBEE chips for wireless communication. They really are plug and play.. Here’s another video –

Wireless Power Experimentation

October 11th, 2012

It’s been a while since I made a post here as I’ve been a little busy working on my new venture http://www.expertinternetsecurity.com/ but I’m going to try and get back to it again. I’ve been messing around with some cool projects from the Pololu robot, to wireless power, to a wireless network exploit station built around the raspberry pi.

Anyway, some time ago, I became interested in wireless power. I don’t know a huge amount about electronic theory, but thought I’d give it a go. The circuit is really simple and really really REALLY inefficient. I use a signal generator to drive a high power transistor at about 10kHz square wave and then have 24VDC pulsed through the coil. The receiver is just a coil with a noisy weak AC current and some LEDs. I can increase efficiency slightly using a capacitor.

Of course, there are some far better circuits out there like http://iteadstudio.com/application-note/wireless-power-transmission-or-charge-module/ or http://www.youtube.com/watch?v=2ODW-ntPHSU but this was just a quick hacked together test without going too much into the electronic theory of it. Here’s some pics..

[imagebrowser id=1]

Driving the robot with the power of the mind

May 3rd, 2011

In this video I’ll be showing how I used the Emotiv headset to drive the robot. Please excuse the editing, and in fact the video itself. I will perhaps aim for a better one in future. Hopefully the video is sufficiently clear in what’s happening.

Emotiv EPOC Headset

May 3rd, 2011

Having an interest in Brain Computer Interface (BCI) hardware, and with the release of the Emotiv EPOC headset, I decided to invest in the Research Edition. The research edition comes bundled with the research version of the SDK. The benefit of this version of the SDK is that we also have access to the raw EEG outputs from each channel, as well as a piece of software called TestBench that allow for saving/replaying sessions.

The headset itself comes almost ready to go, just attach the felt pads and wet them with saline. Affixing the headset to the head is a bit difficult the first few times and requires a bit of practice. Once you’ve done it a few times, it becomes a lot easier. The key is getting each of the felt pads absolutely soaking wet with saline before putting it on the head.

I’m going to be using the headset for a number of different purposes. As a BCI, I intend to use it to manipulate the robot, and probably in future other more useful tasks. Separately, I plan to use it to monitor sleep and meditation sessions which are a separate area of interest of mine.

In a previous post, I showed how it was possible to control the robot using voice commands. Here, I’ve modified the voice control script to handle simple keystrokes instead. The Emotiv control panel comes with a tool called ‘Emokey’ that can issue defined keystrokes when certain actions are detected within the control panel. Here’s a video:

The purpose is really to show how simple it is to interface with any regular program/script using EmoKey. There are other more exciting possibilities such as directing music based on the Affectiv suit. The Affectiv suite deals in mind states such as frustration, alertness, meditation, etc.

Robot voice control

May 2nd, 2011

I’ve set up a new mic and used cvoicecontrol (with some bug fixes) to perform voice control. I’ve integrated cvoicecontrol into my C HAL layer. Each voice model needs training and saving, however once done, they can be reused in the code. For example; if (listen(“yesno”)) { … } is all that’s required to listen for a yes or a no, assuming that “yesno.cvc” has been trained in advance. I’ve also integrated the clap switch across the one of the Phidgets digital inputs. The software requires two toggles within 8 seconds of each other, and the hardware configuration requires two claps to generate one output toggle. This seems the best way to filter out other noise from triggering it. The result is two sets of two claps are required to activate the voice control. Here’s an example:
Read the rest of this entry »

Robot vacuum? Who needs a Roomba

May 2nd, 2011

The Roomba’s a great invention. Who needs one when you’ve got one of these though? </joke> For over 4 times the price and nowhere near the simplicity or ease of use, I present:

Linux robot automatically charging

May 2nd, 2011

Since the robot’s rebuild, I finally tackled the automatic charging situation. There are a number of ways to get the device to autocharge. If it always has line of sight to it’s charger, it can spin until it finds it using infra red, then follow the beam – this however doesn’t work without line of sight. It could use a compass, although there are too many magnetic fields, and this requires advance knowledge of positioning. The simplest method would be to always start on charge, and just store movement history, reversing it when it was necessary to charge. Problem here is that even with good wheel alignment, AND accelerometers, even after few movements, simply reversing them is often not good enough to get it even close to it’s original position.
Read the rest of this entry »

Linux Robot – Manual Movement

May 1st, 2011

The robot’s new design also allows for better manual movement – here’s a video of the robot being manually controlled. This is all done via the TCP server and can be hooked to any TCP speaking application.

Rebuilding the Robot

May 1st, 2011

It had been a while since I’d worked on the robot, and I wanted to work on some movement algorithms. I’ve done some AI work lately on a separate project, and thought that this would help with the automated movement task. Unfortunately, the Robot had a little accident, namely falling out of the loft whilst I was bring it down. It’s been long overdue the removal of some of the excess hardware, and also needed some bugfixes that I now had no choice but to perform.
Read the rest of this entry »

Linux Controlled Door Entry

January 31st, 2010

Having recently moved to a new apartment, one of the first things that I decided to do was build an RC entry system 😉

Here’s some pictures:

Door Door

The black box at the top is a simple Velleman RC control kit and the black box below is a 240VAC->12VDC regulated converter.  The Velleman RC receiver has two relays, one connected to an electric strike lock and the other connected over the button input in the entryphone which unlocks the main door.

On the RC transmitter there are two buttons, and as they are currently connected, one opens the main door and one unlocks the electric strike on the apartment door, with a 5 second timer on each.

This works well so far and I have paired the transmitters with the receiver so that default unpaired transmitters will not activate the relays. A few weeks on, having already locked myself out once, the next step is to extend this project.

I intend to have the RC transmitter connected separately to some embedded linux board, probably the spare Alix and Phidgets boards I have from the robot I built a while ago. The linux board will signal over a separate frequency to this door entry system. The linux board will perform a variety of functions from logging entries to automated surveillance.  Additionally the linux board will have net access and possibly run asterisk. I can either SMS my way in or alternatively call in to asterisk and do some voice authentication. More to follow when I actually have time to get this done..