Real world CSRF: Update your Radiant now

Filed under Uncategorized

Radiant is a no-fluff, open source content management system designed for small teams, written in Ruby on Rails.

I have found several security problems in Radiant, informed the vendor, who fortunately removed the (critical) vulnerabilities quickly. As an update is available, I’m now publishing information about the vulnerabilites.

CSRF in a real world application
About Cross Site Reference Forgery attacks I’ve written in a previous post. Here is an example of what you can do with it in a real world application: An attacker could add his own administrator users, change the current’s administrator’s user name and password, or create malicious pages in the content management system. Vulnerable is Radiant version 0.6.6 and most likely previous versions. Not vulnerable is version 0.6.7.

In this proof-of-context page, you have to enter the URL of your Radiant setup and click the link. If you you’re still logged in to that site, i.e. your cookie didn’t expire, a new administrator “cracker” with the password “cracker” will be added. Of course the attacker won’t ask you about the URL, and there are many ways to obfuscate the attack.
Changing the password
To change the password of an account, the user doesn’t have to enter the old password. As Radiant version 0.6.7 is not vulnerable to CSRF, the admin’s password may not be changed by CSRF. However, if an attacker manages to use the application in the admin’s name, he will be able to hijack the entire application by changing the admin’s password and possibly the user name. The attacker may use the application if he managed to brute-force the admin’s login credentials or if he got hold of the admin’s cookie (by listening to network traffic, for example).
Although this is an attack with (hopefully) difficult preconditions, I prefer to take care of second level attacks, too. As a precondition, require to enter the old password when changing the password, and use good passwords.
Unsalted passwords
The user’s passwords in the database are encrypted, but not salted. So if someone gets hold of a user entry in the database, he can brute-force the users password in the matter of minutes using rainbow tables. From version 0.6.7, passwords are salted.

 

Holes in the textile
At least the Textile filter is vulnerable to injection, try to inject this:

!http://www.google.com/intl/en_ALL/images/logo.gif(Bunny” onclick=”alert(‘XSS’))!

You can find more details in this post about Textile security. This is how an attacker could introduce malicious content. Of course this would require that the attacker has access to the application. But, as mentioned before, I prefer to make sure less/nothing will happen, if someone got past the first barrier.

The countermeasure against this, is to use Rails’ sanitize() method with the Textile output.