Mitigating the Wireless Hacking Station

October 19th, 2012

I covered an all in one wireless exploit device previously, and will now cover some mitigation ideas. There is no individual exploit to mitigate but a series of weaknesses and insecurities that can lead to attack. To cover each step of the attack;

Attack Step
The device entices clients to connect, by responding to all wireless probes.

Client wireless implementations should be more careful when beacons are sent out. Beacons should not be sent out for all stored wireless networks indiscriminately. Clients should use broadcast probes where appropriate instead. iOS 6 seems to now implement broadcast probes as standard. Whilst this is a positive move, most mobile wireless devices have connected to at least one wireless hotspot. Beaconing for popular SSIDs in the local area such as “BTOpenzone”, “FON”, “Boingo Hotspot” in the UK and so on will continue to attract most wireless devices. Another option would be to require that open networks are manually connected to by default unless that setting is manually overridden along with associated warning. In the mean time, not connecting at wireless hotspots, removing saved wireless hotspot profiles, and turning WiFi off when not in use are all options.

Attack Step
Once connected, assign the device an IP via DHCP and use DNAT to redirect all traffic to all hosts back to the device itself.

The device should perhaps perform some tests to see if traffic manipulation is in use. This could be legitimate, but at least warn the user that something strange could be going on.

Attack Step
The device will answer iPhone or Blackberry’s HTTP test for internet access and return the expected response

I suspect this feature is supposed to detect if an internet hotspot login is required. It should either be removed or secured better to avoid just opening an arbitrary page on connection to a hotspot. This feature alone could be exploited in other ways.

Attack Step
Client attempts to check email and perhaps contact other servers based on apps installed.

Tighter verification of protocol implementations should be performed. User should be specifically warned if SSL is not in use.

Attack Step
SSL hijack.

The client should display an SSL warning that clearly explains that the session may be being hijacked. Rather than a weak informational type message, the warning should be clear and explicit, and require the user to specifically accept that the connection may be being intercepted. The user should be particularly careful to note any out of character behavior such as suddenly prompting with identity or verification issues

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 »

Zeroshell Router

October 13th, 2012

Routerboard 532aI’ve been using Zeroshell on a Routerboard 532a as my office LAN router for over a year now. It’s one of the best router operating systems that I’ve used and it’s really easy to set up. I’ve configured an OpenVPN connection to a remote office that I work with on a daily basis, and then set routing rules for the VPN’s internal IPs so that my office LAN can connect transparently to the remote LAN. Next, I’ve set up an OpenVPN server so that I and other users can log in remotely to my own office LAN. Routing and firewalling is set up between both VPN connections. Above that, we have the usual local routing, firewalling, DHCP and caching DNS server, inbound port mapping and so on.

Zeroshell runs on a regular Linux kernel, and SSH can be opened for full shell access. It doesn’t do anything that can’t be done manually via the Linux command line, but it’s an excellent and easy to use system that gets it done far quicker. It’s also proven to be completely stable, and allows me to max out the 65mbit DSL without issue.

root@zeroshell root> uptime
18:27:36 up 257 days, 55 min,  1 user,  load average: 0.16, 0.05, 0.01

Highly recommended and only takes as long to set up as writing the image to your CF card. Also compatible with Vmware.

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 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 or 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]