Grey bar Blue bar
Share this:

Wed, 5 Dec 2012

SensePost Hackathon 2012

Last month saw the inaugural SensePost hackathon happen in our new offices in Brooklyn, South Africa. It was the first time the entire company would be in the same room, let alone the same continent, together and away from the pressures of daily work constraints. The idea was simple: weeks before the date, we sent out emails to everyone in the company (not just the tech teams but everyone) to think about ideas, tools, approaches or new business lines that they felt would make us even better at what we did.

Hackathons are used by many tech companies to give their employees breathing space to work on new ideas. Google and Facebook are big fans and Facebook's Like button was conceived as part of a hackathon. Getting everyone together at the same time was no mean feat, the term 'herding cats' springs to mind but on the week of 12th of November, all SensePost'rs were in our new offices and ready to break, build and develop.

Prior to the event, we asked everyone to think about what they wanted to work on. As mentioned above, there was no specific guideline as to what anyone could come up with, as you can't force creativity. After a brainstorming session, the following ideas were given and solutions made during the hackathon period*:

1. SensePost World App

A mobile application (multi-platform) that will streamline the process of receipts, expenses, travel requests, holiday leave etc.

2. SensePost IRC Bot

A IRC bot that will offer:

  1. Integration with our internal twitter clone
  2. SMS functionality to summon $person
  3. Location whereabouts functionality (who is in the office, who's at a client etc.)
  4. Cool links functionality
  5. SensePost short URL functionality
  6. Ability to call $username via Gtalk/Skype
3. SensePost SMS Gateway App

An application that allows us to utilise SMS from a company-wide perspective, including:

  1. Ability to receive OTP passwords to a central number
  2. Ability to send passwords to clients via web interface (for sales)
  3. Ability to send HackRack passwords to clients via web interface
Rogan decided to use kannel to interface with a GSM dongle in an Ubuntu server. This exposed a web API. Glenn then wrote a Python script to monitor for new mail arriving to a SensePost email address, which then dispatched SMSs via kannel.

4. Magstripe Hacking

Having moved into our new fancy offices, we decided to look at the current implementation of magstripe used to work out if we could read the data, clone the data and create free parking for us (at the same time, potentially looking for flaws in the magstripe implementation). The magstripes on the parking tickets were very unsual. Between the reader in the office, and Andrew Mohawk's more advanced ones, we could not get a consistent read. It is possible that the cards use an unusual arrangement of tracks. Typically there are 3 horizontal tracks at predefined heights. If the tracks are at unusual heights we may have been getting interference between said tracks. Andrew has tried to dissect one of the cards, but no luck yet.

Watch this space. 5. AV VirusTotal Project

Rather than submitting our payloads to VirusTotal (who then inform the vendors), we will create our own version that uses all vendors, to determine if our custom payloads could be detected.

6. SensePost Green Project

A project to make our business greener in approach and ideas. How responsibly were we using resources? What was our consumption of electricity and water like and could it be made better?

With teams created and everyone clear on what they had to do, 48-hours were given to create the above ideas. Food, drink, hardware and toys were provided. Vlad brought some amazing Russian Vodka and energy drinks were supplied.

Whilst the older farts faded quickly (I'll put my hand up, 1am and I was broken), the younger crowd went through the night and into the next morning. From simple ideas at first, fully-fledged solutions were designed and then developed in a short space of time. The idea was that once the hackathon 48-hour period was over, everyone would present the results and we'd head outside to our balcony to have a traditional SA braai (barbecue)

The cool thing about the hackathon was that some of the top ideas came from traditionally non-technical people, such as our finance wizard who came up with the idea of the SensePost world app. This was the outcome that we wanted: to prove that you don't need to be a heavy tech-orientated person to come up with meaningful projects or ideas.

Overall the 2012 Hackathon was a brilliant time had. Some amazing ideas have come to light, ones that will see us pushing offensive approaches and also ones that will have an impact on the way we work at SensePost.

For those thinking about running an internal hackathon, I'd say go for it. Giving people the space to work on ideas with likeminded colleagues will only bring benefits.

*There were other projects, but they won't see the light of day as of yet, so will remain confidential until the time is right.

Tue, 20 Nov 2012

HTTPS <=(:)=> via WinAPI

Hijacking SSL sessions initiated by the browser is a trivial task. The challenge comes when trying to intercept SSL traffic in applications such as Dropbox or Easynote. These apps create additional measures to verify certificates and their integrity, hence not very friendly to perform with Burp.

One quick solution to the above problem is hiding one level above (or below :) the OSI layer. Live API monitoring // hooking can be used to capture and manipulate HTTP/S "traffic" before it being placed on the wire, more or less the same way are used to doing it in Burp.

One great tool is the Rohitab API Monitor, which allows you to monitor, and control, API calls made by applications and services.

Steps: Attach to a target process in realtime -> selectively monitor/hook its API -> place breakpoints and manipulate API call parameter content at will.

Fig 1 - Attaching to evernote.exe | Selecting Internet (HTTP Srv API, WEbDav, WinNet etc...) API as primary filter for the session.

Fig2 - Examining HttpSendRequestA call (contains my easynote creds :) ) in realtime, before the assembled POST request leaves the host.

P.S. That isn't my password.

Mon, 3 Sep 2012

Solution for the 44Con Challenge

Last week, we published our 44Con "SillySIP" Challenge for free entry to our BlackOps training course at the 44Con conference this year. We'd like to thank all those who attempted this challenge.

$queue->add($beatbox_drumroll);

The winner, who responded with the first correct answer, is Ben Campbell. As a result, he gets to hang out with our trainers on a free BlackOps training course.

Congratulations Ben! We look forward to meeting you (in person) at the BlackOps training.

For those wondering what the basic / fundamental model answer for this challenge would look like, I've attached the module here.

We hope that all participants found this challenge as an opportunity to reawaken their inner "Metasploit-Module Coding-Daemon" ;-)

