WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.6 - Automating wireless MITM attacks with Easy-Creds

4.6 - Automating MITM attacks with Easy-Creds

- Easy-Creds is a powerful bash script whose main interest is to gather different hacking tools in just one suite of tools. Using Easy-Creds a lot of exploitation attacks can be launched in an automated way.

- From "kali", the attacker machine, easy-creds is started up:

- The first screen allows the user to choose between different options. For instance, option 3 creates a fake AP:

- Option 1 allows a simple fake AP static attack:

- The attack is not related with a web session hicjacking:

- "kali" is connected wiredly to the Internet with eth0 interface:

- "kali" is connected wiressly to the victim "roch" with wlan0 interface:

- The fake AP is called mitm:

- The channel in use is 6:

- The monitor interface is mon0:

- The MAC address won't be changed:

- The tunnel interface is at0:

- Because "kali" is not acting as the DHCP server, dhcpd.conf is not altered:

- The local network used by "kali" and "roch" is 192.168.0.0/24

- From the DNS servers offered by the ISP, the first one is picked up:

- Finally, the attack is launched:

- It is quite interesting to see how Easy-Creds allows to use at the same time all well-known tools and applications (Airbase-NG, DMESG, SSLstrip, Ettercap, URL Snarf, Dsniff). Once the attack configuration is finished, the different tools screens are displayed one on top of the next:

- At this point of the attack, "kali" using Easy-Creds waits until a user from the victim "roch" connects to mitm:

- Airbase-NG detects the association of "roch" (Client 28:C6:8E:63:15:6B) to the created fake AP called mitm:

- Ettercap detects how the DHCP server (the legitimate AP located at "kali"s wired eth0 interface) is offering to "roch" the IP=192.168.0.100, the default gateway GW=192.168.0.1, and DNS=24.159.193.40

- It can be verified that "roch", once connected to mitm, accepts those 3 parameters: IP, GW and DNS.

- If the victims connects to the Internet, either to www.google.com, www.ual.es or any other website, URL Snarf eavesdrops the connections immediately:

- Now, the client tries to check his email account pruebapfm@hotmail.com.As usual, because "kali" is acting as the Man-In-The-Middle, no padlock, HTTPS or green URL bar is shown:

- Ettercap captures the account name (pruebapfm@hotmail.com) and the password (passwordPFM):

- Finally, for the purpose of expanding the demostration of this practice, a Facebook test account is created:

       i) Email: pruebapfm@hotmail.com

       ii) Password: passwordPFM

- If the clients tried to connect the Facebook server normally (before the attack is launched), he would see the padlock and the HTTPS green bar at the URL, ensuring that the connection is being secured:

- However, once the MITM attack has been launched, the URL changes its look. No more padlock or green HTPPS at the URL bar:

- Again, Ettercap captures credentials pruebapfm@hotmail.com and passwordPFM for the Facebook account:

- If the attack is not launched in a smart way, it might appear to the client a screen warning that the connection is not being safe, because of the untruthful certificate used:

- Of course, under any circumstances the user should click "Proceed anaway". However, according to some Google's statistics, many users actually ignore the warning, clicking "Proceed anaway" instead of "Back to safety".

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.5 - Stealing username/passwords with Ettercap MITM attack

4.5 - Stealing username / passwords with Ettercap MITM attack

- This attack is similar to the previous one, in that ARP spoofing is also used. However, now the tool Ettercap will be used in its command shell version. Options used are:

      - T = text only interface

      - q = quiet mode, nor printing packet content

      - M = MITM attack

      - ARP /192.168.0.25/ = ARP replies sent to "roch" 192.168.0.25

      

- Once the attack is launched, "kali" waits for a client to connect to Outlook. Again, there are neither padlock, nor HTTPS and green URL bar, because "kali "Ettercap is intercepting messages between "roch" and the Outook email server:

- Shortly, both test account name (pruebapfm@hotmail.com) and password (passwordPFM) are captured by Ettercap:

- At the victim "roch", it can be checked that not only the legitimate AP 192.168.01 has got the fake MAC address attached, but also all the devices connected to the network segment, either wired or wirelessly:

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.4 - Stealing username/passwords with SSL (Secure Socket Layer) MITM attack

4.4 - Stealing username / passwords with SSL MITM attack

- SSL MITM is one the most common exploitation attack. It requires that the attacker "kali""places himself in the middle of the communication between the victim "roch" and another destination host, for instance the legitimate AP. The prevalent technique used in this attack is the ARP cache poisoning traffic, or ARP spoofing, although other techniques like DNS spoofing can be also very effective. Using a Honeypot, once the victim is connected, the attacker has full control of the Internet traffic sent and received by the victim. Because this attack uses ARP spoofed techniques, it can be considered that happens at Layer 2. The attacker "kali" acts as a delegated proxy of the victim regarding the Internet, because it handles the ARP protocol, DNS request and responses, and data sent and received from outside the local network.

- For the purpose of demonstrating this and following practices, a test Outlook e-mail acount has been created, whose features are:

         e-mail account = pruebapfm@hotmail.com

         password = passwordPFM

