Grey bar Blue bar
Share this:

Thu, 6 Jun 2013

A software level analysis of TrustZone OS and Trustlets in Samsung Galaxy Phone

Introduction:


New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques. In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.


Mobicore OS :


The Samsung Galaxy S III was the first mobile phone that utilized ARM TrustZone feature to host and run a secure micro-kernel on the application processor. This kernel named Mobicore is isolated from the handset's Android operating system in the CPU design level. Mobicore is a micro-kernel developed by Giesecke & Devrient GmbH (G&D) which uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the rich operating system (Android, Windows , iOS) of the Mobile phone or tablet. The following figure published by G&D demonstrates Mobicore's architecture :

Overview of Mobicore (courtesy of G&D)


A TrustZone enabled processor provides "Hardware level Isolation" of the above "Normal World" (NWd) and "Secure World" (SWd) , meaning that the "Secure World" OS (Mobicore) and programs running on top of it are immune against software attacks from the "Normal World" as well as wide range of hardware attacks on the chip. This forms a "trusted execution environment" (TEE) for security critical application such as digital wallets, electronic IDs, Digital Rights Management and etc. The non-critical part of those applications such as the user interface can run in the "Normal World" operating system while the critical code, private encryption keys and sensitive I/O operations such as "PIN code entry by user" are handled by the "Secure World". By doing so, the application and its sensitive data would be protected against unauthorized access even if the "Normal World" operating system was fully compromised by the attacker, as he wouldn't be able to gain access to the critical part of the application which is running in the secure world.

Mobicore API:


The security critical applications that run inside Mobicore OS are referred to as trustlets and are developed by third-parties such as banks and content providers. The trustlet software development kit includes library files to develop, test and deploy trustlets as well as Android applications that communicate with relevant trustlets via Mobicore API for Android. Trustlets need to be encrypted, digitally signed and then remotely provisioned by G&D on the target mobile phone(s). Mobicore API for Android consists of the following 3 components:


1) Mobicore client library located at /system/lib/libMcClient.so: This is the library file used by Android OS or Dalvik applications to establish communication sessions with trustlets on the secure world


2) Mobicore Daemon located at /system/bin/mcDriverDaemon: This service proxies Mobicore commands and responses between NWd and SWd via Mobicore device driver


3) Mobicore device driver: Registers /dev/mobicore device and performs ARM Secure Monitor Calls (SMC) to switch the context from NWd to SWd


The source code for the above components can be downloaded from Google Code. I enabled the verbose debug messages in the kernel driver and recompiled a Samsung S3 kernel image for the purpose of this analysis. Please note that you need to download the relevant kernel source tree and stock ROM for your S3 phone kernel build number which can be found in "Settings->About device". After compiling the new zImage file, you would need to insert it into a custom ROM and flash your phone. To build the custom ROM I used "Android ROM Kitchen 0.217" which has the option to unpack zImage from the stock ROM, replace it with the newly compiled zImage and pack it again.


By studying the source code of the user API library and observing debug messages from the kernel driver, I figured out the following data flow between the android OS and Mobicore to establish a session and communicate with a trustlet:


1) Android application calls mcOpenDevice() API which cause the Mobicore Daemon (/system/bin/mcDriverDaemon) to open a handle to /dev/mobicore misc device.


2) It then allocates a "Worlds share memory" (WSM) buffer by calling mcMallocWsm() that cause the Mobicore kernel driver to allocate wsm buffer with the requested size and map it to the user space application process. This shared memory buffer would later be used by the android application and trustlet to exchange commands and responses.


3) The mcOpenSession() is called with the UUID of the target trustlet (10 bytes value, for instance : ffffffff000000000003 for PlayReady DRM truslet) and allocate wsm address to establish a session with the target trustlet through the allocated shared memory.


4) Android applications have the option to attach additional memory buffers (up to 6 with maximum size of 1MB each) to the established session by calling mcMap() API. In case of PlayReady DRM trustlet which is used by the Samsung VideoHub application, two additional buffers are attached: one for sending and receiving the parameters and the other for receiving trustlet's text output.


