What's happening here?
The Rails Security Project wants to make Rails (applications) more secure. I, Heiko Webers, stand strong behind the true meaning of the word hacker, as opposed to a cracker. I write blog posts about Rails and security related topics, carry out security audits for your web applications, and I'm currently rewriting my book. Contact me at 42 -the AT sign- rorsecurity.info.
Here is the news from the Rails Log:
Drew Yao at Apple uncovered a handful of nasty security vulnerabilities affecting all current versions of Ruby. The details are still under wraps because an attacker can DoS you or possibly execute arbitrary code—holy crap! Better upgrade sooner than later.
According to the official Ruby security advisory, the vulnerable Rubies are:
- 1.8.4 and earlier
- 1.8.5-p230 and earlier
- 1.8.6-p229 and earlier
- 1.8.7-p21 and earlier
Those of us running Ruby 1.8.4 or earlier must upgrade to 1.8.5 or later for a fix. Those on 1.8.5-7 can grab the latest patchlevel release for a fix.
(Please note: Ruby 1.8.7 breaks backward compatibility and is only compatible with Rails 2.1 and later, so don’t go overboard!)
Tags: Ruby
Security is not easy-to-use, not fancy and it is hard to remember all those nasty attack methods. So there are automatic security checks, firewalls, helpers and a lot more. They are built to make your application more secure. But automatic security tools can't help you to find logic faults. What if you have a Cross-Site Scripting scanner that checks each and every field in your web application, but with a little knowledge, an attacker could change one id in the URL and he sees his neighbor's confidential data.
BUT, automatic tools can be of great help, if you won't solely rely on them. The SafeErb plugin reminds you to sanitize output, but it doesn't do it automatically. A mass-assignment scanner might find this kind of security holes in you application. Or a web application firewall may protect holes you are not aware of. And, of course, security is a process and should be incorporated into the entire project life cycle.
That having said, I'd like to show you a nice web application firewall for your .htaccess, if you happen to use Apache. It comes from 0×000000.com, a whitehat hacker site, and it's the result of seven years of server administration. It is not perfect, it is not especially for Rails applications or for your specific application, but it is definitely a good starting point. You can read the tutorial for explanation.
RewriteEngine On
Options +FollowSymLinks
ServerSignature Off
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC,OR]
RewriteCond %{HTTP_REFERER} ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI} ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set
|declare|drop|update|md5|benchmark).* [NC,OR]RewriteCond %{QUERY_STRING} ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]
RewriteRule ^(.*)$ access_log.php
Tags: Rails · Server · Web server
Two weeks ago, the Debian package of OpenSSL has been found to generate weak keys (CVE). Here's the news from Heise online:
Security expert Luciano Bello has now discovered a critical vulnerability in the OpenSSL package which makes the random number sequences, and therefore keys generated, predictable. The problem only affects Debian and distributions derived from it, such as Ubuntu and Knoppix. […]
OpenSSL provides connection security for many important network services, such as the Apache web server, the SSH login service, the OpenVPN service, the Bind name server, S/MIME e-mail encryption and the trustworthiness of digital signatures. This could enable attackers to listen in on and manipulate SSL connections, obtain unauthorised access to SSH servers or poison DNS server caches.
As it is a serious security vulnerability, it is strongly advised to update your keys, especially for the SSH login service. Although the security advice is two weeks old already, there are still thousands of servers vulnerable. Heise Security found 5% of nearly 2,000 servers tested to use weak keys.
Tags: Server
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 passwordsThe 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.
Tags: Rails · WebAppSec · XSS and Rails
