
Metasploit Rails 3 Remote Code Execution Hours Away - tptacek
https://community.rapid7.com/community/metasploit/blog/2013/01/09/serialization-mischief-in-ruby-land-cve-2013-0156?x=1
======
tptacek
Expect a point-and-click exploit that will run _arbitrary code_ on vulnerable
servers.

If you've never dealt with a problem like this, you may not be ready. So,
here's the most important thing you need to understand:

 _If you have a vulnerable application_ anywhere, on any port _it will be
found and compromised. This is a spray-and-pray vulnerability._ It costs
attackers nothing to try, attempts don't crash servers, and so people will try
_everywhere_.

If you lose an application in your data center / hosting environment, that's
the ballgame. It doesn't matter that the app you lost was the testing instance
of a status dashboard with no real data in it, because the exploit coughs up
shell access on that server. If there is one thing every black-hat attacker in
the world is truly gifted at, it is pivoting from shell access on one server
to shell access on every goddam server.

Please make sure you didn't just patch the app servers you know/care about.
THEY ALL NEED TO BE PATCHED OR RETIRED.

Additionally:

* If you are one of those "same password on a whole bunch of services people", now is a good time to make sure nothing you care about has that password. Some app somewhere is about to lose that password.

* Now would not be the worst time in the world to go to your Twitter config, hit Settings -> Apps, and scrub out all the stuff you don't use.

* Now you know why you never give 3rd party web apps your Gmail password.

~~~
patio11
(Bah, great point about passwords. I need to reform my ways.)

