SecTor 2010: Touring (and surviving) the mobile app minefield

TORONTO — When using a BlackBerry, Android, iPhone or other smart phone, we tend to assume all the nifty Web apps on these devices are relatively secure. At the least, we expect that a lot of the painful security lessons we received on PCs a decade ago have been applied to today’s phone apps.

But when Intrepidus Group researchers Zach Lanier and Mike Zusman started taking mobile phone apps apart to see what makes them tick, they discovered that our assumptions have been wrong. At the SecTor 2010 conference Wednesday, they walked their audience through some of the more glaring examples of old-school flaws they uncovered in many Web apps for mobile phones.

The problems that need fixing are on the developer side, Lanier said. In the rush to satisfy smart phone users hungry for new apps, the same mistakes that were made around 1999-2000 in the PC world are being repeated. After looking at the more popular phones like Android and BlackBerry, the two discovered, among other things, that:

• Intercepting one’s credentials on an app like Foursquare is pretty easy.
• Storage apps — popular among those who like to store and easily retrieve music and video on their phones — contain security holes an attacker could exploit to cause a denial of service or bypass digital rights management controls.
• Carrier-based apps tend to trust you just because you happen to be on the carrier network.
• Third-party apps are sometimes better than carrier-based apps in this regard, but there’s still incomplete support for open standards.
• Man-in-the-middle attacks are fairly trivial across the board.
• It’s trivial for a bad guy to replay a user’s picture upload requests via a third-party upload app for BlackBerry and send their own, potentially malicious files to random accounts. Zusman said injection flaws in the picture upload feature abound and that it was fairly simple to inject their own XML attribute.

Lanier and Zusman concluded that in the mobile phone Web app world there’s a lack of guidance, standards and best practices for developers.

“We learned about many of these weaknesses 10 years ago,” Lanier said. “We’re forgetting the lessons we already learned.”

By exposing these old-school problems, the researchers hope to shake the developer community into a state of vigilance.

Over the course of their research, the duo relied on such techniques as white box source code review, black box code review that included acquiring the Web app binaries, and lots of reverse engineering, disassembly and decompilation, and network-protocol analysis.

The presentation comes a few months after CSO reached out to experts on several LinkedIn security forums in an effort to find common ground on the best way to secure these devices, both on the user and developer sides. What follows are a collection of do’s and don’ts from five respondents:

Joe Brown information systems security engineer, CISSP, McAfee 

There are AV packages available for most smart phones. Same use caveats apply for phones as PCs — If you don’t recognize the sender, or there is a suspicious attachment, don’t open it. Be careful where you surf. Some Web proxies do support mobile devices. Bluetooth is evil! Control your Bluetooth footprint. With iPhone, Droid and BB there are now products that can control the ability to add applications (think white listing or common operating environments).

Derek Schatz, senior security architect for a company in Orange County, Calif.

DO:

• 1. Only deploy devices that can support key features like encryption, remote wipe, and password locking.
• 2. Create specific security policy and procedure items for mobile devices that govern acceptable use, responsibilities (e.g. what to do if device is lost or stolen), etc.
• 3. Monitor security vulnerability tracking feeds for new attacks on mobile devices.
• 4. Ensure devices in the field can be updated quickly to fix security issues.

DON’T:

• 1. Assume smart phones should only be given to senior management. Many staff-level positions can become much more productive with these tools.
• 2. Deploy devices for enterprise use without proper protections and control. The loss of proprietary information can be very costly to the business.

Michael Schuler, Chicago-based systems administrator

DO:

• 1. Define the purpose of having smart phones in the environment.
• 2. Define the best roles for having smart phones in the environment.
• a. Human resources should have a big part in this. Especially when it comes to salaried employees.
• 3. Evaluate the products for security/performance features that fit your market.
• a. Certain products/devices may not meet the security requirements of financial or government institutions.
• b. How well does the product integrate with our existing infrastructure.
• 4. Implement security policies based on what was determined from Step 3.
• 5. Define what level of support you plan to provide if implementing different types of smart phones.
• 6. Solicit info from similar companies who have already implemented what you are looking to implement.
• a. Ask about how long they’ve been using the product for.
• b. Find out if they’re any pinch points that they didn’t foresee.
• 7. Build a test group of more than just IT staff to test your POC. Take usability information from IT and non-IT staff alike.

DON’T

• 1. Assume that all devices treat things like encryption. both on the device and in transit, the same.
• 2. Give every single person in the company a smart phone. While it may be helpful for people below the executive level employee to have a device, HR needs to be involved to make sure that those users understand that they may/may not be compensated for OT worked while communicating with their smart phone.
• 3. Deploy devices without understanding what policies you have (or not) enabled and what your risk of data loss is.

Don’t just limit your evaluation to “Everybody uses Blackberries we should, too.” Good for Technology has a pretty decent application and supports a huge range of devices From Win Mo to certain palm devices (no pre yet) and even the iPhone. The Good for Enterprise application for the iPhone is far better than using ActiveSync, security wise. But, with how the iPhone 3.0 OS is built. The app doesn’t really sync messages, contacts and calendar until it’s launched. The db backend for the application is slow. But, they’re promising an overhauled backend for the next revision. I’m hopeful the version after that will support the network back-grounding features of the iPhone 4 OS.

Also, RIM devices have been really disappointing in their most recent devices. They have really poor reception in most areas. Also the latest device OSes, to my understanding, don’t meet the DOD’s security requirements. While you may not have DOD level security needs for your devices. It’s something to think about in your evaluation.

