There is a serious skills shortage in our industry. There are just not enough skilled hackers out there to fill all the open positions. In November of last year, I proposed a new approach for us at SensePost to address these concerns. I looked at what we could do as a company to ensure the next generation of hackers were being educated correctly (no, it's not about how you use a tool) and moulded into what we, at SensePost, perceive to be good penetration testers.
I termed this the SensePost Academy and it is a structured training programme for all new recruits looking at a life at SensePost in the Assessment team. It is a combination of basic technical + offensive attack approaches and client interaction skills that provide an excellent stepping stone for those looking at starting a career as a penetration tester. The academy runs for a period of six months, finishing with a final culminating exercise (CULEX) before the decision is made to accept the recruit into the assessment team as an unmonitored penetration tester. The SensePost Academy Review Board (SARB) oversees each recruit and is responsible for grading and testing the recruit on each phase, in addition to mentoring (or should that be tormenting?) them.
Interviews were performed, we wanted the right recruit and had to turn down a lot of people in the process, but we did find two gentlemen, and as a team, decided on our first ever recruits:
This theme tune would be played whenever they were addressed and as often as possible.
Over the past six months, they've been on many training courses internally, been shown the ways of the pwnage by the assessment team, presented at conferences and also developed and broken applications. Each phase was carefully monitored by the review board to ensure they were being moulded into a form we felt was right.
Finally, the CULEX week was upon us. A client application assessment (fictitious German company) and client feedback meeting. No hand holding, just perform the test like you've been shown and don't mess up.
After making them sweat, we took a vote this morning and I'm happy to welcome both Johan and Dane to our assessments team as Junior penetration testers.
If you think you'd be a good addition to the next academy intake, we've love to hear from you. Tweet us on @sensepost or email us at firstname.lastname@example.org
We recently ran our Black Hat challenge where the ultimate prize was a seat on one of our training courses at Black Hat this year. This would allow the winner to attend any one of the following:
Simply trying out this feature and viewing how it functions. Viewing the feed tester result, we noticed that the contents of the XML formatted RSS feed were echoed and it became clear that this may be vulnerable to XXE. The first step would be to try a simple XML payload such as:
It looks like we have some more XML being submitted.. Again we tried XXE and found that using "file://" in our payload created an error. There were ways around this, however the returned data would be truncated and we would not be able to see the full contents of flag2.txt... When stuck with XXE and not being able to see the result (or complete result) there is always the chance that we can get the data out via the network. To do this we needed to generate a payload that would allow us to fetch an external DTD and then "submit" the contents of our target file to a server under our control. Our payload on our server looked like this:
As soon as the XML decoder parsed our malicious payload, we would receive the base64 encoded contents on our server:
Now it was a simple matter of decoding the payload and we had the second flag. This was not the only way to get flag 2! It was the most "fun" way of doing it though and used a really handy method. Remember it for your next pentest...
The two runners up who both can claim one of our awesome 2014 t-shirts:
Vitaly aka @send9
Sash aka @secdefect
Starting-point: Read the contents of /home/spuser/flag1.txt
Once you've completed the challenge, email us with a screenshot of your victory and a short overview of how you did it.
The prize: The winner of this challenge will be offered a free seat on any one of the SensePost training courses at Black Hat 2014.
It's almost Black Hat time again and as always SensePost will be presenting numerous Hacking by Numbers training course, which we've rewritten this year. For more information on the training courses on offer at Black Hat this year, check out:
It was originally released as a PoC at 44Con 2012, but this version is a complete re-write, is 99% Python, modular, and just feels better. The 'modularity' is possibly the most important improvement, for reasons which will become apparent shortly.
We've also made it much easier to run Snoopy by itself, rather than requiring a server to sync to as the previous version did. However, Snoopy is still a distributed framework and allows the deployment of numerous Snoopy devices over some large area, having them all sync their data back to one central server (or numerous hops through multiple devices and/or servers). We've been working on other protocols for data synchronisation too - such as XBee. The diagram below illustrates one possible setup:
|ZigBee||Digi Xbee||1km to 80kms|
The distances can be increased with appropriate antennas. More on that in a later blog post.
git clone https://github.com/sensepost/snoopy-ng.git
1. To save data from the wireless, sysinfo, and heartbeat plugins locally:
snoopy -v -m wifi:iface=wlanX,mon=True -m sysinfo -m heartbeat -d <drone name> -l <location name>
snoopy_auth --create <drone name> # Create account
snoopy -v -m server # Start server plugin
snoopy -v -m wifi:iface=mon0 -s http://<server hostname>:9001/ -d <drone name> -l <location name> -k
There sure is a lot of stunt hacking in the media these days, with people taking existing hacks and duct-taping them to a cheap drone for media attention. We were concerned to see stories on snoopy airborne take on some of this as the message worked its way though the media. What's the benefit of having Snoopy airborne, then? We can think of a few reasons:
This blog post is about the process we went through trying to better interpret the masses of scan results that automated vulnerability scanners and centralised logging systems produce. A good example of the value in getting actionable items out of this data is the recent Target compromise. Their scanning solutions detected the threat that lead to their compromise, but no humans intervened. It's suspected that too many security alerts were being generated on a regular basis to act upon.
The goal of our experiment was to steer away from the usual data interrogation questions of "What are the top N vulnerabilities my scanner has flagged with a high threat?" towards questions like "For how many of my vulnerabilities do public exploits exist?". Near the end of this exercise we stumbled across this BSides talk "Stop Fixing All The Things". Theses researchers took a similar view-point: "As security practitioners, we care about which vulnerabilities matter". Their blog post and video are definitely worth having a look at.
At SensePost we have a Managed Vulnerability Scanning service (MVS). It incorporates numerous scanning agents (e.g. Nessus, Nmap, Netsparker and a few others), and exposes an API to interact with the results. This was our starting point to explore threat related data. We could then couple this data with remote data sources (e.g. CVE data, exploit-db.com data).
We chose to use Maltego to explore the data as it's an incredibly powerful data exploration and visualisation tool, and writing transforms is straight forward. If you'd like to know more about Maltego here are some useful references:
It's also worth noting that for the demonstrations that follow we've obscured our clients' names by applying a salted 'human readable hash' to their names. A side effect is that you'll notice some rather humorous entries in the images and videos that follow.
Jumping into the interesting results, these are some of the tasks that we can perform:
In summary, building 'clever tools' that allow you to combine human insight can be powerful. An experiences analyst with the ability to ask the right questions, and building tools that allows answers to be easily extracted, yields actionable tasks in less time. We're going to start using this approach internally to find new ways to explore the vulnerability data sets of our scanning clients and see how it goes.
In the future, we're working on incorporating other data sources (e.g. LogRhythm, Skybox). We're also upgrading our MVS API - you'll notice a lot of the Maltego queries are cumbersome and slow due to its current linear exploration approach.
The source code for the API, the somewhat PoC Maltego transforms, and the MVS (BroadView) API can be downloaded from our GitHub page, and the MVS API from here. You'll need a paid subscription to incorporate the exploit-db.com data, but it's an initiative definitely worth supporting with a very fair pricing model. They do put significant effort in correlating CVEs. See this page for more information.
Do get in touch with us (or comment below) if you'd like to know more about the technical details, chat about the API (or expand on it), if this is a solution you'd like to deploy, or if you'd just like to say "Hi".