Exploit Understanding Address Resolution Protocol Attacks

Exploiter

Хакер
34,644
0
18 Дек 2022
EDB-ID
13190
Проверка EDB
  1. Пройдено
Автор
CIJFER
Тип уязвимости
PAPERS
Платформа
MULTIPLE
CVE
N/A
Дата публикации
2006-04-08
Код:
Understanding Address Resolution Protocol Attacks

Copyright (c) 2006 cijfer <cijfer@netti!fi>
All rights reserved.

Table of Contents

   1 About this paper
   2 Introduction to ARP
       2.1 What does ARP mean?
       2.2 The purpose of ARP cache
       2.3 How ARP works
       2.4 Protocol flaws
   3 ARP attack methods
       3.1 Terms & definitions
       3.2 Connection hijacking & interception
       3.3 Connection resetting
       3.4 Man in the middle
       3.5 Packet sniffing
       3.6 Denial of service
   4 References & links
       4.1 Documents
       4.2 Software & programs
   5 Greets

1 About this paper

   In this particular paper, i will be discussing accordingly
   a basic introduction to understanding Address Resolution
   Protocol (ARP) as well as several methods of attack. These
   methods . in no specific order . include detailed
   explanations for hijacking and resetting a users connection
   and/or session, man in the middle attacks, packet sniffing
   on switched environments, and denial of service attacks
   (DoS).

   Concluding the introduction and other sections, i will give
   several links to documents, software, and such to help aid
   in further reference of ARP.

2 Introduction to ARP

 2.1 What does ARP mean?
 
   Address Resolution Protocol (ARP) . a stateless protocol .
   was designed to map Internet Protocol addresses (IP) to
   their associated Media Access Control (MAC) addresses. This
   being said, by mapping a 32 bit IP address to an associated
   48 bit MAC address via attached Ethernet devices, a
   communication between local nodes can be made.

   On a majority of operating systems . such as Linux, FreeBSD,
   and other UNIX based operating systems, and even including 
   Windows . the "arp" program is present. This program can be 
   used to display and/or modify ARP cache entries. By simply 
   running "arp -na" in your terminal, a list of current
   entries in the local ARP cache will show. This includes IP
   addresses, hardware types, MAC (HWaddress) addresses, flag 
   masks, associated NIC interfaces, and link types (output 
   may vary depending on system).

   An example of the "arp" utility's output would look like the
   following:

    Windows:
     > arp -a
     Interface: 192.168.1.100 .- 0x10003
     Internet Address      Physical Address      Type
     192.168.1.1           00-13-10-23-9a-53     dynamic

    Linux:
     $ arp -na
     ? (192.168.1.1) at 00:90:B1:DC:F8:C0 [ether] on eth0

    FreeBSD:
     $ arp -na 
     ? (192.168.1.1) at 00:00:0c:3e:4d:49 on bge0

   You will notice also that on the Windows example, the Type 
   for that particular entry is labeled as "dynamic". Dynamic 
   entries in the ARP cache are eligible to be purged from the 
   cache. This is avoidable if the entry is labeled as static
   or permanent which is self explanatory by its name. I will
   get into static ARP entries near the end of this paper.

 2.2 The purpose of ARP cache

   As stated in section 2.1, the Address Resolution Protocol 
   was designed to map IP addresses to MAC addresses. ARP uses 
   a cache to keep track of these addresses in a table known as
   the ARP cache. The ARP cache . like any other cache . has
   data stored only temporarily. The average amount of time 
   that data is stored in this cache, is normally between 1 
   minute to 10 minutes. The Time to Live (TTL) however can be
   much greater than that, such as with Cisco routers, which 
   have an estimate TTL of 4 hours. Each system has a different
   TTL period until non-permanent data is cleared - Previous 
   cache entries which are obsolete and not used waste space 
   and have no purpose being there. Therefore, entries  are 
   either updated or purged from the cache completely.

   As stated, the ARP cache has a job to maintain ARP replies 
   and data. To reduce the amount of ARP cache entries, the ARP
   cache updates with the newly received IP addresses and
   corresponding MAC address. It does this as a method of 
   reducing network traffic. If i were to map the hardware
   address of another node on my local network, the ARP cache
   holds its entry in the cache so i do not have to 
   continuously map it out during my communication. 

 2.3 How ARP works

   Specifically for Internet Protocol Version 4 (IPv4), ARP 
   maps IP addresses between the Network layer and Data Link 
   layer of the Open System Interconnection (OSI) model. 

   The Data Link layer is split into two sublayers, The Media 
   Access Control layer, and the Logical Link Control layer. 
   The MAC layer has the power to control access to data flow 
   and whether or not transmission is permitted. The Logical 
   Link Control layer's job however is to control frame 
   synchronization, packet flow (like MAC), and error checking 
   throughout data packets. These two sublayers work together
   to create the Data Link layer.

   The next step for successful packet transmission is the most
   important. Transmission itself. The Network layer provides 
   the switching and routing by transmitting data between nodes
   on a network. Not only is packet transmission a part of this
   layer, but also addressing, internetworking, error handling,
   and packet sequencing. This layer ensures that each packet 
   is sent accordingly to their final destinations without 
   errors and possible collision.

   For a more complete and thorough explanation of how address
   resolution works, and protocol specifics, please consult RFC
   826 (David C. Plummer, 1982). RFC 826 was written in 1982 by
   C. Plummer, and is considered to be outdated and complicated
   material to the neophytes. Consult the end of this paper in 
   section 5.1 for links to papers regarding ARP, MAC, and 
   further discussions on ARP based attacks.
  
 2.4 Protocol flaws

   ARP's main flaw is in its cache. Knowing that it is possible
   for ARP to update existing entries as well as add to the 
   cache, this leads one to believe that forged replies can be 
   made, which result in ARP cache poisoning attacks. I will 
   discuss each type of attack in section 3 as well as terms 
   and definitions reviewed in section 3.1.

