BeyondTrust

Security In Context

Bringing you news and commentary on solutions and strategies for protecting your critical IT infrastructure.

Android Handset Makers – Adding Value or Vulnerabilities?

Post by The eEye Research Team October 10, 2011

So many things in life can cause perception to over take reality and one great example of that is as it relates to Google’s Android security. Android itself is a very robust and security minded operating system backed by one of the best security research teams in the business. One of the big things that sets Android a part from other mobile operating systems is the level of openness that they support. We actually think this is a great thing but it does put the responsibility of security on the shoulders of not just Google but their partners. In the gold rush that is today’s mobile market, the problem is that most partners are not thinking about security. They are thinking about which widget will allow them to have better differentiation in an overly crowded market. Security simply becomes an afterthought. And we all know how that story goes…

Since Android’s release in September of 2008, it has become one of the most pervasive open source projects around, landing itself on myriad devices and into consumer’s pockets and homes. Its popularity is continually fueled by its customization and portability. However, since that time, Android’s incredible growth and recent market majority have put a lot of end users at risk from attackers, due to its fragmented nature.We’ve all read about issues with the Android lifecycle – including the well-known fact that it takes many wireless service providers and manufacturers several months to roll out critical patches and updates released by Google. A lesser discussed, but equally dangerous issue, is that carriers and manufacturers piggyback third-party software and customization onto their Android compatible devices.

NOTE TO VEF ATTENDEES: Add your comment to this blog post for a chance to win an Amazon Kindle and $25 gift card!!! Contest ends on Friday, Oct. 14 at 3PM (Pacific). Give us your expert thoughts on the Android security issue!

Let us say you buy an Android phone, perhaps… oh, I don’t know… an HTC EVO 3D. It’s brand new, right out of the package… torn “Tamper Proof Tape” lines the box edges as you grab the phone from its plastic womb. You sign on with your Google Account and begin downloading AWESOME applications that let you shoot birds at pigs and stream music to your car. You start texting all your cool friends, telling them you got an EVO 3D and it is THE BEST THING that has ever happened to you. That is, until all your cool friends start complaining about text spam promising, “CIALIS for only $15 per bottle”. At first you chuckle… until you see that all your cool friends are complaining about the same thing.

What happened?! Could my new phone be compromised? You looked at the permissions of the applications you downloaded via third-party app stores and you avoided downloading anything that had too much POWER within the SYSTEM. What went wrong? Nada, HTC just included some software it thought might be useful for error reporting. And it just so happened that you downloaded some nefarious application that knows about this custom HTC software and happened to steal every identifiable bit of information on your phone. That nefarious app you downloaded targets software that comes with every EVO 3D, but that software is not from Google. By now you’ve probably heard about “TellHTC”, the offending HTC application. TellHTC leaks a lot of sensitive information on your phone by listening for commands from applications that have android.permission.INTERNET. By sensitive, I mean, “…the list of user accounts, including email addresses and sync status for each… last known network and GPS locations and a limited previous history of locations… phone numbers from the phone log…” and finally, “…SMS data, including phone numbers”. Good thing ‘anyone’ is a selective group of responsible applications, only existing for the benefit of society and for the USER, OR NOT.

Disgusted with both the manufacturer and your service provider, after finding out that you can’t actually turn HTCs logging feature off without deleting the app entirely, you switch carriers and purchase a Samsung Galaxy S II (because the name rolled easily off the tongue). Unfortunately, within minutes of owning the device, you find that the pattern lock is trivially bypassed by… wait for it… letting the screen time out and then pressing the lock key again. What. Whaaaaaaat.

