We’ve all seen Simple Nomad’s presentation from Shmoocon 2006, [http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt Hacking The Friendly Skies]. And we all took notice secured our environments from this threat, right? WRONG! While traveling on a short flight recently (just over an hour) Bob wrote in and told us about an experience that he had while doing some hacking on the plane (“Hackers On The Plane” would be a cool sequal to the cinematic briliance that is “Snakes On The Plane”).
It all started when Bob got bored on the plane. Bad things tend to happen when Bob get bored, so he decided to whip out his MacBook Pro and see what he could find and hack into in under and hour using the tools already installed on his laptop. Certainly this will be more interesting that talking to the person next to him or reading the airlines very own magazine. The first thing that Bob noticed was an ad-hoc wireless network called “Free Public Wifi” (Screenshot). “There must be something interesting there”, thought Bob with an evil grin on his face. Associating to it yielded him an IP address on the 169.254.0.0/16 subnet, the range that you get when you can’t pull a DHCP address. “Well, if there is another host on this subnet, it may take some time to scan and find it” Bob thought. But wait, why don’t we just fire up a sniffer and see what I can find. Low and behold a couple if minutes later:
4v1lhax0r:~ root# tcpdump -i en1 -nn -X -s0 host 169.254.35.218 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes 10:54:21.339837 IP 169.254.80.136.53349 > 169.254.35.218.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
Looks like the machine told me where it was all by itself. Sweet! Lets start with some light scanning with “nbtscan” to find out more about the NetBIOS configuration:
4v1lhax0r:~ root# nbtscan 169.254.35.218 Doing NBT name scan for addresses from 169.254.35.218 IP address NetBIOS Name Server User MAC address ------------------------------------------------------------------------------ 169.254.35.218 CAMP9317 unknown unknown 00-19-e3-bd-15-fd
(NOTE: Names and MAC addresses were changed to protect the innocent, or not so innicent as teh case may be)
Awesome, now we know its NetBIOS name, although Bob was hoping to get more information. We can assume that this is most likely a Windows host (What are the chances that someone on the plain is on an ad-hoc wireless network with a Linux laptop running Samba querying the network with SMB packets?). Now, lets try our trusty friend “Nmap”:
Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-28 10:39 EDT Interesting ports on 169.254.35.218: Not shown: 65530 closed ports PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 6129/tcp open unknown 32981/tcp open unknown MAC Address: 00:19:D2:AF:04:DC (Unknown) No exact OS matches for host (If you know what OS is running on it, see
The standard TCP ports open for NetBIOS and CIFS, and some other interesting ports on 6129 and 32981. Hrm, lets do a services scan just on those two ports because they look interesting:
4v1lhax0r:~ root# nmap -T4 -p6129,32981 -sV 169.254.35.218 Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-28 10:41 EDT Interesting ports on 169.254.35.218: PORT STATE SERVICE VERSION 6129/tcp open damewaremr DameWare Mini Remote Control 32981/tcp open unknown MAC Address: 00:19:D2:AF:04:DC (Unknown) Service Info: OS: Windows
Interesting, either someone has already 0wned this machine, or its some weird service that is throwing a false positive on Nmap’s service fingerprinting. Too bad we didn’t have a copy of DameWare installed on our Parallels instance of Windows. Instead, Bob used the remaining time to throw every available exploit for Windows SMB at the target in both framework versions 3.0 and 2.7. In between exploits, attempts were made to connect to smb://169.254.35.218/c$ as administrator using various common passwords and then….”This is your captain speaking, please return all seat backs to their full and upright position, and lock all tray tables…..” Blah, blah, oh well, more hacking to be done for the next flight.
Recommendations
There are many lessons to learn from this fictitious story:
1) Disable your wireless adapter when you are not using it. Not only does this improve battery life, it keeps the “Bobs” of the world away when you are traveling.
2) Enable the built-in firewall in your operating system. By simply disallowing all connections initiated from the outside, all of the above scanning and attacks could have been thwarted immediately.
UPDATE: While this recommendation is good for general wireless network usage, I am told that ad-hoc networks bypass the local windows firewall. Anyone know of any good windows client firewalls that will block connections via ad-hoc networks? Add in here that you should configure you wireless adapter to never connect to ad-hoc networks, nor create them.
3) Scan your system regularly. Systems should be scanned at least on a weekly basis for open ports. This can be easily scripted with Nmap, or even done with Nessus. If your client or server machines have dropped shields and show they now have DameWare installed (and you don’t use DameWare) you want to know about it for sure! I Nessus scan my servers weekly and review the reports to be certain that my firewalls are working and configured properly, that there are no new vulnerabilities on my servers, and that I don’t see any new listening programs. The same can be done for clients…
4) Disable the administrative shares. I know, this breaks all kinds of stuff. At least if you are not going to disable them, put in a local account and password policy so that the LOCAL administrator account gets locked when you try different passwords. Also, do your clients really need to be sharing out files with NetBIOS locally? Make certain you have a good network storage facility to curb users from having to share files between workstations, and more importantly share them with the hackers on the plane.
