Heiko, Page 4 Author

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!)

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 0x000000.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

Two weeks ago, the Debian package of OpenSSL has been found to generate weak keys (CVE). Here's the news from Heise online:

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.

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.

Several people asked me about automatic assessment tools to check the security of an application stack. My opinion is that they may be a great support, but they cannot replace some manual work (oh, well, maybe). Rails test are a great way to make sure your application is safe, but you have to write them on your own. Security is not a plug-n-play product, but rather a process.

Automatic security
One automatic security scan is provided by McAfee. The HackerSafe certification is a service that detects vulnerabilities on web sites using automatic tools. If all tests pass, the site owner gets an HackerSafe logo, that he can put on his site. Over 80,000 sites, according to McAfee, use the HackerSafe logo to increase customer trust. According to the description, the service uses port scans, a vulnerability scan on the network layer, but also an automatic audit of the web application layer. On this layer, it looks for SQL Injection and Cross-Site Scripting (XSS) vulnerabilities. It is, however, not clear whether the service scans for other important attack methods, such as CSRF.

Cross Site Reference Forgery works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.

Most Rails applications use cookie-based sessions. Either they store the session id in the cookie and have a server-side session hash, or the entire session hash stays on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if he can find a cookie for that domain. The controversial point is, that it will also send the cookie, if the request comes from a site of a different domain. Let’s start with an example:

• Bob browses a message board and views a post from an attacker where there is a crafted HTML image element. The element references a command in Bob’s banking application, rather than an image file (note that .src is meant to be src).

• <img .src=”http://www.bank.com/transfer?account=bob&amount=1000&destination=attacker”>

• Bob’s session at www.bank.com is still alive, because he didn’t log out a few minutes ago.

• By viewing the post, the browser finds an image tag, which it tries to load from www.bank.com. As explained before, it will also send along the cookie with the valid session id.

• The web application at www.bank.com verifies the user information in the corresponding session hash and transfers the money to the attackers account. It then returns a result page which is an unexpected result for the browser, so it will not display the image.

• Bob doesn’t notice the attack, only a few days later he finds out about the strange transfer.

It is important to notice that the actual crafted image or link doesn’t necessarily has to be situated in the web application’s domain, it can be anywhere – in a forum, blog post or email.

See the figure at shiflett.org to see how CSRF works.

CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures), less than 0.1% in 2006, but it really is a ‘sleeping giant’ [Grossman]. This is in stark contrast to the results in my (and others) security contract work – CSRF is an important security issue.

CSRF Countermeasures

First of all, GET and POST have to be used according to the W3C. Secondly, a security token in non-GET requests will protect your application from CSRF.

The HTTP protocol basically provides two main types of requests – GET and POST (and more, but they are not supported by most browsers). The World Wide Web Consortium (W3C) provides a checklist for choosing HTTP GET or POST:

Use GET if:

• The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Use POST if:

• The interaction is more like an order, or

• The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or

• The user be held accountable for the results of the interaction.

The verify method in a controller can make sure that specific actions may not be used over GET. Here is an example to verify that the transfer action will be used over POST, otherwise it redirects to the list action.

verify :method => :post, :only => [ :transfer ], :redirect_to => { :action => :list }

With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application.

But this was only the first step, because POST requests can be send automatically, too. Here is an example for a link which displays harmless.com as destination in the browser’s status bar. In fact it dynamically creates a new form that sends a POST request (.href is meant to be href).

<a .href=”http://www.harmless.com/” onclick=”var f = document.createElement(‘form’); f.style.display = ‘none’; this.parentNode.appendChild
(f); f.method = ‘POST’; f.action = ‘http://www.example.com/account/destroy’; f.submit();return false;”>To the harmless survey</a>

Or the attacker places the code into the onmouseover event handler of an image (again, .src is meant to be src):

<img .src=”http://www.harmless.com/img” width=”400″ height=”400″ onmouseover=”…” />

There are many other possibilities, including Ajax to attack the victim in the background. The solution to this, is to include a security token in non-GET requests, which will be checked on the server-side. In Rails 2 this is a one-liner in the application controller:

protect_from_forgery :secret => “123456789012345678901234567890”

This will automatically include a security token, calculated of the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won’t need the secret, if you use CookieStorage as session storage. It will raise an ActionController::InvalidAuthenticityToken error, if the security doesn’t match what was expected.

Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form.  This is how the Samy MySpace worm did it.

A security advisory has been released for libpng, the "official PNG reference library". Libpng is used by ImageMagick, "a software suite to create, edit, and compose bitmap images". Some Rails applications use it to convert, resize or to create thumbnails. The original security advisory was issued by oCERT:

Applications using libpng that install unknown chunk handlers, or copy unknown chunks, may be vulnerable to a security issue which may result in incorrect output, information leaks, crashes, or arbitrary code execution. The issue involves libpng incorrectly handling zero length chunks which results in uninitialized memory affecting the control flow of the application.

The security advisory from libpng reads:

We believe this is a rare circumstance. It occurs in "pngtest" that is a part of the libpng distribution, in pngcrush, and in recent versions of ImageMagick (6.2.5 through 6.4.0-4). We are not aware of any other vulnerable applications. 

And here is the CVE:

libpng 1.0.6 through 1.0.32, 1.2.0 through 1.2.26, and 1.4.0beta01 through 1.4.0beta19 allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via a PNG file with zero length "unknown" chunks, which trigger an access of uninitialized memory.

Here are my slides for my talk at the RubyFools Conference in Copenhagen, home of Rails. It was about advanced Rails security topics, including:

• Injection in different contexts
• Whitelists vs. Blacklists
• Cross-Site Reference Forgery (CSRF)
• Intranet and Admin security
• Session fixation
• Login security
• User management
• CookieStore
• Working with files
• The idea of negative CAPTCHAs

Slides at Slideshare

There's a new sign-in seal on the Yahoo! login page, which is intended to make phishing attacks more unlikely.

A sign-in seal is a secret message or photo that Yahoo! will display on this computer only. Look for it every time you sign in to make sure you're on a genuine Yahoo! site. If the message, photo, or colors are different, you may have landed on a phishing site.

There might be other techniques to fight phishing, but it is certainly smart to raise awareness. And the technology behind it is clever too. Of course a normal browser cookie would go away from time to time when you (or the browser) clear your cookie cache. So Yahoo! uses so-called Flash SharedObjects which are sort of Flash cookies. They're available cross-browser, and they won't go away normally, because not many people are aware of how to clear these objects.