On the other hand because of Security BSides and other smaller conferences over the years more unknown speakers are getting out there. We’re also seeing more great talks and discussions then ever before because of these smaller conferences. This is a good thing for our industry. Many good talks still get rejected from the big conferences like Black Hat and this is where conferences like Security BSides really shine. However, we potentially run the risk of seeing the same speakers, same content and as Matt said we appear to have an “echo chamber problem” at all of these conferences including the big ones. Is anyone else seeing this trend? Does the overlap of multiple security conferences matter to you? Like any trend in technology are we about to bust the “Security Conference Bubble”? I often wonder what the security conference world will look like in a few years if this trend continues.

Share and Enjoy

I hope to do a review of this book soon. So far it looks to be a good technical read.

Share and Enjoy

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

Share and Enjoy

Share and Enjoy

One update we forgot to mention in the talk is that you should use Mallory, which is a transparent TCP and UDP proxy for testing mobile applications.  This is an excellent tool created by the guys at Intrepidus Group.  We’ve found that some apps will bypass proxy settings and lots of apps are sending data over binary protocols and more.  Mallory is the tool you need for testing any mobile app fully!

Just a reminder that I’ll be presenting Smart Bombs: Mobile Vulnerability and Exploitation with John Sawyer and Kevin Johnson at OWASP AppSec DC on April 5th in Washington DC.  I’ll be focusing my research on iOS application testing and some of the vulnerabilities discovered in some of the top 25 iOS applications.

Share and Enjoy

Share and Enjoy

What I liked most about this event was that there were plenty of “real world” talks on how enterprises are deploying and managing mobile deployments.  Real in the “trenches” types of talks.  Here are some of the themes that I heard throughout all the talks:

• Jailbreaking/Rooting is BAD
• The OWASP Mobile Top 10 is going to be just as important as the traditional web application OWASP Top 10
• Mobile Threats are an evolving, moving target.  Security teams have to be quick to adapt to new mobile technology
• MDM (Mobile Device Management Solutions) are a requirement
• Apple iOS devices are preferred over Android in the enterprise (seriously, that was the consensus).  No one seems to care about BlackBerry or Windows Mobile devices.  I think only one speaker mentioned Windows Mobile…

Speaking to the last point I find this pretty interesting.  Especially given the fact that Android seems to be beating Apple in regards to market share of devices and app store apps.  I also enjoyed hearing about some of the challenges and pitfalls real IT and security departments are facing.  Many of the speakers talked about some best practices they’ve developed and problems they’ve had.  One of the highlights for me was a talk by Det. Cindy Murphy from the Madison WI Police Department Computer Forensics Unit.  She shared some of her experiences with mobile device forensics and how this evidence holds up in court.  I highly recommend you check out this summit next year, it’s one not to miss!

I should have my slides from the latest version of my talk that I gave at the summit (Attacking & Defending Apple iOS Devices in the Enterprise) in the next day or so.

Share and Enjoy

I did some research and found this blog post which says this is simply a configuration issue with the passcode settings.  Check your setting for “Require Passcode” (under the Passcode Lock screen) and make sure it’s set to “Immediately”.  If it’s set to 1 minute or more, you really haven’t locked your device.  You’ve just been shutting off the screen.  See the screen shot below for the passcode setting you should be using.

Share and Enjoy

Share and Enjoy

#1 – The Passcode
This is the most important security feature of your device. It’s also one of the least configured settings. While it may be a pain to “unlock” your device when you want to use it, it’s also your first line of defense if your device is ever lost or stolen. The key to the passcode is to ensure its complex and greater than 4 characters or digits. Never use simple passcodes like “1234” or your ATM PIN number. The two other settings that you need to set are to “Require Passcode Immediately” and set “Simple Passcode” to OFF. You can find these settings under the “Settings” icon then “Passcode Lock”.

#2 – Erase Data
The erase data functionality adds another layer of security to your device. This function will erase all data after 10 failed passcode attempts. What this means is that if someone steals your device and tries to brute force your passcode, if they enter it incorrectly, the device is erased and returned to the factory default settings. Turn “Erase Data” to ON in the Passcode Lock screen.

#3 – Find My iPhone/iPad
If you ever lose or misplace your iPhone or iPad, “Find My iPhone/iPad” is a very important feature to enable. Simply download the application on your device or access it through iCloud (icloud.com). If your device is iOS 4 or below you will need to use the “MobileMe” (me.com) feature instead of iCloud. Either way, you will need to login with your Apple ID to set it up. You can then send the device a message or alert, locate the device on Google Maps, remotely set a passcode, and remotely erase the device. This feature is invaluable if your device is lost or stolen.

#4 – Backup Encryption
One of the more obscure settings that many users don’t set is the “Encrypt Backup” setting, which is found in iTunes. This setting even applies to the new iCloud service in iOS 5. This setting ensures that the backup of your device is encrypted. It goes without saying, if you can access this backup, the data on your device can be accessed and harvested. For example, earlier last year there was a “feature” in which Geolocation data could be easily harvested from the backup file. This has since been remediated, but just think how much information could be harvested about you through an unencrypted backup file.

#5 – Keep iOS Updated
Making sure that you always have the latest version of Apple iOS on your device is important because Apple is always releasing security updates and implementing new security controls. Simply plug your device into iTunes and you will get prompted to update your phone to the latest version. As a side note, don’t Jailbreak your device! Jailbreaking makes many of the built in security features useless and allows your device to be an easy target for data theft.

Ensuring that you have enabled and configured these security settings on your Apple iOS device is more important than ever. Devices like these are lost or stolen all the time and without taking the proper precautions, your data could be vulnerable. Having conducted Apple iOS device penetration testing assessments at SecureState for our clients, I can tell you how easy it is to break into these devices. It’s easy because the proper basic precautions were not taken. Take five minutes now and enable these settings; you’ll be glad you did.

Cross-posted from the SecureState Blog

Share and Enjoy

Probably the easiest Jailbreak tool out there as well…

Share and Enjoy

Share and Enjoy

Share and Enjoy

Download the white paper.  Download Josh’s Metasploit modules.  Download Kevin’s vulnerable web services.

Share and Enjoy

See the full gallery on Posterous

Share and Enjoy

UPDATE (5/27): I found a very nice script by Patrick Toomey which can dump the contents of the keychain on Jailbroken iOS devices.  More details about how the script runs can be found in this blog post.  Note that the type of information you get back depends if the passcode is enabled or not.  You will get more keychain entries back if the passcode is not enabled.  I had mentioned in my presentation that I hadn’t found a script to do this yet…well here it is.

Share and Enjoy

Share and Enjoy