[转载]Case of a wireless hack
信息来源：[url]http://neworder.box.sk/newsread.php?newsid=13688[/url]ekskavaator writes:
This is a short story about using a couple of computers, some interesting tools, an operating system and a bit of thinking to solve a not-entirely-artificial problem of getting wireless internet access where measureas are in place to stop it. Both the technical side as well as some of the reasoning behind the actions are explained.
1. Intro
2. First attempt - MAC spoofing
3. Planning the second attempt - ICMP tunneling
4. A little bit of coding
5. Setting up the tunnels
6. Conclusion
1. Intro
Well, I had just got my first laptop and really wanted to try and do something cool with it (even tried to do some work but grew tired of it). Wardriving was exciting at first, but it became a bit dull when I realised that WEP enabled networks are out of my reach (as they didn't have any traffic to analyze - almost dead home networks) and unencrypted ones aren't a challenge at all. Luckily, the wireless network on my university's campus proved to be a bit more interesting.
They do provide free wireless internet, but require you to register your MAC address to your name before allowing access - unregisterd users get redirected to a web page explaining the situation. Registering would have involved 2 minutes with an administrator, but I thought "maybe there is a way to get access without 'all the hassle'". Surely enough, there was.
2. First attempt - MAC spoofing
As the dance was all around MAC addresses, my first idea was to find a MAC address that had already been registered and spoof it. Sure, it's easy enough to say but it still took quite a bit of effort, as it was all so new.
First thing I did was run kismet ('kismet -c orinoco,eth1,wifi') and sniff the network. Kismet dumps all the sniffed packets into a file ('/var/log/kismet/*.dump' in my case) that can be later opened by ethereal. It was possible to look through the packets and write suitable MAC addresses down, which I did.
The commands to change the MAC address of a NIC:
ifconfig eth1 down
killall dhclient
ifconfig hw ether 00:11:22:33:44:55
ifconfig eth1 up
dhclient eth1
All the commands aren't neccessary, but they are useful when trying several MAC addresses in a row - which in turn was neccessary because the addresses I tried didn't work straight away. I had strange lockups (that ended when I pulled the card out), wireless going down and not coming up again and many other interesting and challenging annoyances to deal with. They were propably because of faulty hardware/firmware/driver and possibly because there already was a NIC with the same MAC address on the network.
Not many stations were very active, and using kismet/ethereal was inefficient (lots of cruft to look through), so I tried another approach. As the MAC-based filtering was done at a pretty high level (they wanted to display the explanitory web page to unregistered MACs) I could associate with the network and even get an IP address without a problem. Naturally, thinking about finding active hosts, nmap came to mind. So I ran a ping scan on the IP range active stations seemed to be in:
marktwain:~# nmap -sP 10.0.0.1/22
Starting nmap 3.81 ( [url]http://www.insecure.org/nmap/[/url] ) at 2005-05-23 12:54 EEST
Host 10.1.0.14 appears to be up.
MAC Address: 00:0E:35:97:8C:A7 (Intel)
Host 10.1.0.95 appears to be up.
MAC Address: 00:02:2D:4D:1C:43 (Agere Systems)
Host 10.1.0.109 appears to be up.
MAC Address: 00:0D:54:A0:81:39 (3Com Europe)
... snip ...
Host 10.1.2.92 appears to be up.
MAC Address: 00:02:2D:4D:1C:CE (Agere Systems)
Host 10.1.2.187 appears to be up.
MAC Address: 00:02:2D:4D:1C:43 (Agere Systems)
Nmap finished: 1024 IP addresses (20 hosts up) scanned in 53.980 seconds
A lot of MACs. The best bit is that it also populated my arp tables with (what I presume is) the MAC addresses of all the stations that had visited the network in recent days. The table had 245 distinct MAC addresses. I don't know if it's normal behaviour for an AP, but it would make sense if it had something to do with the MAC-blocking scheme they used (propably bridged the wireless and wired networks somehow?).
Whatever the reason, I now had enough MAC addresses from stations thad had visited the network but were most likely long gone. A couple of tries at the spoofing thing and I was already surfing to neworder.box.sk and revealing my cookie to anyone who cared to listen. I walked home at a speedy pace and changed the password.
3. Planning the second attempt - ICMP tunneling
I had accomplished what I had set out to do, but there was still some marrow in the bone of this network (figuratively speaking). What had I done, if there hadn't been any stations on the network with me? If nmap'ing hadn't revealed all those MACs? If I had been born a mighty dragon? Well, whatever the reasons, I wanted to try yet another way of getting access.
It hasn't been mentioned yet, but aside from allowing association and DHCP the network also allowed ICMP messages to pass through. Pinging any internet site worked fine (can't really understand why they haven't blocked it - unless they forgot) and the pings even showed up on a sniffer I ran on my server (so the responses weren't just faked by some box at the university).
My the plan was to try to create an ICMP tunnel between my laptop at the university and a server at home. And then pass all the connections through it.
I had looked for a ICMP tunneling applications on the net before but none had really worked as I would have liked (namely, I wanted it to be transparent - so that I could fire up my favourite browser or any other program and it would "just work
页:
[1]