Phishing WiFi hotspots with captive portals
09 February 2016
Are you using a paid Wifi hotspot service, which allows you to have Internet on various spots around the country? This convenience could come at a cost! If you are not careful enough, you might fall victim to - an easy to implement - phishing attack, therefore revealing your username and password to perpetrators. What is worse, is that the essential components cost around 30$ and can be hidden in one’s pocket! Want to learn how this can be done so you can tackle such attacks? Read on….
DISCLAIMER: This article does not intend to facilitate phishing attacks or any other kind of illegal activities. The misuse of information contained in this article CAN bring criminal charges against you. The author will not be held responsible if criminal charges are brought against any persons utilizing any information related to this article, to break the law. DO NOT try to reproduce the scenario demonstrated in this article, with networks and devices you do not own, unless otherwise expressly permitted. The author has exclusively run this experiment on private premises and equipment. This paradigm, inspired by academic interest on IT security, merely points out the risks to the confidentiality of data, submitted via WiFi access points that require their users to log in via a captive portal. It should act as a cause of concern both for the users, but mostly for the companies that have deployed such services and it’s primarily their duty to protect their customers’ privacy and security. If such an attack is commenced successfully, then the perpetrator can impersonate the legitimate user and perform malicious activities under the unsuspected victim’s identity. Furthermore by disclosing the username and the password of this service, to a malicious individual, the credentials for others (e.g. online payment system, email etc) can be derived, especially if - as it is sadly a common practice - the same or similar are used. The tutorial you will find below, is only about setting up a Physical Web Space, using an Open WRT device and specifically the Onion Omega. This attack, is a potential use case of the Physical Web Space, which could be as easily conducted, utilizing different technology. Additionally, the script that actually logs down the victim’s credentials is not published, however it is practically very easy to compile. To conclude, the combination of low cost, pocket sized equipment and software that does not require high technical knowledge to set up, can annotate this scenario as a valid threat that should be countered by appropriate security measures and increased user awareness. It is imperative that such risks are exposed publicly and coped with. Lack of security is not as dangerous as a false sense of security.
Despite not posting much in this blog lately, I have been particularly busy on various projects, mainly the SmartCar educational platform, more about which I promise to report on soon. One of them, was My Physical Web Space, that was published and featured on Instructables. The Physical Web Space, is a website that literally follows you around wherever you go, is hosted on a micro server that can fit in your pocket and the visitors can get access to it by using its WiFi hotspot. Moreover, the WiFi hotspot is enhanced by a captive portal, which redirects all requests to a specific (local) address.
A typical scenario of the Physical Web Space, begins the user detecting an open WiFi network on their smartphone, connecting to it (because we all love free Internet, don’t we?), receiving a notification that sign in is required and then to be redirected to a local website hosted on the micro server. Additionally, all other (non https) requests are redirected to the local server.
The Physical Web Space original prototype, includes a Raspberry Pi Zero running lighttpd and just 3 AAA batteries as its power source which. Without any particular power consumption optimizations on the Zero, this setup provides enough juice for a couple of hours. Here, we will use it to demonstrate how easy it is to perform phishing attacks against users trying to connect to WiFi hotspots, that require some form of membership, paid or otherwise and a log in via a web page, in order to gain access to the Internet.
The rationale is fairly straight forward: The micro server will create a hotspot around it, with the same SSID as the network we want to target. At this point, it does not matter if the legitimate network actually exists in the area, but if it does, its access point(s) might have a stronger signal than your portable server and most clients will connect to it instead. On the server, a captive portal is configured, that redirects all requests to a certain webpage. That webpage looks identical to the legitimate one, with the only difference that it does not actually connect the user to the Internet, but instead logs down the supplied username and password! After the user has submitted their sensitive data, they can be redirected to the main page again, thus lead to believe that there is just something wrong with this network.
And that was it! Scary right? The Physical Web Space will be used as the proof of concept platform in order to demonstrate the validity and high risk of this attack.
In this tutorial, I will not use a Raspberry Pi Zero for the Physical Web Space but an Onion Omega. The Omega is a single board computer, running Open WRT, which is a lightweight Linux based operating system, commonly found in network oriented embedded devices, such as gateways and routers. I have always been fascinated by this operating system due to its limited requirements on hardware and high usability when it comes to networks. If you want to read more about setting up DD-WRT which is a, similar to Open-WRT, network-focused operating system, check out this ultimate DD-WRT router guide. The Onion Omega, is a tiny computer, that comes with (two) WiFi interfaces already up and running and will cost you from 20$ to 30$. Which is approximately the same price of the Raspberry Pi Zero plus the essentials (microSD card, WiFi adapter, cables etc), especially if you buy them from Europe. Provided that you are lucky enough to grab one while it’s in stock. :-)
The procedure is fairly similar between the two devices, or any Linux system. If you have a Raspberry Pi and want to recreate this, follow the original tutorial and then jump to the steps . Since we will be changing some configuration files (not a lot), it is advised to create backups. You can easily create a backups by typing: cp /path/to/file /path/to/file.old
Materials needed for the Physical Web Space with an Onion Omega:
1. Onion Omega + dock. 2. USB power-bank or batteries + regulator.
Steps:
1. Set up the connection to the Onion Omega, according to the Get started guide and connect it to your local WiFi. The Omega will need Internet access in order to update its firmware and additional software. 2. Upgrade the firmware (this will reboot the system and delete all changes made outside of /etc folder): oupgrade -f 3. Update opkg: opkg update 4. Install the lighttpd server, php that will allow us to log down the username and the password submitted by the user and nano which will be our text editor: opkg install lighttpd php5 php5-cgi lighttpd-mod-cgi nano 5. Set up php in lighttpd server. Edit the 30-cgi.conf file: nano /etc/lighttpd/conf.d/30-cgi.conf In the cgi.assign field, add the following argument: “.php” => “/usr/bin/php-cgi”
Don’t forget the comma if necessary. Ctrl + o to save and Ctrl + x to exit. 6. Create a new root folder for your website, inside /etc/, so it is not deleted every time you update the firmware: mkdir /etc/www 7. Edit the lighttpd configuration file and add the new server root path, as well as a rule to redirect all 404’d requests to the main page: nano /etc/lighttpd/lighttpd.conf Change the server.document-root field from /www to /etc/www Add the following line: server.error-handler-404 = “/index.php” which will allow you to redirect all faulty requests back to index.php (or whatever your index page is called)
Save and exit. 8. Configure the website root folder in the php.ini file: nano /etc/php.ini Find the doc_root field and change it to /etc/www. An easy way to do this is by pressing ctrl+w then type doc_root and press enter.
After you are done, save and exit. 9. Redirect all traffic to your localhost. Note that you will not be able to visit the Omega’s web interface any more: nano /etc/dnsmasq.conf Add the following line in the end, which is Omega’s default localhost address. You can specify a different one in /etc/config/network: address=/#/192.168.3.1
Save and exit. 10. Let’s change the hotspot’s name. The default one should be something like Omega-XXXX where the X’s are usually digits: nano /etc/config/wireless
Change the Omega’s SSID to the SSID of the network you want to impersonate.
Now it’s time to recreate the website we want to attack. You can use the SingleFile chrome plugin to download everything from a web page. Then find where the submission form for the username and the password by using a simple PHP script you can save the user’s credentials in a local file in plain text. I will not publish this script (it’s fairly easy anyway), so to not be considered that I am facilitating such attacks. Instead, this article is about raising a cause of concern when it comes to connecting to such networks.
11. Copy the bogus page(s), to your Omega. You can do this many ways, depending on your operating system. If you are on a Unix system, you can write: scp /path/on/your/laptop/to/index.php root@192.168.x.x:/etc/www where index.php is the captive portal’s landing page and 192.168.x.x the local IP address. Don’t forget you can also connect to the Omega using a USB cable, which I find particularly useful. 12. Go back to lighttpd.conf and check what is the username and group name the lighttpd server has. The defaults one for me were http and www-data respectively: nano /etc/lighttpd/lighttpd.conf
13. Give lighttpd the appropriate permissions to the www folder. Navigate to the website’s root folder: cd /etc/www/ Then change the ownership of the files in the folder: chown http:www-data * Finally, assign the appropriate permissions, e.g. 644: chmod 644 *
EDIT on 14/2/2016 14. I noticed that with the above setup, if the Onion Omega does not manage to connect to a local network, then the WiFi hotspot will not be created. In other words, it will not work when you are at a random place outside. I will look more into the specifics, but a quick fix is to go to the /etc/config/wireless file and comment out the local network details. First: nano /etc/config/wireless Then comment out by adding “#” the relevant network details, where your Onion Omega used to connect to, in order to get access to the internet.
And that was it! Now you have a captive portal on the Onion Omega, or a Physical Web Space as I would like to call it, that has the same SSID as the network you want to attack, will lead the users to the same page as the legitimate hotspot does and will log down the credentials of the ones that were not careful enough to notice that there is something wrong going on.
Easy huh? Well, that is why if you are using such networks you need to pay extra attention. If you want to avoid falling victim to such an attack, the most obvious give away is the non encrypted (https) connection to the landing page where you need to supply your credentials. Generally, you should NEVER submit critical information in plain text. Furthermore, depending on how well the legitimate website is replicated, there could be other smaller details that should make you suspicious. On the other hand, the companies providing such services, should deploy the appropriate measures in order to hinder such attacks. But more about those, on another article in the future. :-)
