RE: IIS 4 Security
From: LordInfidel (LordInfidel@vdat.com)
Date: 12/13/02
- Previous message: Axel de Kimpe: "RE: Exchange 5.5 delivery receipts"
- Maybe in reply to: anyluser: "IIS 4 Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: LordInfidel <LordInfidel@vdat.com> To: focus-ms@securityfocus.com Date: Fri, 13 Dec 2002 16:15:41 -0500
Throwing my 2 sense in.
For this we have to define "reasonable". If reasonable is, I just want to
protect my page from joe blow
end user, then yes. If reasonable is, I want to protect my machine from joe
blow cracker/hacker, then no.
I prefer the latter.
If we all turn to page 143 in our bible " Hacking Exposed Web Applications"
Since he is using just basic auth without SSL(digest is subject to replay
attacks, ntlm is a little better depending on the version being run; but
ntlm works only with IE, but NTLM APS helps with breaking in)
It is just a simple matter of eavesdropping, getting the basic auth header.
Take the results and Using bd64.pl you have just decoded the u/p.
Now you have free reign to access the unsecured system via port 80, right
thru it's front door.
Now I can levy as many different directory traversals, htr requests and
anything else my little
heart desires.
Fooling yourself into thinking that a unpatched, unsecured webserver is
"reasonably" secure just by using password protection is a fanciful and
foolhardy thought at best.
In my definition of reasonably secure; protecting against the hacker. Just
using basic auth w/o ssl or any patches is not reasonable protection.
LordInfidel
-----Original Message-----
From: Deus, Attonbitus [mailto:Thor@HammerofGod.com]
Sent: Friday, December 13, 2002 1:50 PM
To: H D Moore; Ogle Ron (Rennes); 'anyluser@yahoo.com';
focus-ms@securityfocus.com
Cc: hsieff@orthodon.com
Subject: Re: IIS 4 Security
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 10:13 AM 12/13/2002, H D Moore wrote:
> > I disagree here... Most of the buffer overflows require accessing the
> > vulnerable .dll file, which would not be possible without
> > authentication in the example provided by the OP.
>
>Yes, but it doesn't have to be the attackers authentication used in the
>exploit. Someone really determined could simply email a HTML page to a
>logged-in user and place a background image link to a unicode URL which
>downloads and executes a command. Many people forget to set the ACL's for
>the virtual directories, so things like /iishelp and /msadc could still
>be used to exploit the system. There is no excuse for deploying a badly
>configured or unpatched IIS system these days...
Certainly no excuse for such a deployment, but I think the OP was more
interested in the theory behind authenticated-only access configurations
and what 'inherent' security such a setup would offer against 'direct'
attacks on the public system.
One could indeed try to exploit a internal client system first and use
authenticated access as in your example (assuming integrated authentication
was in use) or some other insidious methods-- I would still assert that the
OP's contention that "It is reasonably secure right up until a brute force
attack or eaves dropping yields a valid username/pass" is correct-- it is
"reasonably secure."
I found Henry's post very interesting, specifically the notion that the
request is first parsed before the ACL applied to see what object was being
called in the first place. If correct, that would support the theory that
one could exploit a component with ACL's on it before the ACL was
enforced. I just couldn't get that to work in any of my tests (which was
good!).
Any other comments about that particular theory?
AD
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1
iQA/AwUBPforyohsmyD15h5gEQIL1ACgv9slfkEUk4cGKkUHzmgMqRFBquoAn0ac
RPXfMRStdwHBckSeq3baiYMH
=9Pml
-----END PGP SIGNATURE-----
- Next message: Marc Fossi: "Users Peeved at Microsoft Security Effort"
- Previous message: Axel de Kimpe: "RE: Exchange 5.5 delivery receipts"
- Maybe in reply to: anyluser: "IIS 4 Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|