RE: SecureIIS - protecting IIS
From: shannong (shannong@texas.net)Date: 09/02/02
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "shannong" <shannong@texas.net> To: <focus-ms@securityfocus.com> Date: Mon, 2 Sep 2002 09:06:46 -0500
One thing that is being ignored when assessing these vulnerabilities and
whether or not they can be prevented through admin preparation is that
you are working from a known list. That is to say that you can protect
yourself against these exploits because others were exploited already
for you to learn about them. What if you were one of the first 10,000
people to be hit by the exploit? How would you patch/harden your server
against it before hand?
Whether you use SecureIIS or URLScan, it is analogous to an ACL on a
router. It works based on positive confirmation, and all else is
dropped. You don't need to define everything that needs to be dropped.
Instead you define what should be allowed. So when "Exploit X" comes
out tomorrow, you will already be "protected" because it wasn't allowed
in your rule set.
-S
-----Original Message-----
From: M. Burnett [mailto:mburnett@xato.net]
Sent: Friday, August 30, 2002 2:33 PM
To: focus-ms@securityfocus.com
Cc: Marc Maiffret
Subject: RE: SecureIIS - protecting IIS
>Host: memoryleak/overflow. This vulnerability was in how IIS handled
>Host headers in a manner that stacked buffers until IIS would become
<snip>
>::$DATA .asp file view source vulnerability. This vulnerability was a
>fundamental flaw in how IIS/windows-api's, were handling file
<snip>
>There also was an older IIS 4.0 chunked encoding flaw, forget the MS
>bulletin ID off hand but goto their security page and you can find it.
>This again was not something a good config would stop.
I should have qualified my statement better. I meant to only be
referring to IIS5. I consider NT4 to be UNFIXABLE and therefore
should have made that more clear. That eliminates the stuff above.
>Another .asp file view source flaw was Translate: f. This attack was
>another way to get .asp file source by using the translate f header
>etc... your configuration wouldn't have saved you here either.
Actually a good configuration would have performed very well here.
By turning off read access to script files, this vulnerability is no
longer an issue. Also, setting the hidden attribute on .asp files
works too.
If you have other specific exploits that you want to mention, throw
them out, I'd love proving my point even further.
>Then there are other things which made are not quite vulnerabilities
>but still are "bad things" such as %u encoding to perform attacks
>against IIS without any IDS systems picking up the attacks. bla bla
>bla.
Ok, but this is really an IDS issue.
>These are just a few quick ones off the top of my head. Hardened
>configurations are a GREAT start, but not the end it all, NOR is one
>good security solution. You need everything, and then still pray to
>server gods at night.
My point was that you *could* do this. By no means would I say that
you *should* do this. Perhaps the best way to approach security is
to make a server that can withstand attack on its own, then install a
product that can protect IIS on its own, then combine the two. My
focus is building ultra-hardened IIS servers, so this research was
relevant.
>| However, it only allowed | IWAM access, which can be totally
>mitigated by severely limiting that | account's permissions on the
>system. Hehe. This could be another start of a back and forth who is
>right and wrong thread but I will say it again as I have said many
>times on these mailing lists. WINDOWS NT4/2000/XP DO NOT PROVIDE USER
>PRIVILEGE SEPARATION.
>IT IS COMPLETELY TRIVIAL TO GO FROM ANY LOCAL USER TO GAIN SYSTEM.
>IWAM especially. Local windows flaws are easy and common... go check
>the microsoft security site for examples. Heck even the recently
>rediscovered "shattered" attacks are more examples.
Yes there are ways to perform privilege escalation in win2k, but most
of them require certain services (i.e., net dde, still image service,
telnet, etc.), interactive login, the ability to write to the file
system, access to cmd.exe, etc. that make it MUCH more difficult to
accomplish on a hardened server. To exploit an overflow, inject
working shell code, inject working code for privilege escalation,
etc., all done in memory since the account has no file system access,
all on a hardened server would be quite impressive. I must admit
that it could theoretically be done with enough skill, but on the
other hand, I can also think of many countermeasures. That's
probably an argument that neither of us would win. Nonetheless, it
would be quite interesting to see an exploit that pulled this off.
As a side note, many buffer overflows can be stopped with careful use
of the MaxClientRequestBuffer setting. However, because the asp
chunked encoding overflow used the POST method, this is one of the
few exploits that is very difficult to defend against. Again, the
effectiveness of this can be severely limited.
>| I have tracked every Windows 2000 and IIS (not including SMTP,
>NNTP, | etc.) vulnerability that is remotely exploitable and have found
>that | every one can be prevented or severely limited through
<snip>
>Well this clears up a lot of things. Your research above is a bit
>incomplete and misleading. However, even if it was complete and
>accurate then it still would be rather unrealistic because most
>environments, especially web servers, _REQUIRE_ some functionality, and
>that's going to be enough to get exploited.
The research is by no means incomplete, for the purposes of this
chart I simply removed anything that wasn't remotely exploitable and
anything that wasn't web services. I certainly would not make such a
bold statement without some research to back it up.
If it is misleading, it is probably because space did not permit
proper explanations. However, it is totally realistic because it
does most web functionality (asp, etc.). Again, this is an exercise
in learning how to secure IIS, not a recommendation that you should
not use other security measures.
And let me clarify one thing. I never said that such a configuration
was unhackable, but by following such measures you could certainly
produce an extremely server that may never be hacked. While there
may be a small number of hackers with the skill, time, and motivation
to exploit such a configuration, other security measures will quickly
eliminate those as well.
You also must keep in mind that this only dealt with known exploits.
There are plenty of other private exploits, plus there are some that
Microsoft discovered and never documented. I could not address
either of those.
The whole purpose here was to emphasize how effective the hardening
process really is. With such a process, you can buy yourself hours or
perhaps even days before a hotfix is installed, IDS signatures are
updated, etc.
In summary:
- You are right about NT4 being vulnerable, I should have clarified
that
- The only other exploit you specifically mentioned, translate:f,
could be stopped with hardening
- While I would love to say that privilege escalation couldn't be
done using my configuration, I must concede that it would be possible
(yet extremely difficult) with an unpatched server that has no other
protection.
Mark Burnett
iissecurity.net
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
