Offensive security Pentesting with backtrack

I'm currently doing the Offensive security online training "Pentesting with Backtrack"

I chose this for my first course for certification due to the good things I had heard and that is a much more practical course than theory. It does, of course give a lot of theory along the way, but it teaches you how to really do them in a real life situation.
I'm currently nearly a week in and really enjoying the course (even though it has involved a few late nights as it is coinciding with a project at university. The thing I am liking most about the course so far is that it really encourages you to try extra things by making them count for something at the end.
I've learnt a lot more python already in just a week and I feel I will be using it to automate things a lot more often in the future.

I particularly liked this script I just created which scans a subnet for smtp servers (port 25 only),
but even this could easily be adapted for other things, and a more generic version could be accomplished just by using another argument that accepts a port number.

But here is the code for 'smtpPing.py' -

#!/usr/bin/python2.5 -tt

import socket, sys

if len(sys.argv) != 2:
  print "Usage    :", sys.argv[0], " "
  print "example  :", sys.argv[0], " 192.168.13."
  sys.exit(0)

subnet = sys.argv[1]
if not subnet.endswith('.'):
  subnet+='.'
for i in range(254):
  ip = i + 1
  ip = subnet+str(ip)
  try:
    #create a socket
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    #set timeout in seconds
    sock.settimeout(2)
    #connect to a server
    connect = sock.connect((ip, 25))
    #close socket
    sock.close()
  #if error occurs
  except socket.error:
  #carry on to the next IP
    continue
  else:
  #print the IP if you didn't catch an error
  #as this means that it connected i.e. smtp server running on machine
    print ip

and if you want to learn more about python in general (as I will be using it in my university project, I thought it would be handy to learn anyway), I've found for starters, a good source is the Google's Python class videos by Nick Parlante, which can be found here:

http://code.google.com/edu/languages/google-python-class/

How to destroy a company and be a better pentester for it

Chris Nickerson’s recent talk at BruCON was probably the one that made my way of thinking change the most.

He pointed out the fact that the way things are currently being done, just DOES NOT WORK.

Just because you do a pentest, get root and go “look, I got root, I just p0wn3d you b14tch!!!111” – this doesn’t really mean anything to them. Whereas to a lot of security professionals, this means a hell of a lot and it is a major problem. But to the head of a company, we could be talking an alien language.

Unless we show them what somebody could do with these exploits, then we are doing a bad job, as they won’t think it is that important, and they won’t fix the problems.

I don’t necessarily think we need to go as far as some of the suggestions made in the talk, (for example taking pictures of the CEO’s children and saying you could kidnap them may not be the best idea) but we are able to show some of the things that could be possible. So if you have root on the payroll system, you could show how you could print everybody’s payment details, showing their bank details and telling each person how much they earn compared to the person sitting next to them, and how this could affect the company.

As in the end, this is all these people will care about. We aren’t the ones who need to make the decisions on what would be best for the company, as however much it may annoy us, it could be economically better for the business not to fix certain faults, they will only pay out money that really needs the investment. So if you show that they really need to fix this vulnerability in their network, or there could be some real consequences to their business.

I want to thank Chris for such a great presentation and for pointing out how much we suck, so that hopefully we can all eventually be better at our jobs.

Cloud computing can be a great thing, who knew?

When I went to BruCON recently, one of my favourite presentations was ‘Project Skylab 1.0: helping you get your cloud on’ from Craig Balding.

The full presentation slides can be found here: http://www.feedsite.org/security4all/BruCON_2010_skylabv2.pdf

The thing that I mostly liked about this talk, among with the other great ones, was the fact it really got me thinking and that I had ideas flying through my head as the talk was still being done.

I have always been very skeptical of so called ‘Cloud Computing’.

This is due to the way it is used by companies and within the media, when they use it as such a general term that is trending at the moment. And it is used in such ways that if you add that it is ‘in the cloud’ the your product must be undeniably amazing.

