Sniffing the Network

This article is intended to provide a simple demonstration of how easy it is to sniff/intercept traffic on various types of networks, and serve as a warning to utilize secure methods of communication on a) untrusted networks and b) known networks with the potential for untrusted clients or administrators. The first consideration is the topology of the network we’re connected to. To consider 5 common scenarios: Wired ethernet hub network: Hubs are becoming more and more obsolete as they are changed to switches. Multiple devices can be connected to a hub, and any data received by the hub from one device is broadcast out to all other devices. This means that all devices receive all network traffic. Not only is this an inefficient use of bandwidth, but each device is trusted to accept traffic destined for itself and to ignore traffic destined for another node. To sniff such a network, a node simply needs to switch it’s network interface card to “promiscuous mode”, meaning that it accepts all traffic received. Wired ethernet switched network: Multiple devices can be connected to a switch, however a switch has greater intelligence than a hub. The switch will inspect the traffic sent on each port, and learn the hardware (MAC) address of the client connected to a particular port. Once learned, the switch will inspect any frames it receives on a port, and forward that frame to the known recipient’s port alone. Other devices connected to the switch will not receive traffic that is not destined for them. This offers enhanced bandwidth usage over a hub. Switches rely on ARP packets which are easily forged in order to learn which devices are on which ports. Wireless open networks: Multiple devices can connect to an open wireless network. All data is broadcast across the network in plain text, and any attacker can sniff/intercept traffic being broadcast across the network. An open wireless network may present the user with a form of hotspot login page before granting internet access, however this does not detract from the network itself being open. WEP encrypted wireless network: A WEP encrypted network requires a WEP key to encrypt and decrypt network traffic. WEP has long been an outdated and insecure method of wireless network protection, and cracking a wireless network’s WEP key is fast and requires low skill. WEP is not secure. In addition, all clients connected to the network use the same WEP key to connect. That results in any user on the network with the WEP key being table to view any traffic transmitted to and from other nodes on the network. WPA/WPA2 encrypted network: A WPA/WPA2 encrypted network is significantly more secure than a WEP network. Whilst attacks exist on parts of the protocol, and extensions such as WPS, no known attack is able to recover a complex WPA/WPA2 password within an acceptable period of time. Whilst all clients connect to the network with the same password, the protocol is engineered to create different keystreams between each connected client and the access point. This means that simple sniffing in the traditional sense is not possible on the network. […]

By | December 14th, 2014|Linux, Security Consultant, Wireless|0 Comments

Two paid wifi attacks to bypass hotspot payment

Most hotels around the world offer paid wireless internet services. There are various different ways that these operate on a technical level, however in general terms; Your device connects to the paid network The network router puts your ‘MAC address’ into the unpaid pool Any traffic from your device is blocked aside from DNS traffic which is hijacked by the router and resolves any query to the router’s IP, and web traffic which is also hijacked by the router and redirected to a page presenting a signup and payment page The router will only allow traffic to the internal payment system and perhaps allowed IPs such as the hotel web site servers. Once payment is made, the payment system notifies the router and your MAC address is added into the paid list Enjoy surfing the net Basic WiFi Hotspot Network A basic wifi hotspot will contain a wireless access point allowing wireless devices to connect, and a router that performs, you guessed it, routing, hotspot authentication and so on acting as the ‘gatekeeper’. This router will then be connected to the internet. More complex systems may include more access points to span multiple floors or locations, more routers, separate authentication servers and so on, although the basic principle is the same, and the network layout is largely irrelevant to our attack scenario in any case. To the non technical readers, there are a few terms we are interested in – MAC Addresses & IP Addresses: A MAC address is a hardware address assigned to your network device – the ethernet (network) card has one, the wireless card has one, the wireless device in a mobile phone has one. It’s not the same as an IP address. A MAC address is (or should be) unique to your device but most importantly, unique to the current network segment. In this case, the network segment that we are on extends through the wireless network and up to the top connection on the internet router. The secondary connection between the router and the internet provider is a second segment. Routers break up segments and MAC addresses do not pass through the router. To simplify, in this case, every device connected to the wireless network will have a different MAC. IP addresses are ‘routed’ i.e. passed across the internet and translated, MAC addresses are not. This point is important to know in understanding one of the attacks. Of course as with every rule there are exceptions and for more advanced reading, ‘proxy ARP’ is one such exception however this scenario has specifically been kept basic to illustrate a successful attack. DHCP: When you connected to the wireless network, your device sent out a ‘DHCP request’. Basically – “I’m new to this network, please let me have the details”. The DHCP server then responds providing a private IP address, router, DNS server and so on. As all of your traffic is passed through the network router, the network router can mangle it and modify it in any way that it wishes. DNS: DNS is the service that turns addresses such as ‘www.adampalmer.me/iodigitalsec’ into an IP address such as which are what the IP networks on the internet run on. Other protocols also exist that we don’t need to be concerned with here. DNS actually does a lot more than just turning names into IP addresses but that’s all that’s relevant here. As an unpaid user, when you fire up your browser and visit www.adampalmer.me/iodigitalsec your browser will contact the DNS server (router in this case) and ask for the IP address. The router will respond with it’s own address, perhaps rather than the real address. This means that your browser will then attempt to connect to the web server on – the paid hotspot signup page. Attempting to enter in to your browser directly will bypass the DNS query, but the router will nevertheless hijack the request and redirect it to the payment page – if it didn’t that would be a simple method for bypassing the payment system. […]

By | July 4th, 2013|Security Consultant, Wireless|0 Comments

Fully Automatic Wireless Hacking Station

