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>
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>
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'
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.
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:
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.
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:
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:
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 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
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.appOnce 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 cryptThis 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 = 0xE8000Therefore, 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 0xE8000Once 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.binThe 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 ldidFinally, sign the patched binary using ldid:
ldid -s blahThis will fix the code signatures and you will be able to run the patched app on your iPhone.
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.
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:
Code analysis of the malware resulted in the following findings:
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.