RE: Evading inline security devices? (was: Evading IDS?)

• Previous message: Reava, Jeffrey: "RE: Email Pen-testing"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 23 Mar 2004 16:37:24 -0500
To: <pen-test@securityfocus.com>

Hey Mark! Interesting to hear about the Host-based quandary (from your
perspective anyways!). Definitely worth kudos to the customer in your
report, especially since a lot of places focus so heavily on
network-based (more specifically, edge-based) pro/detection and neglect
end stations.

Anyways, I received a few questions off-list about my reasonings, and I
didn't get a chance to answer yet. Figured now would be a good time kill
a couple of birds with one stone. (Heck, as a post-note, it's already
taken about 8 hours to get this email completed. I suppose being
long-winded doesn't help either.)

So, it doesn't take rocket science to figure we're going to start
running into the problem of being automatically black-listed more
frequently with the greater acceptance of automated network-based
reaction technologies. You pretty much have two main ways of avoiding
being audited (and therefore blocked) through traffic modification...
One would be protocol manipulation (at any layer of the stack, a la
fragroute, etc.), and the other would be just changing the exploit.
(Sure they all use fanciful marketing tricks, but don't think they're
not keying off "signatures" observed in exploits either. :) That's a
*much* longer discussion, and one I'll defer for another time.) :)

Anyways, when it comes to protocol mutilation, you see people focus on
the most common areas. Heck, both examples came up in this thread. One
is IP-layer fragmentation, and the other being http encoding. IP-layer
fragmentation, segmentation, and L3 trickery in general is something I'm
not a huge fan of. It's not a totally obsolete method yet. However, NICs
now support the ability to not bother interrupting the kernel with
packets that have glaring problems with fragmentation or checksum
errors, and even basic routers have the ability to just drop network
fragments wholesale (since these days it really is anomaly to see them
in many enterprises). So in my book, that makes it close enough to
obsolete to make me look elsewhere. A lot of the problems either have
been solved with hardware, or are being solved as we speak. (Of course,
a comprehensive test might include the results of such testing along
with your recommendations, but let's assume for now that you just want
to avoid detection lock-stock for whatever reason.)

As far as the HTTP encoding stuff is concerned, this is just as much
old-news too. How many years ago was whisker first released, and how
many new evolutions have there been in the space of http encoding-based
obfuscations? A few, but not an extensive amount. Additionally, they're
all so obvious when seen, that it's trivial to make the decision on the
security device to just not bother passing the blatantly irregular
requests in the first place, whether or not the device can properly
decode it. Just because it's legal doesn't make it normal. It actually
makes good sense too. In a lot of environments, if you don't have the
ability to audit the activity, then it shouldn't necessarily be
inherently trusted.

On top of that, http obfuscations are the one area that vendors focus so
heavily on. A vendor would be nuts to go into the marketplace without
the ability to decode all the obfuscations included in the most widely
deployed tools like whisker/nikito. Look at OSEC testing results for
proof of this. Sure, someone might have misconfigured their ID/PS so you
could get by unnoticed, but you shouldn't rely on that scenario when
there are other alternatives available.

I like the layer-4 stuff because it hasn't gotten as much attention, so
it's more likely to be successful. Combine the fact there are far more
mischievous tricks that can be played at layer-4. I mean, the firewall
vendors are still trying to get this one right - you think that content
filtering vendors suddenly figured the problem out before them and still
have the computing resources available to compensate for it?! :)

There's still a lot of room available for protocol layer attack
obfuscation tools though. Think Robert Graham's Sidestep
(http://www.robertgraham.com/tmp/sidestep.html) in the form of a proxy.
Do most products deal gracefully with Sidestep? Sure. Would they deal
the same with *any* random activity proxied through such a tool? ;)

Anyways, before this becomes a "12-hour in the making" email, I'll shut
up now. :)

-gary

PS -
Try this for probing (small requests) for *nix-based targets:
tcp_seg 4 new
tcp_chaff paws
order random
print

Jack the segment size up for actual attacks since some inline security
devices actually handle larger segments less gracefully. Probes/scans
are typically small requests, so you kind of need to keep the segment
size small to break apart your request enough.

For Windows and Solaris based hosts, use:
tcp_seg 4 old
tcp_chaff paws
order random
print

(Win/Sol reassemble differently than most *nix's.)

> Original Message From: Mark G. Spencer
>
> Hi Gary,
>
> I've been banging away on the target network and it looks like host
based
> IDS/IPS .. While getting locked out of each webserver during fragroute
> testing today, I noticed I could still telnet into routers and domain
> servers on the target network. I took your advice and have been
testing
> each fragroute method with "legitimate" traffic to make sure things
are
> put
> back together properly on the other end - so far, they do. I've tried
the
> following fragroute configs and still got blacklisted once I fired up
> Nikto:
>
> Tcp_chaff paws
>
> And
>
> Tcp_chaff paws
> Order random
>
> So I've got many more methods to go. I'm still using Nikto for my
testing.
> I haven't figured out yet how to turn the trace/track tests (where I
get
> blacklisted) off, but will get to that soon to see if getting rid of
those
> tests has any impact on the IDS/IPS behavior.
>
> Thank you, and everyone else on the list, for the great advice!
>
> Mark
>
> -----Original Message-----
> From: Golomb, Gary [mailto:GGolomb@enterasys.com]
> Sent: Thursday, March 18, 2004 7:08 PM
> To: Mark G. Spencer; pen-test@securityfocus.com
> Subject: RE: Evading IDS?
>
>
> As far as already available tools go, use fragroute with the
PAWS/wrapped
> sequencing chaffing options. Don't bother with the fragmentation
options -
> you'll probably just run into the same problem.
> This could be used together with overlapping and out-of-order segments
> with
> some lapses in timing. (The fragroute man page is well written and
covers
> all this stuff.) The only caveat is that you'll need to know how the
end
> host will handle reassembly of your packets. A good way to test is to
set
> up
> fragroute, send completely benign/normal requests though it, and see
if
> you
> get replies. In reality, you'll get limited mileage with
application-layer
> encoding against most IDSs, *especially* when it comes to http. (Not
that
> it's completely ineffective. There are just easier alternatives
available
> IMO.)
>
> -gary
>
>
>
>
------------------------------------------------------------------------

--
> -
> You're a pen tester, but is google.com still your R&D team?
> Now you can get trustworthy commercial-grade exploits and the latest
> techniques from a world-class research group.
> www.coresecurity.com/promos/sf_ept1
>
------------------------------------------------------------------------
--
> --
---------------------------------------------------------------------------
You're a pen tester, but is google.com still your R&D team?
Now you can get trustworthy commercial-grade exploits and the latest
techniques from a world-class research group.
www.coresecurity.com/promos/sf_ept1
----------------------------------------------------------------------------

• Previous message: Reava, Jeffrey: "RE: Email Pen-testing"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]