lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: 22 Jul 2003 22:12:40 -0000
From: Hugo "Vázquez" "Caramés" <overclocking_a_la_abuela@...mail.com>
To: bugtraq@...urityfocus.com
Subject: IIS 6.0 Web Admin Multiple vulnerabilities




Hi,

last week I installed Windows 2003 for the first time
(Enterprise edition and Web Server edition).
My first objective was to check the security in the IIS
6.0 and of course my target was the Web Admin interface
that comes with a lot of ASP's to play with ;-)

Some flaws were detected, the vendor has not been
contacted... many people know that we don't like M$.

In less than 2 days, one vulnerability and some flaws
had been identified.

The major problem is a Cross Site Scripting in the
parameter  "ReturnURL" that is parsed to many ASP's
without any kind of filtering. We have not searched for
more XSS, one is enougth to prove that M$ critical
products like IIS are not being pen-tested... before
release it to the public. 

You can check one of those XSS (in Web_LogSettings.asp)
by inyecting in the "ReturnURL":

ReturnURL=">&lt;script&gt;alert(document.cookie)
&lt;/script&gt;?tab1=TabsWebServer%26__SAPageKey=<session
identifier>... etc.

The exploitation of this XSS depends mainly on the
client side security, since not all the browsers have
the same behaviour... With Mozilla browser it's trivial
to exploit as it parses "Basic Auth" header between
windows...so a simple link in a HTML formated mail will
work, on I.E. you need some extra client side work.

But hei, the XSS is present, no matter how it can be
exploited!

Other flaws found are related to the way IIS Web Admin
track sessions... really, we don't understand how M$
wants to increase security... users sessions tracking
can be easily bypassed by requesting ASP's
(default.asp, tasks.asp, users.asp,...)that do not need
session ID's but provide a new one or the ID currently
in use, so the attacker can obtain valid ID's with a
fake request... amazing :-(

And if you take a look to the all the Web Admin
environment you will probably see some ugly things like
the possibility of re-setting administrator user
password without asking for the old value of the
password... you want to modify the admin password??
Yes, change it, as we said in Spain,...venga Pachi...

A more detailed explanation of some of those problems
are described at our web page (www.infohacking.com).

I can't understand how a big company as Microsoft wants
us to believe they are doing an effort on improving the
security on their products... I can promise you I do
not follow any special methodology to find those
problems...  

Is M$ paying for someone for pen-testing their
products? Notice, I talk about "pen-test", is not the
same as "security audit"... Security Analyst usually
says: "This is not a serious flaw",... while the
Pen-Tester says: "Yeah,...those litle flaws will let me
do nasty things...".

IIS 6.0 is far from being unhackable.
 
Hugo Vázquez Caramés & Toni Cortés Martínez
Infohacking Research 2003
Barcelona
Spain


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