Dave Aitel
25/03/03, 23:20
Actually option 2) is not any better in this particular case, since you
are unable, as far as I can tell, to find a way to return into any
..text segments with call ebx or ecx (which contain pointers to your
shellcode in unicode form). This is not the only unicode exploit though,
so you'll have a chance to use the encoder sometime soon, I'm sure.
I'm not having the same problem you are with characters > 0x7f though.
Did you use the % character in your shellcode?
Dave Aitel
VP of Research and Development
Immunity, Inc.
http://www.immunitysec.com/CANVAS/ "Hacking like it is in the movies."
* We have two alternatives:
*
* 1) The easy one: find any occurrences of our ascii string (i.e.
before it gets converted to
* the Unicode form) in process memory. Problem: normally we should
find it by debugging the
* vulnerable application and then hardcode the found address (which
will be the RET address)
* in our exploit code. This RET address is variable, even for the
same version of OS and app
* (I mean, different instances of the same application in the same
machine could make the
* guessed RET address invalid at different moments). Now add the
restriction of RET value
* padded with null-bytes. Anyway, the main advantage of this method
is that we will not have
* to deal with 0x00-padded shellcode.
*
* 2) The not so-easy one: you could insert an encoded shellcode in such
a way that when the app
* expands the ascii string (with the encoded shellcode) to Unicode,
a valid shellcode is
* automagically placed into memory. Please, refer to Chris Anley's
"venetian exploit" paper
* to read more about this. Dave Aitel also has a good paper about
this technique and indeed
* he released code written in Python to encode shellcode (I'm
wondering if he will release a
* working tool for that purpose, since the actual code was released
as part of a commercial
* product, so it cannot be run without buying the whole product,
despite the module itself
* being free!). Problem: it is not so easy as the first method ;-)
Advantage: when the over-
* flow happens, some registers may point to our Unicoded string
(where our Unicoded-shellcode
* lives in), so we don't need to guess the address where shellcode
will be placed and the
* chance of a successful exploitation is greatly improved. For
instance, in this case, when
* IIS is overflowed, ECX register points to the Unicode string. The
idea is then fill in
* RET value with the fixed address of code like "call %ecx". This
code may be contained in
* any previosly-loaded library, for example).
*
On Tue, 25 Mar 2003 19:25:48 +0100
Roman Medina <roman@rs-labs.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I wrote another exploit for the nt.dll bug some days ago.
> Explanation and a little documentation is included in the source
> file. It compiles in Linux/gcc without any error.
>
> http://www.rs-labs.com/exploitsntools/rs_iis.c
> [19.5 kbytes]
>
> Regards,
> --Roman
>
> - --
> PGP Fingerprint:
> 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
> [Key ID: 0xEAD56742. Available at KeyServ]
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPoB8TOR/in3q1WdCEQLvqgCeLnYnMNDRQggwSn3hEe5YKKPLPl8AnR6K
> YV1r+FKjoQmG+nPN0BsRv6jn
> =Td4v
> -----END PGP SIGNATURE-----
>
>
are unable, as far as I can tell, to find a way to return into any
..text segments with call ebx or ecx (which contain pointers to your
shellcode in unicode form). This is not the only unicode exploit though,
so you'll have a chance to use the encoder sometime soon, I'm sure.
I'm not having the same problem you are with characters > 0x7f though.
Did you use the % character in your shellcode?
Dave Aitel
VP of Research and Development
Immunity, Inc.
http://www.immunitysec.com/CANVAS/ "Hacking like it is in the movies."
* We have two alternatives:
*
* 1) The easy one: find any occurrences of our ascii string (i.e.
before it gets converted to
* the Unicode form) in process memory. Problem: normally we should
find it by debugging the
* vulnerable application and then hardcode the found address (which
will be the RET address)
* in our exploit code. This RET address is variable, even for the
same version of OS and app
* (I mean, different instances of the same application in the same
machine could make the
* guessed RET address invalid at different moments). Now add the
restriction of RET value
* padded with null-bytes. Anyway, the main advantage of this method
is that we will not have
* to deal with 0x00-padded shellcode.
*
* 2) The not so-easy one: you could insert an encoded shellcode in such
a way that when the app
* expands the ascii string (with the encoded shellcode) to Unicode,
a valid shellcode is
* automagically placed into memory. Please, refer to Chris Anley's
"venetian exploit" paper
* to read more about this. Dave Aitel also has a good paper about
this technique and indeed
* he released code written in Python to encode shellcode (I'm
wondering if he will release a
* working tool for that purpose, since the actual code was released
as part of a commercial
* product, so it cannot be run without buying the whole product,
despite the module itself
* being free!). Problem: it is not so easy as the first method ;-)
Advantage: when the over-
* flow happens, some registers may point to our Unicoded string
(where our Unicoded-shellcode
* lives in), so we don't need to guess the address where shellcode
will be placed and the
* chance of a successful exploitation is greatly improved. For
instance, in this case, when
* IIS is overflowed, ECX register points to the Unicode string. The
idea is then fill in
* RET value with the fixed address of code like "call %ecx". This
code may be contained in
* any previosly-loaded library, for example).
*
On Tue, 25 Mar 2003 19:25:48 +0100
Roman Medina <roman@rs-labs.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I wrote another exploit for the nt.dll bug some days ago.
> Explanation and a little documentation is included in the source
> file. It compiles in Linux/gcc without any error.
>
> http://www.rs-labs.com/exploitsntools/rs_iis.c
> [19.5 kbytes]
>
> Regards,
> --Roman
>
> - --
> PGP Fingerprint:
> 09BB EFCD 21ED 4E79 25FB 29E1 E47F 8A7D EAD5 6742
> [Key ID: 0xEAD56742. Available at KeyServ]
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPoB8TOR/in3q1WdCEQLvqgCeLnYnMNDRQggwSn3hEe5YKKPLPl8AnR6K
> YV1r+FKjoQmG+nPN0BsRv6jn
> =Td4v
> -----END PGP SIGNATURE-----
>
>