5) The application copies the command and parameter types to the WSM along with the parameter values in second allocated buffer and then calls mcNotify() API to notify the Mobicore that a pending command is waiting in the WSM to be dispatched to the target trustlet.


6) The mcWaitNotification() API is called with the timeout value which blocks until a response received from the trustlet. If the response was not an error, the application can read trustlets' returned data, output text and parameter values from WSM and the two additional mapped buffers.


7) At the end of the session the application calls mcUnMap, mcFreeWsm and mcCloseSession .


The Mobicore kernel driver is the only component in the android operating system that interacts directly with Mobicore OS by use of ARM CPU's SMC instruction and Secure Interrupts . The interrupt number registered by Mobicore kernel driver in Samsung S3 phone is 47 that could be different for other phone or tablet boards. The Mobicore OS uses the same interrupt to notify the kernel driver in android OS when it writes back data.


Analysis of a Mobicore session:


There are currently 5 trustlets pre-loaded on the European S3 phones as listed below:


shell@android:/ # ls /data/app/mcRegistry


00060308060501020000000000000000.tlbin
02010000080300030000000000000000.tlbin
07010000000000000000000000000000.tlbin
ffffffff000000000000000000000003.tlbin
ffffffff000000000000000000000004.tlbin
ffffffff000000000000000000000005.tlbin


The 07010000000000000000000000000000.tlbin is the "Content Management" trustlet which is used by G&D to install/update other trustlets on the target phones. The 00060308060501020000000000000000.tlbin and ffffffff000000000000000000000003.tlbin are DRM related truslets developed by Discretix. I chose to analyze PlayReady DRM trustlet (ffffffff000000000000000000000003.tlbin), as it was used by the Samsung videohub application which is pre-loaded on the European S3 phones.


The videohub application dose not directly communicate with PlayReady trustlet. Instead, the Android DRM manager loads several DRM plugins including libdxdrmframeworkplugin.so which is dependent on libDxDrmServer.so library that makes Mobicore API calls. Both of these libraries are closed source and I had to perform dynamic analysis to monitor communication between libDxDrmServer.so and PlayReady trustlet. For this purpose, I could install API hooks in android DRM manager process (drmserver) and record the parameter values passed to Mobicore user library (/system/lib/libMcClient.so) by setting LD_PRELOAD environment variable in the init.rc script and flash my phone with the new ROM. I found this approach unnecessary, as the source code for Mobicore user library was available and I could add simple instrumentation code to it which saves API calls and related world shared memory buffers to a log file. In order to compile such modified Mobicore library, you would need to the place it under the Android source code tree on a 64 bit machine (Android 4.1.1 requires 64 bit machine to compile) with 30 GB disk space. To save you from this trouble, you can download a copy of my Mobicore user library from here. You need to create the empty log file at /data/local/tmp/log and replace this instrumented library with the original file (DO NOT FORGET TO BACKUP THE ORIGINAL FILE). If you reboot the phone, the Mobicore session between Android's DRM server and PlayReady trustlet will be logged into /data/local/tmp/log. A sample of such session log is shown below:



The content and address of the shared world memory and two additional mapped buffers are recorded in the above file. The command/response format in wsm buffer is very similar to APDU communication in smart card applications and this is not a surprise, as G&D has a long history in smart card technology. The next step is to interpret the command/response data, so that we can manipulate them later and observe the trustlet behavior. The trustlet's output in text format together with inspecting the assembly code of libDxDrmServer.so helped me to figure out the PlayReady trustlet command and response format as follows:


client command (wsm) : 08022000b420030000000001000000002500000028023000300000000500000000000000000000000000b0720000000000000000


client parameters (mapped buffer 1): 8f248d7e3f97ee551b9d3b0504ae535e45e99593efecd6175e15f7bdfd3f5012e603d6459066cc5c602cf3c9bf0f705b


trustlet response (wsm):08022000b420030000000081000000002500000028023000300000000500000000000000000000000000b0720000000000000000


