As we grow and operate on a number of continents, so does our dependence on a rock-solid IT infrastructure. We are expanding our repertoire to include a greater collection of Linux/Open Source/Windows and OS X products. With this, we are on the look-out for a rock star to wrangle control of our internal networks, external cloud infrastructure and help us us utilise technology in a way to make us even better.
Job Title: IT Network Packet Wrangling Penguin Master
Salary Range: Industry standard, commensurate with experience
Location: Johannesburg/Pretoria, South Africa
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:
An application that allows us to utilise SMS from a company-wide perspective, including:
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.
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.
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.
P.S. That isn't my password.
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.
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" ;-)
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:
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 [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.