Cатсн²² (in)sесuяitу / ChrisJohnRiley

Well I always meant to go back to it… so I guess now is as good a time as any!

Back at the start of 2009 I stumbled on a small encryption bug in TYPO3. It wasn’t anything ground breaking, and even though it had a few interesting points to it, it wasn’t really worth talking about at length. I’m no cryptographer and talking about crypto bugs seemed a bit pointless when I was the dumbest guy in the room! Still, at the time I wrote up a quick proof of concept script in Python (my language of choice at the time) and reported it to the TYPO3security team. They released a patch (security advisory Typo3-sa-2009-001) and life went on.

In the two years since, there have been a number of  other similar findings in TYPO3 (including Typo3-sa-2009-002), but late last year an interesting bug in TYPO3 caught my interest (security advisory Typo3-sa-2010-020). The bug was unique (at least to me) as it was a quirk in the way PHP handles == comparisons. Simple to fix, but the way it could be exploited was genius. Anyway, I won’t go through the whole issue from start to finish, as Gregor Kopf (the researcher who discovered the flaw) has already done a great job of that in his presentation “Non-Obvious Bugs By Example” which discusses this issue and an issue in Joomla. I highly recommend you to try and grab the video or look through the slides if you can.

Anyway, back to the beginning. I’d always thought that I’d take some time and convert the PoC code I’d written over to Metasploit. The code I’d put together wasn’t particularly useful, and I’m moving more and more towards Ruby to stop from having to port things all the time. I’d implemented the original PoC using the showpic feature, and the result was a simple method of bypassing Cross-Site Scripting restrictions in Typo3. In reality the bug was able to do so much more, as once you’d recovered the encryption key (a matter of 1000 requests maximum), you can use it to form valid requests to read pretty much any file on the system. Obviously more interesting than a Cross-Site Scripting (in most cases). Anyway as I was finally working on porting Typo3-sa-2009-001 to Metasploit, so I took a closer look at Typo3-2010-020, as there was no public exploit code public exploit code that my google fu totally missed*, and came up with a simple method to exploit that bug as well. I also threw in a module for TYPO3WINstaller as well, as I was using them in testing the modules it quickly became obvious that they used a very small set of hard-coded Encryption Keys.

WINstaller (http://typo3winstaller.sourceforge.net)

Now to the defense of the TYPO3WINstaller team, they do point out this is a developer install and it is restricted to localhost communication only out of the box… but you and I both know, that kind of thing quickly gets forgotten, changed and left running on some disregarded server under a desk somewhere. So, if you see ports 8503, 8504, 8505 open and serving TYPO3 content, just check that they’ve changed the defaults (BTW… the default Backend username passwords are admin:password, and typo3:typo3)

Anyway, I’m still working out some kinks, but feel free to test out these versions and let me know what you think. I’ll be putting them forward for inclusion into the Metasploit trunk once they’ve been ironed out a little more 😉 Oh, and the threaded version of Typo3-sa-2010-020 kills my test server… you’ve been warned!

• /auxiliary/admin/http/typo3-sa-2009-001
• /auxiliary/admin/http/typo3-sa-2010-020
• /auxiliary/admin/http/typo3-sa-2010-020_threaded (can cause issues)
• /auxiliary/admin/http/typo3-winstaller_default_enc_keys

* Luca from the nibblesec blog rightfully pointed out that he created a PoC for typo3-sa-2010-020 (and 022) that I didn’t find when looking into this bug. I encourage interested parties to talk a look at his exploit over at http://blog.nibblesec.org/2010/12/typo3-sa-2010-020-typo3-sa-2010-022.html