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.


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


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 ;)

Sunday, 30 December 2012

How to become a pentester :)

PentesterLab just released Bootcamp, a learning path to get into pentesting... Follow each week and you will get there and learn security the right way ;)

Friday, 28 December 2012

Happy first year PentesterLab...

It has been a year since I started PentesterLab... such an amazing year ;)

Since the first day, a lot have changed, the biggest change was probably to put the exercises for free instead of $12-$20. At first, I thought something like Peepcode will work for PentesterLab, but I realised that I was more interested by sharing stuff and that there were other way to do money and share the content for free. I wrote about this in a previous blog post...

I have also learn a lot in the last year:
  • to know my enemies: distraction (started other project like PNTSTR or some crazy coding) and procrastination (, Facebook, Twitter...). Losing focus (creating side projects) makes you waste a lot of time and people don't really understand were you are going... Having one clear goal is the way to make sure you are going to achieve it and send a better message to potential users/clients.
  • to improve the way I create exercise. I used to write the PDF and build the ISO in the same time... Such a waste of time! I was spending my time telling myself: "I will come back to write that part of the course once I have the correct value from the ISO", it was just a way to postpone stuff and not getting things done. Now, I create the ISO, once it works, I write the course. That way, I also avoid last minute changes and I'm way more effective.
  • to improve the way I blog: instead of trying to write something perfect, I start by a brain dump and improve it over time. Some blog posts stayed few months before being published like How not to get a good pentest
  • to avoid remembering stuff. I put everything in a todo list and come back to it later, even blog posts, crazy coding ideas, ... I use things on my phone since I always have my phone on me it's perfect. Remembering stuff is bad: you will either forget or keep thinking about it, both ways are bad :/ Write things down as soon as you think of them!

For the exercises, I will try to publish a new free exercise every month... so keep in touch, follow @PentesterLab on twitter, register to the mailing-list, or like PentesterLab on Facebook or on Google+, to get the last exercises :)

Thanks to everyone who helped me during this first year, who purchased exercices and commercial licenses, who sent email saying thanks, you are the people who makes Pentesterlab's growth. Thanks to everyone who review the courses and send me feedbacks (typo, grammar, diff file). In 2013, we are going to organise few trainings around the world mostly during security conferences but also in-house training (if you are interested shoot me an email: louis_*at* :)

Happy first year PentesterLab ;)

Saturday, 22 December 2012

Test-Driven Security

For many years, security coding has been a problem in many companies. So far, the following solutions have been implemented with more or less success:

  • teach people a list of dangerous functions and how to avoid them or use them securely. This method mostly comes from the old "don't use strcpy" mentality.
  • teach people what type of vulnerabilities exist and how to prevent them. We can call that the "OWASP top10" method. 
  • Only hire the best developers. We can call that the "successful startup" model. However there is only a limited number of best developers and everyone does mistakes.

With more and more frameworks and all the protection in place (automatic data mapping, XSS protection, automatic CSRF protection). The traditional issues are less and less relevant (if you already have a SDLC and care about security, this obviously does not apply to people getting a PHP website done by a trainee in 2 weeks). Most of the issues are now based on business logic and corner cases.

Test-Driven Security is another really simple method: instead of asking developers to write secure code,  this method just explain how to test if their code is secure and tell them to test the security of their code like they will do for any other functions. 

The problem with tests is that most people only do "positive testing", something works ("WINNING") or does not. Test-Driven Security is based on "negative testing" and make sure that things cannot happen: testing that things do not work.

For example, if you want to test authentication, you should add the following test cases:
 - Can I log in without password: it sounds silly but how many of you are 100% sure that your application is not vulnerable to this (especially if you have a LDAP backend, try to remove the password parameter from your login request) ?
 - Can I log in with the wrong password?
 - Can I log in with only the first 8 letters of my password ?
 - ...

You can do the same thing for authorisation: 
 - Can I access someone else personal information
 - Can I edit someone else personal information 
 - Can I reset someone else password
 - ...

Another point is testing for "Breaking the syntax", that I already covered in a previous post.

The good thing about adding all these checks inside your tests is that these checks will be performed as often as you run your tests... and you will be 100% sure that these security questions are covered, and that no regression happens between two releases of your application.

I did a talk on this few months ago at OWASP Melbourne, and most of the questions were around the return of investment of this method. To be honest, that's a really good question and I have no metrics on this. But I think that it's not too much work to "teach" people how to do that and get 100 test cases written to cover the basics, especially if you compare that to the price of a pentest...

Wednesday, 5 December 2012

How not to get a good pentest?

As an introduction, you should probably read "Maker's schedule, Manager's schedule" (don't be afraid by the startup ad it's a really good read) for more inside on how pentesters (makers) (should) work.

I put together a list of things that will ensure you don't get a good pentest:
  • Make sure a WAF and/or IDS are used and don't put the testers in a white-list.
  • Organise a lot of meetings, the rule is "the more meetings... the better".
  • Make sure you don't get a technical person involved during the scoping of the test/application.
  • Make sure you put multiple layers of people between the testers and the developers/sysadmins, if you don't they may be able to have all information in time and move forward quickly... It works for the remediation part as well.
  • Ask for information (full write-up) on discovered issues as soon as they appear and make sure you fix them as soon as possible. This way testers won't find more in-depth issues in your system and the down time due to fixes will ensure they can't work.
  • Don't provide access to source code if needed. EVER. 
  • Make sure some performance tests are performed during the security testing... nothing like a really slow environment when you're doing security testing.
  • Make sure there is no sample of data provided and that the databases are as empty as possible
  • Ask for daily updates, or even better twice a day... (see maker's schedule above to understand this)
  • Make sure you don't provide administrator/root access during host review. 
  • Don't provide internet access to testers... They may need to search for something or download a tool.
  • Make sure the first day is spent waiting for credentials or waiting for the environment to be setup.
  • Make sure test and production environments are as different as possible.
  • Make sure the environment is constantly changing, new features added, the application can't look the same on the first day and the last day.
Any other ideas?