Recently, we found that Android’s debugging feature could be used to steal information from apps running on an Android device. We won’t go into the full details of the problem here, but here is the short version: with some effort, an app can be set up on Android to debug another running app. This debugging app would have access to all the information the debugged app has, so items like user names and passwords are trivial to steal.

Before we go any further, however, we need to be clear what versions of Android are affected. This vulnerability is only in version 2.3 (Gingerbread) or earlier. Practically all Android devices sold today run newer versions, as Gingerbread was last updated in September 2011. However, Google’s own numbers indicate that more than half of all Android devices in use still run these potentially older versions of Android.

In a way, this problem serves as a microcosm of the issues surrounding the entire Android ecosystem. Let’s divide the ecosystem into three parties: app developers, Google and telecom companies, and end users. What can each segment do?

App developers

In this particular instance, for an app to be vulnerable to being debugged it has to have been set to be debuggable in the first place. In general, debuggable versions of apps should not be released to the public. (Approximately 5% of apps in the Top Free apps list are set to be debuggable, so the risk is not insignificant.)

In general, however, “best practices” for mobile apps may not be as set in stone as they are for desktop applications. It would be a good idea for mobile developers to consider the security of their apps, not just their features and ease-of-use.

Read the rest of this entry »

Last month, a Georgia Tech study found that mobile browsers frequently left even expert users insufficient information to judge if a site was potentially dangerous, because of user interface limitations.

The item that is most problematic is how SSL information is displayed. Compared to desktops, mobile browsers have far more limited ways to show if a site is using SSL. While the basic padlock is displayed if SSL is being used, other more advanced features may not be immediately apparent. For example, desktop browsers highlight the organization for extended-validation certificates quite prominently; for mobile browsers this is not always immediately apparent.

The reason for this is simple: user interface limitations. The space on a mobile device is much more limited compared to any conventional PC; in addition the interfaces of mobile UIs tend to be explicitly designed with simplicity in mind. This may limit the amount of information the user is shown in the browser that would be able to help them judge if a site is real or not.

This may be why studies suggest that mobile users are more likely to fall victim to phishing attacks than desktop users. More than the technical reasons, however, user attitudes may be responsible.

It’s very easy for users to consider mobile devices as simple devices that “just work” and don’t pose a security risk. Nothing could be further from the truth. Today’s mobile devices are full-fledged computers, with all the capabilities that implies. A mobile browser is as capable of running advanced scripts as a desktop browser. As our Product Manager Warren Tsai noted at an APEC workshop in April, “The mobile browser is super capable and the performance is as powerful as the desktop.”

Read the rest of this entry »