After reading a post by Gursev Kalra here, I decided to have a shot at putting together a slightly expanded version of his ssl Cipher suite checking code in ruby.
I've got it working reasonably well in my tests and it can chuck out reports in text and XML . The code for the main script and a Metasploit module which does the same is here. Any feedback/suggestions welcome :)
I've been meaning to do a post on burp for a while, and courtesy of my new years resolution to stop procrastinating, here it is :)
I was thinking of a way to sum up burp, so far the best I've got is "If you're doing web application testing and not using Burp, you're missing out !", it is that useful...
Burp has been around for a while now as one of a group of handy web application proxy tools along with the likes of Web Scarab and Paros. Over time it's developed a huge range of handy features, which make web app. testing a lot more productive.
There's the basics, in terms of intercepting and modifying requests, which all the tools in this category tend to do quite well, but on top of that there's just loads of other things that Burp does.
The Web app scanner is a good targetable way to test for several types of common web app vulnerabilities. As an add-on in the latest beta, there's a wizard which lets you reduce the number of requests that Burps going to make, by removing duplicates and similar requests. If you've used many commercial web app. scanners you'll know that volume of requests generated can be a real problem, so anything that can help bring down the load is useful.
Another stand-out feature of Burp for me, is intruder which lets you pick a specific parameter or set of parameters from a request and easily modify them. As an example pretty much every time I see a URL that looks like request.asp?id=123 , it's going to be worth running burp Intruder over that parameter to see what pops up when you change that value.
One of the things I have found about burp is that it's easy to miss functions that are available and not get the best out of it. Luckily there's a blog which covers a lot of the new features as they come out. Also I need to mention the Burp Tip of the Day series of posts on Cktricky's blog which has loads of good tips on getting more out of Burp.
So, we're back from a bit of an unscheduled break for my web server. The hosting company had a bit of a problem with disks, so my VM has been out of action for a week or so.
Luckily, my backups worked pretty well so minimal content lost. I'm using the rather unorthodox backup over SMTP, which seems to work pretty well for smaller files. I knocked up a ruby class called Rbackup and just have a script running in cron nightly...
Actually had a trio of hardware failures over the festive period (2 hard disks and a graphics card), which just goes to show that checking backups (and restores!) is very important and not to be put off...
I got a Nokia N900 the other week and I've started playing around with the software.
At heart it runs Maemo Linux which is based on debian, so in theory any software that runs on debian should run on the phone !
Also unlike other smart phones which can be coaxed into running linux, the N900 has a shell out of the box and getting root access just requires a package install and issuing the "sudo gainroot" command.
So far I've found the ssh client pretty handy, and openvpn is available in the maemo-testing repository for all your vpn needs.
In terms of the hardware it's got a variety of interfaces which could be pretty cool for hacking testing. There's wifi and GPS for war-driving/walking and obviously having 3G data is pretty useful when out and about :)
Getting software to run on it, isn't always quite as straightforward as just apt-get, as the repositories don't have the breadth of the debian ones yet. So if it's not already available in maemo-extras/testing/devel then cross-compiling is the way to go.
The Cross-compile environment is reasonably straightforward to get set-up and there's instructions on the maemo wiki for packaging apps
So far I've ported nmap 5.00 across to it, and that runs just fine, kismet seems to run ok but the default console colours make it a bit unreadable, so more work there.
Ruby 1.8.7 is available in the repositories and I've had Metasploit running (albeit a bit slowly).
All in all it's definitely smarter than your average smart phone!
OWASP Scotland November meeting is next Thursday, the 26th. We've got something a bit different lined up with the main presentation being one on physical security and lock picking (hey if you can break into the server room and take the box, who needs SQL injection ;oP )
More information here
I've been using Dradis for a couple of months now. It's an interesting piece of software that's designed to help teams of people share information on penetration tests.
That said I find it useful on the tests I do even when I work alone.
Essentially Dradis provides the base environment for users to work in, either from the command line or the rails based web interface, and then pretty much lets them get on with it, so it can be a bit difficult to work out how you want to use it at first, but once you get used to it it's very handy!
What I've done is started to create templates for information that I need to collect during a test and areas to review, that way it reduces the number of times I get into writing the report and realised I've missed something ;o). Once you create the tree structure in Dradis, containing any information you want, you can export it as a single file and then re-use it as a template on future tests (for example one for web application tests, one for infrastructure etc)
you can also import information from other tools (nmap, nikto, nessus and burp at the moment) into Dradis, meaning you've got a single place to view all the information relating to the test.
It's well worth a look, as it's under active development there are new features coming pretty frequently. Also there are guides on the site for prospective developers and as it's all done in ruby it's nice and easy to start coding for!
The OWASP Scotland september meeting is all set for Tuesday the 15th of September.
We've got three good speakers lined up so, it's shaping up to be a good meeting.
More details here . Meeting is open to all, but if you're planning to come along, please RSVP to me at this address, so we can get an idea of numbers.
After encountering some SNMPv3 servers recently and looking into the differences from a pen. test perspective, I thought it may be worth a quick write-up.
SNMPv1 and v2 do not respond when traffic is sent their way unless there is a valid community string in the message, a fact used by scanners like onesixtyone . So traditionally the theory is unless there's a known community string, the service running has a vulnerability or you can get in-line to sniff traffic, there's not a lot to get from SNMP services.
Turns out that SNMPv3 behaves differently from v1 and v2. Firstly the notion of using community strings for authentication is gone, replaced by username/passwords. Second the traffic can be encrypted to limit sniffing opportunites.
However it's not all bad from a testers perspective! unlike earlier versions SNMPv3 will respond to correctly formatted requests and provide some information about itself as part of the reply. This allows confirmation of the servers existence.
To get these responses there's a couple of different tools we can use. Nmap with version detection will confirm that a SNMPv3 service is running and looking at the traffic in wireshark 
From this there's a couple of interesting pieces of information. The Engine Enterprise ID field seems to identify the server type that's running, net-snmp in this case and the msgAuthoritativeEngineTime parameter shows the time in seconds since the service was started (according to this page ).
In addition to using nmap, it's possible to use the inbuilt snmp tools to get some information out of the service including possible username enumeration and brute-force password attacks.
Issuing the snmpwalk command with an invalid username like so:
snmpwalk -v 3 -n '' -l noAuthNoPriv -u "invaliduser" 192.168.207.142 IF-MIB::ifName
provides the response snmpwalk: Unknown user name
but if we use a valid username and no password like so:
snmpwalk -v 3 -n '' -l noAuthNoPriv -u "snmpUser" 192.168.207.142 IF-MIB::ifName
we get Error in packet. Reason: authorizationError (access denied to that object)
So it's possible by parsing responses to figure out valid usernames for the service.
Update : Here's a ruby script (should work on linux with snmp tools and ruby installed) which iterates over a list of usernames and a list of IPs and attempts to guess whether the username is valid or not snmpv3enum.rb
A similar technique works with specification of passwords which would allow for brute-forcing those as well, (although that said the snmp tools try to stop people choosing passwords less than 8 characters, so unless a dictionary word is used it isn't too likely to be successful.
Additionally for people who're fond of metasploit, I've knocked up a very basic SNMPv3 scanner. At the moment all it does it take a range of IP addresses and say whether a valid SNMPv3 packet provokes a response from the server, but could be handy. it's here.
There's some good references on setting up and using SNMPv3 here, here and here.
So I got across to Defcon this year (and of course security Bsides)
There were several interesting presentations , here's some notes on some of the ones that I got along to. The CD is up at defcon.org, and you can get the slides for most of the presentations there.
SSL Talks - There were several presentations on ways to bypass or subvert SSL. From my point of view the drive was around 2 themes. The difficulty in correctly parsing SSL certs due to the complexity of the relevant RFCs and also the weaknesses in the issuing processes of some CAs (which is exacerbated by the fact that any CA can issue a "valid" cert. for any domain). Dan Kaminsky's white paper on the subject is here, Moxie's blackhat presentation is here and Michael Zusmans' blackhat presentation is here (the defcon presentations are on the CD linked above).
Metasploit - The Metasploit team had a whole track to themselves on Saturday and there's a load of interesting stuff in there, basically looks like Metasploit will have some coverage for most types of assessment eventually, which is very handy!
Egypts presentation on client-side attacks with Metasploit had some great content on browser fingerprinting (not just relying on User-Agent) and client side attacks with Metasploit.
The Oracle presentation from mc and Chris Gates had some good content on going through the steps of an Oracle attack purely using Metasploit (more information on this on CG's blog
Druid had a good talk on the war-dialer that he's added to the framework (unfortunately the slides for that one aren't on the CD, but I'd guess that they'll be around soon). Another interesting thing in the Metasploit track was the demos of the Mac OSX and POSIX versions of meterpreter which are both in active development.
Other Ruby Tools - There was a bit of a theme of ruby tools across some of the presentations. In addition to all the Metasploit stuff, there was a mobile device fuzzer (although the website for it, www.fuzzit.com isn't up yet). Also there was a good presentation on Dradis from etd , which is a Pen test management and reporting tool written in Ruby and Rails.
Password Cracking - There was a good presentation, from Matt Weir, on approaches to password cracking, speeding up brute-force attacks and picking good dictionary files . There's more informaton on this one on his blog as well as on the presentation slides.
Router Hacking - FX had some more information on how to create reliable exploits on Cisco devices and the difficulties in doing so (amazing to think that Cisco Maintain thousands of discreete monolithic router builds!). Slides from the Blackhat presentation are here and White paper here
USB Hacking - Interesting presentation from a guy from MWR on how they approached an assignment to assess the security of a USB device and the approaches to fuzzing that they took. Slides are up on their site here
So I'm off to Defcon and security BSides next week, and I thought a couple of precautions were in order before I go...
1. Tunnel all traffic through SSH to a trusted host, instructions here
2. Set iptables up to explicitly deny any traffic not travelling through the tunnel
3. Turn off any vaguely network related features on my iPhone!
