[29503] in bugtraq
Re: WebDAV exploit: using wide character decoder scheme
daemon@ATHENA.MIT.EDU (Roman Medina)
Thu Mar 27 12:47:49 2003
From: Roman Medina <roman@rs-labs.com>
To: bugtraq@securityfocus.com
Date: Thu, 27 Mar 2003 17:17:04 +0100
Message-ID: <6u868vssq49cgabrvta7l3fb507upd86j7@4ax.com>
In-Reply-To: <20030326111443.6fb287a3.dave@immunitysec.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--=_00968v00i3s6467tva5rnvohss02lg0slg.MFSBCHJLHS"
----=_00968v00i3s6467tva5rnvohss02lg0slg.MFSBCHJLHS
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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=3D1 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=EDn J. Serna <fjserna@ngsec.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]
----=_00968v00i3s6467tva5rnvohss02lg0slg.MFSBCHJLHS
Content-Type: application/octet-stream; name=rs_brute.sh
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=rs_brute.sh
IyEvYmluL2Jhc2gKIyBCcnV0ZSBmb3JjaW5nIHNjcmlwdCBmb3IgcnNfaWlzLmMgZXhwbG9pdC4g
KGMpIFJvTWFOU29GdC4gMjcvMDMvMjAwMwoKVElNRU9VVD0zMAoKaWYgWyAkIyAtbmUgMSBdIDsg
dGhlbgogIGVjaG8gIlVzYWdlOiAkMCA8aG9zdD4iCiAgZXhpdApmaQoKZm9yIGkgaW4gYHNlcSAx
IDI1NWAgOyBkbwogIGg9YHByaW50ZiAiMHglLjJ4JS4yeCIgJGkgJGlgCiAgZWNobyAtZSAiXG5U
cnlpbmcgd2l0aCBSRVQ9JGgiCiAgLi9yc19paXMgJDEgODAgMzEzMzcgJGgKICBlY2hvICJXYWl0
aW5nIGZvciAkVElNRU9VVCBzZWNvbmRzLi4uIgogIHNsZWVwICRUSU1FT1VUCmRvbmUKCmVjaG8g
IklmIHlvdSByZWFjaCB0aGlzIHBvaW50LCBleHBsb2l0YXRpb24gaGFzIGZhaWxlZCA6LSkiCg==
----=_00968v00i3s6467tva5rnvohss02lg0slg.MFSBCHJLHS--
