• Choose a category
• All
• Classic-Fiction

By Root 446 0

of them are currently running open networks. If there are many strong and free APs in the area, the attack will be less likely to work, but if the only APs with strong signal are encrypted, users will be much more likely to connect to the attacker's open AP with excellent signal strength. Therefore, areas such as coffee shops and hotels would be particularly good candidates for this sort of attack as the users in the building will quickly jump at the chance for free Wi-Fi when presented with the paid access model the business is likely running.

Once a location has been selected, Wireless Tether needs to be configured to appear as an innocent public AP. The SSID can be changed from within Wireless Tether by pressing the Menu key, selecting "Setup", then scrolling down to "Change SSID". Wireless Tether doesn't allow spaces in SSID names, and also has an unusually short character limit, but in practice you can still get the point across. Changing the SSID to something like "free_wifi" should get the desired results, but for added effect it could be more contextually relevant to the target location, such as "hilton_wifi". With the SSID set as something sufficiently approachable, start Wireless Tether by pressing the large icon in the center of the screen (Wireless Tether must be running to complete the next steps).

With Wireless Tether up and running, the next step would be to get Shark set up and begin logging packets. Normally, tcpdump will listen on the default interface, which in the case of a phone would be the 3G radio. Capturing packets from 3G is just going to get us a big log file of gibberish, so Shark needs to be set up so that it runs tcpdump against the phone's Wi-Fi interface where the victims will be connecting.

To do that, you need to figure out what the Wi-Fi interface is actually called. Just like on desktop Linux, some Wi-Fi drivers rename the interface instead of leaving it as the standard wlan0, so you need to do a little digging to figure out what your particular phone is running. The easiest way to do this is by using a terminal emulator (such as ConnectBot) and running the command "netcfg", which will list the device's networking interfaces like so:

# netcfg

lo UP 127.0.0.1 255.0.0.0 0x00000049

dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082

usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002

ppp0 UP 75.206.123.22 255.255.255.255 0x000010d1

tiwlan0 UP 192.168.2.254 255.255.255.0 0x00001043 Here we can see the two important interfaces, ppp0, which is the 3G Internet connection, and the tiwlan0 interface, which is running Wireless Tether. You can tell them apart easily as one is running a public IP (ppp0), and the other is using a private IP (tiwlan0). The Wi-Fi interface in this case is called tiwlan because the phone in question is using a Texas Instruments chipset. Different devices will be running different hardware, so don't be surprised if you see something completely different.

With the Wi-Fi interface name in hand, you can start up Shark and add in the proper tcpdump parameters. To specify a different interface from the default, you use the "-i" option, so add "-i tiwlan0" to the parameters already listed in Shark (substituting your particular Wi-Fi device name, if necessary). Then press "Start", and make sure it begins logging packets. You should see a line at the bottom that says "Got xx", where "xx" is the numbers of packets currently captured.

Now, all that is left to do is wait. With patience and a little luck, a client device should connect to the phone and attempt to get online. Wireless Tether can be set up with various notifications when new devices connect, including a vibrate option that would let the attacker know a client has connected without making a sound or even having to glance at the phone. Once a client device connects, they will be routed to the Internet just as they expected. Their experience will be identical to that of a regular public Wi-Fi connection, and they would have no reason to suspect anything is wrong.

Obviously, there are some constraints due to the device's relatively