Is Your Web Site Under Attack?

October 26, 2009, 7:24 PM — Though none of us has time to examine our web logs in great detail -- particularly those of us who collect gigabytes of log data every month, looking for signs of web attacks can be easier than you might imagine and will at least give you an idea of what types of exploits are being attempted.

To begin with, one of the more well known attack methods that hackers use goes by the name "buffer overflows". In the case of buffer overflows, the name is very descriptive of what the hacker is attempting to do. In other words, when an application inadvertently puts more data into a buffer than it is designed to hold and process, the data overflows and the "extra" (non-processed) data can overwhelm the server or end up on the executable area of the stack where the hacker hopes it will be executed and the results returned to his browser.

One simple way to detect buffer overflow attempts is to look through your web access logs for unusually long GET requests. These may be as simple as extensive repetitions of a single character (such as GET AAAAAAAAAAAAAAAAAAAA). In any case, these requests are clearly NOT valid web requests. Here is an example:

123.45.67.89 - - [01/Jan/2009:10:25:15 -0500] "GET /\x90\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9
...
0
\x90\x90\x90\x90\x90" 414 250

The ellipsis (...) is meant to indicate that this request went on for much longer than I care to insert into this column. I've seen some requests like this with nearly 30,000 characters. The return code, 414, indicates that the server refused the request because it was too long. Good call!

If you want to look just for very long requests, you can do so with a very simple Perl script such as this. The 400 in this case indicates the length of the entire log entry, not just the GET portion; adjust this if you like.

#!/usr/bin/perl -w

$log="/usr/local/apache/logs/access_log";

open LOG,"<$log";

while (  ) {
    $len=length($_);
    if ( $len > 400 ) {
        print $_;
        print "Length: $len\n";
    }
}

SQL injection attacks have become quite popular among the hacking crowd and might be obvious or more subtle. Here's a request with an obvious select command:

123.45.67.89 - - [20/Oct/2009:21:39:26 +0000] "GET /news/latest.html%20or%201=convert(int,
(select%20@@version+'/'+@@servername+'/'+db_name()+'/'+system_user))--sp_password HTTP/1.1"
500 4110

This next GET request, expressed largely in hex, is harder to distinguish but, if you're curious, a hex to ascii translator should bring what is being requested into clearer focus.

GET /index.html?';DECLARE%20@S%20CHAR94000);SET%20@S=CAST(0x4445434C41524520405
4207661726368617228323535292C40432076617263686172283430303029204445434C415245205
461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6
...

Going after specific files such as any .exe files, your /etc/passwd or /etc/shadow files or even your server's .htpasswd and .htaccess files in an obvious attempt to get at restricted information. These can also be selected as you scan your logs.

Any use of "../.." strings to reach beyond the confines of your document root
such as "../../etc/passwd" should be recognized as a hacking attempt as would be any use of backticks (``) to run commands or use of explicit commands such as ls or cat which will likely look like "ls%20-al" or "cat%20/etc/passwd" since any blank (space) is encoded in a URL as "%20".

Unusual characters such as pipes, semicolons, exclamation points, redirects (such as > and >>)and use of <? (possible php insertion) should also be considered suspect.

Here's a simple script that looks for evidence of hacking and writes suspects log entries to a separate file for your perusal. Notice that, in this script, we break out the fields in the access log and examine the requested URL specifically.

#!/usr/bin/perl

# -------------------
$log=$ARGV[0];
$suspect="$log-suspect";
open LOG,"<$log";
open SUSP,">$suspect";
$counter=0;

sub suspect {
    print SUSP "$_";
    $counter++;
}

# -------------------
while (  ) {
  # parse log record
  my($host,$id,$user,$date,$request,$URL,$status,$bytes)=/^(\S+) (\S+) (\S+) \[([^]]+)\] "(\w+) (\S+).*" (\d+) (\S+)/;

# ------------------------------
# copy request to suspect log if looks like hacking
# ------------------------------
    $len=length($URL);
    if ( $len >= 300 ) {
        suspect;
        next;
    }
    if ( $URL =~ /\.\.\//  || $URL =~ /`/ ) {
        suspect;
        next;
    }
    if ( $URL =~ /EXEC/i ) {
        suspect;
        next;
    }
    if ( $URL =~ /SELECT/i || $URL =~ /DECLARE/ ) {
        suspect;
        next;
    }
    if ( $URL =~ /PASSWD/i || $URL =~ /shadow/ ) {
        suspect;
        next;
    }
    if ( $URL =~ />/ || $URL =~ /|/ || $URL =~ "%20" ) {
        suspect;
        next;
    }

print NEW $_;
}
print "$counter suspect requests found\n";
print "new log is $suspect\n";

If you haven't been in the habit of combing through your web logs for signs of hacking attempts, you might find the output of simple scripts such as this to be quite interesting. Of course, what you ultimately want to know is whether any attacks have been successful. Your web site history (have you suffered outages?) and the return codes in your log files (maybe redirecting to an error page or indicating "file not found"?) will provide information on how your web site is reacting to the hacking attempts that you extract from your logs.