- Before starting the attack, let's check that a user connects from "roch" to Outlook with HTTPS (HTTP Secure working on top of the SSL/TLS protocol). The browser shows a padlock, writting the beginning of the URL in green, meaning that the visited website is the real one:

- Also, it can be checked that "roch" (192.168.0.25) holds a correct ARP table, associating the default gateway AP's IP 192.168.0.1 with its real MAC address 00:25:F2:9B:91:22

- Now, let's prepare the "kali" machine for the attack. First of all, "kali" needs to be able of routing packets that arrive to it. For that purpose, ip_forward must be set to 1:

- Also, the firewall iptables must ensure that packets arriving to port 80 are redirected to port 10000 (used by default by the tool sslstrip):

- The tool sslstrip acts as the proxy between "roch" and "kali", and it can be found at: Kali Linux -> Sniffing/Spoofing -> Network Spoofing:

- Then, sslstrip is launched:

- Next step will be to use arspoof. With ARP spoofing technique the attacker "kali" sends fake ARP messages, associating its MAC address with the IP address of the legitimate AP default gateway, redirecting any traffic meant for the legitimate AP to be sent to "kali" instead. In this way, "kali" can intercept, stop or even modify the traffic. In other words, the tool arpspoof convinces "roch" that "kali"s MAC address is the legitimate AP's MAC address. The kernel forwards everything except for traffic destined to port 80, which it is redirected to a listening port like 10000 (as allowed before with Iptables). Actually, this attack can be used as a starting point for other attacks, like DoS, session hijacking or MITM. arpspoof takes this options:

- i = interface used to send fake ARP messaages

- t = target or victim, in this case "roch" which IP is 192.168.0.25, and the legitimate AP 192.168.0.1

- From the debug messages created by arpspoof, it can be read that the AP gateway has got an IP address 192.168.0.1 associated to MAC address 08:00:27:EA:E9:D0, what obvioulsy is not true:

- However it is not true, the victim "roch" believes the whole deception, adding to its ARP table the fake IP-MAC association:

- As a result of the spoofed ARP table, whenever "roch" wants to send a packet to the legitimate AP 192.168.0.1, it will be actually sent to "kali", whose MAC address is 08:00:27:EA:E9:D0.

- Now, when "roch" tries to connect with Outlook, there is no padlock, and the URL is neither HTTPS nor green anymore, because who is responding to the HTTP request is actually "kali", not using any certificate to prove that communication with the website is secured. An unaware users would not notice that detail:

- Let's focus on the detailed URL after the attack authentication is done:

- Comparing it with the previous one (before the attack was launched):

- Using the command tail to detect what's happening at the file sslstrip.log, it can be verified that the account name (pruebapfm@hotmail.com) and the password (passwordPFM) have been successfully captured by sslstrip:

- Also, let's see what happen if the administrator of "roch" wants to access the legitimate AP's Graphical User Interface, writng 192.168.0.1 at the browser:

- Again, username (admin) and password (Ab12345) are captured by sslstrip:

- Once the attack has been successfully performed, it is important for the attacker to cover tracks. For that reason, as soon as possible, once the desired info has been captured, arpspoof must be stopped in order to the fake ARP table could not be detected. It is funny that when arpspoof is stopped, there is a message telling that everything is being cleaned, and targets are recovering their correct ARP tables: "cleaning up and re-arping targets":

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.3 - Web session hijacking over wireless with MITM

4.3 - Web session hijacking over wireless with MITM attack

- To demonstrate this practice, let's start up the Apache server at "kali" machine to have a look at the default page:

- Writing 127.0.1.1 as URL, the Apache default page appears. It will be useful for comparing it with later web search by "roch":

- In order to launch the Web session hijacking attack, the attacker needs to send fake DNS responses that will resolve IP addresess from "roch" to "kali"s own IP. For that purpose, the command dnsspoof is available. As the victim "roch" (192.168.0.15) sends DNS requests (to DNS server 24.159.40.53 provided for the ISP), the attacker records everything at its terminal:

- Now, let's see what happens now when the victim "roch" tries to connect again to "www.ual.es". Because the session is hijacked by DNS spoofed responses, "roch" is able to see only what "kali" allows him to see. In this case, the default page of the Apache server:

- The victim "roch" sends an HTTP request for "www.ual.es", but it actually receives the "kali"s Apache server default page":

- The conclusion of this practice is that the attacker is able to modify data when relaying responses to the victim, being this one unaware of the suffered attack. The tool dnsspoof running on attacker's laptop sends DNS responses to the victim with its own IP address, faking the original one. The victim accepts this responses and sends HTTP requests to the attacker's IP address on port 80. What the responses contains is up to him, whatever the attacker wants the client to believe, maybe a masquerade web site imitating the original or legitimate one, so that the victim introduces credentials, maybe spoofed email, ... , or simply breaking options for the victim to connect to the Internet, in which last case it would be considered a Denial of Service attack.