Perimeter
3/30/2012
10:30 AM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Forensic Approach To Mobile App Vulnerability Research

Intro to a unique approach for vulnerability research on mobile apps using traditional PC forensic tools

I recently gave a presentation at the SANS Mobile Device Security Summit in Nashville, titled "Smart Bombs: Mobile Application Vulnerabilities and Exploitation." The talk was a bit of a preview of a talk of the same name that Kevin Johnson, Tom Eston, and I will be giving at OWASP AppSecDC next week. The focus of the SANS presentation was to cover some of the tools and methods I use for analyzing mobile devices for vulnerabilities. I'll be covering some of those approaches and tools in this and upcoming Evil Bytes blogs.

While some of my methods (i.e., Burp to intercept HTTP[S] traffic) are pretty common among security researchers and penetration testers, I think a few techniques are a bit unique. Why? Well, I've developed them based on my experiences as a forensic examiner, network intrusion analyst, and penetration tester. Today, I'm going to start discussing the forensic methods and introduce one particular tool that I've adapted from PC-based forensic cases to mobile platforms.

The use of timeline analysis is one of the areas in forensics that has gained a lot of attention during the past few years. Thanks to the wonderful log2timeline tool, timelines have experienced a rebirth as more and more sources of data (i.e., logs, browser history, Windows Registry) can be pulled into a timeline, making it easier to determine what has happened. What's cool is that timeline analysis techniques can also be applied to mobile application research to find all sorts of interesting things about applications.

Like what, you ask? The locations of the application itself, where it stores temporary files, any associated log files, and downloaded content are a few examples. What I typically do is create several timelines, including one before an application is installed, another while it is running, and a third after the app is closed.

The different "snapshots" of the filesystem at different times gives insight into what the application is doing and how it's interacting with files on the actual mobile device. For example, the app might store downloaded files in an odd location or might decrypt encrypted attachments and put them it in a temporary directory.

Based on what I've heard from some other researchers, they use the tool dd to create a full bit-for-bit copy of the mobile device filesystem and analyze it using forensic tools like AccessData's FTK or Guidance Software's EnCase. While that works for filesystem analysis and is useful for recovering deleted files, it is often incredibly slow trying to dump 16 to 64 GB from a mobile device.

To make my analysis process faster, I started using mac-robber from Brian Carrier about a year ago to collect timestamps directly on the device and process them on my analysis machine using mactime from the Sleuth Kit project. Mac-robber runs quickly and the resulting "body" file can be quickly copied off the device and processed with mactime to create the timeline. From there, you can enjoy the timeline goodness.

In the next part of this blog series, I'll cover how to get mac-robber running on Android and iOS devices, along with examples of how to use it to find interesting things (like vulnerabilities).

It's important I point out that I'm not attempting to perform a forensically sound analysis. My goal is to perform security research, which ends up having an impact on the actual mobile device environment -- something you want to avoid as much as possible during the forensic process.

John Sawyer is a Senior Security Analyst with InGuardians, Inc. The views and opinions expressed in this blog are his own and do not represent those of his employer. He can be reached at johnhsawyer@gmail.com and found on Twitter @johnhsawyer.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
johnhsawyer
50%
50%
johnhsawyer,
User Rank: Moderator
4/1/2012 | 2:27:46 PM
re: Forensic Approach To Mobile App Vulnerability Research
Thank you for the comment. I'm not advocating this approach is the only way--far from it. This is simply a basic, introductory approach to get people started that is easier to explain and teach. It can built upon or be a precursor to advanced methods like runtime analysis and binary reverse engineering.

Plus, I like finding alternative uses of tools to do things outside of what they were designed to do and the application of timeline analysis with mac-robber here is a good example of that.

(I'm sure you know the following, but I'm including it for other readers.) The difference between the tools you mention and those I discuss are akin to the difference between static binary and runtime analysis of executables (like malware) to behavioral analysis of what happens to the system when the executable runs.

There is a learning curve and depth of knowledge that the average system administrator and security professional won't have for more advanced methods so they're less likely to be comfortable with GDB and IDA Pro, but they would be more comfortable with analyzing environmental changes to the filesystem, Registry, event logs, etc. and looking at network traffic (maybe even strace if they have *nix background). That's where this approach allows them to leverage their knowledge to do analysis and can build upon that experience to do more advanced analysis later on.

-jhs
flast_name606
50%
50%
flast_name606,
User Rank: Apprentice
4/1/2012 | 5:03:52 AM
re: Forensic Approach To Mobile App Vulnerability Research
I don't agree that forensics is a "good" way to evaluate mobile platforms or apps for vulnerabilities. I think they are "one" way, but they do not get into the runtime or the binaries or code.

My favorite tools for runtime are cycript for iOS and strace for Android, which are not equivalent tools. strace can really see what files and networks are touched by an Android app that Burp and mac-robber will never see into...
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8243
Published: 2014-11-01
Linksys SMART WiFi firmware on EA2700 and EA3500 devices; before 2.1.41 build 162351 on E4200v2 and EA4500 devices; before 1.1.41 build 162599 on EA6200 devices; before 1.1.40 build 160989 on EA6300, EA6400, EA6500, and EA6700 devices; and before 1.1.42 build 161129 on EA6900 devices allows remote a...

CVE-2014-8244
Published: 2014-11-01
Linksys SMART WiFi firmware on EA2700 and EA3500 devices; before 2.1.41 build 162351 on E4200v2 and EA4500 devices; before 1.1.41 build 162599 on EA6200 devices; before 1.1.40 build 160989 on EA6300, EA6400, EA6500, and EA6700 devices; and before 1.1.42 build 161129 on EA6900 devices allows remote a...

CVE-2013-0334
Published: 2014-10-31
Bundler before 1.7, when multiple top-level source lines are used, allows remote attackers to install arbitrary gems by creating a gem with the same name as another gem in a different source.

CVE-2014-2334
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2335
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.