[Snort-sigs] Unicast ARP Request: Considered Harmful?

Patrick Mullen pmullen at ...435...
Mon May 19 12:44:11 EDT 2014


Kevin,

You bring up very interesting points.  Without getting into technical
details, can we go with your answer of (paraphrasing) "why does anyone
care about this detection?"  This was written a very long time ago and
the threat landscape has changed.  My original claim to fame was the
first snort portscan preprocessor, written in 1999 but I'll be the
first to say nobody cares about portscans anymore.  :)

I don't mean to squash an interesting, technical discussion, but to
answer your question of why it exists I can't say much more than over
a decade ago someone thought it would be cool to write and since then
attack techniques have changed and many threats have completely
reversed direction.  A great example is back in 2004 we trusted Web
servers and spent our time blocking attackers against them.  We still
do that, of course, but these days more detection is centered around
blocking malicious content coming FROM Web servers than the other way
around.

If you have further questions, I'd be more than happy to help out
where I can, but generally speaking I wouldn't enable ARP spoof
detection and wouldn't worry about it.


Thanks,

~Patrick

On Sun, May 18, 2014 at 5:33 PM, Kevin Le Gouguec
<kevin.le-gouguec at ...3902...> wrote:
> My point exactly! So what's the purpose of this rule since there's so many legitimate uses for unicast ARP?
>
> And the attack scenario I just described does not even necessitate unicast ARP. Looking again at the algorithm, the host only updates his translation table if a) the pair "IP address/MAC address" is already in his table or b) his IP is the one specified. So you can run the "attack" I described with broadcast requests, which means this rule about unicast ARP requests does not protect against that.
>
> So I still don't understand the purpose of this rule :/
>
> (I suppose this is somewhat insolent but I tried asking Jeff Nathan about this rule since he seems to have written it. Neither jeff at ...95... nor jeff at ...3903... work...)
>
>
>
> ----- Original Message -----
> From: "Jeff Kell" <jeff-kell at ...922...>
> To: "Kevin Le Gouguec" <kevin.le-gouguec at ...3902...>, snort-sigs at ...2723...urceforge.net
> Sent: Sunday, May 18, 2014 11:20:58 PM
> Subject: Re: [Snort-sigs] Unicast ARP Request: Considered Harmful?
>
> 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 at ...3902...>
>> To: snort-sigs at 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 at ...3865...>
>> To: "Kevin Le Gouguec" <kevin.le-gouguec at ...3902...>
>> Cc: snort-sigs at 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 at ...3904.....> 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 at 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 at 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 at 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 at 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!



-- 
Patrick Mullen
Response Research Manager
Sourcefire VRT




More information about the Snort-sigs mailing list