I have also been skeptical of it due to the fact that when using these services, you are expected to just trust the company you are using, when they don’t really give any indication that they are trustworthy, apart from them perhaps having a well known name – and just because your company name is amazon, or Google, does this mean that I should trust you more with my data than a random stranger in the street I’ve never met before?

But as Craig pointed out, there are 3 layers in the cloud services model (which I didn’t realise):

Software as a service (Saas) – which is the basic one that everybody has heard of,

Platform as a service, and the last layer (which I hadn’t heard of),

Infrastructure as a service.

Now I found this last service really interesting, mostly as he was using examples that could relate to specifically to the security industry, but it was also the service that had me thinking about the possibilities and real advantages that cloud computing could have to me specifically. This is another reason I had never really cared much hearing about cloud computing, as I had never really thought of any great advantages that I could have testing, or exploiting.

I’m not going to go into great detail of what Craig discussed in his presentation, as (even just for the cool slides) you should check them out for yourself (link at top).  But an example that I specifically remember is the idea of being able to use infrastructure as a service easily for password cracking, as you could use VMs on demand, distributing the cracking over the many VMs, and if you wanted it quicker, you could just pay to use more VMs.

At last I’ve found a reason to actually really look forward to cloud computing, and this also doesn’t have as many security concerns, (for me at least, which after all would be my main concern when using cloud computing) as most uses would be on an on-demand basis, so the data used probably wouldn’t be that important, as I wouldn’t be expecting to keep it. And if there was, you could always build a personal server for cloud use of important data.

In the end it was a good presentation, that really got me thinking, which is probably why I enjoyed it so much. And I advise you to check it out yourself.

The video of the presentation should be available shortly through the BruCON website http://2010.brucon.org/

Brucon 2010 - my thoughts

This was the second year of BruCON, and my first time and my first time at any security/hacker conference at all, so as you can imagine, it was a little disconcerting.
To start off with it was a bit scary, going there on my own (I was supposed to be going with friend who couldn’t make it), country I'd never been to, and using language I didn't know, and since I’m just a student at university, spending a lot of my free time studying security and trying to keep up with everything I already felt a bit of an outsider to the whole community there. I didn’t really know anybody there (by that I mean I’ve spoken to a few of the people on Twitter, but it isn’t the same). And there’s also the fact I don’t actually work in security, I don’t work in the same environment day in day out, so there will obviously be a lot of stuff that is way over my head, as I am still just learning a lot of the stuff.

Due to the fact that I didn’t know many people, I still spent as little time as possible socialising (not sure whether it was the best tactic or not), but this meant that I spent all the time in presentations and workshops.
And if I was forced to describe the whole thing in one word, it would be awesome!



Obviously, there were some presentations/workshops better than others, but this is just a human reaction to compare things. But the best presentations and workshops were the ones that got me really thinking about that specific part of security, like Didier Steven’s workshop on malicious PDF analysis, or Craig Balding’s presentation on cloud computing and Chris Nickerson’s presentation, “Top 5 ways to steal a company” which ended being edited slightly.


I wish I had tried more to socialise though, as once I had got into it (mostly on the second day), it was really interesting to talk to people about things I did and didn’t know about and meet a few of the people I regularly read blog posts from or follow and talk to on twitter.


I wish I could’ve made it to a couple of the other workshops, like the DVWA and lockpicking workshops, and Samy Kamkar’s talk “How I met your girlfriend” which I was only unable to attend due to the small size of the room.

I fully intend to be booking my ticket for next year as soon as they are released (and book a hotel in a better location next time), signing up for the hex factor, and perhaps even putting my name down for a lightning talk.
Basically, I thought BruCON was great, and as long as I can make it, I will be going next year, and hopefully go for the training on the days before.

New blog!

I have decided to maintain a second blog. This one specifically for information security (thus the name)

Anyway, this will be my main security blogging site, which will soon be running under my own domain name. I will be blogging much more frequently as well hopefully, but anyone who wants to read my other material can go to my other blog which can be found here.

Peter