Having spoken at both at the SANS Mobile Device Security Summit as well as OWASP AppSec DC recently about testing mobile applications I’ve encountered that like the old saying goes “There are many ways to skin a cat”, there are also many ways to assess a mobile application. I’ve seen very detailed testing methodologies, not so detailed and everything in between. I’ve also heard other security professionals say that testing mobile applications are just like testing a web application. This is simply a wrong and inaccurate statement. Mobile applications are fairly complex and just assessing the application layer is only a small look into the overall security of a mobile application. While the OWASP Mobile Security Project will help define a complete mobile application testing methodology (which is in process), here are three areas that need to be tested in every mobile application.
1. The Mobile File System
How’s the application storing data and where is it being stored? You’d be surprised how much information is being stored in files, SQLite databases, system logs and more. If you’re lucky you will sometimes find private keys and hardcoded passwords. As a great example, the mobile Facebook application suffers from a file system vulnerability as I write this. The author likes to call this a “plist hijack attack”. Simply move the plist file to another mobile device and you are logged in as that user. As for tools to use when looking for file system vulnerabilities you should really check out the forensic approach that John Sawyer from InGuardians has developed. It’s my preferred method for seeing how the app writes to the file system and saves lots of time over creating a dd image.
2. The Application Layer
How’s the application communicating over HTTP? How are web services being used and how are they configured. Important things such as authorization and authentication need to be reviewed as well as session handling, business logic, input validation and crypto functions. Business logic needs to reviewed just like you would in a Web Application Assessment to find flaws in the way critical functions (like shopping cart checkout processes) were developed. Remember to never under estimate the criticality of Web Services! For reference and context, check out the presentation that Josh Abraham, Kevin Johnson and I gave at Black Hat USA last year.
Something else worth mentioning is that you can’t rely on traditional web proxies like Burp Suite to test the application layer on a mobile app. I’ve encountered applications that are configured to bypass device proxy settings! You need to use a tool like Mallory which is a fantastic TCP and UDP proxy. Mallory sees all traffic and allows you to manipulate and fuzz it. There are other ways to do this as well but regardless, you need to have a way to see all traffic the mobile app may generate.
The application layer is also where you need to look for issues specific to mobile applications like UDID usage in iOS. UDID is currently being used by many applications for unique device identification. However, the use of UDID is becoming an increasing concern from a privacy perspective. Not to mention, Apple is cracking down on UDID usage by now denying applications in the Apple App Store. Check out the presentation I did at OWASP AppSec DC this year about some of the privacy and security concerns regarding UDID.
3. The Transport Layer
How does the application communicate over TCP? How are custom protocols and third-party APIs used? Does the application use SSL? At OWASP AppSec DC we talked about the LinkedIn mobile application that was vulnerable to “sidejacking” or better known as HTTP session hijacking. This is where an attacker can pull out the session cookie in clear text and replay this so the attacker can login as the user. The popular “Firesheep” tool released in 2010 demonstrated this nicely. The good news is that the recent release of the LinkedIn app (version 5.0) fixes the sidejacking issue. Unfortunately though, using SSL for just the login process and defaulting back to HTTP is an issue many mobile and web applications still have.
Mobile Application testing is something that will evolve as mobile apps get more complex and the business drives more towards mobile solutions. If you’re deploying mobile apps for your business it’s more important than ever to have testing done on these three areas at a minimum. Lastly, keep up-to-date on the latest developments on Mobile security and testing methodologies by getting involved with the OWASP Mobile Security Project.
Cross-posted from the SecureState blog
Share and Enjoy
I saw a post from my friend Matt Neely on Twitter about how CarolinaCon and BSidesROC are on the same weekend this year. I’ve also had conversations with others earlier this week about DerbyCon (September 28-30) and GrrCon (September 27-28) being back to back as well. This is a trend that seems to be increasing every year based on the large pool of conferences out there. Not only do we have more security and hacking conferences then ever before but now there is more overlap with each other. My thought is that these choices can make it harder for researchers to present new and relevant content and also tough to decide which conferences to attend from a attendee perspective. DerbyCon was an excellent conference but I’ve also heard great things about GrrCon as well. Which conference would a speaker or attendee choose? They are also both located in the central part of the country and near large cities which makes it even more difficult for local folks to choose.
This week I co-presented “Smart Bombs: Mobile Vulnerability and Exploitation” with 
