Grey bar Blue bar
Share this:

Thu, 17 May 2012

A closer look into the RSA SecureID software token

Widespread use of smart phones by employees to perform work related activities has introduced the idea of using these devices as an authentication token. As an example of such attempts, RSA SecureID software tokens are available for iPhone, Nokia and the Windows platforms. Obviously, mobile phones would not be able to provide the level of tamper-resistance that hardware tokens would, but I was interested to know how easy/hard it could be for a potential attacker to clone RSA SecureID software tokens. I used the Windows version of the RSA SecurID Software Token for Microsoft Windows version 4.10 for my analysis and discovered the following issues:

Device serial number of tokens can be calculated by a remote attacker :

Every instance of the installed SecurID software token application contains a hard drive plug-in (implemented in tokenstoreplugin.dll) that has a unique device serial number. This serial number can be used for "Device Binding" and the RSA documentation defines it as follows:

Before the software token is issued by RSA Authentication Manager, an additional extension attribute (<DeviceSerialNumber/>) can be added to the software token record to bind the software token to a specific devicedevice serial number is used to bind a token to a specific device. If the same user installs the application on a different computer, the user cannot import software tokens into the application because the hard drive plug-in on the second computer has a different device serial number from the one to which the user's tokens are bound”.
Reverse engineering the Hard-Disk plugin (tokenstoreplugin.dll) indicated that the device serial number is dependent on the system's host name and current user's windows security identifier (SID). An attacker, with access to these values, can easily calculate the target token's device serial number and bypass the above mentioned protection. Account SIDs can be enumerated in most of the Microsoft active directory based networks using publicly available tools, if the “enumeration of SAM accounts and shares” security setting was not set to disabled. Host names can be easily resolved using internal DNS or Microsoft RPC. The following figures show the device serial number generation code:

The SecureID device serial number calculation can be represented with the following formula:

device_serial_number=Left(SHA1(host_name+user_SID+“RSA Copyright 2008”),10)

Token's copy protection:

The software token information, including the secret seed value, is stored in a SQLite version 3 database file named RSASecurIDStorage under the “%USERPROFILE%\Local Settings\Application Data\RSA\RSA SecurID Software Token Library” directory. This file can be viewed by any SQLite database browser, but sensitive information such as the checksum and seed values are encrypted. RSA documentation states that this database file is both encrypted and copy protected: “RSA SecurID Software Token for Windows uses the following data protection mechanisms to tie the token database to a specific computer:

• Binding the database to the computer's primary hard disk drive

• Implementing the Windows Data Protection API (DPAPI)

These mechanisms ensure that an intruder cannot move the token database to another computer and access the tokens. Even if you disable copy protection, the database is still protected by DPAPI.”

The RSASecurIDStorage database file has two tables: PROPERTIES and TOKENS. The DatabaseKey and CryptoChecksum rows found in the PROPERTIES tables were found to be used for copy protection purpose as shown in the figure below:

Reverse engineering of the copy protection mechanism indicated that:

  • The CryptoChecksum value is encrypted using the machine's master key, which can only be decrypted on the same computer system, unless the attacker can find a way to import the machine key and other supporting data to their machine
  • The DatabaseKey is encrypted using the current logged-on user's master key and provides token binding to that user account
Previous research on the Microsoft Windows DPAPI internals has made offline decryption of the DPAPI protected data possible. This means that if the attacker was able to copy the RSA token database file along with the encryption master keys to their system (for instance by infecting a victim's machine with a rootkit), then it would be possible to decrypt the token database file on their machine. The detailed attack steps to clone a SecurID software token by copying the token database file from a victim's system are as follows:
  1. Copy the token database file, RSASecurIDStorage, from the user profile directory
  2. Copy the user's master key from %PROFILEDIR%\Application Data\Microsoft\Protect\%SID%; the current master key's GUID can be read from Preferred file as shown in the figure below:
  3. Copy the machine's master key from the %WINDIR%\system32\Microsoft\Protect\ directory. Microsoft Windows protects machine keys against tampering by using SHA1 hash values, which are stored and handled by the Local Security Authority Subsystem Service (LSASS) process in Microsoft Windows operating systems. The attacker should also dump these hash values from LSA using publicly available tools like lsadump.
  4. Having all the required master keys and token database file, install and deploy a windows machine and change the machine and user SIDs to the victim's system SID by using available tools such as newSID.
  5. Overwrite the token database file, user and machine master keys with the ones copied from victim's system. You would also need to find a way to update the DPAPI_SYSTEM value in LSA secrets of the Windows machine. Currently, this is the only challenge that I was not able to solve , but it should be possible to write a tool similar to lsadump which updates LSA secrets.
  6. When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token.
In order to demonstrate the possibility of the above mentioned attack, I installed and activated token A and token B on two separate windows XP virtual machines and attempted to clone token B on the virtual machine that was running token A. Taking the above steps, token B was successfully cloned on the machine running token A as shown in the following figures:

In order to counter the aforementioned issues, I would recommend the use of "trusted platform module" (TPM) bindings, which associates the software token with the TPM chip on the system (TPM chip for mobiles? there are vendors working on it).

Wed, 4 Apr 2012

Towards Firmware Analysis

While I was evaluating a research idea about a SCADA network router during the past week, I used available tools and resources on the Internet to unpack the device firmware and search for interesting components. During security assessments, you may find interesting embedded devices available on the network. Whilst many don't look at the feasibility of doing firmware analysis, I decided to document the steps I took to analysis my target firmware, so you can take the similar approach in the case of assessing such devices. This could also be a good indication on the feasibility of automating this process (An unfinished project was launched in 2007:

The following process would be easy for most of you who use *nix systems on a daily bases:

Step 1) Scanning the firmware image

