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.
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.
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.
We then wait for airbase-ng’s `at0′ interface to come up, before starting a DHCP server handing IPs out on the 10.0.0.0/16 range whilst at0 itself is set to 10.0.0.1. Clients are set with DNS and router set to 10.0.0.1.
We then create a DNAT entry with iptables to redirect any traffic that comes in on at0 that would have been routed back to ourselves on 10.0.0.1;
iptables -t nat -A PREROUTING -i at0 -j DNAT –to-destination 10.0.0.1
Remembering that we have no default gateway, the biggest issue we have is that whilst we can run fake services on our device, we have no way of performing DNS lookups, and therefore even if we respond to all DNS A requests with ‘10.0.0.1’, we’ll most likely be logging useless credentials.
At this point, I thought it would be a good idea to brush up on my programming skills and relearn PERL. Using the POE framework and sqlite3, we next run a fake DNS server. The DNS server is assigned a range, in this case 199.0.0.0/8 on which to hand out IPs. The first request is assigned 199.0.0.1 and logged in the database, the second request 199.0.0.2, and so on. If we already have a record of that request, we’ll hand out the IP we handed out the last time. Whether the client accepts our DNS or has their own hardcoded, the DNAT will redirect any DNS request to our device. Our DNS table might look something like;
id
ip
host
1
199.0.0.1
apple.com
2
199.0.0.2
www.google.com
3
199.0.0.3
m.google.com
4
199.0.0.4
imap.gmail.com
Now, iDevices and Blackberries attempt to connect to a URL to confirm internet service. If they do not receive the expected response, they assume they are on a wireless hotspot and pull up a login page. We must satisfy the query to pretend to the devices that they have valid internet access.
The next step in the process is where the client tries to connect to a service. I have currently built protocol support for POP3, IMAP, HTTP and their SSL versions, and additional services can be added easily.
Once the client initiates a connection, it is redirected back to us over DNAT. Under Linux, we have the originally requested destination IP available by using the socket option SO_ORIGINAL_DST. Assuming the client attempts to connect to 199.0.0.3 now over IMAP, our IMAP server implements enough of the protocol to log the credentials and keep the client happy, as well as looking up the requested hostname ‘m.google.com’ in the sqlite3 database and presenting it as the banner.
Should SSL be in use, we dynamically create a self signed certificate for ‘m.google.com’ and present it to the client. It will yield the usual SSL warning although having a matching hostname, the non-technical user is more likely to accept. The iPhone [4 at least] had an annoying feature where no matter how many times ‘cancel’ is clicked, it will keep presenting with the same SSL warning until ‘continue’ is clicked or wifi is shut off. This almost guarantees that the user will click continue. In addition, whilst testing, I did not even realise at first that the warning I was presented with on the iPhone was even an SSL certificate warning. I am very surprised that the warning is not worded in stronger terms than it is.
Once we have credentials, these are logged in a separate table and related back to an IP entry which ultimately relates back to the original host the user attempted to connect to. Thus we are able to log host details, username and passwords on a standalone portable device with no network connectivity. Lastly, the device was kitted out with a BlueNEXT GPS dongle, and so GPS coordinates can be logged if they are available for where credentials were sniffed.
It is not legally possible to actively run such a device in public, however based on internally testing the system with my own devices, as well as passively collecting some of the broadcast probes sent over the air in public places, running such a device in public could very easily harvest many hundreds of passwords ranging from home to corporate in only a few minutes at a suitably busy location. Furthermore, as the device has no internet or external connectivity of its own, and the attacker would be entirely untraceable.
In my next posting, I will discuss some of the weaknesses we touched upon and how they can be overcome.
The post Fully Automatic Wireless Hacking Station appeared first on HaCoder.