DHCP Starvation Attack and MAC Address Spoofing

It was a rainy holiday but I still enjoyed my stay in the Philippines last December 2018. My family visited the Mind Museum in BGC Taguig, which was just few minutes away from F1 Hotel where we stayed.

I always longed the fresh air and cool climate in Tagaytay, so we went there after celebrating the New Year. Our first stop was Paradizoo, a mini zoo where you can interact and feed various farm animals. They also have other attractions such as the butterfly garden and a honeybee farm.

We had Filipino lunch at Balay Dako and they have a spectacular view of Taal Lake and Volcano.

This helpful link describes the anatomy of a DHCP server spoofing attack. I also used a Layer 2 attack tool called Yersinia, which is included in Kali Linux distribution.

In my Cybersecurity lab, the Cisco ASA5506-X act as the DHCP server for the wired inside hosts on the 192.168.1.0/24 subnet and for the wifi hosts on the 192.168.10.0/24.

Both DHCP ranges has a maximum of 42 IP addresses that it could lease out:

• 192.168.1.10 - 192.168.1.50

• 192.168.10.10 - 192.168.10.50

The ASA firewall/DHCP server currently displays only 1 host with the assigned IP address 192.168.10.43 (my iPhone).

root@kali:~# yersinia --help

    Û²ÛÛ²²Û                                                                    

   ²Û°°°²²Û²²                                                                  

 Û²²²°ÛÛÛ°²Û²²                                                                 

²²°²°Û±²±Û²°°²²²Û                                                              

°²°°Û±²±²²±Û²²°²²Û                                                             

²°²°Û±²±±²²±Û°°²°²²               Yersinia...                                  

²²°°²Û²²±²²±²±Û°²ÛÛ²²²                                                         

Û²²²°Û±²²²±±²²±ÛÛ°²°ÛÛ²²²         The Black Death for nowadays networks        

 ²²²°²ÛÛ±²²²²²²²²±Û°°²²°²²                                                     

 ²ÛÛ°°²°Û±²²±±±²²²²²±Û°²²Û²²             by Slay & tomac                       

  Û²²Û²°°Û±²²²±±²²²²²²±Û²°°²²Û                                                 

     ²²Û²°Û±±²²±±±±±±²²²±Û°²°²Û        http://www.yersinia.net                 

      Û²°²²ÛÛ±±±²²±±±±²²²ÛÛÛ²Û²            yersinia@yersinia.net               

       Û²²°°²ÛÛ±±±²²²±²²²ÛÛ²°ÛÛ                                                

         ²Û²°²²°Û±±±²²²²±Û²°Û²²                                                

         ²Û²²Û°²°ÛÛÛÛÛ±ÛÛ°²²²²     Prune your MSTP, RSTP, STP trees!!!!        

             ²²Û°°²²²°°²°°Û²²                                                  

Usage: yersinia [-hVGIDd] [-l logfile] [-c conffile] protocol [protocol_options]

       -V   Program version.

       -h   This help screen.

       -G   Graphical mode (GTK).

       -I   Interactive mode (ncurses).

       -D   Daemon mode.

       -d   Debug.

       -l logfile   Select logfile.

       -c conffile  Select config file.

  protocol   One of the following: cdp, dhcp, dot1q, dot1x, dtp, hsrp, isl, mpls, stp, vtp.

Try 'yersinia protocol -h' to see protocol_options help

Please, see the man page for a full list of options and many examples.

Send your bugs & suggestions to the Yersinia developers <yersinia@yersinia.net>

MOTD: The world is waiting for... M-A-T-E-O!!!

root@kali:~# yersinia -G      // LAUNCH GUI

A pop-up message is displayed. Just click OK.

To launch a DHCP Starvation (DoS) Attack, go to DHCP tab > Launch attack (gear icon) > choose sending DISCOVER packet > OK.

The DHCP table went full (42 Active Leases) in less than a minute.

To stop the DHCP Starvation attack, click List attacks > Stop