This article describes a working all-in-one standalone mobile wireless attack station that can perform MITM type attacks on clients automatically and without any internet access or other external connectivity or influence. 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. […]

By | April 26th, 2013|Linux, Perl, Projects, Raspberry Pi, Security Consultant, Wireless|18 Comments

Linux on a Mikrotik 532a , Part 5 Final – OpenWRT and Custom Scripts

Follow on from: http://www.adampalmer.me/iodigitalsec/linux-on-a-mikrotik-532a-part-4-customization-debian-scripts-shaping-firewall-nat-picolcd/ I’ve used OpenWrt previously to this project to build some firmwards for the Linksys Router WRT54 range. OpenWrt is an incredibly powerful and small Linux distro. Although debian is probably better suited to the reasonably powerful hardware, I wanted to give OpenWrt a go anyway. Unless you’re running a MIPS 4Kc processor on your host which I’m guessing you’re not, you’ll either need to cross compile your binaries, or just compile them natively on the device itself. Compiling on the device works fine as long as you have the relevant packages, however if I was going to build a 2.6 kernel, I’d rather do it on an x86 quad core intel host, rather than waiting a week for the device to do it. I also wanted to minimize the writes on the CF card. OpenWrt comes with a nice buildroot environment which you can read about and download from www.openwrt.org using Subversion. Here http://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-310002 is a great HOWTO on getting the build root environment set up on your x86 host. Also, see: http://wiki.mikrotik.com/wiki/RB500_Linux_SDK – this is a very complete HOWTO, which is why I’ve not covered most of the installation process and just detailed customizations. You’ll need to select the RB5xx target for the kernel. Also, run: make kernel_config In your build root top directory, and add USB support (as my one is modded for USB which is not RB5xx default. While you’re there, browse to the networking options and make sure you have everything you want, specifically the schedulers for traffic shaping. […]

Linux on a Mikrotik 532a, Part 4 – Customization, Debian Scripts, Shaping, Firewall, NAT, picoLCD

Follow On From: 05 Oct 08 APNIC Box – Linux on a Mikrotik 532a, Part 3 – Installing Debian, Prebuilt Disk Image Following on from the previous article, I’ve written some scripts which you’ll find in the /root/scripts/ directory of the prebuilt image. I’ve attached and commented them here, as they could also be useful elsewhere. bridge.sh #For setting up a simple bridge […]

APNIC Box – Linux on a Mikrotik 532a, Part 3 – Installing Debian, Prebuilt Disk Image

Follow on from 01 Oct 08 APNIC Box – Linux on a Mikrotik 532a, Part 2 The device runs a 2.4.30 kernel on a debian woody (mipsel) environment. If anyone can contribute anything for 2.6.x and debian etch, that would be great. Installation instructions: […]

APNIC Box – Linux on a Mikrotik 532a, Part 2 – Hardware Modifications

Follow on from 01 Oct 08 APNIC Box – Linux on a Mikrotik 532a, Part 1 Custom Hardware Modifications Here’s a labelled image of the inside of the device. You can also look towards the bottom left of the image for my simple solder modifications. Enlarge the image to see the labels. APNIC Box Image 2 1. External 2.4GHz/5GHz antenna. Same on opposite side. 2. 5V solder point 3. 5V connector for miniPCI USB card 4. 2x 2USB Headers. 1 Header in use providing 2x USB interfaces, one to regular host connector for mass storage or other usb connection. Other port for picoLCD on top 5. 512MB CF card 6. miniPCI USB controller On the underside of the board there is a single miniPCI socket which houses an Atheros 5212 802.11a/b/g miniPCI card. It has two antenna outputs which run under the board and two the two external antennae. I haven’t taken a picture of this but if anyone really wants to see it, I will power down the device, get a picture of it and post it here. […]

APNIC Box – Linux on a Mikrotik 532a, Part 1 – The Device

I put this device together for fun sometime around the start of 2007. The ideas that spawned this was using OpenWRT on a Linksys WRT54G access point. A surprisingly powerful and full linux distro with all kinds of advanced capabilities running on a Linksys wireless router which I’d previously thought to be a reasonably dumb device with computing power more comparable to a calculator than a PC. The project opened my eyes to embedded devices, and I wondered what device base I should start with. To cut a long story short and for reasons that I can’t even remember anymore I came across the Mikrotik Routerboard 532A and decided that I should start with that. Conception APNIC Box Image 1 Here’s a picture of the device from the outside with some labels, view the full image to see them. 1. Status LEDs. Blue at the bottom left shows it’s on, orange at the top right shows that there’s wifi activity. 2. Ethernet (eth0) 3. Standard Serial Console (57600, 8 N 1) 4. Ethernet (eth1) 5. Ethernet (eth2) […]

Wireless Hacking, Problems with WEP, Wireless Security and WPA

Unfortunately today there are still a huge range of wireless OEM equipment being shipped with WEP as standard. WEP has been known as vulnerable for a long time. This HOWTO assumes Linux familiarity, compatible hardware, the ability to read and troubleshoot, and a brain. Hacking your wireless network is not difficult, and here’s a procedure you can use to test: You’ll need: 1. A PC and wireless network. 2. A linux PC/laptop with a wireless networking device Method: 1. Boot your (debian) pc 2. wget http://download.aircrack-ng.org/aircrack-ng-1.0-rc1.tar.gz 3. tar -xzf aircrack-ng-1.0-rc1.tar.gz 4. cd aircrack-ng-1.0-rc1 5. ./configure 6. make 7. make install […]

By | September 22nd, 2008|Hardware, Internetworking & Routing, Linux, Technology, Wireless|0 Comments