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