Also, and I don’t mean to hate on RIM, if you actually enable encryption on your blackberry devices. Expect a good amount of lag in working with your device. It’s very tolerable, on strong, if you just use it as a messaging device. But, the minute someone puts a microsd card in it and takes some company pictures with it. It slows down very quickly as it has to decrypt the data on the card every time it’s unlocked and re-encrypt it every time it’s locked.

Overall there are features in the BES admin interface that I feel are lacking, but easily fixed by buying a third-party product like Zenprise or Boxtone. But a lot of that functionality is built into the Good for Enterprise product.

My one recommendation is to avoid ActiveSync. In general I’ve had very poor results with managing devices using ActiveSync. Granted I’ve not managed them with a 2007 or later Exchange environment. But, I don’t feel that ActiveSync is nearly as robust or well thought out as Good or BES.

Mayank Aggarwal, global threat center research engineer, SMobile Systems 

1. From the SMobile Systems Threat Center paper “Man in the Middle Attack”: MITM attacks are considered to be a legitimate threat to confidential or private data in the PC side of information security. The testing team has adequately shown that with a mobile laptop in a Wi-Fi network, it is possible to intercept communications between the smartphone and the Wi-Fi hotspot. The testing team was able to perform successful MITM attacks against four different smartphone devices, illustrating that protections provided by SSL can be bypassed and login credentials can be intercepted.

This study underscores the fact that the use of publicly available Wi-Fi hotspots should be approached with caution and care should be taken to ensure that confidential or private data is adequately encrypted, when it becomes necessary to access such data. Where possible, smartphone users should seek out and identify applications that provide adequate encryption technologies to protect confidential or private information. At this point, such applications do exist, but are scarce. When selecting applications to handle sensitive communications, users should search for applications that provide end-to-end encryption between the client application and the end server. Additionally, when dealing with applications that provide access to financial institutions or other sensitive information, the same precautions should be taken to ensure those communications are encrypted end-to-end. When such applications are not readily available, users must ensure they take necessary precautions to ensure they are only accessing sensitive information over, either, the service provider’s internet connection provided from their data plan or from a trusted, secure Wi-Fi network, where available.

Additionally, personal smartphone users and enterprises providing (or allowing) smartphone access into their environments for productivity, should ensure that security software is installed that provides firewall and anti-virus capabilities, at the least. Users and enterprises must begin to treat their smartphone devices with the same care that they do when using their PC’s or laptops. The threats, while not as extensive at this point, are quite similar and costly when successful attacks occur. Moreover, as always, as vulnerability/exploit research continues to occur against smartphone devices, so to will the number of exploits that translate into successful attacks against smartphone users.

2. From the SMobile Systems paper on SMS-based attacks:

There is another prominent threat that every mobile user is vulnerable and is hardly discussed i.e. SMS spamming. Currently, neither mobile devices nor their carriers offer substantive support or features that could regulate the flow of incoming SMS messages, out of the box. This is likely the reason why SMS continues to receive the attention of attackers as a viable attack vector, which garners the service so much research attention. Note: The above article just mentions one way of spamming user. However, I am working on a new article that will discuss that spamming process can be automated by using a tool (that I wrote as a POC) that can send unlimited SMS spam to a number of users at once.

Yinal Ozkan, Principal Architect, CISM, CISA, CISSP, INTEGRALIS

DO:

• 1. No unmanaged mobile devices — central management is a mandate. Unmanaged devices should not have access to corporate data.
• 2. Managed devices should be managed over the air. Remote policy pushes over the carrier network must work (Over-the-air programming (OTA)). End user profiles should be encrypted with no options for local modification.
• 3. Central logging should enforce a policy with the following items (it is possible to increase policy items): mobile data encryption, lock timeout settings (screen-saver lockout); authentication/Password policy; PIN (Blackberry) SMS and IM, Bluetooth policy (ok or not); remote wipe; OTA; allowed applications; policy for social media; and a policy for cameras.
• 4. Try to expand your endpoint security policy to mobile endpoints (URL filtering/AV/media handling/firewall) but do not get overexcited, only deploy the solutions that work. It is a good idea to implement these solutions at the enterprise gateway (proxy all network connections) instead of limited resource mobile devices. URL filtering in the cloud is a very good example.
• 5. Try to expand your corporate phone system to your smart devices. There are soft clients that expand into mobile devices seamlessly so that all voicemails/extensions/DIDs do work on your smart phones. Again do not get overexcited. This expansion will carry over your existing security to mobile devices.
• 6. Do 802.1x on the wireless VOIP clients on the smart phones.
• 7. Manage authentication with certs (preferably on the SIMs)

DON’T

• 1. Do not block all third-party applications. Have a process to approve applications. Create a whitelist for approved applications. Blocking is not the keyword, the keyword is controlling.
• 2. Do not allow unmanaged devices to access and retrieve classified data (and if you do not have data classification, please do). The data on the unmanaged devices should be treated as lost (they will be). If you allow unmanaged device access make sure that you manage the risk.
• 3. Do not install more than 1 security clients on mobile devices. If it is possible, do not install a client. They are already slow maybe in the future, focus on network based security solutions.
• 4. Do not make these devices more slow or more complicated for end users, your projects will be terminated regardless of the security merits.
• 5. Do not allow every single carrier. Try to standardize end point device types and the carrier.