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.

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.2 - Eavesdropping with MITM attacks

4.2 - Wireless Eavesdropping with MITM attack

- The first step in this attack, as usual, is the attacker creating a virtual monitoring interface mon0 attached to the physical interface wlan0.

- Then, a fake AP called "mitm" is created using airbase-ng, broadcasting its beacon frames everywhere in the channel 6:

- After running airbase-ng there is a new interface called at0 (tap interface), that could be considered as the wire-side interface of the virtual fake AP. In contrast with mon0, that would be the wireless side interface:

- The next step consists of establishing a bridge called "puente" between at0 and the physical Ethernet interface eth0:

- Interfaces eth0 and at0 are added to the bridge "puente":

- Both interfaces are turned on:

- Verifying that the bridge "puente" has been correctly created:

- The bridge "puente" is assigned an static IP 192.168.0.50 (also it could be do dynamically with DHCP):

- A very important step is to prepare the attacker "kali "for being able to route and forward packets, turning IP Forwarding on:

- At this moment of the attack, let's consider that the victim "roch" connects to the fake AP "mitm":

- airbase-ng immediately detects that "roch" (28:C6:8E:63:15:6B) has connected to "mitm":

- One interesting aspect of the connection is that the victim "roch"automatically gets a dynamic IP, because at the wired-side the legitimate AP is running the DHCP service. So, as the victim connects to the network (through the fake AP), it is also considered a host of the network with the right of being assigned an IP and DNS services:

- Now, the victim "roch" can ping the default gateway of the network 192.168.0.1:

- Also, the victim "roch" has got access to the Internet pinging Google's public DNS 8.8.8.8:

- Because the attacker "kali" is located in the middle of the victim and the legitimate AP, he is able to sniff, see and analyze all the traffic sent and received by "roch". Let's see what happens when the victim "roch" decides to connect to www.ual.es:

- "kali" runs Wireshark, which allows the "Follow TCP stream" option to see all packets from a single TCP stream displaying them in order:

- Applying that option, the filter "tcp.stream eq 18" is generated automatically. Then, the whole conversation between the victim "roch" and "www.ual.es" is available for the attacker "kali" to be analyzed and eavesdropped.

- At next screenshot, "roch" (192.168.0.15) and "www.ual.es" (193.147.117.18) establish a TCP and HTTP session, what is being captured by the attacker "kali":

- It can be checked that 193.147.117.18 corresponds to www.ual.es:

- Also with whois:

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.1 - MITM wireless setup

4.1 - Man-In-The-Middle (MITM) wireless setup

The basic idea of a MITM attack consists of an attacker taking a position between the legitimates users of a network, so that the attacker can eavesdrop the communication, having access to connections of the victims, and relaying messages between them. The victims believe that the communications are being legitimate, although the truth is that the attacker has got actually the control of the process.

There are a lot of different architectures or layouts in a MITM attack, depending on the topology, characteristics and technologies available at the network. In this chapter, the used setup will consist of the victim "roch" trying to communicate with the legitimate AP, and the attacker "kali" intercepting and relaying packets between them.

In this setup, the attacker "kali" is connected to the Internet through a wired LAN with its Ethernet interface eth0. At the same time, "kali" creates a fake AP, broadcasting an ESSID equal to the legitimate's one. The victim "roch" would get connected to this fake AP, believing that he is connected to the legitimate AP.

For that purpose "kali" creates a bridge between its wired and virtual wireless interface, forwarding all the packets through the bridge towards and from the Internet.

The attacker "kali" has got access to analyze all the packets sent and received by the victim "roch", not only eavesdropping all the traffic over wireless, but also being able to modify it with malicious intentions, as it will be seen later. For instance, hijacking web sessions, creating denial of service attacks, redirecting to sites intentionally created for the attack, stealing cookies or passwords, redirectioning to ports, spoofing DNS requests and responses, etc ...

WI-FI PT / 3 - ATTACKS AGAINST AUTHENTICATION AND ENCRYPTION / 3.10 - Attack against WPA/WPA2 Enterprise and RADIUS authenticacion

3.10 - Attack against WPA/WPA2 Enterprise and RADIUS authenticacion

- WPA/WPA2 Enterprise, also known as 802.1x mode or WPA (as opposed to WPA-PSK), has the purpose of providing authentication services for enterprise enviroment networks. WPA/WPA2 Enterprise works hand to hand with a RADIUS server. The protocol used for authentication is usually the Extensible Authentication Protocol (EAP), which is available in a lot of different versions. The most important EAP versions are:

• EAP - PEAP: supported by Microsoft and Cisco, it uses only a server side certificate. The EAP - PEAP - MSCHAPv2, natively integrated with Windows, is the most popular of all EAP versions as Wi-Fi security mechanism.
• EAP - TLS: it is considered the most secure, because a certificate is necessary both at the server and the client sides.
• EAP - TTLS: the server uses a certificate, but the client can optionally authenticate with a Certification Authority to the server, which simplifies a lot the whole process. It is faster, but less secure than TLS.
• EAP - FAST: Cisco propietary, used to replace the obsolete LEAP.