trustltlet text output (mapped buffer 2):


==================================================


SRVXInvokeCommand command 1000000 hSession=320b4


SRVXInvokeCommand. command = 0x1000000 nParamTypes=0x25


SERVICE_DRM_BBX_SetKeyToOemContext - pPrdyServiceGlobalContext is 32074


SERVICE_DRM_BBX_SetKeyToOemContext cbKey=48


SERVICE_DRM_BBX_SetKeyToOemContext type=5


SERVICE_DRM_BBX_SetKeyToOemContext iExpectedSize match real size=48


SERVICE_DRM_BBX_SetKeyToOemContext preparing local buffer DxDecryptAsset start - iDatatLen=32, pszInData=0x4ddf4 pszIntegrity=0x4dde4


DxDecryptAsset calling Oem_Aes_SetKey DxDecryptAsset


calling DRM_Aes_CtrProcessData DxDecryptAsset


calling DRM_HMAC_CreateMAC iDatatLen=32 DxDecryptAsset


after calling DRM_HMAC_CreateMAC DxDecryptAsset


END SERVICE_DRM_BBX_SetKeyToOemContext


calling DRM_BBX_SetKeyToOemContext


SRVXInvokeCommand.id=0x1000000 res=0x0


==============================================


By mapping the information disclosed in the trustlet text output to the client command the following format was derived:


08022000 : virtual memory address of the text output buffer in the secure world (little endian format of 0x200208)


b4200300 : PlayReady session ID


00000001: Command ID (0x1000000)


00000000: Error code (0x0 = no error, is set by truslet after mcWaitNotification)


25000000: Parameter type (0x25)


28023000: virtual memory address of the parameters buffer in the secure world (little endian format of 0x300228)


30000000: Parameters length in bytes (0x30, encrypted key length)


05000000: encryption key type (0x5)


The trustlet receives client supplied memory addresses as input data which could be manipulated by an attacker. We'll test this attack later. The captured PlayReady session involved 18 command/response pairs that correspond to the following high level diagram of PlayReady DRM algorithm published by G&D. I couldn't find more detailed specification of the PlayReady DRM on the MSDN or other web sites. But at this stage, I was not interested in the implementation details of the PlayReady schema, as I didn't want to attack the DRM itself, but wanted to find any exploitable issue such as a buffer overflow or memory disclosure in the trustlet.

DRM Trustlet diagram (courtesy of G&D)


Security Tests:


I started by auditing the Mobicore daemon and kernel driver source code in order to find issues that can be exploited by an android application to attack other applications or result in code execution in the Android kernel space. I find one issue in the Mobicore kernel API which is designed to provide Mobicore services to other Android kernel components such as an IPSEC driver. The Mobicore driver registers Linux netLink server with id=17 which was intended to be called from the kernel space, however a Linux user space process can create a spoofed message using NETLINK sockets and send it to the Mobicore kernel driver netlink listener which as shown in the following figure did not check the PID of the calling process and as a result, any Android app could call Mobicore APIs with spoofed session IDs. The vulnerable code snippet from MobiCoreKernelApi/main.c is included below.



An attacker would need to know the "sequence number" of an already established netlink connection between a kernel component such as IPSEC and Mobicore driver in order to exploit this vulnerability. This sequence numbers were incremental starting from zero but currently there is no kernel component on the Samsung phone that uses the Mobicore API, thus this issue was not a high risk. We notified the vendor about this issue 6 months ago but haven't received any response regarding the planned fix. The following figures demonstrate exploitation of this issue from an Android unprivileged process :

Netlink message (seq=1) sent to Mobicore kernel driver from a low privileged process


Unauthorised netlink message being processed by the Mobicore kernel driver


In the next phase of my tests, I focused on fuzzing the PlayReady DRM trustlet that mentioned in the previous section by writing simple C programs which were linked with libMcClient.so and manipulating the DWORD values such as shared buffer virtual address. The following table summarises the results:
wsm offsetDescriptionResults
0Memory address of the mapped output buffer in trustlet process (original value=0x08022000)for values<0x8022000 the fuzzer crashed


