bugtraq - Re: WebDAV exploit: using wide character decoder scheme

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6u868vssq49cgabrvta7l3fb507upd86j7@4ax.com>
Date: Thu, 27 Mar 2003 17:17:04 +0100
From: Roman Medina <roman@...labs.com>
To: bugtraq@...urityfocus.com
Subject: Re: WebDAV exploit: using wide character decoder scheme

On Wed, 26 Mar 2003 11:14:43 -0500, you wrote:

>Unfortunately, on my US Windows 2K SP3 build (and I assume all others),
>those %u directives get translated into question marks. (0x003F in hex)
>:<
>> "%u32ac%u77e2",

 I tried the "%u trick" while coding rs_iis.c exploit and it happened
as Dave stated so I forgot the idea. I was using Spanish W2k Server +
SP2.

 Another problem with Mat's exploit is that it seems not to check well
when the exploit is successful or not. When the exploit has success
(which is impossible at least in Spanish/US Windows versions due to
the %u problem), IIS will not respond neither close the connection so
the exploit keeps waiting until the 15 secs timer expires. Then
$flagexit=1 and sendraw2 function returns "Timeout", so main program
will print "Failed to exploit: Server not crashed\n". This is wrong.
It should have printed something like "Success". It looks like a silly
issue but perhaps the people (with Japanese Windows version?) trying
the exploit never notices it was successful.

 Related to my exploit and after receiving some feedback (thanks
ppl!), I'd like to clarify:
1) The offset between the start of the string and the address where
RET is placed could change. What I did was to put many instances of
the RET value so chances of a right guess were higher. This cover the
cases where offset is incremented or decremented by a 2*x value.
Nevertheless, there will be one align problem if the offset changes by
(2*x+1). In that case, the least significant byte of RET becomes the
more significant one.  Fermín J. Serna <fjserna@...ec.com> pointed the
easy solution: use a RET value with the two bytes being identical. So
the recommended way to perform a brute force attack with rs_iis.c is
to try: 0x0101, 0x0202, 0x0303, ..., 0xffff (255 possible RET values).
2) I've attached a bash script which demonstrates this and makes
easier the testing of a vulnerable machine. You should adjust the
TIMEOUT variable (in seconds), so IIS is alive when the script tries a
new RET value.

 Regards,
 --Roman

--
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]

Download attachment "rs_brute.sh" of type "application/octet-stream" (397 bytes)