Throughout Trustwave SpiderLabs’ many forensic investigations, we often stumble upon malicious samples that have been ‘packed’. This technique/concept can be unfamiliar to the aspiring malware reverser or digital forensic investigator, so I thought it would be fun to use this opportunity to talk about portable executable (PE) packers at a high level. If you already know what PE packers are and how they work, you’re more than welcome to continue reading, however it’s certainly possible you may not learn something new. Think of this as a 101 blog post.
So what are PE packers? How do they work? How can you defeat them? I’m going to do my best to answer these questions.
I was here in the TypePad editor working on a new web honeypot blog post about some XSS attacks we were seeing when, BOOM, my browser was suddently redirected to the hxxp://www.txt2pic.com website. What the heck just happened?!? I clicked back in my browser to take me back to the TypePad editor session. Then, a few moments later... I was redirected yet again. Something was seriously wrong here. I sat there for a moment with a blank stare on my face as my mind quickly ran through different scenarios of what could be happening when it suddenly hit me. Wait a minute, that URL (hxxp://www.txt2pic.com) was familiar.
A couple of weeks ago I posted Part 1 of Cracking IKE, detailing some useful techniques when cracking Aggressive Mode PSK hashes. In that post we saw that a hash is not always ‘crackable’ and additional steps are required in order to find a correct group name or ID. In this post I will be discussing a more recent vulnerability I discovered on the Cisco ASA platform that allows you to do just that.
A Quick Recap
Going back to the previous post we saw that it was possible to enumerate group names by analyzing subtle differences in the response from the ASA firewall, specifically the presence of a DPD (Dead Peer Detection) payload. So by sending requests to the device with a list of potential group names it’s possible to find a valid group name if the ASA software isn’t patched.
So I decided to look for any additional signs that may leak information about the validity of the group name. I did this by analyzing genuine IKE negotiations and sending a variety of different requests, looking for anything that may provide a clue. I eventually noticed that some differences remain even in the latest version of ASA software. Basically, a correct group name elicits four (this can vary depending on the software version) attempts to continue the handshake and an additional encrypted phase 2 packet, while the device will only respond twice to an incorrect group name. This is probably better described in images.
Incorrect group name:
Correct group name:
The differences are quite obvious so to demonstrate I’ve written a proof of concept python script that enumerates the group names using this technique, which can be found here. Although it’s incredibly slow because of the need to wait for the response packets each time a request is made. It requires a wordlist and a target as input, allows the hash type to be specified (MD5 or SHA1) and looks like this:
The group name (or ID) can then be used to capture a genuine hash for cracking using a cracker of your choice, as described in Part 1:
Personally I prefer Hashcat:
How Do I Protect Against This?
Cisco have released software updates to address this issue, further details/updates can be found here and here. Administrators with affected software versions should be aware that this information could be potentially revealed, it is recommended that these updates are applied if your devices are allowing PSK authentication. It is also recommended that default or easily guessable group names should not be used and strong Pre-Shared Keys are a must. The keys should be rotated as often as is practically possible and Aggressive Mode IKE negotiations should be disabled where possible, but of course this is not always a possibility with Remote Access setups. In an ideal world PSK negotiations should be replaced with certificates.
Stay tuned for Part 3 which will cover the next steps where Mission:Improbable becomes a reality…
It's been a short while, but we find ourselves again with a Java vulnerability in our hands, this time via a PoC provided by IKVM.NET.
This particular vulnerability is somewhat different than most java vulnerabilities we run into, but feels like a natural progression from the last Java 0day we discussed in our blog (CVE-2013-1493). Both these vulnerabilities allow direct memory manipulation, something which is quite uncommon in Java.
The vulnerability itself has to do with type confusion between an int and a double, causing 8 bytes to be copied instead of 4, thus overwriting a pointer and allowing us to reach otherwise inaccessible area in the memory.
The latest update to the TrustKeeper Scan Engine is now available. It adds coverage for more than 20 vulnerabilities, including several recent vulnerabilities that are likely to affect many websites running on Ruby on Rails, WordPress, Drupal and/or Moodle. Newly covered vulnerabilities also include recent denial-of-service vulns in Cisco IOS and ISC BIND, likely to affect many administrators as well.
In our latest Global Security Report, we noted malicious spam campaigns were on the increase, and roughly 1 in 10 spam messages were malicious.
There is a large scale malicious spam campaign going on that is shamelessly exploiting the Boston bombing. Subject lines are similar to the following:
Growing up I read every book my library had to offer by Jules Verne and Isaac Asimov. These and many other similarly minded authors inspired me to think far beyond "what is" into "what might be". I was so excited about the ideas proposed by some of these early science fiction writers that I seriously considered post-graduate study in Artificial Intelligence (A.I.) before ultimately accepting a job as a Pentester. Yeah, I sold out early - so what. However, those initial seeds have stuck with me through my life and have continued their influence into my eventual career in computing and security. Imagination and idea creation are still invaluable tools that I credit directly to my world being expanded while reading under the covers with a flashlight as a boy.
"That's right. When I was your age, television was called books."
--The Princess Bride (1987)
Now, ████ years later as a Security Researcher with Trustwave SpiderLabs I get to spend a percentage of my time working on pet1 research projects. I am in the opportune position to be able to come full circle and attempt to seriously explore some of those exciting buds of ideas I once only day dreamed about while flipping through the pages of whichever Philip K Dick novel I had just discovered.
The purpose of this post is actually several fold. The first is to publicly announce the project I am about to work on because I am excited about it, and because by doing so I have taken the first step in being accountable for its progress. Secondly, by self-admission, I am no expert in this advanced field but I hope to document my progress here on this blog, both the happy successes AND the inevitable failures. Lastly, by posting here with my progress it is my hope that a discussion will be created with others out there who are also interested in this topic. To share ideas, and to brainstorm new approaches in such a way that the whole community can benefit from them.