Grey bar Blue bar
Share this:

Mon, 20 Jan 2014

January Get Fit Reversing Challenge

Aah, January, a month where resolutions usually flare out spectacularly before we get back to the couch in February. We'd like to help you along your way with a reverse engineering challenge put together by Siavosh as an introduction to reversing, and a bit of fun.

The Setup


This simple reversing challenge should take 4-10+ hours to complete, depending on your previous experience. The goal was to create an interactive challenge that takes you through different areas of the reverse engineering process, such as file format reverse engineering, behavioural and disassembly analysis.


Once you reached the final levels, you might need to spend some time understanding x86 assembly or spend some time refreshing it depending on your level. To help out, Siavosh created a crash course tutorial in x86 assembly for our malware workshop at 44con last year, and you can download that over here.


The zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com

The Scenario


You've been called into ACME Banks global headquarters to investigate a breach. It appears Evilgroup has managed to breach a server and deploy their own executable on it (EvilGroupVM.exe). The executable is software that accepts bytecode files and executes them, similar to how the Java Virtual Machine functions. Using this technique, Evilgroup hopes they can evade detection by antivirus software. Their OPSEC failure meant that both the virtual machine executable and several bytecode files were left behind after the cleanup script ran and it's your job to work out the instruction set of EvilGroupVM.exe.


Disclaimer: When using the term "virtual machine" we mean something like the Java Virtual Machine. A software based architecture that you can write programs for. This particular architecture, EvilGroupVM.exe, has nine instructions whose operation code (opcode) you need to find through binary reverse engineering.


The tools you will require are:


  • A hex editor (any will do)

  • A disassembler like IDA (the free version for Windows will work if you don't have a registered copy)

  • A debugger, Olly or WinDBG on Windows, Gnu GDB or EDB on Linux https://www.gnu.org/software/gdb/


Basic Usage: Unzip the reverseme folder, open a command line and cd to it. Depending on operating system, type
Windows: EvilGroupVM.exe <BytecodeFile>
Ubuntu Linux: ./EvilGroupVM <BytecodeFile>

For example, to run the helloworld bytecode file on Windows, you would type:
EvilGroupVM.exe helloworld

IMPORTANT: Note that the EvilGroupVM.exe architecture has debugging capabilities enabled. This means, it has one instruction that shows you the thread context of a binary when it is hit. Once you start developing your own bytecode binaries, it is possible to debug them (but you need to find the debug instruction/opcode first).


The outcome of this exercise should include the following key structures in your report:


  1. A description of the binary file format. For example:

    • What does the bytecode file header look like?

    • What determines where execution will start once the bytecode is loaded in the VM?

    • Does the architecture contain other parts of memory (like a stack) where it can store data and operate on them?


  2. The instruction set including their impact on the runtime memory. You should:


    • Find all instructions that the EvilGroupVM.exe accepts

    • Analyse each of them and understand how they make changes to the runtime memory of the bytecodes thread


  3. Write a proof of concept self modifying bytecode file that prints your name to the screen. The binary must be self modifying, that is, you may not use the "print_char" instruction directly, rather, the binary must modify itself if it wants to make use of "print_char".

  4. For the advanced challenge, if you have the ability and time, send us back a C file that, when compiled, will give an almost exact match compared to EvilGroupVM (Ubuntu Linux) or EvilGroupVM.exe (Windows). Focus on getting pointer arithmetic and data structures correct.


In case you missed it earlier, the zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com


Good luck!

Wed, 12 Jun 2013

BlackHat Challenge - 2013


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.


The Scenario:


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 197.221.19.20.


The Mission:


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.


If you find this type of test enjoyable, we think you'd enjoy our BlackOps course, which aims to fine-tune your penetration testing skills. A summary of our other courses is available here.


The Prize:


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.

Fri, 14 Dec 2012

Dangers of Custom ASP.NET HttpHandlers

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:


  1. They are used by a 3rd party component of a target application and often the auditor wants to focus on the main functions of the application

  2. They often are found performing such operations as displaying an icon file or chart from image cache. This is deemed useless during an assessment.


In this post, I'm going to demonstrate a data validation vulnerability in a custom HttpHandler which is used by a number of well known ASP.NET apps such as DotNetNuke CMS and was not fixed by the vendor until 2012/3. We still come across web applications that use this vulnerable component, so thought it useful that we document this vulnerability in the Telerik ASP.NET UI Control, which could allow a remote user to download and remove files from the web server under application's pool permission.


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!).


Vulnerability details:


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:



All versions up to and including 2011.2.915.35 are vulnerable. I've created a proof of concept that can be downloaded here . Please note that the target file will be deleted from the web server by the chart image handler after being downloaded from the server, as it considers the requested file as an expired cache entry.


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.

Mon, 10 Sep 2012

44Con: Vulnerability analysis of the .NET smart Card Operating System

Today's smart cards such as banking cards and smart corporate badges are capable of running multiple tiny applications which are often written in high level programming languages like Java or Microsoft .NET and compiled into small card resident binaries. It is a critical security requirement to isolate the execution context and data storage of these applications in order to protect them from unauthorized access by other malicious card applications. To satisfy this requirement, multi-application smart cards implement an “Application Firewall” concept in their operating system which creates an execution sandbox for card applications.

During the recent 44con conference in London, we presented the "HiveMod" reverse engineering tool for .NET smart cards and demonstrated the exploitation of a vulnerability to bypass the card's application firewall. The talk also highlighted threats and possible attack scenarios against smart corporate or military badges.

The presentation slides can be viewed below:

The following video shows exploitation of the "public key token spoofing" vulnerability on the .net smart card using the "HiveMod" tool:

Please contact SensePost research team for more information.

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.