Let’s take a closer look at the two separate, yet equally disturbing issues we just encountered:
Firstly, HTC includes software with their phones like every other manufacturer and carrier. TellHTC, which is designed to help customer support and troubleshooting by providing anonymous information about the phone, is one of those pieces of software. TellHTC has a logging service by the name of HTCLoggers that logs all the sensitive information I spoke of earlier (not really anonymous, is it?). If this data were only available to HTC, this would not be as big of an issue. However, any application with Internet permissions can query HTCLoggers, which listens for commands on a local port, and request the information that it keeps in its massive log files. Reports vary, but the text logs can be up to multiple Megabytes in size, which gives you an idea of just how much information it captures. In addition to this, it was discovered that HTCLoggers continues to log files even after the user has selected an option to disable its logging capabilities. After 5 days of being ignored by HTC, TrevE, the researcher who privately disclosed the issue to the manufacturer, went public with his findings. Shortly after word got out, HTC announced they would push a fix out to their phones. There has not however been any specific timeline given by HTC and it seems as though HTC lacks a formal security response process. They might have something internally but externally it appears some things standard security response processes are lacking.

Secondly, Samsung… Samsung… Samsung… Pattern unlock. Granted, the device is not yet available in the United States (available elsewhere), but something so fundamental to the user experience should work. According to Samsung, the issue arises, “…[i]f a user presses the power button on the device after the timeout period it will always require a password. If a user presses the power button on the phone before the timeout period, the device requests a password – but the password is not actually necessary to unlock it.” AT&T and Samsung have provided a workaround for the UI issue, stating, “Samsung and AT&T are investigating a permanent solution. In the meantime, owners of the Galaxy S II can remedy the situation by re-setting their time-out screen to the “immediately” setting”. I appreciate their timely responses to this issue, but at the same time my original Pattern Lock that came with my Nexus S 4G actually works, so there’s that. This sort of vulnerability is so basic that like HTC it shows a lack of security being engrained in any in-depth way as part of Samsung’s development process.

Android’s current, disjointed state really isn’t even Android’s fault, or Google really. The problem lies with openness and choice (wait, what?). Android itself is a very flexible platform that easily lends itself to mobile devices while retaining some cool security oriented features. However, because Google allows for manufacturers and carriers alike to preload Android capable devices with software, some say ‘bloatware’, the attack surface of a single device is widened that much further. In addition to this, Android differs from device to device. Sprint, AT&T, HTC, Samsung and others customize the Android kernel, user-interface and capabilities to best suit their corporate needs, which do not necessarily coincide with the needs of customers (uh, tethering). We end up seeing that feature creep and poor patch response times drastically increase the window of opportunity for attackers to easily steal information, create mobile botnets and cause a ruckus.

The fragmented nature of the Android ecosystem does not naturally promote security. As a result, it would be… a good idea… to be highly selective when considering Android devices for your corporate environment or even for personal use. Try to stick with the tried and true great Android devices, *cough cough* Nexus One and Nexus S or the upcoming Nexus Prime, which just so happen to receive updates straight from the mothership. Then again you could just get an iPhone 4S. Thank you Steve, rest in peace.

 

Tags:
, ,

Leave a Reply

Additional articles

BI-Qualys-Connector-IMG1

Getting More Value from QualysGuard Vulnerability Data with BeyondInsight v5.1

If your vulnerability assessment scans can’t produce meaningful and actionable reports, performing a scan does no good for anyone. If you’ve read my other blog posts, you know I have no qualms about stating that BeyondTrust provides the best vulnerability reporting in the industry. Ask your favorite analyst and they’ll tend to agree. Of course,…

Post by Morey Haber April 18, 2014
Tags:
, , , , , , , ,
insider-threat-fed

Mitigating Inside Threats to U.S. Federal IT Environments

Recent high-profile cases have increased the perceived risks that go along with disclosure and usage of confidential information. One of the most difficult security threats to mitigate is an attack from the inside. When an over-privileged user, such as an unhappy current or former employee, contractor, or consultant, begins navigating your network, how will you…

Post by BeyondTrust Software April 17, 2014
Tags:
, , , , ,

Are you a Target? Investigating Security Breaches with Kevin Johnson

Last week, over 1,000 IT security professionals watched as Kevin Johnson, CEO of Secure Ideas, presented his expert opinion on lessons learned from recent, high-profile retail breaches. Here’s a summary of key takeaways from the webcast plus an on-demand recording of the full, 60-minute presentation. Understanding the “why” behind attacks According to Kevin, the primary…

Post by Chris Burd April 17, 2014
Tags:
, , , , ,