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
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".
BlackOps you say?
At SensePost we have a range of courses in our Hacking by Numbers reloaded series. We feel each one has its own special place. I've delivered almost all the courses over the years, but my somewhat biased favourite is our recently updated BlackOps Edition. Myself (Glenn) and Vlad will be presenting this course at BlackHat Vegas in August.
Where Does BlackOps fit in?
Our introductory courses (Cadet and Bootcamp) are meant to establish the hacker mindset - they introduce the student to psychological aspects of an attacker, and build on that to demonstrate real world capability. BlackOps is designed for students who understand the basics of hacking (either from attending Bootcamp/Cadet, or from real-world experience) and want to acquire deeper knowledge of techniques we use. We built the course based on our 13 years of experience of performing security assessments.
But really, what's the course about?
This course is aimed at those who've been performing penetration testing for a while, but still feel a bit lost when they've compromised a host, or network and want to know the best possible approach to take for the next step. All of the labs in this course come from real life assessments, with the final lab being a full-blown social engineering attack against an admin with pivoting, exfiltration and the works. Specifically, we're going to cover the following topics:
1. Advanced Targeting
A hacker who can quickly and effectively identify targets is a successful attacker. We'll be looking at non-standard techniques for identifying targets, such as mDNS, IPv6, and other rapid reconnaissance techniques.
You may know how to roll a generic metasploit payload, but we'll be looking at some lesser utilised approaches to compromise. From WPAD injection, to rogue routers in IPv6, to good old smbrelay attacks, to crypto attacks against obfuscated credentials.
4. Privilege Escalation
So you've gotten a shell, now what?
Following on somewhat succinctly, how do you elevate your privileges after compromising a box? Everyone wants to be root or enterprise admin, but how do you go about this without raising the alarm and keeping your shell?
Don't underestimate the importance, or intricacies of this topic. Once you've compromised a lowly network edge server, or the receptionist PC, how do you bounce through that box to get to the good stuff, three DMZs deep? We'll show you how. A must-have for every hackers box of tricks.
6. Open Source Intelligence (OSINT)
Finding out as much as possible about an adversary from publicly available information is one of the most important steps of any hack. This relates to both infrastructure (domains, IP ranges, etc) and personnel. In this section we'll focus mainly on the latter. How can you find out more information about the girlfriend of the son of your target company's CEO? We'll show you. Why would you want to? A good social engineering attack abuses trust relationships, so nothing makes a dad click on that dodgy looking email if it was from his son.
7. HIPS Evasion
Hackers don't like getting caught. So we'll teach you how to evade 100% (yes, 100%) of anti-virus products on the market, as well as hiding from smart traffic filtering devices. Bring your own ninja outfits, we'll provide the skill-set.
8. Client Side Attacks
The weakest layer of the OSI stack - the human. Trust us, if you really want to compromise an organization, going after the receptionist's outdated Windows box is the first stepping stone. After all, why wouldn't she open an email that appears to come from her boss, and has a harmless .xls attached?
Each module of the above modules has a theory section followed by a practical lab to allow you to practise your newly acquired skills. The course finishes with a Capture-the-Flag, with a grand prize. Honestly, this final lab is enjoyable and guaranteed to bring a smile on your face whilst doing it.
We're looking forward to sharing out knowledge, experience, and passion for security with you. Please sign up here.
-Glenn & Vlad
A few years ago we made the difficult, and sometimes painful, shift to enable remote working in preparation for the opening of our UK and Cape Town offices. Some of you probably think this is a no-brainer, but the benefit of being in the same room as your fellow hackers can't be overlooked. Being able to call everyone over to view an epic hack, or to ask for a hand when stuck is something tools like Skype fail to provide. We've put a lot of time into getting the tech and processes in place to give us the "hackers in the same room" feel, but this needs to be backed with some IRL interaction too.
People outside of our industry seem to think of "technical" people as the opposite of "creative" people. However, anyone who's slung even a small amount of code, or even dabbled in hacking will know this isn't true. We give our analysts "20% time" each month to give that creativity an outlet (or to let on-project creativity get developed further). This is part of the intention of SenseCon: a week of space and time for intense learning, building, and just plain tinkering without the stresses of report deadlines or anything else.
But, ideas need input, so we try to organise someone to teach us new tricks. This year that was done by Schalk from House 4 Hack (these guys rocks) who gave us some electronic and Arduino skills and some other internal trainings. Also, there's something about an all-nighter that drives creativity, so much so that some Plakkers used to make sure they did one at least once a month. We use our hackathon for that.
Our hackathon's setup is similar to others - you get to pitch an idea, see if you can get two other team mates on board, and have 24 hours to complete it. We had some coolness come out of this last year and I was looking forward to seeing what everyone would come up with this time round.
Copious amounts of energy drinks, snacks, biltong and chocolates were on supply and it started after dinner together. The agreed projects were are listed below, with some vagueness, since this was internal after all :)
Keiran and Dane put our office discone antenna to good use and implemented some SDR-fu to pick up aeroplane transponder signals and decode them. They didn't find MH370, but we now have a cool plane tracker for SP.
Using wifi-deauth packets can be useful if you want to knock a station (or several) off a wifi network. Say you wanted to prevent some cheap wifi cams from picking you up ... Doing this right can get complicated when you're sitting a few km's away with a yagi and some binoculars. Charl got an arduino to raise a flag when it was successfully deauthed, and lower it when connectivity is restored for use in a wifi-shootout game.
Panda (Jeremy) and Sara ended up building local Maltego transforms that would allow mass/rapid scanning of large netblocks so you can quickly zoom in on the most vulnerable boxes. No countries were harmed in the making of this.
gcp and et decided on some good ol'fashioned fuzz-n-find bug hunting on a commercial mail platform, and websense. Along the way they learned some interesting lessons in how not to fuzz, but in the end found some coolness.
The hackathon went gangbusters; most of the team went through the night and into the morning (I didn't, getting old and crashed at 2am). Returning that morning to see everyone still hacking away on their projects (and a few hacking away on their snoring) was amazing.
Once the 24-hours was up, many left the office to grab a shower and refresh before having to present to the entire company later on that afternoon.
Overall this years SenseCon was a great success. Some cool projects/ideas were born, a good time was had AND we even made Charl feel young again. As the kids would say, #winning