values >0x8022000 no errors

41memory address of the parameter mapped buffer in trusltet process (original value=0x28023000)0x00001000<value<0x28023000 the fuzzer crashed


value>=00001000 trustlet exits with "parameter refers to secure memory area"


value>0x28023000 no errors

49Parameter length (encryption key or certificate file length)For large numbers the trustlet exits with "malloc() failed" message

The fuzzer crash indicated that Mobicore micro-kernel writes memory addresses in the normal world beyond the shared memory buffer which was not a critical security issue, because it means that fuzzer can only attack itself and not other processes. The "parameter refers to secure memory area" message suggests that there is some sort of input validation implemented in the Mobicore OS or DRM trustlet that prevents normal world's access to mapped addresses other than shared buffers. I haven't yet run fuzzing on the parameter values itself such as manipulating PlayReady XML data elements sent from the client to the trustlet. However, there might be vulnerabilities in the PlayReady implementation that can be picked up by smarter fuzzing.


Conclusion:


We demonstrated that intercepting and manipulating the worlds share memory (WSM) data can be used to gain better knowledge about the internal workings of Mobicore trustlets. We believe that this method can be combined with the side channel measurements to perform blackbox security assessment of the mobile TEE applications. The context switching and memory sharing between normal and secure world could be subjected to side channel attacks in specific cases and we are focusing our future research on this area.

Sat, 1 Jun 2013

Honey, I’m home!! - Hacking Z-Wave & other Black Hat news

You've probably never thought of this, but the home automation market in the US was worth approximately $3.2 billion in 2010 and is expected to exceed $5.5 billion in 2016.


Under the hood, the Zigbee and Z-wave wireless communication protocols are the most common used RF technology in home automation systems. Zigbee is based on an open specification (IEEE 802.15.4) and has been the subject of several academic and practical security researches. Z-wave is a proprietary wireless protocol that works in the Industrial, Scientific and Medical radio band (ISM). It transmits on the 868.42 MHz (Europe) and 908.42MHz (United States) frequencies designed for low-bandwidth data communications in embedded devices such as security sensors, alarms and home automation control panels.


Unlike Zigbee, almost no public security research has been done on the Z-Wave protocol except once during a DefCon 2011 talk when the presenter pointed to the possibility of capturing the AES key exchange ... until now. Our Black Hat USA 2013 talk explores the question of Z-Wave protocol security and show how the Z-Wave protocol can be subjected to attacks.


The talk is being presented by Behrang Fouladi a Principal Security Researcher at SensePost, with some help on the hardware side from our friend Sahand Ghanoun. Behrang is one of our most senior and most respected analysts. He loves poetry, movies with Owen Wilson, snowboarding and long walks on the beach. Wait - no - that's me. Behrang's the guy who lives in London and has a Masters from Royal Holloway. He's also the guy who figured how to clone the SecureID software token.


Amazingly, this is the 11th time we've presented at Black Hat Las Vegas. We try and keep track of our talks and papers at conferences on our research services site, but for your reading convenience, here's a summary of our Black Hat talks over the last decade:



2002: Setiri : Advances in trojan technology (Roelof Temmingh)


Setiri was the first publicized trojan to implement the concept of using a web browser to communicate with its controller and caused a stir when we presented it in 2002. We were also very pleased when it got referenced by in a 2004 book by Ed Skoudis.


2003: Putting the tea back into cyber terrorism (Charl van der Walt, Roelof Temmingh and Haroon Meer)


A paper about targeted, effective, automated attacks that could be used in countrywide cyber terrorism. A worm that targets internal networks was also discussed as an example of such an attack. In some ways, the thinking in this talk eventually lead to the creation of Maltego.


2004: When the tables turn (Charl van der Walt, Roelof Temmingh and Haroon Meer)


This paper presented some of the earliest ideas on offensive strike-back as a network defence methodology, which later found their way into Neil Wyler's 2005 book "Aggressive Network Self-Defence".


2005: Assessment automation (Roelof Temmingh)