Mon, 25 Jun 2012

Solution for the BlackHat Challenge

We had published a network protocol analysis challenge for free entry to our BlackHat 2012 Vegas training courses and received seven correct answers. We'd like to thank those who attempted this challenge and hope that they find it useful.

The winner, Peter Af Geijerstam managed to respond first, with the correct answer. As a result, he wins a free place on any of our Hacking By Numbers courses. Here is a brief solution for it:

If you start by running the client and server binaries provided in the challenge zip file, you'll observe the following output from the client:

And we can see the same challenge (177) and 16-byte response values in the network traffic:

So, this indicates that the client and server are running a simple challenge-response authentication protocol with a 3-digit random number (R) as the challenge and a 16-byte response value which should be calculated using the R and the shared secret value. We need to figure out the response calculation formula in order to fully understand this simple authentication protocol. This can be done by reading the provided source code. If the source code was not available then we'd have to use a disassembler, such as IDA Pro, in order to find out the formula. The following code snippet shows a function call to HMAC(char *msg, char *key,byte *mac) to calculate the response value:

And inside HMAC function we can see calls to Windows CryptoAPI to calculate MD5 hash value of (msg+secret):

Now, we can summarise the authentication protocol as below and work out our attack strategy:

Client->Server : HELLO Server->Client: R Client->Server: RESP (MD5(R+secret)) Server->Client: OK/Incorrect Response

The attacker had both R and MD5(R+secret) values from the network traffic capture file and he also knew something about the shared secret format (7 alphanumeric excluding uppercase characters). Therefore, he can run a brute force attack on the 16-byte MD5 hash value with a narrowed charset and known message format which would be [448][abcdefghijklmnopqrstuvwxyz0123456789]. There are several public hash cracking tools which support raw md5 hashes, such as hashcat. we can run hashcat with the following options:

cudaHashcat-plus32.exe --attack-mode 3 --custom-charset1 abcdefghijklmnopqrstuvwxyz0123456789 hash.txt 448?1?1?1?1?1?1?1

It would take about 43 minutes for a NVIDIA GeForce 405 graphic card to recover the shared secret:

And the shared secret value is: bm28lg1. In order to calculate the session key value (kc) we can simply set the R to 448 in authentication server source code instead of the random value and compile it. By running the client binary using the recovered secret key value (bm28lg1), we will get the session key:

And the session key value is : 07e0f7a7cbc2d8b3dba6b7d3b69c3236

I saw a similar solution (in Spanish) on the internet posted here . I also received a question not about the challenge itself, but the source code of the authentication client and why I'v set resp buffer size it to 128 bytes while the client response length is always 21 bytes (basically why I've wasted 107 bytes of 1MB default stack). The answer is that the server not only processes RESP messages from the client, but also need to receive and decrypt MSG messages (which is marked as not implemented in both source codes). MSG messages clearly have a bigger size than 21 bytes and in order to use the same RESP buffer for incoming data, I set its size to 128 bytes which is purely an arbitrary number in this case and should be changed to a more suitable size based on the encryption algorithm's block sizes which are not implemented in the current code.

If you have questions or recommendations regarding this challenge (or similar ones), please drop me an email to the address inside the challenge file.

Thu, 24 May 2012

RSA SecureID software token update

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:

  1. The user applies for a token via a RSA self-service console or a custom web form
  2. The user receives an email which contains the "software token download URL", once the software is installed, they should open the program and then choose Token Storage Devices where they would read the "Device Serial Number" and reply back with this device serial number to complete their token request.
  3. The second email will contain an attachment of the user's personal RSA SecurID Token Configuration file, which they will import to the RSA software token. This configuration file is bound to the users' laptop or PC.
  4. The third email contains an initial password to activate the token.
An attacker who is able to capture the victim's configuration file and initial password (The security of this initial password is subject to future research at SensePost and will be released in the future) would be able to import it into his token using the described method to bypass the token binding. This attack can be launched remotely and does not require a "fully compromised machine" as RSA have stated.

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.