How To: Break MOLLY!

I have wanted to post this for a long time now, but I had previously been afraid of retaliation by RIT's IT department since this exploit was discovered using their public facing website. However, http://it.rit.edu and http://nssa.rit.edu have both recently switched from Molly, a pseudo in-house solution written mostly by Ronald Vullo. Molly's status as a publicly available CMS from sourceforge opens the possibility that other people outside of RIT will be using it, and these people would probably appreciate being told about a security vulnerability in their software...unlike the IT department which would likely try to expel me or prevent me from graduating on schedule. (Yeah, I have great faith in these people.)

Anyway. Molly stands as a key case example for how you should NOT write PHP. It makes heavy use of BAD-THINGS ®, does not use any sort of legitimate string munging to prevent SQL injection, and has almost no concept of session security.
As for bad things, I mean things like polluting the global namespace, using .html files with PHP in them, the eval() statement, old functions like eregi_*(), and heavy use of $_REQUEST as opposed to $_GET and $_POST. The PHP manual itself states that $_REQUEST cannot be trusted, as you do not know which of Environment, Cookies, Get, Post, Server sources provided the variable you're looking at in $_REQUEST or if one has over-written what you actually want.

The most glaring exploit I've found, however, is related to the rendering engine the the database module (Called forms). Molly controlled pages will often have some string in their URL which tells the Molly engine how to render said page, example: people.maml?id=77&renderAs=output Or renderAs=edit
Yup. I can just see all the tech minded people thinking "What if I change output to input?".
When RIT used Molly, exactly what your worst fears were, is what happened. Each element on the page became HTML Input.


After that point it became trivial to use the Firebug plugin for Firefox to modify the contents of the page on the fly to make Molly bend over for you. To update any record you wanted, it was a simple matter of navigating to that page, changing the URL, using firebug to change the form action from "insert.html" to "replace.html" and adding a value to a hidden input element named something along the lines of "form[0][id]".

Since Molly doesn't understand security, the files which parse the form input and create the SQL queries are wide open for all to access, as long as you can post the right information.

One way these can be protected is through the use of an .htaccess file using the directive and some form of HTTP authentication. And that's probably the simplest way, but I don't know if there's anything resembling security on the rest of the engine that could be expanded to these files.

YOUR CODE IS BAD AND YOU SHOULD FEEL BAD TOO!

--PXA