Monthly Archives: July 2013


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 ‘’ 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 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

Security Through Obscurity – Fail

I was pen testing a web application last week, when I fired up ‘wfuzz’ using a custom large dictionary for file and directory brute forcing. To the non technical readers, this means that whilst there might be links on the site to say /login, /register, /contact-us and so on, I’m looking for files and directories on the web server (site) that don’t have links to them. Perhaps hidden functionality or testing and debugging files that the developers left behind and so on. I often find ‘phpinfo.php’ or ‘test.php’ type files and I once even remember finding a ‘’ which was a zip file containing PSD files for the entire site layout. Another common issue I find, is that while ‘index.php’ will be interpreted on the server side and the resulting data sent to the client as expected, ‘index.php.old’ and ‘index.bak’ will be sent directly to the client. This is down to the server being configured that .php files are interpreted by php, whilst unknown extensions such as .old and .bak are assumed to be plain text assets. The problem with this, is that these files will contain all kinds of goodies such as variable names, paths, business information and possibly database or other credentials. Whilst under development, pages will often undergo editing and revisions, and developers often forget to remove old versions, test and backup files. This inadvertently leaves them available to the public through the web server with just a little poking around. You did WHAT?! Last week was something entirely different when I found ‘/nickreport’. This directory contained scripts allowing me to download a full report of customer signups and sales stats for the past 14 days for, you guessed it, Nick the sales director. The authentication prompt was defeated with credentials of ‘nick/nick’. When I confronted the application developer about this complete fail, his response was that the password authentication wasn’t for security but was just to prevent Google from crawling the site, and that there was no way that anyone would guess the URL anyway. He didn’t seem to understand the link between that statement and the fact that a) I HAD ‘guessed’ it and b) his password authentication was an attempt to prevent Google from indexing it. This alone implies that he was aware that search engines had or may in future have ‘guessed’ it. […]

By | July 3rd, 2013|Security Consultant|0 Comments