One of the things we try and get across in our training - is that pen-testing requires out of the box thinking. It's also about solving puzzles and making things work the way you want them to. It's about identifying the small vulnerabilities (which are often easy to spot), and trying to leverage them into something useful. A key process we strive to do at SensePost, when performing these penetration tests, is about having fun.
However, since we're not presenting our HBN Combat course at BlackHat this year, we thought we'd treat people to a nice, mind-boggling challenge prior to BlackHat. Furthermore, instead of opting for the normal crypto or reversing-type challenges which seem to have become the norm, we thought we'd make it an infrastructure challenge for once. In other words, people get to compromise real, live boxen. We've also made it real-world, this is something you might be faced with when performing a infrastructure test.
You've been tasked with performing an infrastructure assessment against ACME Bank. You've fired up your favorite foot printing tool, run through the usual intelligence gathering methodology and noticed they seem to have a minute Internet footprint. So small, in fact, that the only entry point you have is what appears to be a router at 188.8.131.52.
Obtain access to a host on the internal network and put your name on the wall of fame. The first name on the wall wins.
If one takes a quick glimpse at the target, it will be obvious that the person who makes the first break is probably going to be able to control what other people do (with great power comes great responsibility). Also, there is probably a relatively high chance of people inadvertently blocking themselves off from the target. As such, the challenge is going to be reset to "factory default" at 04h00 MT every day.
We've created a very cool SensePost Blackhat USA 2013 t-shirt and this is limited edition to SensePost staff only, but for the person who gets the first name on the wall, we think you deserve your own.
Have fun, happy haxoring, and hope to see you all at BlackHat.
We have an updated breakdown of our BlackHat courses here
With the 'early registration' discount period coming to an end on May 31, I wanted to provide an overview of what courses we're offering and how those courses fit together.
Please be sure to take advantage of these discounted prices whilst they're still available. This summary will help you decide which course is best for you...
1. "Cadet" is our intro course. It provides the theoretical and practical base required to get the most of our other courses. Don't let the introduction title put you off, this course sets the stage for the rest of the course, and indeed fills in many blanks people might have when performing offensive security assessments. We only offer it on the weekend (27th & 28th) but its really popular so we've opened a 2nd classroom. Plenty of space available, so sign up!
2. "Bootcamp" is our novice course. Its a legendary program that we've offered successfully for almost 10 years now. The course is modified and updated each year to reflect new thinking, paradigms and attack vectors, but its real beauty is in the fundamental and unchanging principles and thinking skills it presents. We've opened up additional classrooms also, so we can accommodate plenty of people.
3. Our "Unplugged" course is an entry-level wireless security-training course. It is done in the same style as our other HBN courses; highly practical with a focus on learning how things work, not just the tricks. Last year "Unplugged" sold out quickly but this year we have additional space. But please sign up before we can't take any more people there.
4. "BlackOps" is a student's final course in the Hacking By Numbers series before being deployed into "Combat." In BlackOps, students will sharpen their skills in real-world scenarios before being shipped off to battle. BlackOps covers tools and techniques to brush up your skills on data exfiltration, privilege escalation, pivoting, client-side attacks and harnessing OSINT. Students will also focus on practical elements of attacking commonly found systems and staying under the radar. BlackOps also sold really well last year, and and we can't open additional classrooms, so please sign up early.
5. "Mobile" is our very first Mobile Hacking course, and the first of its kind for beginners in this field. As mobile phone usage continues to grow at an outstanding rate, this course shows you how you would go about testing the mobile platforms and installed applications. "Mobile" will give you a complete and practical window into the methods used when attacking mobile platforms. This course is ideal for penetration testers who are new to the mobile area. Our enrolments have just reached double-figures and seats are limited, so please sign up early.
If you need help selecting the right course, or getting registered, please contact us via training[at]sensepost[dot]com.
About 50 people have already signed up. Register now to benefit from the early-registration discounts and join us in Vegas in July!
A break down of what will be covered during this course:
What? SensePost Hacking by Numbers, Bootcamp edition
Where? Amsterdam, BlackHat EU
When? 12th & 13th March 2013
See the BlackHat course page for more information, or to book your seat.
We're looking forward to seeing you there!
Glenn & Sara
ASP.NET HttpHandlers are interesting components of a .NET web application when performing security assessments, mainly due to the fact they are the most exposed part of the application processing client requests in HttpContext level and at the same time, not yet part of the official ASP.NET framework.
As a result, data validation vulnerabilities in custom HttpHandlers can be exploited far easier than issues on the inner layer components. However, they are mostly overlooked during the web application tests for two reasons:
If you are using any of the Telerik components in your application, make sure to replace the "Telerik.Web.UI.dll" with the latest version (about 9MB!).
The Telerik UI control has a web-based charts feature, which stores rendered graphic files in a cache folder for performance reasons. It registers a custom HttpHandler in the web.config file, which processes the following GET request and displays the chart in the client browser:
http://site/ChartImage.axd?useSession=false&imageFormat=image/png&ImageName=[base64 encoded value]
The next step is to decompile the code of the ChartHttpHandler.ProcessRequest(HttpContext), which gives us:
Although, the ImageName query string parameter is encrypted using an AES algorithm to prevent tampering, the encryption key and initialization vector are embedded in the application's assembly (Telerik.Web.UI.dll) and can be used to construct malicious requests to download files from the remote server, as shown in the following figure:
Next time you are on an assessment, don't overlook the mundane and not-so-interesting parts of the application, as they can often provide you with an additional attack surface area.
There has been a healthy reaction to our initial post on our research into the RSA SecureID Software Token. A number of readers had questions about certain aspects of the research, and I thought I'd clear up a number of concerns that people have.
The research pointed out two findings; the first of which is in fact a design vulnerability in RSA software's "Token Binding" mechanism. The second finding is another design issue that affects not only RSA software token but also any other software, which generates pseudo-random numbers from a "secret seed" running on traditional computing devices such as laptops, tablets or mobile phones. The correct way of performing this has been approached with hardware tokens, which are often tamper-resistant.
Let me first explain one of the usual use cases of RSA software token deployments:
The second finding, as I mentioned before, is a known issue with all software tokens. Our aim at SensePost was to demonstrate how easy/hard it would be for an attacker, who has already compromised a system, to extract RSA token secrets and clone them on another machine. A number of people commented on the fact that we did not disclose the steps required to update the LSA secrets on the cloned system. Whilst this technique is relatively easy to do, it is not required for this attack to function.
If a piece of malware was written for this attack, it does NOT have to grab the DPAPI blobs and replicate them on the attackers machine. It can simply hook into the CryptUnprotectData and steal the decrypted blobs once the RSA software token starts execution. The sole reason I included the steps to replicate the DPAPI on another machine, was that this research was performed during a real world assessment, which was time-limited. We chose to demonstrate the attack to the client by replicating the DPAPI blobs instead of developing a proof of concept malcode.
A real-world malware targeting RSA software tokens would choose the API hooking method or a similar approach to grab the decrypted seed and post it back to the attacker.
"I'm also curious to know whether software token running on smartphones might be vulnerable."
The "Token Binding" bypass attack would be successful on these devices, but with a different device serial ID calculation formula. However, the application sandboxing model deployed on most modern smartphone operating systems, would make it more difficult for a malicious application, deployed on the device, to extract the software token's secret seeds. Obviously, if an attacker has physical access to a device for a short time, they would be able to extract those secrets. This is in contrast to tamper-proof hardware tokens or smart cards, which by design provide a very good level of protection, even if they are in the hands of an attacker for a long time.
"Are the shortcomings you document particular to RSA or applicable to probably applicable to Windows software tokens from rival vendors too?"
All software tokens found to be executing a pseudo-random number generation algorithm that is based on a "secret value", are vulnerable to this type of cloning attack, not because of algorithms vulnerabilities, but simply because the software is running on an operating system and storage that is not designed to be tamper-resistance like modern smart cards, TPM chips and secure memory cards.
One solution for this might be implementing a "trusted execution" environment into CPUs, which has been done before for desktop and laptops by Intel (Intel TXT) and AMD. ARM's "trustzone" technology is a similar implementation, which targets mobile phone devices and secures mobile software's from logical and a range of physical attacks.