Grey bar Blue bar
Share this:

Mon, 11 Feb 2013

Poking Around in Android Memory

Taking inspiration from Vlad's post I've been playing around with alternate means of viewing traffic/data generated by Android apps.


The technique that has given me most joy is memory analysis. Each application on android is run in the Dalvik VM and is allocated it's own heap space. Android being android, free and open, numerous ways of dumping the contents of the application heap exist. There's even a method for it in the android.os.Debug library: android.os.Debug.dumpHprofData(String filename). You can also cause a heap dump by issuing the kill command:

kill -10 <pid number>

But there is an easier way, use the official Android debugging tools... Dalvik Debug Monitor Server (DDMS), -- "provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more." Once DDMS is set up in Eclipse, it's simply a matter of connecting to your emulator, picking the application you want to investigate and then to dump the heap (hprof).


1.) Open DDMS in Eclipse and attach your device/emulator


* Set your DDMS "HPROF action" option to "Open in Eclipse" - this ensures that the dump file gets converted to standard java hprof format and not the Android version of hprof. This allows you to open the hpof file in any java memory viewer.


* To convert a android hprof file to java hprof use the hprof converter found in the android-sdk/platform-tools directory: hprof-conv <infile> <outfile>


Using DDMS to dump hprof data


2.) Dump hprof data


Once DDMS has done it's magic you'll have a window pop up with the memory contents for your viewing pleasure. You'll immediately see that the applications UI objects and other base classes are in the first part of the file. Scrolling through you will start seeing the values of variables stored in memory. To get to the interesting stuff we can use the command-line.


3.) strings and grep the .hprof file (easy stuff)


To demonstrate the usefulness of memory analysis lets look at two finance orientated apps.


The first application is a mobile wallet application that allows customers to easily pay for services without having to carry cash around. Typically one would do some static analysis of the application and then when it comes to dynamic analysis you would use a proxy such as Mallory or Burp to view the network traffic. In this case it wasn't possible to do this as the application employed certificate pinning and any attempt to man in the middle the connection caused the application to exit with a "no network connection" error.


So what does memory analysis have to do with network traffic? As it turns out, a lot. Below is a sample of the data extracted from memory:



And there we have it, the user login captured along with the username and password in the clear. Through some creative strings and grep we can extract a lot of very detailed information. This includes credit card information, user tokens and products being purchased. Despite not being able to alter data in the network stream, it is still easy to view what data is being sent, all this without worrying about intercepting traffic or decrypting the HTTPS stream.



A second example application examined was a banking app. After spending some time using the app and then doing a dump of the hprof, we used strings and grep (and some known data) we could easily see what is being stored in memory.

strings /tmp/android43208542802109.hprof | grep '92xxxxxx'

Using part of the card number associated with the banking app, we can locate any references to it in memory. And we get a lot of information..



And there we go, a fully "decrypted" JSON response containing lots of interesting information. Grep'ing around yields other interesting values, though I haven't managed to find the login PIN yet (a good thing I guess).


Next step? Find a way to cause a memory dump in the banking app using another app on the phone, extract the necessary values and steal the banking session, profit.


Memory analysis provides an interesting alternate means of finding data within applications, as well as allowing analysts to decipher how the application operates. The benefits are numerous as the application "does all the work" and there is no need to intercept traffic or figure out the decryption routines used.

Appendix:


The remoteAddress field in the response is very interesting as it maps back to a range owned by Merck (one of the largest pharmaceutical companies in the world http://en.wikipedia.org/wiki/Merck_%26_Co.) .. No idea what it's doing in this particular app, but it appears in every session I've looked at.

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.

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
Mov EBP, ESP
JMP loc_6969
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 blah.app 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 blap.app
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.

References:

1) http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

2) http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html

Mon, 16 May 2011

Rhodes MSc Information Security Weekend

An education isn't how much you have committed to memory, or even how much you know. It's being able to differentiate between what you know and what you don't. - Anatole France

Jobs within Information Security, and indeed Information Technology, are often more than a 9-5 affair for many who choose them as their career. There is a wealth of different technologies, frameworks, approaches and information that you need to understand to perform your job to a suitable level. In IT security specifically, with the pace of technology constantly growing, keeping abreast is often easier said than done.

Local there is a severe lack of established courses catering for those new to Information Security, or those looking at obtaining a more meaningful qualification, which are few and far between. When Rhodes University announced they were offering a Masters course in Information Security here in South Africa, and asked SensePost if they'd like to present a number of modules, we were more than happy to be involved.

Barry Irwin asked us to deliver a weekend of application security: the whys, hows, whats and whens of all things application security. Armed with suitable vulnerable web applications for the students to abuse and use, I made the trip down to Grahamstown in April.

The course started with an understanding of why security has traditionally been hard to implement in the development life-cycle and then moved on to the various challenges faced by those responsible for developing applications. The course drew on the experience of those within SensePost, who have been involved in large application deployments and worked with customers in helping them produce secure applications.

Since all talk and no fun isn't the best approach for learning, students were let loose on commonly deployed applications and taught how to break them. Whilst many have heard the term "SQL injection", doing it correctly for the first time always brings an evil smile upon the face of who ever is doing it. As an industry, we are very quick to use acronyms and expect others to know what we are talking about, but often fail to realise this isn't always the case. From basic authorisation flaws to chained logic flaws, the main areas of abuse were talked about.

Besides being told by a few of the students that their brains had exploded, the course went well and everyone enjoyed hacking and learning, even if it was only for a weekend.

It was fantastic to see many reach the "aaah ha!" moment when it all made sense. SensePost have a large training offering, from beginner to advanced courses and nothing means more to the trainer than when someone understands something they've struggled with previously.

It's a great sign for the country knowing that Rhodes are producing some of South Africa's next Information Security champions and is even better knowing that SensePost was helping.

If you wish to learn how to perform security assessments the correct way, SensePost offers a comprehensive suite of training courses. We are also offering training at the Black hat security conference in Las Vegas in July.

Contact our sales team if you wish to learn more about the training offerings.

Wed, 27 Oct 2010

Analysis of a UDP worm

Introduction

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 virustotal.com 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:
  • jebena.ananikolic.su
  • peer.pickeklosarsk.ru
  • teske.pornicarke.com
  • juice.losmibracala.org
  • 92.241.190.237
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 "http://www.juniormind.com/" 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 ThreatExpert.com's report.

Conclusion

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.