TYPO3-SA-2010-020, TYPO3-SA-2010-022 explained

On 16th December, TYP03 released a new security update (TYPO3-SA-2010-022) for their content management system. Apparently, this web-based framework is widely used in many important websites.
Within this update, TYPO3 team fixed a vulnerability that I've discovered a few weeks ago. In detail, this discovery pertains to a previous vulnerability fixed in TYPO3-SA-2010-020 and discovered by Gregor Kopf.

TYP03 decided to follow a policy of least disclosure. Although it's an Open Source project, no technical details are available in the wild besides these (1,2). As I strongly believe that this practice does not improve the overall security (as mentioned in a previous post), I've decided to briefly explain this interesting flaw.

From the advisory, we can actually deduce two important concepts:

A Remote File Disclosure vulnerability in the jumpUrl mechanism [..] Because of a non-typesafe comparison between the submitted and the calculated hash, it is possible [..]
In a nutshell, the JumpUrl mechanism allows to track access on web pages and provided files (e.g. /index.php?id=2&type=0&jumpurl=/etc/passwd&juSecure=1&locationData=2%3a&juHash=2b1928bfab)

The patch (see this shell script) simply replaces the two equal signs with three (loose vs strict comparisons).

That's the affected code:

Having this knowledge, it is probably clear to the reader that the overall goal is to bypass the comparison between $juHash and $calcJuHash. While the former is user supplied (string or array), the latter is derived from a substr(md5_value,10) (string).

In PHP, comparisons involving numerical strings result in unexpected behaviors (at least for me before studying this chapter).
If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically
If the string does not contain any of the characters '.', 'e', or 'E' and the numeric value fits into integer type limits (as defined by PHP_INT_MAX), the string will be evaluated as an integer. In all other cases it will be evaluated as a float.
For instance, the following comparisons are always TRUE:
if(0=="php")-> TRUE
if(12=="12php")-> TRUE
if(110=="110")-> TRUE
if(100=="10E1")-> TRUE
if(array()==NULL) -> TRUE
And again, also the following comparisons are TRUE:
Consequently, we can pad and wait till the substring of an md5 hash resembles this form. If you do the math, you will discover that the combined probability of having such calculated hash is considerably less than pure bruteforcing.
~37037037 max trials (worth case) VS 3656158440062976 all possibilities
In practice, the number of iterations is even less as "0000E13131" and similar strings are also accepted.

To further improve this attack, I've discovered another bypass (TYPO3-SA-2010-022) which allows the disclosure of TYPO3_CONF_VARS['SYS']['encryptionKey']. In this way, it is possible to retrieve the key once and download multiple files without repeating the entire process. Using multiple requests, this attack takes a few minutes (8-20 minutes in a local network). A real coder can surely enhance it.

As you can see from the exploit (posted on The Exploit Database), the fileDenyPattern mechanism bypass is pretty trivial. A demonstration video is also available here (slow connection, sorry).

Keep your TYPO3 installation updated! A patch is already available from the vendor's site.


Unspecified vulnerabilities

If you're a pentester, it's probably not news to you that "least disclosure" policies for disclosing vulnerabilities are fruitless. Unfortunately, they are even counterproductive for the entire security ecosystem and I will try to convince you within this post.

Before going any further, let's explain what "least disclosure" actually means.
In a nutshell, least disclosure is about providing the least necessary facts of vulnerabilities that are needed to know if a user might be affected and what the possible impact would be. No technical details, no exploits, no proof-of-concept code.

As mentioned here, you may argue that it increases the overall security as a random "black hat needs to put some efforts in thinking and coding before he's able to exploit a vulnerability".

However, we all claim that "security through obscurity" is bad:

  • Aggressors don't have time constraints. They can analyze patches, read all documentation and spend nights on a single flaw

  • No technical details in the wild generally means no signatures and detectors in security tools

  • "Least Disclosure" tends to degenerate in "Unspecified Vulnerability in Unspecified Components". Please fix your computer and don't ask why
Although we cannot certainly force vendors' disclosure policies, sharing the outcome of any security research may be beneficial at the end of the day.

Thoughtful reader, please note that getting profit from vulnerabilities does not necessary implicate concealing details. For instance, see the Mozilla Security Bounty Program FAQ.
We're rewarding you for finding a bug, not trying to buy your silence
If you enjoy the spirit, you may appreciate the following posts. Welcome back NibbleSec readers!


VASTO has a new home!

VASTO (the Virtualization ASsessment TOolkit) will leave this blog to findings only and will now be at vasto.nibblesec.org.
You can find version 0.3 right there!

Announcing VASTO 0.2

The new version of VASTO, now with Cloud tricks! VASTO 0.2 includes attacks against the Abiquo and Eucalyptus private cloud systems, and improved versions of the previously released VMware-targeting modules. You can grab a copy here.
VASTO 0.2 was released at SyScan 10 Singapore: the slides are embedded at the end of the article.

As usual, feedbacks are warmly welcome.

By the way, I'm also uploading some videos of my demo.

Announcing VASTO beta

Today at Troopers10 I released the first beta of VASTO, the Virtualization ASsessment TOolkit. VASTO is being developed at Secure Network and wants to be the reference in penetration testing in virtualized environments.
You can find more information in the attached presentation, and download the binary here.

By the way, Troopers 10 was really an amazing conference, wonderful venue and great people.

Modern magicians

Recently, I have been asked to write a non-tech article about pentesting and vulnerability research. As it might be interesting to some readers, I decided to share a few fragments here.

"Any sufficiently advanced technology is indistinguishable from magic"
Arthur C. Clarke

Since my early days with computers, I have always cited this Clarke's Law to people astonished by technology artifacts. These days, I am still using the same quote while explaining my job as a pentester to non-technical persons. Beyond the shadow of doubt, security testing is far away from magic being a complex technology-based process. It requires a proper mix of scientific know-how, creativity and expertise on cutting-edge technologies. Staying on top of the latest in vulnerabilities and computer attacks requires continual study, in-depth research, as well as continual discussions and feedback with fellow security professionals.

"0days are a device to prove that a client is unready to handle the unknown"
Pete Herzog

Understanding incoming threats or even discovering new vulnerabilities gives a crucial advantage over potential aggressors. It allows system owners to protect their installations in spite of the public spread of critical flaws. In the long term, it also provides important insights which are useful to design more secure technologies for the future. As 0days are a product of an intensive research work, vulnerability research activities are essential for pentesting.

"I’ve always said that hacking is not about skill set. It is mostly about dedication, patience and a lot of motivation"

Hacking is about skills, dedication, patience, passion and creativity. Properly mixing these elements makes possible to experiment with computers (and not only!). During a pentest, trying to understand how systems work and using them in an unconventional way is the key to circumvent protections and exploit vulnerabilities. After all, security testing is just about mastering technology and doing magic tricks.