Re: TMG Firewall Client long host entry exploit attempt

["Randal T. Rioux" <randy () procyonlabs com>]

Top-Posting since this is a contextual comment!

Just wanted to say, Carlos, your comments make perfect sense. I've had
this problem forever (my lab looks like a "How NOT To Do Networking"
tutorial. The whole "turn off the rule" crap gets annoying (though not
as annoying as "use PP", which is not relevant to this discussion).

The rule is misinformation at best, broken by logic at worst.

Meh.


On 3/4/2014 2:51 PM, Carlos G Mendioroz wrote:
> Patrick, thanks for replying. Please see inline:
>
> Patrick Mullen @ 04/03/2014 16:18 -0300 dixit:
> > Carlos,
>
> > Both of the Shared Object Rules you mention (sids 19187 and
> > 21355) are open source.  You can download and read the source
> > from the Open Source rule pack on snort.org <http://snort.org>.
>
> Great to know, but even if I do have source reading knowledge, I
> was trying to troubleshoot what it seems a basic problem given that
> this happened in a not so special setup with default
> configuration. And I hoped that this was related to a fault in a
> setup or a bug of sorts...
>
> > Sid 21355's (mismatched TXID) source has a long description at
> > the top that explains how it works and includes some examples of
> > when it could false positive.  In a nutshell, the problem is UDP
> > is not stream-based and we have a limited amount of "stuff" we
> > keep track of for performance reasons, so a condition can arise
> > where we store the TXID for a queried domain, then store the TXID
> > for the same queried domain from another packet, stuff makes us
> > forget the first TXID when the response with that TXID is
> > received, causing the response TXID to not match the only TXID we
> > have stored (which is the one from the later request).  This
> > usually won't happen unless you have a non-caching server and
> > multiple users request the same domain at the same time.  But it
> > can happen.  I don't think the "-k none" had any effect on this,
> > but it's possible, I suppose.  This rule provides good detection,
> > but if it's causing problems I recommend you disable it since
> > that is the default state for that rule.
>
> Well, that explains why it triggers when some entity is shooting an
> A query followed by an AAAA query of the same domain. If your cache
> has size one for each domain, then it will trigger.
>
> I don't understand your last phrase though. I have not "enabled"
> the rule other than by enabling the dynamic rules as a whole. I
> don't know which entity is triggering the query either, cause I'm 
> running a bind9 server at the border, and serving all clients
> inside my network with it. But I do know that I have no special DNS
> query app.
>
> > Sid 19187 is looking for DNS responses that have excessively long
> >  (according to the vulnerable software) host entries.  This rule 
> > has known false positive issues because some hosts have very
> > long alias lists that cause this rule to alert even though it is 
> > non-malicious traffic but do keep in mind that despite no ill 
> > intent the traffic WOULD crash the vulnerable software.  This
> > rule is disabled by default because of its known issues with
> > falsing on legitimate traffic.
>
> Ok, if the size of the response is what triggers it, then that 
> explains why I see it related to ROOT NS answers. I don't know why 
> bind9 (or some other app) is asking for ROOT NS so frequently, but 
> this is an Ubuntu 12.04 with nothing that special. Also, I did
> nothing to enable this rule in particular. So I still see this as
> "on by default" in contrast to what you say. I'm sure missing 
> something that may be obvious, but not (yet?) to me.
>
>
> > My recommendation is to follow the recommended policy of
> > disabling both of these rules after ensuring your environment is
> > not susceptible to the related risks.
>
> Already done that, was trying to help by sharing a case. -Carlos
>
>
> > Thanks,
>
> > ~Patrick
>
>
>
> > On Mon, Mar 3, 2014 at 6:28 AM, Carlos G Mendioroz <tron () acm org
> >  <mailto:tron () acm org>> wrote:
>
> > Joel Esler (jesler) @ 03/03/2014 00:53 -0300 dixit:
> > > On Mar 2, 2014, at 4:05 PM, Carlos G Mendioroz <tron () acm org
> > <mailto:tron () acm org>
> > > <mailto:tron () acm org <mailto:tron () acm org>>> wrote:
>
> > > > Signed PGP part Thanks Joel, as I said, that one is like 
> > > > sweeping under the carpet, right ?
>
> > > No, any Snort instance should be tuned to its environment.
>
> > I would concurr if the rule had some known false positives (none
> >  documented) or if I was running some particular soft that could
> > be causing benign triggers, which I'm not.
>
> > That being the case, it seems a good case to troubleshoot the 
> > rule, either it or my installation has some fault.
>
> > > > Snort is surprisingly quiet too. Other than this, it seems
> > > > all the bad guys went on vacation…
>
> > > Try running with “-k none” turned on.
>
> > I will, but I fail to understand why. I'm not seeing cheksum 
> > errors. In fact, in 10 minutes I have now (after suppressing 
> > 3:19187 and adding -k none) some 3:21355:2 - mismatched txid.
>
> > Fact is, I checked one of the triggering events and the TXID was 
> > ok. (answer had same TXid as query).
>
> > -Carlos
>
>
> > > -- *Joel Esler | *Threat Intelligence Team Lead |Open Source 
> > > Manager | Vulnerability Research Team
>
>
> > > > On this one, it seems that the rule is triggering on answers
> > > > to a ROOT dns query. That one also makes me wonder why is
> > > > bind asking for that.
> > > >
> > > > -Carlos
> > > >
> > > > Joel Esler (jesler) @ 02/03/2014 17:59 -0300 dixit:
> > > > > The easiest way to deal with this one is, if you aren't 
> > > > > running the tmg firewall client, shut the rule off.
> > > > >
> > > > > -- Joel Esler Sent from my iPhone
> > > > >
> > > > > > On Mar 2, 2014, at 6:51, "Carlos G Mendioroz" 
> > > > > > <tron () acm org
> > <mailto:tron () acm org>
> > > > <mailto:tron () acm org <mailto:tron () acm org>>>
> > > > > > wrote:
> > > > > Hi, I've recently installed snort on a home border server.
> > > > >  (again, this is a complete re-install of my place 
> > > > > infrastructure :)
> > > > >
> > > > > I keep snort running, not frequently updated, just to have
> > > > >  some sense of activity. Upload alerts to dshield too.
> > > > >
> > > > > This time, snort remained way too silent. But 3:19187:2 is
> > > > >  firing with many of my server's DNS queries. (bind9 
> > > > > forwarder)
> > > > >
> > > > > I've search for clues but this seems to be an so rule and I
> > > > >  don't know how to troubleshoot this. I guess I can
> > > > > disable the rule, but that's just going to hide the issue.
> > > > > I do have a capture of one incident triggering the rule,
> > > > > not that it is difficult to reproduce (
> > > > >
> > > > > Help ? TIA,
> > > > > >
> > ------------------------------------------------------------------------------
> > > > > >
>
> >
> Flow-based real-time traffic analytics software. Cisco certified
> > > > tool.
> > > > > > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with 
> > > > > > NetFlow Analyzer Customize your own dashboards, set
> > > > > > traffic alerts and generate reports. Network behavioral
> > > > > > analysis & security monitoring. All-in-one tool.
> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > > > > >
>
> >
> _______________________________________________
> > > > > > Snort-users mailing list
> > > > > > Snort-users () lists sourceforge net
> > <mailto:Snort-users () lists sourceforge net>
> > > > <mailto:Snort-users () lists sourceforge net
> > <mailto:Snort-users () 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!
> > > >
> > > > -- Carlos G Mendioroz  <tron () acm org <mailto:tron () acm org>
> > <mailto:tron () acm org <mailto:tron () acm org>>>
> > > >
>
>
>
> > ------------------------------------------------------------------------------
>
> >
>
> Subversion Kills Productivity. Get off Subversion & Make the Move
> to
> > Perforce. With Perforce, you get hassle-free workflows. Merge
> > that actually works. Faster operations. Version large binaries. 
> > Built-in WAN optimization and the freedom to use Git, Perforce
> > or both. Make the move to Perforce. 
> > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
> >
>
> _______________________________________________
> > Snort-users mailing list Snort-users () lists sourceforge net 
> > <mailto:Snort-users () 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
>
>
> ------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to
Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually
> works. Faster operations. Version large binaries.  Built-in WAN
> optimization and the freedom to use Git, Perforce or both. Make the
> move to Perforce. 
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
> Snort-users mailing list Snort-users () 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!

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Snort-users mailing list
Snort-users () 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!