Saturday, 22 June 2013

Operation scavenger

Following my talk last year at Ruxcon on Monitoring repositories for fun and profit,  a friend suggested me that I should look into files that gets added to a git repository and deleted in the next few commits... Operating scavenger was born.

How to do it

Since adding files is fairly common in a git repository, I decided to work the other way around, search for deleted files and see if they have been added in the last 3 commits.

Github provides a nice API that you can use to retrieve all the repositories. Since I didn't want to abuse the service, I only scanned 8000 repositories (out of the ~ 10 millions).

All together, the script is around 100 lines of Ruby.

Results

And as my friend suggested, I found stuff:
  • config/database.yml with 2 root passwords (really good ones) and one user password
  • password for growlnotify
  • PHP script with MySQL root password
  • XML file with mysql credentials
  • Deployment script with MySQL root password
  • One SSH key
  • CouchApp credentials
  • Few hashes from database dump
  • ...
For a total of 500Mo of deleted files.


Any idea of what else I should look for?

Wednesday, 24 April 2013

CVE-2012-6081

When you see that a bug in a Wiki engine used by Python and Debian gets published and got used to own them, you know that there is something interesting to look at...

This bug is a really simple directory traversal that you can use to write an arbitrary file on the system. The beauty of it is its exploitation (based on an exploit found on pastebin), the exploit bypasses 5 restrictions:


  1. It's valid python code.
  2. It starts with  the string `drawing.`.
  3. It contains `def execute(p,r):` to be a valid MoinMoin plugin.
  4. It does not contain any dot (`.`)
  5. It is less than 100 characters (due to the tar format).

If you want to know more, check out our latest exercise on cve-2012-6081.

Thursday, 3 January 2013

On exploiting CVE-2012-5664...

Just a quick write-up on this, I will probably do an exercise on it soon, like I did for the previous bug in ActiveRecord. It's pretty trivial to exploit if you have the right condition...

The right condition being: the ability to send symbols to activerecord. When you read the advisory, you could think that this bug could be exploited by only doing something around: http://vulnerable/?id[select]=SQL.

However, ActiveSupport (a Rails core library that is used by ActiveRecord) prevents this since it ensures the keys are valid, and make sure the keys are 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? 

From my testing the following keys are valid: :conditions, :include, :joins, :limit, :offset, :extend, :order, :select, :readonly, :group, :having, :from, :lock. And since Ruby cares about data type (ie: the string "select" and the symbol :select are not the same thing):

>> ["select"] - [:select]
=> ["select"]

It can't be trivially exploit like in the URL above. I can't think of any way to bypass this at the moment... However, if you can modify a rack session for example (especially if you don't sign them since you think they don't contain anything worth tampering), it's trivial to exploit ;)