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 (imgur.com, 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*_pentesterlab.com) :)

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?