RE: SecureIIS - protecting IIS
From: Kurt Keys (kkeys@sddpc.org)Date: 08/30/02
- Previous message: M. Burnett: "Re: IIS and Frontpage Extensions Vulnerability."
- Maybe in reply to: M. Burnett: "RE: SecureIIS - protecting IIS"
- Next in thread: DSardina: "RE: SecureIIS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 30 Aug 2002 11:06:24 -0700 From: "Kurt Keys" <kkeys@sddpc.org> To: marc@eeye.com, focus-ms@securityfocus.com
There have been some interesting comments from some very knowledgeable persons on this topic, but I want to add my two cents anyway. We had occasion to add Win2k servers running IIS 5.0 because some of the applications we use require that configuration. We also did not want to leave our selves open to the ever growing list of vulnerabilities, so We began to look for solutions. To the point, when we did a default install of a Win2K server with IIS 5.0, and then ran a vulnerability scan with N-STEALTH Vulnerability Scanner version 3.0 by N-STALKER Inc. written by Felipe Moniz, it showed 117 vulnerabilities. After installing SecureIIS and removing 3 virtual directories the scanner showed the system as hardened.
Hope this helps.
Respectfully,
Kurt M. Keys
Information Security Specialist
San Diego Data Processing Corporation
kkeys@sddpc.org
858-581-7844
>>> "Marc Maiffret" <marc@eeye.com> 08/29/02 11:42PM >>>
| -----Original Message-----
| From: M. Burnett [mailto:mburnett@xato.net]
| Sent: Thursday, August 29, 2002 1:24 PM
| To: marc@eeye.com; focus-ms@securityfocus.com
| Subject: RE: SecureIIS - protecting IIS
|
| >However, there are times
| >when you cannot lock down a system enough without using an added
| >tool. An example would be the recent .asp ISAPI filter overflow.
| >Yes, maybe your system does not need ..asp file functionality.
| >However, the majority of systems do and there was no "proper
| >configuration" that would have protected from that attack.
| >SecureIIS did though.
|
| That is not completely true. In fact, there are no IIS issues that
| cannot either be completely eliminated or severely limited through
| server hardening procedures and best practices.
I can only but offer my humble opinion as someone whom has been apart of
researching/discovering almost every major remote IIS vulnerability that's
been published, well at least the overflows ;-).
I gave .asp ISAPI overflow (discovered by eEye) as the most recent example,
however it is NOT at all the only example.
So lets run down memory lane...
Host: memoryleak/overflow. This vulnerability was in how IIS handled Host
headers in a manner that stacked buffers until IIS would become very
unstable. Well that is how it was reported but for those that were more
inclined then they also know that this was an exploitable heap overflow when
done right. Now I personally do not know how a hardened configuration would
have stopped this?
::$DATA .asp file view source vulnerability. This vulnerability was a
fundamental flaw in how IIS/windows-api's, were handling file names ending
with ::$DATA which would give you the raw file, which was not parsed by the
.asp ISAPI, therefore supplying you with complete source to .asp files. No
config would have saved you.
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.
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.
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.
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.
| The ASP chunked encoding vulnerability Marc mentioned is the only one
| that is very difficult to prevent.. The fact that it uses POST data
| makes it even more difficult to stop (with native win2k resources).
Yah untrue statement. See above.
| The only way to actually prevent the overflow is to completely
| disable ASP.DLL or to use the AspEnableChunkedEncoding metabase
| entry, both of which may not be possible for many web sites. In fact,
| this particular vulnerability likely affected more systems that any
| other previously released vulnerability.
Ya, that was a badass flaw wasn't it? :-) hassell for president.
| 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.
| With a properly hardened system, you could give anyone IUSR or IWAM
| access and not have any problems. For example, if these accounts
| cannot write to any directories and have severe limitations on what
| they can execute, it would be very difficult to exploit a server with
| these accounts.
Really? This is also totally untrue. Once again, its trivial to perform
privilege escalation under Windows systems.... hell even the guys at
Entercept found a way once. :-o
| 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 nothing more
| than server hardening.
| I have made a chart that lists each vulnerability and its prevention:
| http://www.iissecurity.net/archive/prevention.zip
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.
<snip>
| The only feature I wish IISSecure had is the ability to block FPSE
| and/or WebDAV on a per-site or a per-client basis.
Done! SecureIIS 2.0 does have such functionality.
| Mark Burnett
| iissecurity.net
Mark, hopefully you don't take this all the wrong way... just my humble
viewpoint. Love the site and the service you provide, seriously keep it up.
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
- Previous message: M. Burnett: "Re: IIS and Frontpage Extensions Vulnerability."
- Maybe in reply to: M. Burnett: "RE: SecureIIS - protecting IIS"
- Next in thread: DSardina: "RE: SecureIIS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
