[Snort-users] Question about SO Rule 3:21355

Jeremy Hoel jthoel at ...11827...
Fri Sep 6 15:39:55 EDT 2013


Joel, would you like me to send you a small pcap that shows this
problem happening?  It seems to be a FP, but if it's a known problem,
then maybe we'll disable this.

Thanks

On Thu, Sep 5, 2013 at 8:05 PM, Jeremy Hoel <jthoel at ...11827...> wrote:
> Ok.. so looking at the source and your email, we're talking about the
> transaction id being different between the query and the response.
> Well, then we have another odd issue, because in these cases, it's the
> same.
>
> When we have the full pcap (a few minutes before and after) , we can
> trigger the following alerts:
>
> 09/05-15:28:49.843677  [**] [3:21355:2] BAD-TRAFFIC potential dns
> cache poisoning attempt - mismatched txid [**] [Classification:
> Attempted Information Leak] [Priority: 2] {UDP} 170.149.173.133:53 ->
> xxx.yyy.152.55:51813
> 09/05-15:28:50.851973  [**] [3:21355:2] BAD-TRAFFIC potential dns
> cache poisoning attempt - mismatched txid [**] [Classification:
> Attempted Information Leak] [Priority: 2] {UDP} 170.149.173.133:53 ->
> xxx.yyy.152.55:51397
> 09/05-15:29:02.068531  [**] [3:21355:2] BAD-TRAFFIC potential dns
> cache poisoning attempt - mismatched txid [**] [Classification:
> Attempted Information Leak] [Priority: 2] {UDP} 170.149.172.100:53 ->
> xxx.yyy.152.55:52716
>
> and when we filter the pcap to just show these 6 sessions (3 request,
> 3 response) the rule doesn't fire (so yeah, that's odd).  And of
> course, with the same txid, it shouldn't fire at all.
>
> I've attached screenshots showing the query and response info from wireshark.
>
>
>
>
> On Thu, Sep 5, 2013 at 3:42 PM, Joel Esler <jesler at ...1935...> wrote:
>> Jeremy,
>>
>> We'll make sure the information is also put into documentation form for the SID.
>>
>> On Thu, Sep 5, 2013 at 11:02 AM, Jeremy Hoel <jthoel at ...11827...> wrote:
>>> Patrick, thank you for the reminder.. we have source! I keep
>>> forgetting to go there and look for answers. Thanks for the quick
>>> response and overview. Mental note to self..
>>>
>>> So, to provide more information:
>>>
>>> 1 - Before yesterday, we had never gotten this alert before, ever.
>>> 2 - As of this morning we have about 120 alerts for this signature
>>> (1:21355). At first it was just 5 DC's that had been providing DNS at
>>> some offices (out of 40+). It was limited to just NYT domains. This
>>> morning we see more events from some other domains and one more site.
>>> 3 - We (as far as I get from the operation Team) hadn't changed our
>>> DNS settings.  Our DC's send requests up to 4 central DC's and those 4
>>> do caching and send new requests out to a parent domain that should
>>> provide the info. What we are seeing is that for the NYT domains, the
>>> 4 local DC"s gave server failure errors and then the originating DC
>>> made the DNS request directly to NYTs for the answer.  We still are
>>> trying to figure out how the DC got the IP for the NYT server, since
>>> it isn't supposed to be doing root lookup or have root hints.
>>> 4 - Oddly enough, after the DNS request came back, for the next two
>>> hours, no one sent any traffic to the returned IP address.  So if a
>>> client was asking to go to www.nyt, after it got the answer, it never
>>> went.  I need to see about these new domains today to see if that
>>> still holds true.
>>> 5 - If we where under attack, the source of the replies should be
>>> different from the requested domain right? I mean, in this case, the
>>> IP of the reply was from the NYT block of IP space, and the new alerts
>>> this morning are from different IPs and my guess is they will be from
>>> the requested domains.
>>> 6 - I asked my ops people to make sure the servers are patched and
>>> while they think it is, they are going to get back to me.
>>>
>>> On Thu, Sep 5, 2013 at 1:23 PM, Patrick Mullen <pmullen at ...1935...> wrote:
>>>> Jeremy,
>>>>
>>>> Thank you for your query.  Before I begin, I would like to remind
>>>> everyone that the purpose of Shared Object Rules is to provide the
>>>> ability to write rules in C, not to obfuscate detection.  At this
>>>> point, most SO Rules are open source.  The source for this particular
>>>> rule is in bad-traffic_dns-spoof-mismatched-txid.c and as it happens
>>>> that file has several paragraphs at the beginning explaining what it
>>>> does at length.
>>>>
>>>> In short, the rule (pair of rules, technically) looks for a DNS reply
>>>> where the TXID is different than the query(ies) we have on record.
>>>> This is why you see the alert on the reply, not the query.  All of
>>>> this is explained more fully in the comment at the top of the source
>>>> as well as a known potential for FPs.  But that being said, the rules
>>>> have a pretty good tolerance for FPs.
>>>>
>>>> Your email says nothing about how many alerts you've been getting or
>>>> if this is a new thing.  If you are getting a lot of alerts, are you
>>>> sure you're not under attack?  Did you recently change your internal
>>>> dns server to not cache?  Are your users just suddenly all going to
>>>> NYTimes.com at the same time due to recent developments around the
>>>> world?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> ~Patrick
>>>>
>>>> On Wed, Sep 4, 2013 at 6:46 PM, Jeremy Hoel <jthoel at ...11827...> wrote:
>>>>> We started seeing this today from some of our DC's when doing lookups
>>>>> to various nytimes.com sites  The MS Bulletin references issues with
>>>>> Exchange and SMTP and the CVE references the DNS lookup in the
>>>>> smtpsvc.dll in regards to dns caching poisoning.
>>>>>
>>>>> We are only seeing these for responses from the NYT DNS servers, which
>>>>> is also odd, not the original request going outboung which makes me
>>>>> wonder how/what in  the response would trigger this?
>>>>>
>>>>> And finally.. if the servers are patched with MS10-024, then the could
>>>>> something else be causing the FP?
>>>>>
>>>>> Being a SO rule, I don't have much to go on.
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>>>> Discover the easy way to master current and previous Microsoft technologies
>>>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Snort-users mailing list
>>>>> Snort-users at lists.sourceforge.net
>>>>> Go to this URL to change user options or unsubscribe:
>>>>> https://lists.sourceforge.net/lists/listinfo/snort-users
>>>>> Snort-users list archive:
>>>>> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>>>>>
>>>>> Please visit http://blog.snort.org to stay current on all the latest Snort news!
>>>>
>>>>
>>>>
>>>> --
>>>> Patrick Mullen
>>>> Response Research Manager
>>>> Sourcefire VRT
>>>
>>> ------------------------------------------------------------------------------
>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>> Discover the easy way to master current and previous Microsoft technologies
>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Snort-users mailing list
>>> Snort-users at lists.sourceforge.net
>>> Go to this URL to change user options or unsubscribe:
>>> https://lists.sourceforge.net/lists/listinfo/snort-users
>>> Snort-users list archive:
>>> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
>>>
>>> Please visit http://blog.snort.org to stay current on all the latest Snort news!
>>
>>
>>
>> --
>> Joel Esler
>> Senior Research Engineer, VRT
>> OpenSource Community Manager
>> Sourcefire




More information about the Snort-users mailing list