This is a tool that I have wanted to build for at least 5 years. Checking my archives, the earliest reference I can find is almost exactly 5 years ago, and I've been thinking about it for longer, I'm sure.
Finally it has made it out of my head, and into the real world!
Be free! Be free!
So, what does it do, and how does it do it?
The core idea for this tool comes from the realisation that, when reviewing how web applications work, it would help immensely to be able to know which user was actually making specific requests, rather than trying to just keep track of that information in your head (or not at all). Once you have an identity associated with a request, that enables more powerful analysis of the requests which have been made.
In particular, it allows the analyst to compare requests made by one user, to requests made by another user, even as those users log in and log out.
There are various ways in which users can be authenticated to web applications, and this extension doesn't try to handle them all, not just yet, anyway. It does handle the most common case, though, which is forms-based auth, with cookie-based session identifiers.
So, as a first step, it allows you to identify the "log in" action, extract the name of the user that is authenticating, and associate that identity with the session ID until it sees a "log out" action. Which is pretty useful in and of itself, I think. Who hasn't asked themselves, while reviewing a proxy history: "Now which user was I logged in as, when I made this request?" Or: "Where is that request that I made while logged in as 'admin'?"
So, how does it do this? Unfortunately, the plugin doesn't have AI, or a vast database of applications all captured for you, with details of how to identify logins and logouts. But it does have the ability to define a set of rules, so you can tell it how your app behaves. These rules can be reviewed and edited in the "Options" tab of the Identity extension.
What sort of rules do we need? Well, to start with, what constitutes a valid logon? Typically, that may include something like "A POST to a specified URL, that gets a 200 response without the text 'login failed' in it". And we need to know which form field contains the username. Oh, and the sessionid in use by the application, so that the next time we see a sessionid with the same value, we can link that same identity to that conversation as well.
The easiest way to create the login rule is probably via the Http Proxy History tab. Just right click on a valid login request, and choose "Identity -> create login rule". It will automatically create a rule that matches the request method, request path, and the response status. Of course, you can customise it as you see fit, adding simple rules (just one condition), or complex rules (this AND that, this OR that), nested to arbitrary levels of complexity. And you can select the session id parameter name, and login parameter name on the Options tab as well.
Awesome! But how do we identify when the user logs out? Well, we need a rule for that as well, obviously. This can often be a lot simpler to identify. An easy technique is just to look for the text of the login form! If it is being displayed, you're very unlikely to be logged in, right? That can also catch the cases where a session gets timed out, but for the moment, we have separate rules and states for "logged out" and "timed out". That may not be strictly necessary, though. Again, these rules can be viewed and edited in the Options tab. Another easy way to create the logout rule is to select the relevant text in the response, right-click, and choose "Identity -> create logout rule".
Sweet! So now we can track a series of conversations from an anonymous user, through the login process, through the actions performed by the person who was logged in, through to the end of that session, whether by active logout, or by inactivity, and session timeout, back to an anonymous user.
Most interestingly, though, by putting the conversations into a "spreadsheet", and allowing you to create a pivot table of selected parameters vs the identity of the person making the request, it becomes possible to almost automate the testing of access control rules.
This tool is not quite at the "automated" stage yet, but it does currently allow you to see which user has performed which actions, on which subject, which makes it almost trivial to see what each user is able to do, and then formulate tests for the other users. You can also see which tests you have executed, as the various cells in the pivot table start filling up.
In this screenshot, we are pivoting on the path of the URL, the method (GET vs POST), and then a bunch of parameters. In this application (WordPress, just for demonstration purposes), we want the "action" parameter, as well as the parameter identifying the blog post being operated on. The "action" parameter can appear in the URL, or in the Body of the request, and the "post" parameter in the URL identifies the blog post, but it is called post_ID in the body. (It might be handy to be able to link different parameters that mean the same thing, for future development!). The resulting table creates rows for each unique parameter combination, exactly as one would expect in an Excel pivot table.
Clicking on each cell allows you to get a list of all the conversations made by that userid, with the specific combination of parameters and values, regardless of the number of times that they had logged in and out, or how many times their session id changed. Clicking on each conversation in the list brings up the conversation details in the request/response windows at the bottom, so you can check the minutiae, and if desired, right-click and send them to the repeater for replay.
So far, the approach has been to manually copy and paste the session cookie for a different user into the repeater window before replaying the request, but this is definitely something that lends itself to automation. A future development will have an option to select "current" session tokens for identified users, and substitute those in the request before replaying it.
So far, so good! But, since the point of this extension is to check access controls, we'd ideally like to be able to say whether the replayed request was successful or not, right? There's a rule for that! Or there could be, if you defined them! By defining rules that identify "successful" requests vs "failed" requests, conversations can be tagged as successful or not, making it easier to see when reviewing lists of several conversations. Future development is intended to bring that data "up" into the pivot table too, possibly by means of colouring the cells based on the status of the conversations that match. That could end up showing a coloured matrix of successful requests for authorised users, and unsuccessful requests for unauthorised users, which, ultimately, is exactly what we want.
We'd love to hear how you get on with using this, or if you have any feature requests for the plugin. For now, the BurpId plugin is available here.
The course has undergone the full reloaded treatment, with our trainers pouring new tips, tricks and skills into the course, along with incorporating feedback from previous students.
The training introduces all the core skills required to test applications across the major mobile platforms, particularly:
For a full break-down of the course structure check-out our BlackHat training page (https://www.blackhat.com/us-14/training/hacking-by-numbers-reloaded-mobile-bootcamp.html)
Your trainers will be Etienne (@kamp_staaldraad) and Jurgens, both crazy about mobile security and have executed numerous killshots on all the major mobile platforms.
- Etienne and Jurgens -
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
This evening we were featured on Channel 4's DataBaby segment (link to follow). Channel 4 bought several second hand mobile phones that had been "wiped" (or rather reset to factory default) from various shops. Our challenge was to recover enough data from these seemingly empty phones to identify the previous owners.
After a long night of mobile forensics analysis, we had recovered personal data from almost every phone we had been provided with. This information included:
iPhone devices encrypt their data by default, which makes it hard (almost impossible) to recover data after performing a factory reset. There are some attacks against iPhones older than 4s which may have more success.
Android devices by default have no encryption, which means that somebody (like us) could easily recover large amounts of supposedly deleted data. It's a good idea to keep your phone encrypted.
Both Windows phone 8 and BlackBerry allow optional encryption to be configured, but this is not enabled by default. Windows phone 7 does not support encryption of the core filesystem.
If you have an existing phone that you're about to sell we'd recommend you encrypt the phone twice after resetting it to factory default (once to destroy your data, the second time to destroy the key used for the first round).
Keep in mind, this applies to all storage media - hard drives on laptops, camera memory cards, etc. It's largely recoverable, even when seemingly deleted.
We would like to thank Paolo Dal Checco (@forensico) and fellow SensePost'er Vlad (@v1ad_o) for their help during the experiment.
On a legal note, the experiment was conducted on a laptop with full disk encryption, and *all* data was deleted after returning the phones to Channel 4.
Aah, January, a month where resolutions usually flare out spectacularly before we get back to the couch in February. We'd like to help you along your way with a reverse engineering challenge put together by Siavosh as an introduction to reversing, and a bit of fun.
Once you reached the final levels, you might need to spend some time understanding x86 assembly or spend some time refreshing it depending on your level. To help out, Siavosh created a crash course tutorial in x86 assembly for our malware workshop at 44con last year, and you can download that over here.
The zip file containing the reversing challenge and additional bytecode binaries could be found here.
Send your solution(s) to challenge at sensepost.com
Disclaimer: When using the term "virtual machine" we mean something like the Java Virtual Machine. A software based architecture that you can write programs for. This particular architecture, EvilGroupVM.exe, has nine instructions whose operation code (opcode) you need to find through binary reverse engineering.
The tools you will require are:
Windows: EvilGroupVM.exe <BytecodeFile>
Ubuntu Linux: ./EvilGroupVM <BytecodeFile>
The outcome of this exercise should include the following key structures in your report:
In case you missed it earlier, the zip file containing the reversing challenge and additional bytecode binaries could be found here.
Send your solution(s) to challenge at sensepost.com