I’ve just complete work on a project I’ve had in mind for a while now, a warwalking case. As you can probably guess it involves fitting a war-drive rig (car excluded) inside a carryable case.
As I had one going spare I started off with a fairly standard CD carry case:
Bit of fun with a hacksaw and foam later and theres an alcove for my external Alfa wireless card:
The grooves cut into the central partition create secure compartment for my Acer AA1, both in transit and whilst running, (not sure about cooling ventilation yet, still a work in progress):
Finally, a groove in the edge of the case allows for external access for the omni antenna and GPS reciever. Complete kit below:
Now it’s complete I’m not sure whether this kit will actually get used though. It looks a bit suspicious and is now commonly referred to as ‘the bomb’. Not sure I’m looking forward to explaining to an armed response unit that I’ve got nothing more dangerous in the case than an up to date Metasploit install.
This post should be short and sweet as Dale beat me to the punch with an excellent write up of wardriving with BT4. Thanks to some back and forth advice, Dale’s hardware setup is also nearly identical to mine so I wont repeat anything he’s already published. But his post did push me to stop abandoning my wireless kit and update my tools.
The primary change is that I’m now running BT4, rather than BT3; still from a bootable USB drive created via Unetbootin. This provides easy access to the vastly updated Kismet Newcore, Mike Kershaw has done some wonderful work with this release. I’ve found Newcore to be vastly simpler to run than previous Kismet versions, primarily as you can now add additional source interfaces to the setup from the console client itself, rather than needing to modify the config files with some archaic black magic.
Also included within BT4’s toolset is Jabra’s excellent giskismet utility, this provides the same functionality (and more) as my previous kismet2gmapstatic attempts. Since I started development on my home brew tools I’ve had several people point me toward giskismet, wish they’d done so beforehand as it would have saved me some (now defunct) development time. I fully intend to go into more depth with giskismet’s capabilities in a seperate post once I’ve fully got to grips with it as my initial opinion is that this tool is great, so watch this space.
I’ve got the wireless bug again, so if you see a car with plenty of USB cables going through the passenger window be sure to say hi!
I’ve spent the day adding some additional functionality to my GPS mapping proof of concept (original here).
The second release, kismet2gmapstatic-0_2.py, changes the scripts output to wrap the Google maps API call in a self contained HTML page, and contains multiple map images to mitigate the URL length limit.
The third release, kismet2gmapstatic-0_3.py, builds on the HTML framework and includes additional information on each mapped access point: SSID, channel and available encryption options.This will likely be the final release of kismet2gmapstatic in this form, the code has grown organically without any real planning and as a result is a hideous mess, but as a PoC I feel it has served it’s purpose. I still have several ideas and additional functionality that I would like to implement, so watch this space for similar tools in the future.
Unsurprisingly given some of my previous posts, the initial use of the GPS device is to increase the power and data gathering ability of my war-driving rig for wireless security assessments. Therefore I was a little disappointed when I struggled to got the device working out of the box with gpsd, which is pretty much the de-fact0 standard in gps software.
After much hair-pulling, command-typing and Google-searching I found a series of articles and forum posts stating that the BU-353 works fine with gpsd-2.37 (sorry, can’t find links, but thanks to all those who put the information out there). A quick download and compile later and everything was good.
I don’t have prior experience with GPS devices for comparison, but I’ve got no regrets with the purchase. The accuracy seems very impressive, and the data logging ability when coupled with wireless sensors is equally so.
I’m still following my recent interest in wireless networks and devices. In the past month I gained a USB gps reciever (which I forgot to write about, may have a short review shortly). After adding gps capability to my wardrive setup I proceed to scan the local area, then hit a brick wall. There appears (could be my google-fu is failing me) a lack of available tools to meaningfully use the captured data.
After a lot of digging a stumbled upon this script, designed to parse the output from Kismet and generate a .kml file to import into Google Earth. Unfortunately, I’ve been unable to get this to work as Google Earth complains when opening the file. Could be a version issue so your mileage may vary, if anyone does get it working please let me know.
The PerryGeo code did however provide an excellent foundation to utilise the Kismet log file and generate different output. To this end I have released a basic proof of concept script that generates a static map via the Google Maps API. If you want to do anything similar, or want to extend or modify my image code I found the Google documentation to be invaluable.
To the tool itself, starting a disclaimer:
This tool should not be used for illegal or malicious purposes. It was created to visualise network locations and implemented encryption technologies, in an effort to enhance previous analysis of wireless network statistics.
For each discovered access point, the script places a marker on the map, colour coded to level of encryption: Open access points are green, WEP encrypted access points are yellow, whilst WPA encrypted APs are red.
The Google maps API appears to have a limit to the length of URL that it is able to support, as a result the script limits the plotted APs to the first 50 in a given Kismet xml log file. This should be sufficient for site surveys, but is less useful for mapping the results from a wardrive trip. I haven’t manage to locate any firm documentation on this limit, if anyone is able to shed any light or knows a workaround I’d appreciate a heads up.
Below is an example of the tools output (actually, it just outputs the URL, which in turn requests google create the image). The image is created from a subset of data collected during a drive around the Angel of the North.
This is still very early days for the tool (started coding 24hours ago) so any feedback, issues or feature requests would be appreciated. Download available here: kismet2gmapstatic-0_1b.py
‘WEP is insecure and breakable’ – No surprise here, everyone knows this is the case. But there can be a large difference between knowing something is theoretically possible and seeing the security provisions fall over merely by being looked at. Recent InfoSanity research has shown WEP is still found on 30% of real-world access points. This means that WEP security is still a valuable skill for anyone working within information security.
One of the best sources for wireless security information is the Aircrack Project (site currently unavailable, Google cache can be of assistance for the impatient). The tutorial section of the site contains many great walkthroughs and guides to all aspects of wireless security I’m not going to attempt create an all encompassing guide to WEP security, but merely to provide a real-world example of compromising WEP.
First phase of any wireless compromise is to locate and identify the target network, this could be achieved with any number of tools, personally I activate airodump-ng from the aircrack suite with minimal parameters (bt ~ # airodump-ng wlan0). From the target network collect the station MAC address (BSSID), network name (ESSID) and operating channel.
Whilst not a necessity, testing the ability of your equipment to inject packets into the target network can prevent wasting time and resources with an unsuccessful compromise attempt. The ability to inject packets will have a large impact on the ability to compromise a WEP key and the time required to make the compromise. Again the Aircrack suite has good tools for the job, this time in the form of aireplay. In my case the required command was:
bt ~ # aireplay-ng –test -b 00:0F:B5:DC:DE:B7 -e mist wlan0
where -b and -e parameters are the targets BSSID and ESSID respectively. The output will show if packet injection is possible, and the reliability of that injection. The Aircrack documentation states that injection rate should be at or near to 100%. Whilst this is beneficial, I have successfully completed an engagement with injection as low as 15%.
Next step is set up a packet sniffer, airodump does the job nicely. Adding some additional parameters ( -c # ) to fix the capture to the targets operating channel will increase success rate and reduce capture times as your card doesn’t lose packets whilst channel hopping across the wireless spectrum. Again, in my case I used:
bt ~ # airodump-ng -c 13 –bssid 00:0F:B5:DC:DE:B7 -w WEP-example wlan0
-w filename, specifies the file to write captured traffic to.
Before injection packets, the injecting interface needs to associate with the target base station. Aireplay-ng to the rescue again:
bt ~ # aireplay-ng –fakeauth 0 -a 00:0F:B5:DC:DE:B7 wlan0
Aireplay-ng also provides a function for implementing an ARP injection attack:
bt ~ # aireplay-ng –arpreplay -b 00:0F:B5:DC:DE:B7 wlan0
This is where the packet injection ratio determined by the –test function comes into play, the Alfa card with RealTek 8187 chip in use during this engagement generally injects packets at a rate of 500 packets per second, in this scenario the test function report 92% success, airodump-ng reported capturing approx 490 packets per second.
Final stage is to actually crack the collected packets, Aircrack documentation suggests collecting 250,000 IV packets to ensure compromise. In this case I collected 100,000 packets and the key was cracked in under a second, in previous engagements I have successfully gained the encryption key with as few as 10,000 collected packets:
bt ~ # aircrack-ng WEP-example-01.cap
In this case overall engagement required less than 15 minutes from finding network point to obtaining network key. From here it’s trivial to get a machine connected to the wireless network, in many cases this provides direct access to the soft and fluffy internal network, and from there? World (target network) is your oyster…..
As promised when the postman delivered the Alfa equipment, I’ve done some initial analysis of my first wireless capture. The data being analysed was collected during the evening commute back home, a trip that includes urban, sub-urban and rural areas so should be good representative sample group.
The previous wireless post has already touched on the security aspect of the found access points. The chart below shows the breakdown between the the various security implementations. The WPA+ category includes WPA, WPA2 and WPA2WPA columns (as categorised by airodump-ng).
Due to the known insecurities within WEP, almost half of the encountered access points do not have any reliable security in place to protect the attached network and users of their networks.
Most, potentially all wireless access points have the ability to be configured in a secure manner. However, a large percentage home and small office users are not aware of the security implications of wireless equipment or other computer technology. As a result the default factory settings that a wireless device is shipped with often provides the baseline security configuration. The below diagram shows that over 50% of the encountered access points were running in a default state (either provider or manufacturer settings) [n.b. assumption is based solely on essid]
The issue is shown by the split of the BT Home Hub devices, BT are one of the major telecommunications providers within the UK. The initial Home Hub (with default ESSID of BTHomeHub-####) are, in this data set, exclusively protected by WEP. In contrast the majority of newer versions of the same device (ESSID: BTHomeHub2-####) operate with the WPA/WPA2 protocols. Another large UK telecoms player, SKY appears to take security of their provided devices seriously all encountered access points configured with SKY’s default ESSID (SKY#####) almost exclusively employ WPA. The chart below shows the provider breakdown of the encountered access points (obviously we are unable to determine the provider of access points with a custom ESSID), with the dominance of BT and Sky in this area the default configuration of their devices could be crucial for a large number of home users.
Whilst some default configurations are insecure, some modified configurations may inadvertently provide additional information to potential attackers. One advantage behind default configurations is that it can be difficult to determine the location or physical connections of any given access point, however the ESSID can provide a good probability of determining the physical connections. Numerous access points within the data have ESSIDs set to an address or individuals name, this is potentially unavoidable for businesses. Whilst security through obscurity can never replace solid security, some obscurity and misdirection can reduce risk and volume of compromise attempts. As a prime example, this data set includes an access point related (assuming ESSID is relevant) of a local branch of a national bank, more worryingly the access point appears to be running WEP.
A large volume of modified ESSIDs are given ‘humorous’ values or references to pop-culture. Some network names may be references/retorts from the network owners in response finding unauthorised users on the network, Dont-steal-our-network and we-know-who-u-are-thief. Both these networks run WPA2, potentially learning the security message the hard way.
The last network name that caught attention may be an attempt at offensive security, the ESSID reboot may potentially be an attempt to trip up malicious users parsing available networks through poorly considered shell script.
Within the dataset analysed the findings show that wireless infrastructure is becoming widespread. Further to this, the volume of default and insecure configurations may indicate that the usage and security implications of wireless connectivity may not be well understood within the general population. The growing trend of wireless enabled devices to be shipped with secure default configurations is a positive move within this field.