{"id":1042,"date":"2020-06-09T15:33:45","date_gmt":"2020-06-09T15:33:45","guid":{"rendered":"http:\/\/naich.net\/wordpress\/?p=1042"},"modified":"2021-02-18T19:59:17","modified_gmt":"2021-02-18T19:59:17","slug":"abusing-public-wifi-access-point-protocols-for-fun-and-beer-measurement-raspberry-pi","status":"publish","type":"post","link":"https:\/\/naich.net\/wordpress\/index.php\/abusing-public-wifi-access-point-protocols-for-fun-and-beer-measurement-raspberry-pi\/","title":{"rendered":"Abusing Public WiFi Access Point Protocols for Fun and Beer Measurement (Raspberry Pi)"},"content":{"rendered":"\n
\"\"<\/figure><\/div>\n\n\n\n

This is a little sub-project of what I’ve been working on recently – a hideously over-engineered Raspberry Pi-based system to measure the amount of beer left in the kegs in my keezer<\/a>.<\/em><\/p>\n\n\n\n

Normally I would simply set up a web server on the Pi and have it on the home network, so I could see the levels remotely. The problem is that the routers are all inside the house and the Pi is in the garage, invisible to them all thanks to the 2 external walls between them. I needed some way to read out the beer levels on my phone – after all, walking up to something and looking at the level gauge is so last millennium.<\/p>\n\n\n\n

So – Bluetooth or some sort of ad-hoc Wifi thing? I like to re-use stuff I’ve got lying around in drawers, so the solution seemed to be an old WiFi dongle that was gathering dust. And Bluetooth is awful. Setting up a Pi as an access point is fairly well covered on the internets, but this is a bit different in that we don’t want to forward traffic onto our network like an access point – not that it could connect anyway, being out of range. I also didn’t want to install a web server on the Pi. It’s only a Pi 1 model B, so sticking Apache and PHP on it might be asking a bit much – especially when you can do it all with one command and a small BASH script.<\/p>\n\n\n\n

So the cunning plan was to take advantage of a feature of public access points – the ones that show you a registration page for you to fill in with fake info. <\/p>\n\n\n\n

When you connect to a public WiFi hotspot your device tries to load a page on the internet using non-SSL http. It might be any page (captive.apple.com\/ seems to be popular), but it will be a web page that the device knows should exist and if it loads, your device knows the internet is working. <\/p>\n\n\n\n

A public access point intercepts the page request and, rather than forwarding it, sends a 30x redirect HTTP response back to the device – basically hijacking the request and spoofing the reply. Your device then loads up the page it has been redirected to and displays it as a sign-in page.<\/p>\n\n\n\n

It is this mechanism that I used to show the keg levels on any phone, just by connecting to the Wifi. This is how to do it if you want to do something similar. I’m assuming you SSH on to a Pi connected with an ethernet cable to your network, and you have a Wifi dongle hanging out of its USB port. In all likelihood they will be eth0<\/code> and wlan0<\/code> respectively, so I’ll use them.<\/p>\n\n\n\n

wlan0<\/code> is going to use a different range of IP addresses from the ones used by eth0<\/code>, so edit \/etc\/dhcpcd.conf<\/code> to manually assign an IP address to the wlan0<\/code> interface. Add this at the bottom (comment out any existing definition for wlan0<\/code>):<\/p>\n\n\n\n

interface wlan0\n    static ip_address=192.168.4.1\/24\n    nohook wpa_supplicant<\/code><\/pre>\n\n\n\n
Next we need to install hostapd<\/code> to run the hotspot and dnsmasq<\/code> to sort out assigning IP addresses to devices that connect.<\/p>\n\n\n\n
sudo apt-get install hostapd\nsudo apt-get install dnsmasq\nsudo systemctl stop hostapd\nsudo systemctl stop dnsmasq<\/pre>\n\n\n\n
The second two commands disable the services we just installed so we can edit config files before starting them again.<\/p>\n\n\n\n
Create the file \/etc\/dnsmasq.conf<\/code> and put this in it:<\/p>\n\n\n\n
\n
interface=wlan0      # Usually wlan0\ndhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h\naddress=\/#\/192.168.4.1<\/code><\/pre>\n<\/div><\/div>\n\n\n\n
This tells dnsmasq to assign the range 192.168.4.2 – 192.168.4.20 with a netmask of 255.255.255.0 and a lease time of 24 hours. The third line tells it to return the server address for all domain lookups that aren’t in \/etc\/hosts<\/code>, i.e. all of them. When dnsmasq restarts it will look at this file and load up the config information.<\/p>\n\n\n\n
Now to set up hostapd<\/code>. Create \/etc\/hostapd\/hostapd.conf<\/code> and put this in it:<\/p>\n\n\n\n
interface=wlan0\ndriver=nl80211\nssid=Your SSID here\nhw_mode=g\nchannel=7\nwmm_enabled=0\nmacaddr_acl=0\nignore_broadcast_ssid=0<\/code><\/pre>\n\n\n\n
It’s pretty obvious what is happening there, other than some of the technical bits; wmm_enabled<\/code> is something to do with packets (no idea what, though), macaddr_acl<\/code> tells it to whitelist all connections and ignore_broadcast_ssid<\/code> tells it to broadcast the SSID – set it to 1 to hide it. There is no WPA password or setup, obviously. Change the SSID to something hilarious.<\/p>\n\n\n\n
Now you need to tell hostapd where to find the config file when it starts. Edit \/etc\/default\/hostapd<\/code> and add (or uncomment and edit) the line:<\/p>\n\n\n\n
DAEMON_CONF=\"\/etc\/hostapd\/hostapd.conf\"<\/code><\/pre>\n\n\n\n
We have now set up our access point. Start dnsmasq<\/code> and hostapd<\/code> again:<\/p>\n\n\n\n
sudo systemctl start hostapd\nsudo systemctl start dnsmasq<\/pre>\n\n\n\n
If there are no errors, your AP should show up in the list of APs on your phone, laptop etc. Try connecting to it – it should connect but you won’t be able to see the internet because there is no forwarding. One thing you can still do however, is connect to SSH on the Pi. You really don’t want any ports other than 80 visible from an unsecured AP. We’ll use iptables<\/a><\/code> to set up a firewall and do the test page hijacking.<\/p>\n\n\n\n
sudo iptables -A INPUT -p tcp -i wlan0 --dport 80 -j ACCEPT\nsudo iptables -A INPUT -p tcp -i wlan0 --dport 53 -j ACCEPT\nsudo iptables -A INPUT -p tcp -i wlan0 -j DROP\nsudo iptables -t nat -A PREROUTING -p tcp -i wlan0 --dport 80 -j DNAT --to-destination 192.168.4.1:80<\/pre>\n\n\n\n
\"\"<\/a><\/figure><\/div>\n\n\n\n
The first two tell iptables to allow through connections on port 80 (HTTP) and 53 (DNS), the second tells iptables to drop all other TCP connections from wlan0<\/code>. The third redirects any connection with a destination port 80 (regardless of the IP address) to the Pi at IP address 192.168.4.1, port 80, for our server to handle. If you are a bit confused about how iptables work, this flowchart will either clear things up or make it more confusing. Basically there are 4 tables – filter (default if no -t switch), nat, mangle and raw which each contain “chains” such as INPUT which are the instructions on how to route traffic. It’s a vast subject and I learned just enough to work out the 3 lines above. There are other guides that go into more details.<\/a><\/p>\n\n\n\n
One thing to do at this point is make it so that the iptables<\/code> configuration is not lost when the system is rebooted. This command saves it to a file:<\/p>\n\n\n\n
sudo iptables-save >\/etc\/iptables.ipv4.nat<\/pre>\n\n\n\n
To reload the configuration on boot put this in \/etc\/rc.local<\/code><\/p>\n\n\n\n
iptables-restore < \/etc\/iptables.ipv4.nat<\/code><\/pre>\n\n\n\n
So, moving on to the web server. I’m using socat<\/a><\/code> and a bash script. socat<\/code> is one of those amazing Linux tools that is impossible to explain to a layperson. “What it does is, it takes data from one place and puts it in another but it’s more complicated than that…” and so on. Best just to tell them it’s the computer equivalent of magic, before their eyes glaze over and they start thinking about feigning an illness in order to escape. We are going to use it to pipe data from an internet port to a script and back again. Incoming text from port 80 is sent to the script on stdin<\/code> and anything written to stdout<\/code> gets sent back to the port. It’s easy enough to set up with this command:<\/p>\n\n\n\n
sudo socat TCP4-LISTEN:80,reuseaddr,fork EXEC:\"\/home\/your_path_here\/server.sh >\/dev\/null\" 2>\/dev\/null &<\/pre>\n\n\n\n
Obviously change “your_path_here” to where you are doing all this stuff and put this line in \/etc\/rc.local<\/code> if you want it to start automatically on boot. The command tells socat<\/code> to listen on port 80 and then fork off the script when there is a connection. The script referred to as \/home\/your_path_here\/server.sh<\/code> is this:<\/p>\n\n\n\n
\n
#!\/bin\/bash\n\nPAGE_NAME=\"kegs\"\nFOUND_URL=\"http:\/\/1.1.1.1\/$PAGE_NAME\"\n\nrequest=\"\"\nwhile read -r  -t 5 line; do\n  if [[ ! -z \"${line:-}\" && $line == *[^[:cntrl:]]* ]]; then\n    if [[ ${line:0:4} == \"GET \" ]]; then\n      request=$(expr \"$line\" : 'GET \/\\(.*\\) HTTP.*')\n    fi\n  else\n    break\n  fi\ndone\n\nif [[ \"$request\" == \"$PAGE_NAME\" ]]; then\n  printf \"HTTP\/1.1 200 OK\\n\"\n  printf \"Content-Type: text\/html\\n\\n\"\n  cat index.html\t# Show this as a registration page.\nelse\n  printf \"HTTP\/1.1 302 Found\\n\"\n  printf \"Location: $FOUND_URL\\n\"\n  printf \"Content-Type: text\/html\\n\\n\"\n  printf \"Redirect to <a href=\\\"$FOUND_URL\\\">$FOUND_URL<\/a>\\n\"\nfi<\/code><\/pre>\n<\/div><\/div>\n\n\n\n
That’s pretty dinky for a web server, huh? Don’t forget to change permissions of server.sh<\/code> with chmod 755 server.sh<\/code>. Rename PAGE_NAME<\/code> and FOUND_URL<\/code> to whatever you want. Note that because we are grabbing all port 80 traffic coming in on wlan0<\/code>, it doesn’t matter what you put for an IP address – it’ll all go to our server. The first block of code reads the HTTP request coming from the device, which will be saying something along the lines of:<\/p>\n\n\n\n
GET \/ HTTP\/1.1\nHost: captive.apple.com\nAccept: image\/gif, image\/jpeg, *\/*\n... and so on<\/pre>\n\n\n\n
The script ignores everything except the GET \/… part, from which it extracts the page name, if any. It won’t match (unless the test page is called “\/kegs” – unlikely), so it will respond with the redirect code 302, to send the device to “\/kegs”. The device sees the redirect, thinks it’s for a registration page and loads 1.1.1.1\/kegs. This time the script sees that \/kegs has been requested, sends a 200 OK code and  the contents of index.html<\/code>, which the device displays. My beer measurement system generates index.html<\/code> as a page showing how much is left in each keg.<\/p>\n\n\n\n
As a useful tool with which to quickly see the levels of my kegs without any fuss, this is rubbish, quite frankly. But then the whole raspberry-pi-based-keg-measurement thing could be replaced with cheap mechanical bathroom scales, so I might as well go all in on the pointless technology.<\/p>\n\n\n\n
Updated 10\/6\/2020 : Improved the firewall rules.
Updated 18\/2\/2021 : Improved DNS rules.<\/p>\n","protected":false},"excerpt":{"rendered":"
This is a little sub-project of what I’ve been working on recently – a hideously over-engineered Raspberry Pi-based system to measure the amount of beer left in the kegs in my keezer. Normally I would simply set up a web server on the Pi and have it on the home network, so I could see […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[81,102],"tags":[112,110,111],"class_list":["post-1042","post","type-post","status-publish","format-standard","hentry","category-beer","category-raspberry-pi","tag-hacking","tag-raspberry-pi","tag-wifi"],"_links":{"self":[{"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/1042","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/comments?post=1042"}],"version-history":[{"count":77,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/1042\/revisions"}],"predecessor-version":[{"id":1175,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/posts\/1042\/revisions\/1175"}],"wp:attachment":[{"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/media?parent=1042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/categories?post=1042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/naich.net\/wordpress\/index.php\/wp-json\/wp\/v2\/tags?post=1042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}