Cisco ASA FirePOWER Traffic Redirection, Security Zone and Network Object via ASDM

Below is the normal traffic flow in a Cisco ASA Firewall with FirePOWER module.

You can check the ASA Access Rules under Configuration > Firewall > Access Rules (click the box/or maximize icon). There's an implicit permit rule for traffic from the inside and wifi going out to the Internet (outside). You'll need to permit traffic from inside to outside and redirect it to the FirePOWER module in order to apply Next-Generation firewall services such as IPS, URL filter and Advanced Malware Protection (AMP).

Below is the inspection flow for the FirePOWER Access Control Rules

Click on ASA FirePOWER to check the Access Control Policy for the FirePOWER module. Notice there are no rules created yet and the Default Action is set to Access Control: Trust All Traffic 

To redirect traffic to the FirePOWER module, go to Configuration > Firewall > Service Policy Rules. There's a global_policy and inspection_default configured by default. Click on the inspection_default and click Delete (trash) icon.

Click Add (down arrow) > Add Service Policy Rule

Leave the default settings in Step 1 and click Next.

Choose Use class-default as the traffic class > click Next.

Go to ASA FirePOWER Inspection tab > tick Enable ASA FirePOWER for this traffic flow > leave the default Permit traffic > click Finish.

This will allow traffic to flow normally even though the FirePOWER module has failed.

 

Click Apply and ASDM will display an error. Just click Close.

Below is the configuration for the traffic redirection on the FirePOWER module. I also generated some web traffic from a machine residing on the inside interface.

ASA5506W-X# show run policy-map

!

policy-map type inspect dns preset_dns_map

 parameters

  message-length maximum client auto

  message-length maximum 512

  no tcp-inspection

policy-map global_policy

 class inspection_default

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect ip-options

  inspect netbios

  inspect rsh

  inspect rtsp

  inspect skinny 

  inspect esmtp

  inspect sqlnet

  inspect sunrpc

  inspect tftp

  inspect sip 

  inspect xdmcp

  inspect dns preset_dns_map

  inspect icmp

  inspect icmp error

policy-map global-policy

 class class-default

  sfr fail-open

policy-map type inspect dns migrated_dns_map_2

 parameters

  message-length maximum client auto

  message-length maximum 512

  no tcp-inspection

policy-map type inspect dns migrated_dns_map_1

 parameters

  message-length maximum client auto

  message-length maximum 512

  no tcp-inspection

ASA5506W-X# show service-policy

Global policy:

  Service-policy: global-policy

    Class-map: class-default

      Default Queueing      SFR: card status Up, mode fail-open

        packet input 5636, packet output 5636, drop 0, reset-drop 0

You'll need to prepare several objects (alias) to be used for FirePOWER Access Control Policy Rules. First, create the logical Security Zones under Configuration > ASA FirePOWER Configuration > Object Management > Security Zones > Add Security Zone

Choose ASA (which is the only optional available) under Type in order to load the Available Interfaces. In my case I got interfaces on the outside, several inside and wifi.

Type a Name (INSIDE-WIRED) > select the interface(s) > Add > Store ASA FirePOWER changes.

I encountered an issue wherein there were no hits on the FirePOWER access rules. You'll need to add all the inside interface except the interface going to FirePOWER  (inside-1). This is the direct cable between the ASA 5506W-X G1/2 and MGT1/1 interface.

Click the arrow on the Security Zone Object (INSIDE-WIRED) to expand and show its associated interfaces.

Configured the same for the wifi and outside interfaces.

Click the arrow to expand the Security Zone Object and show its associated interfaces.

Next, create individual network objects under Configuration > ASA FirePOWER Configuration > Object Management  Network > Individual Objects.

By default the Network Object for the RFC 1918 Private Networks is configured.

Click Add Network > Type a Name for the Network Object > type the Network (CIDR notation) > click Add > Store ASA FirePOWER Changes.

In this case I added the inside wired (192.168.1.0/24) and wifi (192.168.10.0/24) networks.

 

