Source Disclosure vulnerability in Joomla – the dreaded single quote

We have started receiving reports from Joomla users that our ScanMyServer service is picking up an unknown and undocumented vulnerability on their web site.

The scanner is showing that they have one or more source disclosure/path disclosure vulnerabilities. Since they were using the latest and most up to date version of Joomla their reports looked odd and we started to investigate the matter.

We found out that the vulnerability is “hard” to trigger, as Firefox and Internet Explorer will escape the single quote in a URL to its encoded form, while Chrome will not. So while sending it under Chrome will show something like:
Fatal error: Uncaught exception 'InvalidArgumentException' with message 'Invalid URI detected.' in /home/content/41/9236541/html/libraries/joomla/environment/uri.php:194 Stack trace: #0 /home/content/41/9236541/html/libraries/joomla/application/application.php(248): JURI::getInstance() #1 /home/content/41/9236541/html/includes/application.php(135): JApplication->route() #2 /home/content/41/9236541/html/index.php(36): JSite->route() #3 {main} thrown in /home/content/41/9236541/html/libraries/joomla/environment/uri.php on line 194

The same URL under Firefox and Internet Explorer, will return:
404 - Article not found

Of course, the vulnerability is not in Chrome, but is a real issue caused by Joomla not properly escaping the URL.

The problem has been already spotted in a different section of Joomla, the search option, as can be seen by this post:

So the problem isn’t just in the search, it also spans to other sections of the Joomla framework.

We will keep you posted when a fix is provided, or we have a workaround for this issue.

Someone always checks up on you

I would like to start by thanking Smit Bharatkumar Shah from for bringing to our attention that our site has a potential security vulnerability that could be used by malicious attackers to preform phishing and/or clickjacking attacks. With his help we were able to prevent this attack from occurring. No customers have been affected by this issue.

Our service has been providing security scan reports and vulnerability information for sites from all over the world; but we did however neglect to do one small thing, which is scan our web site with the same service. If we had, would have shown us of the potential issue. How embarrassing is that?!

We have checked our logs for any sign that the vulnerability has been exploited or our customers have been misused but nothing came out. Due to the nature of this issue, any attack would have been recorded in the logs.

The solution for the above mentioned vulnerability is a simple two step fix:
1) Run:
a2enmod headers

2) Add to /etc/apache2/conf.d/security the following line:
Header always append X-Frame-Options SAMEORIGIN

If any of you finds any other issues in our site, please contact us at and we will be happy to credit you with the find. Thanks for making our service better!

Why PS3 Encryption Key Leak is not an End Game

A lot of people a speculating that since the PS3 LV0 encryption key has leaked, that all bets are off and piracy for the PS3 is now a fact and there is nothing Sony can do to resolve. They further claim, even if Sony releases a patch, with the availability of this LV0 encryption key, hackers would just need to decrypt the update and snatch from it the new LV0 keys if those are updated using a patch.

This reminds me of a story about a Satellite Broadcaster a few years ago that has lost similar encryption keys that were part of its update mechanism for enabling/disabling your subscription card. Once you had this encryption key you could enable your card without needing to pay anything to the broadcaster.

When this news got out, it seemed to be an obvious bet that the company would go bankrupt in a few months as piracy would ruin them.

But the broadcaster didn’t lose hope and devised a plan that was quite ingenuous. They knew that updating the encryption key in one “bang” would be blunt and very easy to track down. So instead, over the course of a year they sent “junk” data as part of their updates, gradually sending out more and more chunks of indecipherable data. Then one day, they “executed” this “junk” data, and voila! the “junk” wasn’t junk at all. It was self decrypting pieces of code.

There were two very clever parts to their plan. First, they data they sent just hid there until it got executed. In fact, only in retrospect it was noticed that there was even “junk” data there. The second part was that it was not executable on anywhere but on their specific platform. You couldn’t decrypt that data as it used inherit functionality of the hardware on which it ran – you couldn’t easily disassemble it without knowing some of the secret ASM code that ran on their hardware.

The moral of this story  is, even when all is lost, as long as your true customers are updating, and your thieves need to upgrade too in order to enjoy the full benefits of the system, you can always regain control over you hardware – in essence having “code execution” on your system allows you full control over it, even if someone else is watching and tracking what you are doing – it is just a tad harder to do so in a way that will mask from guy who controls the system what you are doing.

Windows Device Driver Fuzzing

We recently received a request to adapt the beSTORM  fuzzing framework to fuzz a series of Windows Device Drivers. It appears that there is little documentation and practically no commercial tools to provide proper fuzzing for Windows Drivers.

Adding support for device driver fuzzing required us to add a few function to our already existing File Utils library. This library allows you to create and read files with the intent of using the information inside these files to either fuzz something else, or provide a file to a piece of software that you intend to test.

With a device driver you basically do the same, but instead of opening an ordinary file, you open a device driver – usually in the form of “\\.\AAA”. The AAA is replaced by a string that tells the Windows operating system what device he should open. To provide this function inside beSTORM we introduced the Win32CreateFile wrapper function which receives the device driver’s name. This function returns a HANDLE that is then fed to the Win32CloseHandle wrapper function to close the opened handle.

The next step in fuzzing a Windows Device Driver is to send it information and in some cases read from it information. This is done through our Win32DeviceIoControl wrapper function, which receives the HANDLE from Win32CreateFile, and is passed an InBuffer as well as a IoControlCode value. Most commonly this value will be generated through the CTL_CODE macro under Visual Studio, and since it is usually very difficult to calculate this value by “hand” we provide a wrapper function called Win32CtlCode to allow you to do this inside the module you create.

Here is a complete “block” that utilizes all these wrapper functions and exploits a vulnerability in DVWDDriver – which was built with vulnerabilities inside it as an educational tool.

<SC Name="Sequence">
<SP Name="Win32CreateFile" Procedure="Win32CreateFile" Library="File Utils.dll">
<S Name="Filename">
<EV Name="Filename value" ASCIIValue="\\.\DVWD" Description="CreateFile Filename" />
<S Name="DesiredAccess">
<C Name="DesiredAccess value" Value="C0 00 00 00" />
<S Name="ShareMode">
<C Name="ShareMode value" Value="00 00 00 07" />
<S Name="CreationDisposition">
<C Name="CreationDisposition value" Value="00 00 00 03" />
<SP Name="Win32DeviceIoControl" Procedure="Win32DeviceIoControl" Library="File Utils.dll">
<S Name="HANDLE">
<PC Name="HANDLE" ConditionedName="Win32CreateFile" Parameter="HANDLE"/>
<S Name="InBuffer">
<B Name="InBuffer value" />
<SP Name="IoControlCode" Procedure="Win32CtlCode" Library="File Utils.dll">
<S Name="DeviceType">
<C Name="DeviceType value" Value="00000022" Comment="FILE_DEVICE_UNKNOWN" />
<S Name="Function">
<C Name="Function value" Value="00 00 08 01" />
<S Name="Method">
<C Name="Method value" Value="00 00 00 03" Comment="METHOD_NEITHER" />
<S Name="Access">
<C Name="Access value" Value="00 00 00 03" Comment="FILE_READ_DATA | FILE_WRITE_DATA" />
<SP Name="Win32CloseHandle" Procedure="Win32CloseHandle" Library="File Utils.dll">
<S Name="HANDLE">
<PC Name="HANDLE" ConditionedName="Win32CreateFile" Parameter="HANDLE"/>