To amplify and expand on Thomas here: when this was announced I pushed the Big
Red Button and pushed three emergency patches to my servers at 3 to 5 AM Japan
time. My perception was "This just can't wait." I went to sleep with the vague
feeling that I had probably broken something (there's always _something_ that
slips when you're tired and hasty) but that it was almost certainly acceptable
given the alternative.

Sure enough: despite automated and smoke tests passing and metrics remaining
nominal, Appointment Reminder suffered breaking downtime for some customers
(it depended on browser - long story not relevant). This ended up locking them
out for about 16 hours, felicitously mostly not during the US working day.

After being told of the issue by a few mighty pissed end users, I fixed it and
spent a second awake-to-9 AM night both writing a to-all-customers apology
email and fielding questions. I went into detail on why I screwed up (acted
too fast) and a simplified version of why I had to (third-party software
required an urgent patch; delaying deployment by one day would have been an
unacceptable risk to customer data).

Several customers - including a few of the ones most inconvenienced - got it
touch to say "Right call." One of them was of the opinion that, if I hadn't
patched, _he_ would be in Big Red Button mode today, because _no machine or
data on a local network with an unpatched Rails instance is safe_. "I honestly
prefer knowing it broke because you were on top of things than it being stable
because you weren't" end quote.

I'm not a security guy, I'm just a systems engineer, but my take on it is that
this does not just require the Big Red Button, this is the paradigmatic
example of why you _have_ a Big Reg Button. If you don't, or if you pushed it
yesterday like you should have and something blew up, this is an excellent
opportunity to improve procedures for next time.

Edit: Big Red Button is funny shorthand for "Immediately drop what you're
doing, pull out the In Case Shit Happens folder, and have the relevant people
immediately execute on the emergency plan." We call it something different in
big Japanese megacorps but I always liked the imagery.

~~~
cheald
LastPass makes it much, much easier to never re-use passwords. Just make sure
your master password is unique and strong and never re-used and you use 2FA!

~~~
StavrosK
I use SuperGenPass, it's comparable and requires storing no state, thus
nothing to lose or back up.

~~~
amalag
Is it still completely vulnerable?

<http://akibjorklund.com/2009/supergenpass-is-not-that-secure>

~~~
StavrosK
I use EngimaPass[1], which, as an extension, renders outside the DOM, so it's
not.

[1]
[https://chrome.google.com/webstore/detail/enigmapass/bgkipgf...](https://chrome.google.com/webstore/detail/enigmapass/bgkipgfgpifliinhbnfoaafgdeemodoi?hl=en)

~~~
amalag
Thank you, I was looking for one and thinking of buying a yubikey as well.

------
raffi
For those who aren't familiar with the Metasploit Project, it's an open source
collection of safe and vetted exploits. Once an exploit module makes it into
the Metasploit Framework, it's immediately available to ~250K users. The
Metasploit Framework isn't just exploits though, it's an integration point for
offensive capabilities that simply work together. It's also very easy to hook
your own stuff into it.

There are several programs that build on the Metasploit Framework and take
advantage of it. Rapid7 has commercial penetration testing products. I build
the open source Armitage GUI for it and a commercial add-on called Cobalt
Strike.

It's worth spending some time to learn how it works and what it does. Here's a
few links:

Metasploit Unleashed Wiki: [http://www.offensive-security.com/metasploit-
unleashed/Main_...](http://www.offensive-security.com/metasploit-
unleashed/Main_Page)

My 7-part course on pen testing (with Cobalt Strike & MSF):
<http://www.advancedpentest.com/training>

Quick demo of what it looks like to attack a workstation and use it as a hop
point to get other things:
[http://www.youtube.com/watch?feature=player_embedded&v=S...](http://www.youtube.com/watch?feature=player_embedded&v=S_ejYRTM8J0)

The best way to try the Metasploit Framework is to setup BackTrack Linux in a
virtual machine: <http://www.backtrack-linux.org/>

A free vulnerable target is the Metasploitable virtual machine, available at:
[http://sourceforge.net/projects/metasploitable/files/Metaspl...](http://sourceforge.net/projects/metasploitable/files/Metasploitable2/)

~~~
moloch
This particular gentleman also has a few good presentations on Metasploit I
saw at Defcon/Bsides:

[http://www.youtube.com/watch?v=G-JaHWaLmgc&hd=1](http://www.youtube.com/watch?v=G-JaHWaLmgc&hd=1)

[http://www.youtube.com/watch?v=y2M3SpOzeJY&hd=1](http://www.youtube.com/watch?v=y2M3SpOzeJY&hd=1)

------
espes
Available now:

<https://github.com/rapid7/metasploit-framework/pull/1281>

<https://gist.github.com/4499206>

------
jtchang
How prevalent is Rails 3 right now?

I somehow feel that defensive programming practices would have caught this
bug. There is a lot of "magic" going on that lead to this exploit.

Sending text/xml to an application shouldn't have a huge impact but when you
are dynamically creating objects out of the content it can lead to some
serious problems.

Python has this too with pickle. However with Python it is pretty damn obvious
that pickle is NOT SAFE. You also have to import it manually.

~~~
hjr3
I don't think defensive programming would have based on the current situation
across a number of languages. Basically no serializer in any language PHP,
Python, Rails, etc is completely safe. There are known exploits for all of
them.

There is lots of magic in rails, but I bet there are a number of popular PHP
and Python libraries/frameworks that are unserializing in an unsafe way.

~~~
ab
There's an enormous difference between serializers that make _any_ effort at
all to be safe, and those like Ruby's YAML library, which make no effort.
Python's YAML, for example, exposes a safe_load() method.

It's really criminally negligent that no such method exists in Ruby's YAML
library.

~~~
ghostganz
Python's Pickle lib had something similar to safe_load(), that they _removed_
because it gave a false sense of security.

~~~
X-Istence
If you are accepting pickled objects from a remote and using it ... you are an
idiot.

------
postmodern_mod3
Proof-of-Concept Exploits for CVE-2013-0156 and CVE-2013-0155 are here:

rails_rce.rb (<https://gist.github.com/4499206>)

rails_sqli.rb (<https://gist.github.com/4499032>)

rails_dos.rb (<https://gist.github.com/4499017>)

rails_jsonq.rb (<https://gist.github.com/4499030>)

------
fmavituna
It's arrived:

[https://github.com/rapid7/metasploit-
framework/blob/master/m...](https://github.com/rapid7/metasploit-
framework/blob/master/modules/exploits/multi/http/rails_xml_yaml_code_exec.rb)

Same story I submitted yesterday :
<http://news.ycombinator.com/item?id=5030906>

------
moved_to_python
The Good:

The way the Rails team responded so quickly in patching this.

The Bad:

The patches for this and other recent security issues had little time for
testing and hence broke things. The old failed idea of trying to prevent full
disclosure, which ultimately harms the community whilst doing nothing to
really prevent the bad guys arming themselves with working exploit code, and
all the resulting kerfuffle we saw.

The Ugly:

The Rails codebase. Seriously. As you read this, interested people are now
pouring over it, looking for new vectors of attack, and we are awaiting the
next series of having to scramble and fix the bad things that the magic in
Rails enabled.

------
zurn
If you installed Rails from Ubuntu, you have to patch it by hand since they're
not patching it.

Use the conversions.rb patch for 2.x from
[https://groups.google.com/forum/#!topic/rubyonrails-
security...](https://groups.google.com/forum/#!topic/rubyonrails-
security/61bkgvnSGTQ/discussion)

"We're not patching it" statement: <https://launchpad.net/bugs/320813>

~~~
ZoFreX
In my experience, using Ruby or gems from your package manager leads to
headaches down the line - I'd highly recommend using bundler to manage your
gems at the very least, and rvm or rbenv to manage rubies.

~~~
potkor
Does this also apply to end-users of Ruby apps that are just an apt-get away?
I don't really want to learn all that stuff (and remember to redo it on all
installs) just to use some tool that happens to be written in Ruby.

~~~
mnutt
I don't believe there are any rails-apps-as-packages in the official
debian/ubuntu repositories, but if there were I assume they would use bundler
to bundle their gems internally.

~~~
zurn
Yes there are, in our case Redmine. A pretty popular piece of software I
believe. In Debian it's in main and in Ubuntu it's in universe.

Re. bundler/gems, I don't know what those are - the file
"core_ext/hash/conversions.rb" I hand-patched was from a package called ruby-
activesupport-2.3 which is a dependency of the Rails package.

~~~
ZoFreX
It was redmine I was using when I had the issues actually. The real problem
though was that I was trying to use a newer version of Redmine than was
available in the repo, and I did still manage to satisfy the dependencies but
upgrading my Ruby version broke literally everything.

I think if 100% of your eco system is from the package manager you would be
fine, but if even a single component needs to come from outside I would reach
straight for rvm and bundler (no prejudice against rbenv, rvm is just what I
use)

------
parfe
So all these rails exploits are cropping up because someone decided to
actually look at a single module of code? I saw in the last thread someone
comparing these Rails vulnerabilities to Python Pickle (which has a huge
warning screaming "DO NOT USE") and Django's various issues but that
comparison seems pretty unfair now. Rails seems to be at the PHP4 league of
bad code and reading the security threads on this back in time you see tons of
people brushing the initial vulnerability off ("You need the secret key" "Only
projects that leak the secret are vulnerable" etc)

Is a simple code review all it took for this fail cascade?

~~~
techpeace
It wasn't a simple code review, it was a vulnerability that existed in code
unnoticed for a number of years. It required skilled security researchers to
unearth it. Vulnerabilities exist unnoticed in a number of foundational OS
projects like this, and it's only when a CVE is released that people realize
it had been there for quite some time.

~~~
greedo
Unnoticed...

Do not make the mistake of assuming that because there's no CVE, that a
vulnerability is unknown. Not everyone who analyzes code is wearing a white
hat.

~~~
techpeace
Very true. There were no widespread reports of incidents based on this
vulnerability in the wild, though, or it would have been discovered already.
Thankfully, the folks that found this exploit (and the others they are sitting
on for the moment) were wearing white hats. Also thankfully, the core team
responded quickly to rectify and publicize the issue.

------
TallboyOne
What is a 'metasploit'? I just suddenly read this 50 times on twitter and I
have no idea what's going on. I'm halfway through this article and still not
making sense.

~~~
dmix
It's an automated vulnerability tester.

It will probe websites (and local networks) to find out the OS/server
information (IIS, apache, etc), database info (mysql, mssql) and language
(asp, php).

It then uses a database of known exploits and scripts (all types XSS, SQL
injections, etc).

~~~
TallboyOne
So is it a good tool (testing tool) or malicious?

If it's a good tool, why would he release it so soon without giving people
much time to update?

If it's malicious, why is he telling people about it?

~~~
mingpan
It's intended to be used for security testing against one's own machines,
demonstrating a vulnerability if it exists by directly exploiting it. The
general nature of such tools, however, is that they can be used for good or
for evil. It's just assumed that the bad guys have something of the sort
already.

~~~
jrochkind1
You know, when I look at what it is and what it does... I'm not sure I believe
that's what it's 'intended' for, although that certainly is what they say it's
intended for.

But anyway, in the end, it doesn't matter, it exists. Authorial intent is so
20th century.

~~~
techpeace
That's exactly what it's intended for, actually. It was built by pentesters to
perform their work. I'd rather my security tools be open sourced and available
for all the world to see and contribute to. Doing so also compels lazy vendors
to patch awful vulnerabilities.

~~~
jrochkind1
Wikipedia says:

> The Metasploit Project is also well known for anti-forensic and evasion
> tools, some of which are built into the Metasploit Framework.

If so, how are such functions valuable for a pentest/audit?

~~~
greedo
Say you're doing a pentest, and your target has an IDS/IPS to both prevent
infiltration and exfiltration of data. And while you discover a system that is
vulnerable, the payload that you want to deploy to this vulnerable system
would normally trigger an alert by an IDS. With some of the tools in MSF and
BackTrack, you can use an encoding process to obfuscate the payload enough to
get past the IDS/IPS.

Now a blackhat would be able to do this without BT or Metasploit. The tools
are out there, and well known. So the fact that these tools are in BT and
Metasploit doesn't change that. But it does make it easier for a pentester to
prove a system is vulnerable, and to help a company address their
vulnerabilities through remediation.

------
kaonashi
Boy did I pick the right week to leave my last job.

------
dkubb
I just saw a PoC on twitter a few minutes ago. I tested it locally and was
able to run arbitrary ruby code via YAML.load, including shell commands.

~~~
homakov
which one works w/o Rails?

------
teyc
How about an exploit that patches Rails? or at least disables it?

~~~
ovi256
Current US law would still see you as hacking ("unauthorized remote computer
access"). Hey, if you break some apps, their owners would probably agree, so
don't do it.

------
brynary
I wrote up a detailed explanation of the issue and how the proof of concept
works here: [http://blog.codeclimate.com/blog/2013/01/10/rails-remote-
cod...](http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-
execution-vulnerability-explained/)

------
thewillcole
What's the easiest way to verify that
"ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)" is handling
requests with xml parameters properly? Does one of you beautiful people know
of a tool that I could use?

~~~
kapilkale
I posted about this a little bit further up. Run the exploit code on your
local server and ensure that no parameters are getting logged.

You can test by running this ruby file: <https://gist.github.com/4499206>

    
    
      $ ruby rails_rce.rb http://localhost:3000 param "User.destroy_all"
    

Monitor your server and ensure it is disregarding the post parameters.

~~~
thewillcole
thanks!

------
xenophanes
So for old versions of rails 2, can someone tell me where to put this?

ActionController::Base.param_parsers.delete(Mime::XML)

if i just stick it at the bottom of environment.rb, will that work? i am not
sure how to test to confirm that i've fixed it.

~~~
vinhboy
run this for rails 2.x

    
    
      curl -i -H "Content-Type: application/xml" -X POST -d '<id type="yaml">--- !ruby/object:ActionController::Base bar: 1</id>' http://localhost:3000
    

If in your logs the params[:id] is an object, then you are vulnerable. If it's
just a string, then your fix worked.

I put mine in an intializers file.

    
    
      ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol')
      ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml')

~~~
xenophanes
Thank you, very helpful.

EDIT AGAIN: I think putting it at the end of environment.rb works. I somehow
messed it up and got confused, but then I tried it again and it worked. Just
make sure you confirm your fix with the curl command!

~~~
timinman
I can confirm that this method produced the desired change in a Rails 2.1.2
app.

------
thomasvendetta
Can anyone confirm whether or not I still need to add
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) to an
initializer if my apps have been updated to rails 3.2.11?

~~~
tlogan
I suggest that you test it. You should get something like 'Disallowed type
attribute' error if everything is installed correctly. You can use Postman
Chrome extension to quickly test if your server is ok.

~~~
mnarayan01
You will only get that error if you upgrade to 3.2.11 (or whatever) and _do
not_ disable XML. If you disable XML, you'll just silently not parse the XML
(regardless of update status).

~~~
alxndr
If you disable xml or yaml parsing, you'll see the raw yaml come through in
the parameters hash.

------
thenomad
Question: this only affects Rails Version 2 and higher, right?

I suspect I'm not the only person out there with legacy Rails Version 1 sites,
so it would be very good to know the answer to that!

~~~
cschneid
Note the comment about Yaml parsing in 1.1 era rails apps. You'll want to at
least look into what your app is doing.

~~~
thenomad
Yeah - my eventual decision was that it wasn't worth the risk. One extremely
busy day later, we don't have any active Rails apps.

------
rayk
After reading tptacek's comment, I'm curious:

Has this never happened before? Has there never been an exploit of this
significance that has made it to Metasploit, and why not?

~~~
tptacek
Yes, many many times. It's just new to startupland.

------
nnq
Metasploit Framework, the 2nd most important software framework written in
Ruby, and Rails, the topmost ...sweet irony ;)

------
flog
I wonder if Heroku's current downtime on their MyApps site is related?

------
brianbuchalter
I've found a lot of the posts so far to not cover both how to use Metasploit
and actual secure a site. So I wrote [http://blog.endpoint.com/2013/01/rails-
CVE-2013-0156-metaspl...](http://blog.endpoint.com/2013/01/rails-
CVE-2013-0156-metasploit.html).

------
thenomad
Sheeeeit.

Is there a quick way to fix this problem for sites running older versions of
Rails? I can't be the only one who is in that situation. Frankly, provided it
leaves _some_ version of the website online, I'm OK with losing some
functionality, even.

~~~
jhart3333
Older than 2.3? <http://weblog.rubyonrails.org/>

~~~
thenomad
Yes. MUCH older. I still have version 1 Rails sites...

~~~
jhart3333
Not sure this is correct. I just skimmed the article.

<http://www.insinuator.net/2013/01/rails-yaml/>

From the comments:

"From what i’ve see here is that versions below 2.0 should not be affected by
this issue as they do not support xml parameters and don’t have any XMLMini
implementations."

------
jiggy2011
If I download a fresh version of rails from <http://rubyonrails.org/> is it
vulnerable to this?

~~~
remi
No, rails-3.2.11 has fixed this vulnerability.

------
benmmurphy
metasploit people seem to be getting stuck trying to get a version that runs
against rails 2.x 3.x and different ruby versions. so might be a while before
they release :)

however, there are multiple PoCs floating around so it is fairly safe to
assume attackers have access to it.

