Re: Scanning through an IPS

[Todd Haverkos <infosec () haverkos com>]

jond <x () jond com> writes:

> I'm wondering what techniques everyone else uses when you know for a
> fact you're scanning a client who has an Intrusion Prevention System.
>
> As far as determining which IPs and ports are open:
> I know with nmap you can do a SYN scan(by default) which is a little
> stealth and you can slow it down to make it a little more stealthy. Is
> there a better way?
>
> As far as determining if software on said ports is vulnerable:
> I'm assuming the only stealth way is to use netcat or telnet and
> manually grab the banner, and look up what I find?
> Something like Nessus, I'm assuming, is impossible to make stealthy?

Doing penetration testing through an IPS does add some challenges, not
all of which are good for the customer necessarily.  

It depends on their goals for the test.  And it depends on whose
definition of what "penetration testing" encompasses you care to use.

Are they trying to test their staff's response?  Are they trying to
test the effectiveness of their IPS?  Or are they trying to get the
most bang for their buck and figure out as much as possible about
things they can tigthen up?

If they care about increasing their overall defense in depth, having
at least one of your attack IP's on an exception list so you can do
some vuln scanning through it would be something to talk to the client
about.  Explain the tradeoffs to the customer and give them a choice.
If they dont' want to except one of your IP's just for the test
window, then this reduced coverage may give a customer a false sense
of security in the face of an attacker who--unlike a contracted and
rather expensive penetration tester-- isn't constrained by an X day or
X week test window.  Also, legit penetration testers seldom have
hundreds or thousands of machines in a botnet ready to leverage for
such things either.  "Are you more interested in testing your IPS, or
are you looking to maximize our ability to tell you where all the weak
points of your perimeter are within the finite time window we have for
this test?"  This is where discussions of defense in depth can help
further.  Be flexible, but do make the case to the customer that
you'll be able to give them a lot more actionable suggestions for
improving their environment if they give you one IP that sees through
the IPS.  You being able to see the difference with respect to a given
vuln or attack with and without IPS in terms of vulns can add value.

Nessus and friends... yes they're, nearly impossible to make stealthy
unless you can throttle the traffic way back and hope to get under
some threshold.  They light up most IPS like a Christmas tree. But you
might be surprised depending on the environment how much they can tell
you depending on what IPS is in use, and how loosely or tightly they
have it tuned.  If going undetected is part of the goal of the test
and important to the customer, you'll want to avoid them.

Some IPS's are rather braindead and will lock out "offending" IP's
completely.  If you notice that, it'd be worth talking to the client
about what measures they have to prevent an attacker spoofing traffic
from DOSing their network by spoofing "bad" stuff as if it's coming
from a large number of legit IP's.  What if their IPS thought DNS root
servers were attacking it, and fastidiously put those IPs all on a
block list?  Hint: client would have a real tough time doing any DNS
lookups any more.  The better IPS's will quietly drop offending
traffic regardless of source IP, and allow non-offending traffic on
through.  And alert your IPS engineer types appropriately of course.

Passive recon and google hacking can be valuable against an IPS, as
such queries don't even touch the target network.  Sometimes your best
friends in the world are web apps that support SSL.

As far as nmap and -sS -- -sS ain't stealthy these days.  All the
IPS's look for port scans, and a bunch of half open connections stand
out from a given IP just as badly as full TCP connect scans usually.
nmap's idle scanning feature (-I), however, can be a huge help for
evading IDS.  Whether you can effectively spoof packets to the target
network, however may dictate your success.  Look into idle scanning.
While on the topic of nmap, look at the NSE features of the latest
development nmap's and Fyodor's talk about them from Black Hat a
couple months ago.  This can ease some banner grabbing needs and nmap
can be throttled back enough to fly under the radar for banner
grabbing.

If you're going against network based IDS, and there's not a host
based IDS on the web server box that's decrypting the SSL connection,
it's often your ticket in via a web app vulnerability.  Web
application scanners that can be constrained to talking only over 443
and https in this situation can often be run relatively safely as
well.

Good luck!  You'll learn a lot on such engagements. 

--
Todd Haverkos, LPT MsCompE
http://haverkos.com/

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in 
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------