Re: TMG Firewall Client long host entry exploit attempt

[Carlos G Mendioroz <tron () acm org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- -- 
Carlos G Mendioroz  <tron () acm org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMWLrYACgkQ7qM4U9dTH3/fgQCgpGnbduzmShCFoRsm0GJvE9sv
Y0kAoJWX82zzhMhn4n9bRxv9RD8wDAfV
=wSAF
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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!