- At this practice, an attack against WPA-Entreprise with RADIUS using EAP-PEAP wil be exposed, but exactly the same method could be use to crack EAP-TTLS. In both cases, the trick consists of capturing the MSCHAP

challenge/response pair, and applying a dictionary attack with the tool Asleap.

- The most used protocol for EAP-PEAP with Windows devices is MSCHAP, which is the Microsoft version of the Challenge Handshake Authentication Protocol (CHAP). There are two different versions: MS-CHAPv1 and MS-CHAPv2. MSCHAPv2 is often used as an authentication option for RADIUS servers, providing security for Wi-Fi under the WPA Enterprise scenario.The Challenge Handshake Authentication Protocol (CHAP) is used to authenticate a user or a host to an authenticating entity, for instance a RADIUS server. The verification is based on a key secret shared by the client and the server or authenticator. The whole process consists of a 3 way handshake. After the intial establishment phase, the authenticator sends a "challenge" message to the client. The client responds with a one-way hash, calculated with the challenge and the secret combined. The authenticator compares the received hash with its own calculation of the hash value. If both hashes match, the authenticator acknowledges as valid the authentication. At random intervals the authenticator sends a new challenge to the peer.

- The topology used for this practice will be a little bit different than other practices, because in this case it is necessary to introduce RADIUS server authenticators. On the one hand, the victim "roch" should authenticate with the legitimate AP using the services of a legitimate RADIUS server. However, let's suppose that for any reason an attacker has achieved the goal of forcing the victim to connect to a rogue AP, which is using the services of a Free Radius server running on a "kali" Linux machine. For instance:

- In this practice, to setup an AP honeypot will be used a D-Link Access Point, broadcasting an ESSID called "withRadius". The honeypot will try to fake a supposedly real network, which could work for instance with Windows Server 2003, 2008 or 2012 Radius server, integrated with Active Directory.

- Because an external RADIUS server is going to be used, WPA/WPA2 Enterprise is needed:

- The AP is pointing as a client to the FreeRadius server, which is running on the "kali" attacker with IP 192.168.0.198, listening on port 1812. Also, a Shared Secret is needed ("test"), shared between the AP and the FreeRadius server:

- Verifiying that "kali"s IP (FreeRadius server) is 192.168.0.198:

- On the server side, FreeRadius is configured to use EAP-PEAP by default, at eap.conf file:

- Also, FreeRadius needs to be aware of its client D-Link AP, whose IP is 192.168.0.2:

- As said before, both AP client (192.168.0.12) and FreeRadius server (192.168.0.198) have to share a secret key ("test"):

- The shared key is introduced at the clients.conf file for the client 192.168.0.2:

- Then, FreeRadius server is started at "kali", listening on port 1812 to authentication requests:

- A victim user "daniel" from "roch", tries to join the "withRadius" wireless network, and he is prompted for authentication:

- Previously, the certification validation option for EAP has been turned off at the client "roch", with the purpose of showing the potential weakness of this type of authentication. Of course, if a certificate (fake, created by FreeRadius at the attacker "kali") is offered and accepted by the user, the result would be the same. Because the "validate server certificate" is off, the victim is not able to verify if a certificate is either fake of truthful. Not only that, if the "Connect to these servers" option is also turned off, an attacker could get a real certificate from any list of authorized authorities. In case of been accepted by the client, the result would be again the same:

- The connection is succesful:

- FreeRadius debugs the success of the authentication process:

- In the meanwhile, the process of the mschap username / challenge / response is being tailing from radius.log:

- Finally, the tool Asleap, after a brute force attack with the help of the wordlist "diccionario.txt", is able to crack the password for user "daniel": abcdefghi

- It is important to notice that in this practice, and for the purpose of a more clear demonstration, valid credentials have been introduced. However, if non valid credentials had been used, the log would have captured them in the same way, and eventually Asleap also would have been able to crack them.

WI-FI PT / 3 - ATTACKS AGAINST AUTHENTICATION AND ENCRYPTION / 3.9 - AP-less attack against WPA/WPA2

3.9 - AP-less attack against WPA/WPA2

- In previous practices WPA/WPA2 was cracked after capturing the 4 way handshake between AP and client.

- Now, it will be shown how to crack WPA/WPA2 just using the client, with no access point. In this case the 4 way handshake packets won't be necessary, because 2 of them (either the pair 1 and 2, or the pair 3 and 4) will be enough to be known. To achieve that goal, the first step is to create a honeypot where the client will try to connect, sending the message 1 and receiving the answer 2.

- Let's remember a previous picture:

- The attacker "kali" creates a honeypot imititating the legitimate AP, with same ESSID "spaniard" and MAC address 00:25:F2:9B:91:23 (both learnt easily with airodump-ng):

- Also, airodump-ng creates a file called sinAP.cap, where all the interesting packets will be stored:

- The victim "roch" connects to the honeypot and associates to it, in the false believe that it has connected to the legitimate AP:

- airodump-ng detects the association of the victim "roch":

- Also, the file sinAP.cap is created:

- Next, brute-force attack is launched with aircrack-ng:

- A few instants later, the key is found:

- This practice is even lighter than previous practices trying to find the WPA/WPA2 key, because there are less steps involved. The legitimate AP has not been used at all, because no deauthentication packets have been sent to the AP.