Our thinking around pentest automation, and in particular footprinting and link analyses was further expanded upon. Here we also released the first version of our automated footprinting tool - "Bidiblah".


2006: A tail of two proxies (Roelof Temmingh and Haroon Meer)


In this talk we literally did introduce two proxy tools. The first was "Suru', our HTTP MITM proxy and a then-contender to the @stake Web Proxy. Although Suru has long since been bypassed by excellent tools like "Burp Proxy" it introduced a number of exciting new concepts, including trivial fuzzing, token correlation and background directory brute-forcing. Further improvements included timing analysis and indexable directory checks. These were not available in other commercial proxies at the time, hence our need to write our own.


Another pioneering MITM proxy - WebScarab from OWASP - also shifted thinking at the time. It was originally written by Rogan Dawes, our very own pentest team leader.


The second proxy we introduced operated at the TCP layer, leveraging off the very excellent Scappy packet manipulation program. We never took that any further, however.


2007: It's all about timing (Haroon Meer and Marco Slaviero)


This was one of my favourite SensePost talks. It kicked off a series of research projects concentrating on timing-based inference attacks against all kinds of technologies and introduced a weaponized timing-based data exfiltration attack in the form of our Squeeza SQL Injection exploitation tool (you probably have to be South African to get the joke). This was also the first talk in which we Invented Our Own Acronym.


2008: Pushing a camel through the eye of a needle (Haroon Meer, Marco Slaviero & Glenn Wilkinson)


In this talk we expanded on our ideas of using timing as a vector for data extraction in so-called 'hostile' environments. We also introduced our 'reDuh' TCP-over-HTTP tunnelling tool. reDuh is a tool that can be used to create a TCP circuit through validly formed HTTP requests. Essentially this means that if we can upload a JSP/PHP/ASP page onto a compromised server, we can connect to hosts behind that server trivially. We also demonstrated how reDuh could be implemented under OLE right inside a compromised SQL 2005 server, even without 'sa' privileges.


2009: Clobbering the cloud (Haroon Meer, Marco Slaviero and Nicholas Arvanitis)


Yup, we did cloud before cloud was cool. This was a presentation about security in the cloud. Cloud security issues such as privacy, monoculture and vendor lock-in are discussed. The cloud offerings from Amazon, Salesforce and Apple as well as their security were examined. We got an email from Steve "Woz" Wozniak, we quoted Dan Geer and we had a photo of Dino Daizovi. We built an HTTP brute-forcer on Force.com and (best of all) we hacked Apple using an iPhone.


2010: Cache on delivery (Marco Slaviero)


This was a presentation about mining information from memcached. We introduced go-derper.rb, a tool we developed for hacking memcached servers and gave a few examples, including a sexy hack of bps.org. It seemed like people weren't getting our point at first, but later the penny dropped and we've to-date had almost 50,000 hits on the presentation on Slideshare.


2011: Sour pickles (Marco Slaviero)


Python's Pickle module provides a known capability for running arbitrary Python functions and, by extension, permitting remote code execution; however there is no public Pickle exploitation guide and published exploits are simple examples only. In this paper we described the Pickle environment, outline hurdles facing a shellcoder and provide guidelines for writing Pickle shellcode. A brief survey of public Python code was undertaken to establish the prevalence of the vulnerability, and a shellcode generator and Pickle mangler were written. Output from the paper included helpful guidelines and templates for shellcode writing, tools for Pickle hacking and a shellcode library.We also wrote a very fancy paper about it all...


We never presented at Black Hat USA in 2012, although we did do some very cool work in that year.


For this year's show we'll back on the podium with Behrang's talk, as well an entire suite of excellent training courses. To meet the likes of Behrang and the rest of our team please consider one of our courses. We need all the support we can get and we're pretty convinced you won't be disappointed.


See you in Vegas!

Thu, 9 May 2013

Wifi Hacking & WPA/2 PSK traffic decryption