The BinWalk tool is useful for scanning firmware image files to identify embedded file systems and compressed streams inside. It can detect common bootloaders, file systems and compressed archives inside a given firmware image file. Since it works by scanning for signature and magic values, it usually has false positives and the results need to be verified manually.

U-Boot bootloader (yes, it's German :-)) signature was identified at offset 262144 and the uImage header information, such as creation date, CPU type, etc appears to be valid. This bootloader was followed by a gzip compressed stream, which probably is the zImage kernel and a squashfs file system at offset 1522004. We will attempt to extract this file system in the next step. The following are common bootloaders that are used in embedded devices with ARM CPU:

Blob bootloader Bootldr Redboot U-Boot ABLE bootloader

The bootloader's task is to load the kernel image at the correct address and pass initial parameters to it. So in most cases we are not interested in analysing the bootloader itself, but in the root file system.

Step 2) Extracting file systems

First, I extracted the uImage content at offset 262144 by using dd command and then used uboot-mkimage ( to test if it's a valid uImage file and to discover more information about it:

The image format was valid and it contained two other file system images with 1MB and 2MB sizes, which probably are kernel zImage and root file systems (RAMdisk). If you check the uImage file format, you will notice a 64 bytes long header. There is a “multi-file” image list that contains each image size in bytes and this list is terminated by a 32bit zero. So, I would need to skip 64+2*4+4=76 bytes from start of the uImage file to get to the first Image content that would be kernel zImage:

The file command could not detect kernel image or squshfs in the extracted file systems; this might be due to lack of squashfs (with LZMA compression) in my Ubuntu kernel. I proceed by using Firmware Mod Kit which contains a set of programs to decompress various file system images including squashfs-LZMA. After trying the various unsquashfs version 3.x scripts, I was able extract the rootfs image files successfully:

Step 3) Searching the root file system

Once the root file system files were extracted, we can file and strings search tools to look for interesting files and patterns such as RSA private key files, password and configuration files, SQL database files, SQL query string and etc. In my case, I was looking for RSA certificate or private key files and found the following: (a database of private keys in embedded devices was published in 2011 but it's not actively maintained, you can access it at

One can write shell scripts to automate the file system search process.

Step 4) Running and debugging the Executables

The Qemu emulator supports multiple CPU architectures including ARM, MIPS, PowerPC, etc and can be used to run and debug the interesting executable extracted from the firmware image on your system for dynamic analysis purposes. You would need to build the Qemu with —static and —enable-debug options. The following figure demonstrates how to run the web server (httpd) that was extracted from my target firmware using chroot and Qemu:

As you can see from the above screenshot, the web server was working fine, but was not able to display the bootloader version, because it couldn't read this value from the NVRAM (not volatile RAM) normally mounted by the kernel in a real device (there is an interesting post here about resolving the NVRAM access errors while emulating embedded device executables). Some of the executables, like the remote management agent example below, could have more severe problems running under emulator.

For troubleshooting such cases, or monitoring an emulated process while fuzzing it, we would need to attach a debugger to it. This can be achieved by using —g switch in Qemu and using a debugger out of the emulator process or even on a remote windows machine. I used IDA pro remote GDB debugging tool as shown in the figures below:

Once successfully attached to the remote emulated process, IDA pro can be used to simply trace the execution of the process, placing breakpoints or running IDA scripts.

Often overlooked during assessments, firmware analysis of devices can yield results and often do when we target them at SensePost. Our methodology includes the above steps and we recommend yours does too.

Fri, 11 Nov 2011

Decrypting iPhone Apps

This blog post steps through how to convert encrypted iPhone application bundles into plaintext application bundles that are easier to analyse.