3 ARP attack methods

 3.1 Terms & definitions

   A. ARP Cache Poisoning
      Broadcasting forged ARP replies on a local network. In a
      sense, "fooling" nodes on the network. This can be done
      because ARP lacks authentication features, thus blindly
      accepting any request and reply that is received or sent.
      
   B. MAC Address Flooding
      An ARP cache poisoning attack that is mainly used in 
      switched environments. By flooding a switch with fake MAC 
      addresses, a switch is overloaded. Because of this, it 
      broadcasts all network traffic to every connected node. 
      This outcome is referred to as "broadcast mode" because,
      all traffic passing through the switch is broadcasted out
      like a Hub would do. This then can result in sniffing all
      network traffic.
    
 3.2 Connection hijacking & interception

   Packet or connection hijacking and interception is the act
   in which any connected client can be victimized into getting
   their connection manipulated in a way that it is possible to
   take complete control over.

   Those whom may be vulnerable to this type of attack, usually
   connect to servers and computers via unencrypted protocols
   such as Telnet or Rlogin. This can result in sniffing, as
   well as connection hijacking and interception.

 3.3 Connection resetting

   The name explains itself very well. When we are resetting
   a client's connection, we are cutting their connection to
   the system. This can be easily done using specially crafted
   code to do so. Luckily, we have wonderful software that was
   made to aid us in doing so.

   One piece of code that is extremely easy to use to do this,
   is within the DSniff collection. To pull this off, we're
   going to use 'tcpkill'. TCPKill's usage is similar to that
   of TCPDump, both using BPF (Berkeley Packet Filters).

    Cause:
     1. tcpkill -9 port ftp &>/dev/null
     2. tcpkill -9 host 192.168.10.30 &>/dev/null
     3. tcpkill -9 port 53 and port 8000 &>/dev/null
     4. tcpkill -9 net 192.168.10 &>/dev/null
     5. tcpkill -9 net 192.168.10 and port 22 &>/dev/null

    Effect:
     1. Kill connections attempting to access port 21 (ftp)
     2. Kill connections matching the IP '192.168.10.30'
     3. Kill connections attempting to access port 53 and 8000
     4. Kill connections 192.168.10.* (192.168.10.0/24)
     5. Kill connections 192.168.10.* accessing port 22

   TCPKill is mainly used to continously keep the connection of
   the client cut. By simply killing the 'tcpkill' process
   after use, will allow the connection to become available
   again. If not, then the remote client will cease to be able
   to connect.

 3.4 Man in the middle

   One of the more prominent ways of attacking another user in
   order to hijack their traffic, is by means of a Man In The
   Middle (MITM) attack. Unlike the other attacks, a MITM is
   more a packet manipulation attack which in the end however
   does result in packet redirection to the attacker . all
   traffic will get sent to the attacker doing the MITM
   attack. This attack however is specific. As opposed to MAC
   Address Flooding or other attacks against a router/switch,
   the MITM attack is against a victim, and also can be done
   outside of a switched environment. Thus meaning, an attack
   can be executed against a person on the other side of the
   country . to be more thorough.

   Downsides of a MITM attack is the fact that the victim must
   be connected via an unencrypted protocol. Utilities such as
   Telnet, and Rlogin can be attacked via MITM attacks. There
   also is the possibility of executing a MITM attack against
   encrypted protocols . such as SSH - but I will not get into
   that in this paper.

   A MITM attack could be of great use on operating systems
   such as SunOS/Solaris and IRIX, due to the fact that one of
   the main modes of connection to these operating systems
   happens to be Telnet and Rlogin. Rarely do i see the older
   versions of these operating systems using SSH.

   A basic MITM attack consists of an attacker, victim and
   the target/destination that the victim is communicating
   with. Using a visual representation of this attack would be
   a lot more confusing, so I'm just going to subtly explain
   what is occurring when doing this specific attack. But
   before i begin explaining that, we need to do one thing:

   Enable IP forwarding if not already default.

    Linux:
     # echo 1 > /proc/sys/net/ipv4/ip_forward

    Other:
     # sysctl -w net.inet.ip.forwarding=1
       -OR-
     edit /etc/sysctl.conf

   To double check whether or not IP forwarding is enabled,
   you can simply do the following commands:

    Linux:
     # cat /proc/sys/net/ipv4/ip_forward

    Other:
     # sysctl -A | grep net.inet.ip.forwarding

   If the value is set to "1", then IP forwarding is enabled.

   Continuing on, we're going to do this also using third party
   utilities. A suggestion for easy usage would be using the 
   "arpspoof" utility by Dug Song within his DSniff package.

   One of the good reasons about the "arpspoof" utility, is the
   fact that its extremely simple to use and requires only two
   arguments. Information needed in order to use it, is the
   Victim's IP address, and the Target/Destination IP address
   that Victim is trying to authenticate with. With these two 
   IP addresses, we can continue with our MITM attack. A simple
   example of what "arpspoof" will do is as followed:

    1. Communicate with Victim saying that you're Destination.
    2. Communicate with Destination saying that you're Victim.

   This can be easily done by using the following syntax via
   "arpspoof" and two open terminal windows. But before i get
   into that, i just want to make clear about the example IP
   addresses being used:

    Setup:
     Attacker (IP: 2.2.2.2)
     Victim   (IP: 1.1.1.1) <-> Target (IP: 0.0.0.0)

    Term A:
     # arpspoof -t 1.1.1.1 0.0.0.0 &>/dev/null &
     # arpspoof -t 0.0.0.0 1.1.1.1 &>/dev/null &

    Term B:
     # dsniff | less
       -OR-
     # ngrep host 1.1.1.1 | less
       -OR-
     # tcpdump host 1.1.1.1 and not arp | less

   If everything went successfully, then by using one of the
   three optional programs in Term B, you should be able to
   sniff all traffic that is being sent between Victim and the
   Target/Destination.

   If at all something did not go as planned, then there could
   be several reasons. One reason could be that the Victim has
   static ARP tables . which deny the overwriting of entries
   within the ARP cache table. Another possible reason could be
   a detection system of some sort such as ARPWatch which is an
   ethernet/ip monitoring system. As a reminder, this specific
   MITM attack will not work on encrypted protocols . explained
   in this section at paragraph 2.

 3.5 Packet sniffing

   Sniffing on a Local Area Network (LAN) is quite easy if the 
   network is segmented via a hub, rather than a switch. The 
   sole difference, is that a switch is organized when sending 
   packets, thus entitled "switch" because it switches packets
   between destinations respectively. A hub on the other hand 
   broadcasts packets throughout the entire network blindly and
   freely without any specific destination.

   It is of course possible to sniff on a switched environment 
   by performing a MAC flood attack. This is vaguely explained 
   in section 3.1b on MAC Address Flooding.

   As a result of the MAC flood, the switch will act as a hub, 
   and allow the entire network to be sniffed. This gives you a 
   chance to use any sort of sniffing software available to you 
   to use against the network, and gather packets. A few 
   popular sniffing software and programs include: DSniff by 
   Dug Song, LinSniffer (one popular version is LinSniffer 
   0.666 by humble of rhino9), PHoss by FX and Ettercap by
   Alberto Ornaghi, and Marco Valleri.

   Example output from PHoss:

    [root@genii sniff]# ./PHoss
    PHoss (Phenoelit's own security sniffer)
    (c) 1999 by Phenoelit (http://www.phenoelit.de)
    $Revision: 1.13 $
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Source:         192.168.1.100:40895
    Destination:    72.14.0.99:80
    Protocol:       HTTP
    Data:           asrtrin:manheim
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    Source:         192.168.1.105:46537
    Destination:    72.14.0.99:21
    Protocol:       FTP
    Data:           buddy:holly
    [...]

   Example output from TCPDump 3.9.4 (output is not identical):

    [root@genii sniff]# tcpdump -vvX port 21
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), 
    capture size 96 bytes

    [...]
    00:45:40.370082 IP (tos 0x0, ttl 111, id 43980, offset 0,
    flags [DF], proto: TCP (6), length: 57) localhost.pirhana >
    localhost.ftp: P, cksum 0x434b (correct), 1:18(17) ack 38
    win 17483
    4500 0039 abcc 4000 6f06 79e6 44ad 954f  [email protected]
    5056 bbb9 11f9 0015 6595 ed3d 6f7f 82e1  PV......e..=o...
    5018 444b 434b 0000 5553 4552 206d 7975  P.DKCK..USER.myu
    7365 726e 616d 650d 0a                   sername..
    [...]

   Note that we now have a username, which is 'myusername'.

    [...]
    00:45:42.467487 IP (tos 0x0, ttl 111, id 43985, offset 0,
    flags [DF], proto: TCP (6), length: 57) localhost.pirhana > 
    localhost.ftp: P, cksum 0x3e34 (correct), 18:35(17) ack 72
    win 17449
    4500 0039 abd1 4000 6f06 79e1 44ad 954f  [email protected]
    5056 bbb9 11f9 0015 6595 ed4e 6f7f 8303  PV......e..No...
    5018 4429 3e34 0000 5041 5353 206d 7970  P.D)>4..PASS.myp
    6173 7377 6f72 640d 0a                   assword..
    [...]

   And now a password, which is 'mypassword'. But is this login
   a valid one?

    [...]
    00:45:42.473412 IP (tos 0x0, ttl  64, id 53228, offset 0,
    flags [DF], proto: TCP (6), length: 62) localhost.ftp
    > localhost.pirhana: P, cksum 0xae1b (correct), 72:94(22)
    ack 35 win 5840
    4500 003e cfec 4000 4006 84c1 5056 bbb9  E..>..@[email protected]..
    44ad 954f 0015 11f9 6f7f 8303 6595 ed5f  D..O....o...e.._
    5018 16d0 ae1b 0000 3533 3020 4c6f 6769  P.......530.Logi
    6e20 696e 636f 7272 6563 742e 0d0a       n.incorrect...
    [...]

   It was not :(. But we'll know when we get a valid one :)).

 3.6 Denial of service

   Denial of service is just lame. Try not to do it unless you
   absolutely must unless for penetration testing. Denial of
   service is self explanatory. Denial of service attacks can
   occur when large amounts of unsolicited packets are targeted
   against a specific host and/or optionally on specific ports.
   This may result in the remote node to panic and close the
   port (denying its service), or even shutting down the entire
   system - possibly a reboot.

   As explained in section 3.1b, MAC Address Flooding can be
   considered a Denial of service attack. The main idea of the
   MAC flood, is to generate enough packet data to send toward
   a switch, attempting to make it panic. This of course will
   cause the switch to drop into broadcast mode and broadcast
   all packet data. This however did not result in a crash, or
   the service to be dropped, but to be overloaded.

   For further information on MAC Address Flooding, please read
   back to section 3.1B on its definition. 

4 References & links
  
 4.1 Documents

   1. http://ietf.org/rfc/rfc826.txt
   2. http://networksorcery.com/enp/protocol/arp.htm
   3. http://man.he.net/?topic=arp&section=all

 4.2 Software & programs

   1. ARP0c2   - http://phenoelit.de/arpoc/
   2. Dsniff   - http://monkey.org/~dugsong/dsniff/
   3. Ettercap - http://ettercap.sourceforge.net/
   4. Hunt     - http://packetstormsecurity.org/sniffers/hunt/
   5. Ngrep    - http://ngrep.sourceforge.net/
   6. PHoss    - http://phenoelit.de/phoss/docu.html
   7. Shijack  - http://securiteam.com/tools/5QP0P0K40M.html
   8. Tcpdump  - http://tcpdump.org/

5 Greets

   x80, thank you for proof reading.

_EOF_

# milw0rm.com [2006-04-08]
 
Источник
www.exploit-db.com

Похожие темы