When doing wireless assessments, I end up generating a ton of different scripts for various things that I thought it would be worth sharing. I'm going to try write some of them up. This is the first one on decrypting WPA/2 PSK traffic. The second will cover some tricks/scripts for rogue access-points. If you are keen on learn further techniques or advancing your wifi hacking knowledge/capability as a whole, please check out the course Hacking by Numbers: Unplugged, I'll be teaching at BlackHat Las Vegas soon.


When hackers find a WPA/2 network using a pre-shared key, the first thing they try and do most times, is to capture enough of the 4-way handshake to attempt to brute force the pairwise master key (PMK, or just the pre-shared key PSK). But, this often takes a very long time. If you employ other routes to find the key (say a client-side compromise) that can still take some time. Once you have the key, you can of course associate to the network and perform your layer 2 hackery. However, if you had been capturing traffic from the beginning, you would now be in a position to decrypt that traffic for analysis, rather than having to waste time by only starting your capture now. You can use the airdecap-ng tool from the aircrack-ng suite to do this:


airdecap-ng -b <BSSID of target network> -e <ESSID of target network> -p <WPA passphrase> <input pcap file>


However, because the WPA 4-way handshake generates a unique temporary key (pairwise temporal key PTK) every time a station associates, you need to have captured the two bits of random data shared between the station and the AP (the authenticator nonce and supplicant nonce) for that handshake to be able to initialise your crypto with the same data. What this means, is that if you didn't capture a handshake for the start of a WPA/2 session, then you won't be able to decrypt the traffic, even if you have the key.


So, the trick is to de-auth all users from the AP and start capturing right at the beginning. This can be done quite simply using aireplay-ng:


aireplay-ng --deauth=5 -e <ESSID>

Although, broadcast de-auth's aren't always as successful as a targeted one, where you spoof a directed deauth packet claiming to come from the AP and targeting a specific station. I often use airodump-ng to dump a list of associated stations to a csv file (with --output-format csv), then use some grep/cut-fu to excise their MAC addresses. I then pass that to aireplay-ng with:


cat <list of associated station MACs>.txt | xargs -n1 -I% aireplay-ng --deauth=5 -e <ESSID> -c % mon0

This tends to work a bit better, as I've seen some devices which appear to ignore a broadcast de-auth. This will make sure you capture the handshake so airdecap can decrypt the traffic you capture. Any further legitimate disconnects and re-auths will be captured by you, so you shouldn't need to run the de-auth again.


In summary:


  • Don't forget how useful examining traffic can be, and don't discount that as an option just because it's WPA/2

  • Start capturing as soon as you get near the network, to maximise how much traffic you'll have to examine

  • De-auth all connected clients to make sure you capture their handshakes for decryption


Once again, I'll be teaching a course covering this and other techniques at BlackHat Las Vegas, please check it out or recommend it to others if you think it's worthwhile. We're also running a curriculum of other courses at BH, including a brand new mobile hacking course.

    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.

    Wed, 16 Jan 2013

    Client Side Fingerprinting in Prep for SE

    On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.


    First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.


    Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).


    This provided me with the following stats:









    Operating System


    Win XP 8


    Win 7 32 3


    Win 7 64 3

    Browser


    IE 8 8


    IE 6 3


    IE 7 1


    IE 9 1

    Combination


    Win 7 IE 8 4


    Win XP IE 8 4


    Win XP IE 6 3


    Win 7 IE 9 1


    Win XP IE 7 1


    Granted, it could be that the same machine was present in multiple logs and the stats are skewed, but they are a large enough organisation that I thought the chances were low, especially as most of the sites who's logs I found were pretty niche. As validation of these results, later, once we had penetrated through to the internal network, it was clear that they had a big user base in regional offices still on Win XP and IE6, and a big user base at corporate offices who had been migrated to Windows 7 with IE8.


    Unfortunately, the UserAgent didn't make it clear whether they had Acrobat or Java or what versions they were at. We thought of using some JavaScript to do such detection, but were under a time constraint, and went with trying to pwn them instead, with the thinking that if it doesn't work, we could retarget and at least get some debugging information.


    Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).