I searched this, but couldnīt find anything, so hereīs my post
I got some problems with this exploit; it looks really good, but iīm not sure how to use it.
It compiles with Dev-C++ after adding some libs manually (at least i think, cause the exe seems to be useless ), but really canīt figure out how to use it. Can someone else??
( I know that itīs "old" ...)
THX and Gr33tZ
poerk
CODE
/* * Apache-Slasher.c * Apache 1.3.2-1.3.24 Chunked Encoding Exploit * * Older versions of Apache (prior to 1.3.26) have a serious flaw * in a portion of code that handles HTTP post requests. The flaw * is related to a comparison of two signed integers when processing * HTTP/1.1 chunked encoding. A chunk typically has the following * form: * * <size> * <data> * * Where 'size' is in hexadecimal, so: * * 10 * 1234567890123456 * * is a valid chunk. Apache's ap_discard_request_body() API call uses * a static stack-based buffer for reading request body "blocks" of * 8190 bytes. This routine calls ap_get_client_block(), which does * not correctly account for the sign bit being enabled by a given * chunk size. That is, the comparison: * * len_to_read = (r->remaining > bufsiz ? bufsiz : r->remaining) * * does not account for the possibility that r->remaining (a value taken * from the chunk header) is negative (0x80000000-0xFFFFFFFF). * * The resulting call to ap_bread() contains a second error, in that it * ignores the sign bit when calling memcpy(), which results in a large * copy operation that exceeds the bounds of the buffer. It is somewhat * limiting, in that it restricts the attacker to the unread bytes of * the chunk header. However, these bytes can be anything, as the calls * to ap_bgetc() stop when ap_isxdigit() returns FALSE, rather than when * the first newline is received. * * Some third-party handlers call ap_discard_request_body() when handling * GET requests, as there is usually no purpose for an entity body. If * a handler returns an error, or no handler is available, the request is * handed off as a sub-request to mod_include, which calls the function. * This makes a default Apache 1.3.x install vulnerable, even if there * are no scripts offered. * * How the exploit works is fairly simple. The attack code sends a GET * request that should cause an ap_discard_request_body() call. This will * trigger a stack overflow inside ap_bread(), due to incorrect arithmatic * in ap_get_client_block(). The resulting memcpy() call that actually * causes the overflow does not return, as it attempts to copy anywhere * from 2 to 4 gigabytes of data into a stack frame that is only a few * megabytes in length. When the memcpy() call exceeds the bounds of the * stack, an access violation (exception 0xC0000005) occurs. * * You would expect the resulting SEH sequence to terminate the application, * but it does not. While Apache itself does not establish SEH frames, the * kernel32.dll library *does* for every thread when it is created. The * irritating application error dialog boxes are actually triggered from * inside this SEH frame. The corruption of this frame causes execution to * jump to an attacker-supplied payload -- the shellcode. The code is in * the HTTP headers submitted along with the request -- these are in a * heap-based buffer allocated following the I/O buffers used by Apache. * * The code used here is a simple TCP reverse shell over port 1285, which * (unfortunately) doesn't work with Windows 9x/Me. This is the only real * drawback of this code, with the exception of stringent firewalling. * Several people have claimed to have Win32-based exploits for this flaw, but * none (working) have appeared to this date. The exploitation of this flaw * in a global manner (i.e, not OS-specific) is difficult, but (as this code * demonstrates), not impossible. * * Address determination for your particular Apache should not be difficult, * as I believe that this combination of headers/return addresses will be * fairly constant, barring major differences in the CRT heap implementation. * However, there is a mode for brute-force if desired. * * As for compilation: MSVC/Win32 is guaranteed to compile and run. This * should work on other Win32 compilers, provided they include definitions * for wsock32.dll or ws2_32.dll. * * An average POSIX-compliant UNIX should be sufficient. As long as the * BSD socket interface is available, with select() and the FIONREAD * ioctl command. * * This exploit works perfectly with Windows Server 2003, even though it didn't * exist when development began. * * <Humor> * And today's quotes of the day are... * "Yo Steven! I think I found something ACCURATE in the ISS Advisory on * Apache! At least they got the part about Win32 right -- too bad it's * like 10 users, eh?" * * "Anybody here subscribed to X-Force's stuff? You wouldn't happen to * know when their next honeypot goes up yet, would you? I never got to * test out my phf exploit." * * Trick Question Trivia * * Q: How do you tell a secure box at ISS from a honeypot at ISS? * A: EASY! The former type does not exist! ISS employees are all * trained in honeypots, remember? * </Humor> * * Contact: * Matthew Murphy * E-mail: mattmurphy@kc.rr.com * AIM: NetAddict4109 * Web: http://techie.hopto.org/ * * Steven Fruchter * E-mail: steven_fruchter@hotmail.com */
#define REP_RETADDR 2045 /* How many times to repeat retaddr */ #define NOP_OPCODE 0x41 /* Opcode to use for NOP (one byte) */ #define SHELL_TIMEOUT 1 /* How many seconds to wait for reverse shell */
), but really canīt figure out how to use it.