Re: Unicast ARP Request: Considered Harmful?

[Jeff Kell <jeff-kell () utc edu>]

Despite the standards and how things are "supposed" to work...  unicast
ARP is common for some rather common things.  Cisco switches for example
have specific ARP timeouts for their ARP tables.  By default, 30 seconds
prior to an ARP table entry timeout, it will send a unicast ARP request
for the IP in the candidate entry.  If it answers back, the ARP entry is
refreshed for another timeout interval.

Jeff

On 5/18/2014 5:07 PM, Kevin Le Gouguec wrote:
> Looked a bit more into this. RFC 826 (section "Packet Reception") specifies the following steps when receiving an ARP 
> packet (whether request or reply):
>
> ?Do I have the hardware type in ar$hrd?
> Yes: (almost definitely)
>   [optionally check the hardware length ar$hln]
>   ?Do I speak the protocol in ar$pro?
>   Yes:
>     [optionally check the protocol length ar$pln]
>     Merge_flag := false
>     If the pair <protocol type, sender protocol address> is
>         already in my translation table, update the sender
>         hardware address field of the entry with the new
>         information in the packet and set Merge_flag to true.
>     ?Am I the target protocol address?
>     Yes:
>       If Merge_flag is false, add the triplet <protocol type,
>           sender protocol address, sender hardware address> to
>           the translation table.
>       ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
>       Yes:
>         Swap hardware and protocol fields, putting the local
>             hardware and protocol addresses in the sender fields.
>         Set the ar$op field to ares_op$REPLY
>         Send the packet to the (new) target hardware address on
>             the same hardware on which the request was received.
>
> If I understand correctly, this means that any receiving host would log the hardware/protocol mapping into their 
> translation table before even checking whether the packet is a request or a reply.
>
> So I guess any attacker could indeed poison a target's cache by sending a continuous flow of dummy requests (i.e. 
> with fake sender hardware/protocol addresses).
>
> Does this make sense? Is it a thing that could happen in real life (I mean, ignoring the fact that this does not seem 
> to be a very subtle attack, hence easily detectable)? I really only have a basic understanding of layer 2 mechanisms 
> so I'd like to know if the above is plausible. Because if it is, that would be a good justification for the rule 
> (i.e. a flood of unicast requests could be used to corrupt a specific host's ARP cache).
>
>
>
> ----- Original Message -----
> From: "Kevin Le Gouguec" <kevin.le-gouguec () insa-lyon fr>
> To: snort-sigs () lists sourceforge net
> Sent: Sunday, May 18, 2014 2:36:16 PM
> Subject: Re: [Snort-sigs] Unicast ARP Request: Considered Harmful?
>
> The rule can be found in preproc_rules/preprocessor.rules:
>
> alert ( msg: "ARPSPOOF_UNICAST_ARP_REQUEST"; sid: 1; gid: 112; rev: 1; metadata: rule-type preproc ; 
> classtype:protocol-command-decode; )
>
> It can be activated by adding "preprocessor arpspoof -unicast" to snort.conf.
>
> I found some documentation on the website:
>
> http://www.snort.org/search/sid/112-1
>
> Again though, no explanation as to why a unicast ARP request is suspicious enough to deserve its own rule.
> I get that "weird though apparently harmless" behaviour should be detected, and a unicast request could be just that 
> (no reason not to broadcast a request, since either you contact the correct host directly so you already know his MAC 
> address, or you contact the wrong host and the protocol states that he should discard the request). Except it's 
> actually a legitimate feature used for cache validation. I'm ready to believe that it can be a sign of attack, but 
> not before I understand why.
>
>
>
> ----- Original Message -----
> From: "Joel Esler (jesler)" <jesler () cisco com>
> To: "Kevin Le Gouguec" <kevin.le-gouguec () insa-lyon fr>
> Cc: snort-sigs () lists sourceforge net
> Sent: Sunday, May 18, 2014 1:25:40 PM
> Subject: Re: [Snort-sigs] Unicast ARP Request: Considered Harmful?
>
> It helps us to know which rule you are talking about though. 
>
> --
> Joel Esler
> Sent from my iPhone
>
> > On May 18, 2014, at 6:36, "Kevin Le Gouguec" <kevin.le-gouguec () insa-lyon fr> wrote:
> >
> > Hi all,
> >
> > I'm playing around with Snort's downloadable rules and I found one which is easy to activate: sending a unicast ARP 
> > request. Okay, so I start injecting ARP requests, making sure the destination is not set to broadcast. And sure 
> > enough, Snort picks it up. Great, let's move on and do more complex stuff.
> >
> > Though, I'm not sure I understand why this rule exists at all. From what I've read most ARP spoofing/cache 
> > poisonning attacks make use of ARP replies; requests do not seem to cause anyone any trouble (here[1] for example, 
> > unicast "keep-alive" requests are even said to be a problem when implementing attacks).
> >
> > I found a thread[2] where Jeff Nathan explains what the ARP preprocessor does, but not why. He points at TCP/IP 
> > Illustrated's chapter 4; I skimmed through it, but I could not find a justification for this rule.
> >
> > So why is it suspicious for an ARP request to be unicast, when apparently in a lot of implementations this is 
> > considered a feature (e.g. ARP polling in RFC 1122 provides cache validation) ? There's a book[3] on intrusion 
> > detection focusing on Snort that says "ARP requests that are sent to a Unicast address are often the sign of an 
> > attack designed to modify ARP caches". I... can't see how?
> >
> > Then again, I don't have much experience with network security so I guess I'm not thinking creatively enough.
> >
> >
> >
> > [1] http://insecure.org/sploits/arp.games.html ("What can be done", paragraph 5)
> > [2] http://sourceforge.net/p/snort/mailman/message/15537465/
> > [3] 
> > http://books.google.fr/books?id=sVqEFXjbcRoC&pg=PA162&lpg=PA162&dq=arpspoof+unicast&source=bl&ots=D3LwL4dWB8&sig=FTkey-EGTw7s5e9Uhlf4mS_fjVw&hl=en&sa=X&ei=HTl2U67xNJDR4QTt7YHYAw&ved=0CEwQ6AEwBw#v=onepage&q=arpspoof%20unicast&f=false
> >
> > ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > http://www.snort.org
> >
> >
> > Please visit http://blog.snort.org for the latest news about Snort!
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
>
> Please visit http://blog.snort.org for the latest news about Snort!
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
>
> Please visit http://blog.snort.org for the latest news about Snort!



------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!