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.
In light of recent mass hacks (HBGary, Sony, Nintendo, etc) one would have thought that collectively, companies would take notice and at least be slightly more aware of the potential implications vulnerabilities in public-facing services could have.
The problem appears to be that these hacks, and indeed hackers, aren't that technically superior and more often than not, take advantage of simple flaws. Some flaws, like SQL injection, provide so much access on their own that a fairly grim attack scenario can be painted. However, often attackers don't require such extravagant flaws to gain access. Chained attacks utilising "low risk" attacks can be far more deadly than a single flaw.
We had an interesting scenario recently which demonstrated this. This is one example of how we use these minor flaws to gain access, and also show how the house of cards can fall quite spectacularly when basic security principles are not adhered to. We were on a fairly bread and butter security assessment; perform an analysis of the target (a large multinational) and determine where their weaknesses were from an unauthenticated perspective. Increasingly, we advise against unauthenticated assessments as we feel we can offer more value when you assume the shell is already cracked, but this was a special case.
The web application was good; it soon became clear that the developers had followed guidelines for the development of secure applications and ensured that common attacks were indeed handled in a suitable manner. What they didn't do, however, was apply a stringent hardening process to the server itself, and as the platitude goes "security is only as good as the weakest link."
The analyst had already obtained all administrative user names and passwords (stored in a database with no protection at all) and had logged into a number to confirm access. My email, now forwarded in the clear, was sent to all involved with a stern "fix it". Since we had access to the mailboxes, we saw an admin send the reply: "..have changed the password. Ask them to check if the password is strong now, there's no way they can get in now."
Yes, the password was indeed strong and certainly constructed in a recommended manner, but the administrator's account was already compromised and we were monitoring communications. This wasn't an appropriate response, it's a bit like using AV to clean a virus from a box, post-infection, instead of rebuilding it. Some data mining through multiple unencrypted mailboxes provided numerous credentials for other servers inside the network. We could pivot through the internal network to our hearts content, while monitoring their comms to make sure our supply line wasn't under threat.
Takeaway I: Once an attacker is inside the perimeter, trying to control intruder access at the perimeter is a game you've already lost. i.e. Blocking the path in, doesn't mean you've blocked the paths in use.
Starting with a simple directory listing flaw, one that Nessus rates as a "low" risk, the house of cards fell at an alarming rate. Security isn't about looking only at the high risks, because attackers won't limit themselves the same way.
Salut à tous,
It's that time of the year again and like every year, we'll once again be running our ever-popular "BOOTCAMP EDITION" at the BlackHat Briefings in Las Vegas this July-August. This course is part of our established Hacking by Numbers series. BUT, this year, only the name remains the same. We are slaving away at making this course cutting edge, providing you with a hands-on hacking experience on the latest operating systems, application frameworks and programming languages utilizing the latest tools and techniques. Gone are the days of IIS 5.0, Windows XP and we truly understand that [ed: for Bootcamp, maybe... Combat certainly contains an OS older than Win95].
SensePost's Bootcamp edition will provide you with two days of insight into the hacking world. The course is designed to keep a balance between theoretical knowledge & practical experience. Anyone can read a whitepaper about SQL Injection but unless you've exploited it against a real-world application and owned it completely, it all tastes too bland. The Bootcamp spices up the pwning experience.
The training course starts with basics of hacking, the hacker mindset & methodology and quickly moves on to practicalities of modern hacking attacks. Immediately after brainstorming a security concept, the students are placed in different attacker scenarios which have handy pracsheets to guide you (but not answer sheets to spoonfeed). Competition is good and hence we have a few "capture the flag" practicals that'll provoke you to race against each other to grab that surprise gift.
Our trainers are experienced, patient and well groomed. Having a good sense of humor is a requirement here @SensePost, so you don't have to worry about falling asleep.
So, if you're looking to explore the world of hacking or move from newbie to competent in a great environment, remember:
Course Name: Hacking By Numbers: Bootcamp Edition
Venue: BlackHat Briefings, Caesars Palace Las Vegas, NV
Dates: July 30-31 & August 1-2 2011
Sign up here.
See you there!!!