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

Jeremy Hoel jthoel at ...11827...
Thu Sep 5 16:05:28 EDT 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: query.png
Type: image/png
Size: 113033 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130905/838fb08d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: response.png
Type: image/png
Size: 115204 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130905/838fb08d/attachment-0001.png>


More information about the Snort-users mailing list