Local Session Poisoning in PHP Part 3: Bypassing Suhosin's Session Encryption

By default Suhosin transparently encrypts session files stored by PHP. This seems to be adequate protection against local session poisoning in a shared hosting environment. But let's take a closer look.

Local Session Poisoning in PHP Part 2: Promiscuous Session Files

FastCGI, suPHP and suExec can all ensure that a PHP script which is called from the web will execute under the user that owns it, as opposed to the user the web server is running as. This seemingly protects against session poisoning by ensuring that a malicious user no longer can open and manipulate session files owned by other users in a shared host.

The hidden pitfall is that while these protection mechanisms protect session files from unauthorized access, they can not prevent a user from authorizing others to access its session files. If all the session files are stored in a common folder it is trivial to trick a web application into loading session variables from a promiscuous session file.

Local Session Poisoning in PHP Part 1: The Basics of Exploitation and How to Secure a Server

Session poisoning is the act of manipulating sessions specific data in PHP. To add, change or remove variables stored in the super global $_SESSION array.

Local session poisoning is enabled by the fact that one web application can manipulate a variable in the $_SESSION array while another web application has no way of knowing how that variable's value came to be, and will interpret the variable according to its own logic. The $_SESSION array can then be manipulated to contain the values needed to spoof a logged in user or exploit a vulnerable function. PHP programmers put far more trust in $_SESSION variables than for example $_GET variables. The $_SESSION array is considered an internal variable, and an internal variable would never contain malicious input, would it?

Local Session Snooping in PHP

Local session snooping is not as much a security issue as a way of gathering information from an already compromised web application. Unless it is a badly configured shared host where an attacker might gather otherwise unobtainable information. It's basically about extracting all the information a web application stored in the super global $_SESSION variable.

Nevertheless, it is easy. The one thing needed is a session id (the value of the PHPSESSID cookie). If the host uses PHP's default session handler, these could easily be enumerated as in the POC further down in this post.

Local Session Hijacking in PHP

Recently I discovered that the shared hosting provider I sometimes use is susceptible to this age-old technique that everyone really should know about by now.

PHP's default session handler stores session data in files. And by default these files are placed in /tmp. In a shared enviroment session files should never be placed in a directory that can be read by a malicious local user like the world readable /tmp directory.

Encrypt.se New Feature: Key exchange

Encrypt.se is a small tool that helps anyone to easily send encrypted messages. There is no registration, no cookies, no hassle.
Read more about it in this previous post: http://ha.xxor.se/2011/07/encryptse-beta-open-for-public.html

The Key Exchange feature enables users of Encrypt.se to communicate their secret crypto key to their friends over the phone, even if someone might be listening.

phpMyAdmin 3.x Swekey RCI Exploit

Someone else submitted a working python exploit to exploit-db. It's already out there so I might as well publish my original exploit written in PHP.
2011-07-20 - Fixed some bugs in the exploit.

Download here

Encrypt.se Beta open for the public

Encrypt is a small project of mine with it's first stable beta recently opened up for public access. The goal has been to create an encryption tool for shorter messages, which is as secure as possible, yet simple to use.

Click here to visit Encrypt.se

phpMyAdmin 3.x preg_replace RCE POC

I'm flooded with requests for a POC and many doubt that these vulnerabilities are exploitable. And since this vulnerability is rather technically interesting I believe many could learn from it.

The POC uses the session manipulation vulnerability in combination with the remote code execution in preg_replace as detailed in my last blogpost. It will only confirm if the instance is exploitable or not and you need to have valid credentials to the database. Use responsibly.

Download here


Edit:As 0x6a616d6573 reminded me of, blogger removes "%00" if not carefully encoded. The code posted where messed up due to this. (The downloadable file where still fine)
Now it's fixed. I also added the "//" as suggested.

phpMyAdmin 3.x Multiple Remote Code Executions

This post details a few interesting vulnerabilities I found while relaxing and reading the sourcecode of phpMyAdmin. My original advisory can be found here.

Null Byte Injection in preg_replace()

When reviewing some PHP code, I came across a real world example of a strange and undocumented (but it's been breifly mentiond in MOPS Submission 07) feature/bug in the function preg_replace. On certain systems, preg_replace seems to be vulnerable to a null byte injection. If both the first and second argument is derived from user input this could lead to a remote code execution.

Speeding up Blind SQL Injections using Conditional Errors in MySQL

Please note that this article expects some prior knowledge of blind SQL injections.

Edit: If you want to read about this in Russisn, its been published here in 2009.
Edit2: jrm` provided me with a working implementation of this method which he coded using information from this article. His code can be read at the bottom of this article or downloaded here.
Edit3: jrm` also created python script which can be downloaded here.

Usually a syntax error in a blind SQL injection will have some sort of visible effect in the output of a web application. So what if we could conditionally generate such an error instead of relying on conditionally delaying and timing a request using functions such as BENCHMARK or SLEEP?

Comming Soon

I'll be launching this blog with it's first post in a couple of days. Stay tuned.