Grey bar Blue bar
Share this:

Thu, 5 Jun 2014

Associating an identity with HTTP requests - a Burp extension

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'?"


Associating an identity with the requests


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.


Pivoting requests against the user


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.

Tue, 20 May 2014

Mobile Training Reloaded - Las Vegas

Get some.

Exploiting next gen apps
With the explosion in mobile device popularity and the applications that go along with these, testing mobile application security has become a key skill in every pentester's arsenal. Last year we launched the Hacking by Numbers: Mobile, course at BlackHat Las Vegas and follow up training at BlackHat WestCoast Trainings. This year we are taking Mobile training to the next level with Hacking by Numbers reloaded, Mobile Bootcamp (https://www.blackhat.com/us-14/training/hacking-by-numbers-reloaded-mobile-bootcamp.html)


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.

You said mobile?


The mobile space has numerous platforms, each with their own nuances, that would leave any new pentester dizzy. Fortunately this is where the Mobile bootcamp course excels, offering the perfect blend of introductory and advanced techniques, the training is ideal for anyone looking to start testing mobile applications or the experienced tester who is looking to branch out to new platforms.


The training introduces all the core skills required to test applications across the major mobile platforms, particularly:


  • Android

  • IOS

  • Blackberry

  • Windows Phone 8


Training is built around around demonstration and hands-on practical exploitation, with custom practical exercises derived from real-world application security fails.


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)

Who should attend?


The course is relevant for attackers, defenders and developers. Students should have some technical ability in Linux, and understand networking fundamentals, but this is a bootcamp level course. Basic programming knowledge is recommended but not essential.


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 -


 


 

Thu, 15 May 2014

BlackOps Hacking Training - Las Vegas

Get some.


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.


3. Compromise
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?


5. Pivoting
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

Fri, 7 Feb 2014

Channel 4 - Mobile Phone Experiment


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:


  • Browsing history

  • Cookies (e.g. email and Facebook)

  • Contacts

  • SMS messages

  • Photographs

  • Address information

  • Personal documents


It would have been theoretically possible to use the cookies to impersonate the users - i.e. log in as the previous owners. We opted not to do this, as it was crossing an ethical line.

What's the lesson here?


Be very careful when selling your phone. It's fairly trivial to recover large amounts of data from mobile phones - and the tools to do so are freely available.

How can I protect myself?


This will depend on what type of phone you have, and specifically whether the data is encrypted, and if it is, if the key is recoverable. Unencrypted phones were easy game.


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.

Mon, 20 Jan 2014

January Get Fit Reversing Challenge

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.

The Setup


This simple reversing challenge should take 4-10+ hours to complete, depending on your previous experience. The goal was to create an interactive challenge that takes you through different areas of the reverse engineering process, such as file format reverse engineering, behavioural and disassembly analysis.


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

The Scenario


You've been called into ACME Banks global headquarters to investigate a breach. It appears Evilgroup has managed to breach a server and deploy their own executable on it (EvilGroupVM.exe). The executable is software that accepts bytecode files and executes them, similar to how the Java Virtual Machine functions. Using this technique, Evilgroup hopes they can evade detection by antivirus software. Their OPSEC failure meant that both the virtual machine executable and several bytecode files were left behind after the cleanup script ran and it's your job to work out the instruction set of EvilGroupVM.exe.


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:


  • A hex editor (any will do)

  • A disassembler like IDA (the free version for Windows will work if you don't have a registered copy)

  • A debugger, Olly or WinDBG on Windows, Gnu GDB or EDB on Linux https://www.gnu.org/software/gdb/


Basic Usage: Unzip the reverseme folder, open a command line and cd to it. Depending on operating system, type
Windows: EvilGroupVM.exe <BytecodeFile>
Ubuntu Linux: ./EvilGroupVM <BytecodeFile>

For example, to run the helloworld bytecode file on Windows, you would type:
EvilGroupVM.exe helloworld

IMPORTANT: Note that the EvilGroupVM.exe architecture has debugging capabilities enabled. This means, it has one instruction that shows you the thread context of a binary when it is hit. Once you start developing your own bytecode binaries, it is possible to debug them (but you need to find the debug instruction/opcode first).


The outcome of this exercise should include the following key structures in your report:


  1. A description of the binary file format. For example:

    • What does the bytecode file header look like?

    • What determines where execution will start once the bytecode is loaded in the VM?

    • Does the architecture contain other parts of memory (like a stack) where it can store data and operate on them?


  2. The instruction set including their impact on the runtime memory. You should:


    • Find all instructions that the EvilGroupVM.exe accepts

    • Analyse each of them and understand how they make changes to the runtime memory of the bytecodes thread


  3. Write a proof of concept self modifying bytecode file that prints your name to the screen. The binary must be self modifying, that is, you may not use the "print_char" instruction directly, rather, the binary must modify itself if it wants to make use of "print_char".

  4. For the advanced challenge, if you have the ability and time, send us back a C file that, when compiled, will give an almost exact match compared to EvilGroupVM (Ubuntu Linux) or EvilGroupVM.exe (Windows). Focus on getting pointer arithmetic and data structures correct.


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


Good luck!