Re: IPS, alternative solutions

• Previous message: PS R: "Re: Wishlist for IPS Products"
• Maybe in reply to: Daniel: "IPS, alternative solutions"
• Next in thread: p z: "Re: IPS, alternative solutions"
• Reply: p z: "Re: IPS, alternative solutions"
• Reply: Stuart Staniford: "RE: IPS, alternative solutions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 22 Sep 2004 23:18:02 -0400
To: Kyle Maxwell <krmaxwell@gmail.com>

WARNING: Long...

Kyle Maxwell wrote:

> (Apologies if this is a resend, Gmail crapped out briefly and it
> appeared to not go thru)
>
> On Fri, 17 Sep 2004 17:11:38 -0400, Jason <security@brvenik.com> wrote:
>
>>Cure, Samuel J wrote:
>>
>>>I do agree however with the resource requirements necessary for testing and
>>>rolling out each patch or hotfix.
>
>
>>I think we can all agree that IPS is no replacement for Patch
>>Management. My point is that there is no demonstrable ROI that I have
>>seen for IPS yet there appears to be a perception that it is a more cost
>>effective way of dealing with the problem. This is likely a result of
>>the parroting by some IPS vendors of a virtual patching concept. I am
>>open to the case if it can be shown, this is why I asked anyone to
>>provide an actual ROI.
>
>
> Actually, I think what Samuel posted is the ROI: with shorter cycle
> times between vulnerability disclosure to patch availability to
> attacks (including worms), having IPS helps you protect servers during
> that period between signature availability (hopefully very close to
> vulnerability disclosure) and patch rollout. Not that I advocate
> quarterly updates, but organizations do need some time to test the
> patch and roll it out. That can range from a few days to a few weeks
> (if problems arise) and reducing your exposure, even if it's not
> totally eliminated, is valuable.
>

I say lets take the challenge.

Today there is a patch available for the Microsoft GDI+ vulnerability.
We can be certain that people are actively exploiting it and I think it
is a safe assumption that some people are actively attempting to
weaponize it. I have only done minimal research on the issue but believe
the problem is painfully obvious.

A brief summary of the vulnerability from cert

http://www.us-cert.gov/cas/alerts/SA04-258A.html

--- snip ---
Microsoft Windows Graphics Device Interface (GDI+) is used to display
information on screens and printers, including JPEG image files. An
attacker could execute arbitrary code on a vulnerable system if the user
opens a malicious JPEG file via applications such as a web browser,
email program, internet chat program, or via email attachment. Any
application that uses GDI+ to process JPEG image files is vulnerable to
this type of attack. This vulnerability also affects products from
companies other than Microsoft.
--- snip ---

The JPEG format is interesting because it can be an embedded byte stream
just about anywhere. In every case that a JPEG is embedded the GDI can
be invoked to render it.

Some easy reading about it can be had here

http://netghost.narod.ru/gff/graphics/summary/jfif.htm

Don't forget TIFF.

http://netghost.narod.ru/gff/graphics/summary/tiff.htm

What we have are the following network attack vectors which come to mind
with little thought.

- A web page as a regular JPEG.
- A web page as a gz compressed JPEG.
- A regular MIME encoded JPEG.
- A gz compressed mime encoded JPEG.
- A zip compressed mime encoded JPEG.
- A TIFF with an embedded JPEG byte stream.
- A gz compressed TIFF...
- linked to over smb
- linked to over ftp
- attached in an IM
- Copied to a fileserver
- Embedded in Word sent as a MIME encoded mail
- Embedded in Excel as a MIME encoded mail
- Embedded in Powerpoint as a MIME encoded mail
- Embedded in Visio as a MIME encoded mail
- Embedded in chm as a MIME encoded mail
- Embedded in scr as a MIME encoded mail
- Embedded in bmp as a MIME encoded mail
- Embedded in pdf as a MIME encoded mail
- zip all of those
- incorrect mime types provided on download

And the list goes on forever.

So we have an IPS, it might be able to detect a standard JPEG download
over HTTP what about FTP, gzip compressed over http, SMB, AIM, TIFF, PDF...

How do you determine the attack vector and protect against exploitation?
   You can take an educated guess at best but there are still plenty of
available attack vectors with arbitrary encoding that are deployed all
over the world.

Can the IPS hope to understand all of the protocols and formats that a
JPEG could be contained in? Will you depend in the IPS to protect you?
What if it is copied over to a fileserver or webserver using SMB such
that the FF FE 00 0[0|1] is split among 2 packet boundaries? How
confident are you that a comment is the only field that will cause the
code to walk the vulnerable execution path?

Worms are now capable of infecting the global vulnerable population in
15 minutes. Will you bet a penny that any IPS will protect you at the
onset of an attack? Two days into it? Which detection method will it
use? Will the worm use that same method? What will be the false positive
rate for that method? A signature of FF FE 00 00 is sure to have a high
false positive rate.

Will you bet 2 pennies that any IPS will release protection from the
worm within 15 minutes of a launch? What if the worm generates a random
JPEG each time it attacks? There is over 2500 bytes of space available
for code execution, do you think that is insufficient to make a stand
alone worm?

Granted it is a heap issue and more difficult to exploit reliably but
there is cause to believe that it will be done. Just the population of
IE, MSN, or Outlook is ripe for the taking by anyone that can do it.
Even limiting the attack vectors to just those three items I do not
think an IPS is capable of providing coverage in the common plausible
cases. One link to a large jpeg served as a highly gzip compressed image
from a moderately used web site and the game is over.

These examples are intended to drive home the point. In all likelyhood
only one attack vector will be used for a worm and it will be a simple
one. The question is which simple one will it be and will you have
coverage? The unfortunate problem is that these examples are far too
common. If you have the budget and have completed all of the monitoring
and asset management steps I can see where it would be nice to have. I
seriously doubt having it will actually prevent anything if you have all
the other components in place.

If you play the odds you might be able to defer an investment in the
appropriate technologies long enough to make a quarter or two for the
investors by having an IPS but the cost of failure can be significantly
more expensive in hard cash and lost productivity. If the IPS fails one
time and an attack gets through the ROI is gone. Is anyone willing to
bet that the IPS will protect them from a weaponized worm that attacks
the GDI vulnerability?

I am willing to bet that not a single knowledgeable person will defer
patching of this vulnerability because they have or if they had an IPS.
Not one of those knowledgeable people will put the job on the line and
say that they should enable blocking of the threat and can wait an extra
two weeks to roll out the patch. Not one IPS vendor employee will bet
with a single customer one paycheck that the product will protect them
if a worm happens. This is why I do not think there is a measurable ROI
when compared to directing those same resources at better approaches.
The only recourse you have here is patching, praying, and utilizing a
good Intrusion monitoring system to detect the signs of an attack.

--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
--------------------------------------------------------------------------

• Previous message: PS R: "Re: Wishlist for IPS Products"
• Maybe in reply to: Daniel: "IPS, alternative solutions"
• Next in thread: p z: "Re: IPS, alternative solutions"
• Reply: p z: "Re: IPS, alternative solutions"
• Reply: Stuart Staniford: "RE: IPS, alternative solutions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]