Requirements: 1) Jailbroken iPhone with OpenSSH, gdb plus other utilities (com.ericasadun.utilities etc. etc.) 2) An iPhone app 3) On your machine:

  • otool (comes with iPhone SDK)
  • Hex editor (0xED, HexWorkshop etc.)
  • Ida - Version 5.2 through 5.6 supports remote debugging of iPhone applications (iphone_server).
For this article, I will use the app name as “blah”.

Some groundwork, taken from Apple's API docs [1, 2]:

The iPhone apps are based on Mach-O (Mach Object) file format. The image below illustrates the file format at high-level:

A Mach-O file contains three major regions: 1. At the beginning of every Mach-O file is a header structure that identifies the file as a Mach-O file. The header also contains other basic file type information, indicates the target architecture, and contains flags specifying options that affect the interpretation of the rest of the file. 2. Directly following the header are a series of variable-size load commands that specify the layout and linkage characteristics of the file. Among other information, the load commands can specify:
  • The initial layout of the file in virtual memory
  • The location of the symbol table (used for dynamic linking)
  • The initial execution state of the main thread of the program
  • The names of shared libraries that contain definitions for the main executable's imported symbols
3. Following the load commands, all Mach-O files contain the data of one or more segments. Each segment contains zero or more sections. Each section of a segment contains code or data of some particular type. Each segment defines a region of virtual memory that the dynamic linker maps into the address space of the process. The exact number and layout of segments and sections is specified by the load commands and the file type. 4. In user-level fully linked Mach-O files, the last segment is the link edit segment. This segment contains the tables of link edit information, such as the symbol table, string table, and so forth, used by the dynamic loader to link an executable file or Mach-O bundle to its dependent libraries.

The iPhone apps are normally encrypted and are decrypted by the iPhone loader at run time. One of the load commands is responsible for decrypting the executable.

Push EBP
JMP loc_6969
Once you have downloaded and installed an app on your iPhone, make a copy of the actual executable on your machine.

Note1: The is not the actual executable. If you browse this folder, you will find a binary file named blah. This is the actual application binary.

Note2: To find the path where your application is installed, ssh onto your iPhone and use the following command:

sudo find / | grep
Once you have copied the app binary on your machine, follow the steps below (on your local machine).

Open up a terminal and type the following command:

otool —l blah | grep crypt
This assumes that iPhone SDK or otool is already installed on your machine.

The above command will produce the following output:

If cryptid is set to 1, it implies that the app is encrypted. cryptoff and cryptsize indicates the offset and size of crypt section respectively. Now, firstly we'll have to locate the cryptid in the binary and set it to zero. This is done so that when we finally decrypt the binary and execute it on iPhone, the loader does not attempt to decrypt it again. Open the binary in a hex editor and load the binary. I did not come across any definite method of locating the cryptid. Once you have loaded the binary in a hex editor, search for “/System/Library/Frameworks”. You should be able to locate it around the address 0x1000. In the line, just above the very first instance of this statement (/System/Library/Frameworks), you will find bytes 01. Flip it to 00 and save the file.

Note3: In case you find multiple instances of 01, use coin-tossing method of choosing between them.

Use otool again to query the crypt data. You will see that the cryptid is now set to 0 (zero).

Next, we need to run the app, which was installed on iPhone and take a memory dump.

Note4: The actual application code starts at 0x2000. The cryptsize in case of our sample app is 942080 (0xE6000). Hence, we add 0x2000 and 0xE6000.

0x2000 + 0xE6000 = 0xE8000
Therefore, we need to dump the running process from 0x2000 till 0xE8000. Now, ssh onto your iPhone, run the target app and look for the process id using “ps —ax” command. Once you have the process id, use the following command to dump the process:
gdb —p PID
dump memory blah.bin 0x2000 0xE8000
Once you have taken the memory dump, use “quit” command to exit gdb. Use the following command to get the size of memory dump:
ls —l blah.bin
The size of this bin file should exactly be same as the cryptsize of the original app. Refer to screenshot above. Now pull this bin file onto your local machine. On your local machine, load the bin file in a hex editor and copy everything (using select all or whatever). Close the file and open the original app in the hex editor. (The file in which we modified cryptid 01 to 00). If you remember, the cryptoff was 4096, which is 0x1000 (in hex). Proceed to memory address 0x1000 and make sure that your hex editor is in overwrite mode, not in append mode. Once you are on memory address 0x1000, paste everything you copied from the bin file. This will overwrite the encrypted section with the decrypted one. Save the file and you're done.

Open the file in IDA pro and you'll see the difference between the encrypted and decrypted binaries. At this point, you can easily reverse engineer the app and patch it. The first image below shows an encrypted app and the second one illustrates a decrypted app:

After patching the application, ssh onto the iPhone and upload it to the application directory. This would mean replace the original binary with the patched one. Once uploaded, install a utility called "ldid" on your iphone.

apt-get install ldid
Finally, sign the patched binary using ldid:
ldid -s blah
This will fix the code signatures and you will be able to run the patched app on your iPhone.




Thu, 3 Nov 2011

Mobile Security Summit 2011

This week, Charl van der Walt and I (Saurabh) spoke at Mobile Security Summit organized by IIR (

Charl was the keynote speaker and presented his insight on the impact of the adoption of mobile devices throughout Africa and the subsequent rise of security related risks. During his talk, he addressed the following:

  • Understanding the need for mobile security to be taken seriously in Africa
  • Analysing the broader implications for the user and the company
  • The types of attacks occurring against mobile devices
  • What does the future of mobile security look like and what are the potential threats to users?
  • Understanding the particular threats posed by smartphones and other portable devices, e.g. tablets
The presentation can be accessed via link below:

I spoke on iPhone and Android security, demonstrating the ease with which mobile security can be breached and presented some live demos. Below is the agenda of my talk:

  • Why everyone rants about SmartPhone security
  • Understanding iPhone Application layout
  • Decrypting iPhone apps & what can we achieve
  • Android Architecture
  • Android Permission Model & Sandbox
  • Analyzing Android Apps - Deep sea diving
  • Practical Attacks on Android
  • Demos
  • Introducing
I also released a Python script,, which can be used by Penetration testers and Android geeks to find permission-based flaws in Android applications. The script is in early stage of development and will be enhanced in near future. A working copy of this script can be downloaded from link below:

The original presentation can be downloaded from link below:

Wed, 27 Oct 2010

Analysis of a UDP worm


From time to time I like to delve into malware analysis as a pastime and post interesting examples, and recently we received a malware sample that had a low-detection rate. Anti-Virus coverage was 15/43 (35.7%) based on a report and Norman sandbox did not detect any suspicious activity as shown in the report below:

norman sandbox report

Norman sandbox report did not show any registry or network activity. This might be due to the use of virtual CPU or sandbox bypass techniques by the malware. Sunbelt sandbox was down at the time of the analysis.

Dynamic analysis indicated that the malware copies itself to the "application data" directory of the current logged-on user and achieves automatic startup by adding the following registry entry:

  • key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman
  • Value: %AppData%\ygmdrm.exe
It then starts communicating via UDP with the following C&C servers on port number 14000:
The UDP traffic was scrambled and had the following sequence:

Code analysis of the malware resulted in the following findings:

Virtual CPU bypass

Anti-virus programs achieve heuristic detection of unknown malware code by parsing the binary code inside a virtual CPU to detect suspicious pattern (packers, encryptors, etc) and OS activities. Most modern AVs are able to detect and skip "code traps" designed to evade detection, such as time delays, intentional loops and unsupported CPU instructions. However, based on the AV coverage report this malware was able to evade huristic detection in a number of AV products by causing indirect execution delays through crafted calls to GDI functions as shown in the following API call log:

Code injection

The actual malware code is launched after evasive GDI calls. A page of memory is allocated using VirtualAlloc API, 1760 bytes are copied to the newly allocated area and the control is passed to this code with the "call eax" insturction as shown in the following code anippet:
The second stage searches for explorer.exe process and injects its code into it using CreateRemoteThread technique.

Network communications

The first 5 UDP packets were found to be connect request packets (starting with 0x18 command code) and sequence number exchange. The 6th packet with data size of 269 bytes seems interesting and could contain bot commands:

The decryption function was found at offset 0x58be of the second code stage :

The decryption algorithm can be presented by the following formula:

D(buff[n])=buff[n] XOR (buff[n-1]*pow(2,(n-1 AND 3)) where n values range from 1 to data_size-1.

The decrypted buffer contents are not completely readable and contain some metadata inserted at various positions. This indicates that the buffer is also compressed using a byte level compression algorithm. Further debugging reveals a decompression function at offset 0x1118 and decompressed command content is shown in the figure below:

The command instructs the bot to change the startup home page of the victim's browser to "" for a possible SEO campaign.

Other features

Analysis of the text strings in the second stage code indicates that the malware has other capabilities such as:
  1. USB drive infector (via autorun.inf)
  2. Download and execute
  3. Remote Firefox cookie dump
This is cause for concern and warrants a a high risk rating, as opposed to the "low risk" in provided in's report.


Apart from signatures, it's still pretty easy to write malware to bypass A/V heuristic checks, as the GDI calls in this sample showed.