You then create a Network Group Object to tie together the individual network objects create earlier under Configuration > ASA FirePOWER Configuration > Object Management > Object Groups > Add Network Group.

Type a Name for the Network Group Object > select the individual Network Objects on the left > click Add to move under Selected Networks on the right > Store ASA FirePOWER changes.

Man-in-the-Middle (MITM) Attack Using Cain & Abel

A man-in-the-middle attack results when attackers place themselves in line between two devices that are communicating, with the intent of performing reconnaissance or manipulating the data as it moves between the devices. This can happen at Layer 2 or Layer 3. The main purpose is eavesdropping, so the attacker can see all the traffic.

If this happens at Layer 2, the attacker spoofs Layer 2 MAC addresses to make the devices on a LAN believe that the Layer 2 address of the attacker is the Layer 2 address of its default gateway. This is called “ARP poisoning.” Frames that are supposed to go to the default gateway are forwarded by the switch to the Layer 2 address of the attacker on the same network. To mitigate this risk, you could use techniques such as dynamic Address Resolution Protocol (ARP) inspection (DAI) on switches to prevent spoofing of the Layer 2 addresses.

A man-in-the-middle attack can occur at Layer 3 by placing a rogue router on the network and then tricking the other routers into believing that this new router has a better path. This could cause network traffic to flow through the rogue router and again allow the attacker to steal network data. You can mitigate attacks such as these in various ways, including using routing authentication protocols and filtering information from being advertised or learned on specific interfaces.

A man-in-the-middle attack can occur by compromising the victim’s machine and installing malware that can intercept the packets sent by the victim and sending them to the attacker. This type of malware can capture packets before they are encrypted if the victim is using SSL/TLS/HTTPS or
any other mechanism.

To safeguard data in motion, one of the best things you can do is to use encryption for the confidentiality of the data in transit. If you use plaintext protocols for management, such as Telnet or HTTP, an attacker who has implemented a man-in-the-middle attack can see the contents of your
cleartext data packets, and as a result will see everything that goes across his device, including usernames and passwords that are used. Using management protocols that have encryption built in, such as Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS), is considered a
best practice, and using VPN protection for cleartext sensitive data is also considered a best practice.

I simulated a Man-in-the-Middle (MITM) attack in my Cybersecurity Lab using a tool called Cain & Abel. Download v4.9.56 for Windows NT/2000/XP and just follow the installation wizard.

It will also install WinPcap (usually comes with Wireshark installation).

Click Start/Stop Sniffer

Select the Adapter > click OK.

A warning message will pop-up > click OK > click again Start/Stop Sniffer icon.

The active LAN hosts will be displayed under Sniffer > Hosts tab.

Go to Sniffer > APR (ARP Poison Routing).

Click on the area under Status (where the pointer is) > the + symbol will turn from gray to blue > click on the + symbol.

Click on the hosts to hijack the session: click 192.168.1.110 (Kali) on the left and 192.168.1.120 (Metasploitable2) > click OK 

Click Start/Stop APR icon to perform a Man-in-the-Middle (MITM) attack between the selected hosts.

Generate traffic between Kali and Metasploitable hosts.

Notice the APR Status will change from Idle to Poisoning and Packets counter increased.

Go to Sniffer > Passwords tab > Telnet (notice there's a count of 1).

Right-click on the sniffed Telnet session > View

Noticed the displayed password in clear text (msfadmin).

You can remove the APR session by doing a right-click > Remove.

I ran APR again between 192.168.1.100 (Windows 10 machine) and 192.168.1.1 (ASA5506-X).

I tried to SSH to the ASA firewall from Windows 10 machine.

Notice the APR-SSH count became 1 and Cain & Abel detected the routed packets to the Internet.

Go to Sniffer > APR > click APR SSH-1 > right-click on the SSH session > View

Noticed SSH traffic is encrypted and hides the username and passwords. So it's best practice to use secure management protocols such as SSH (or use VPN) in your network.