updated 7/9/2013 6:19:10 PM ET 2013-07-09T22:19:10

Have you ever watched a local television news broadcast in which every commercial break is preceded by a teaser promising a big story if you'll just stay tuned?

"Could a popular device you have at home threaten your family?" the anchorman or anchorwoman will ask with a concerned look. "The answer — after these messages."

San Francisco-based startup Bluebox Security tried to do something similar, putting out news last week of a critical vulnerability affecting "99 percent" of Android smartphones and tablets, without telling Android users exactly what the vulnerability was.

For the full story, the world was supposed to wait until Aug. 1, when Bluebox planned to unveil the details in a presentation at the Black Hat security conference in Las Vegas.

Unfortunately for Bluebox's publicity efforts, it took smart hackers only five days to figure out exactly what was going on.

Yesterday (July 8), English Android developer Al Sutton detailed the vulnerability on his Google+ page, explaining that Android can be tricked by the presence of a second, identically named installation file in an Android app package.

Two other researchers followed up by posting online small scripts that would exploit the vulnerability. (Bluebox today (July 9) posted a free Android app that scans devices for the flaw.)

The past few days' events are an illuminating look at how new information-security companies are pressed to make names for themselves with big discoveries — and the equally strong drive among open-source software developers to patch vulnerabilities as quickly as possible.

[ The 5 Best Android Security Apps ]

All your keys are belong to us

On Wednesday (July 3), Bluebox chief technology officer Jeff Forristal penned a blog post announcing the discovery of an "Android master key that makes 99 percent of devices vulnerable."

At the same time, Bluebox's PR firm emailed a message to tech journalists about the blog posting.

"A device affected by this exploit could do anything in the realm of computer malice, including become a part of a botnet, eavesdrop with the microphone, export your data to a third party, encrypt your data and hold it hostage, use your device as a stepping stone to another network, attack your connected PC, send premium SMS messages, perform a DDoS attack against a target or wipe your device!" the message read. "And it could potentially affect over 900 million Android devices currently on the market."

Stories about the Android "master key" soon appeared on the BBC News and Business Insider websites, as well as on numerous tech websites.

Yet most of the scary details were not news. Many Android Trojans already do exactly what the PR firm's email message described.

Forristal's blog posting also said that the exploit could let malicious hackers clone a legitimate Android app, add malware and pass off the corrupted version as the real thing, but that's quite easy to do.

Scrambled apps with a side of hash

What was novel was Forristal's contention that this mysterious process could let a hacker create a corrupted app with the same cryptographic signature, or "hash," as the real thing.

The "vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application — essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been," Forristal's blog post said.

That's supposed to be nearly impossible. Android apps are verified as genuine before installation by running their "binaries" — the raw 1's and 0's that machines use — through complicated mathematical algorithms that crunch all the digits and spit out long numerical strings, or hashes, unique to each piece of code.

Change just a single 1 to a 0, and you'll get a different hash output. If the hash of the software about to be installed doesn't match the hash the software developer provides with the software, the device won't install the app.

Bluebox's blog posting said their flaw bypassed this security check, and even allowed corruption of installed legitimate apps through malicious updates.

"We can make a malicious Facebook update by inserting Trojan code into a real one without breaking Facebook's signature," Forristal told the Threatpost blog.

In a telephone conversation with TechNewsDaily yesterday, Forristal was friendly but guarded, and vague about whether an app developer's cryptographic signature could also be compromised.

"Developer signatures and APK [Android application installers] hashes are tied in together," he explained.

But, he added, Bluebox's discovery threw into question the whole Android security infrastructure.

"Google presents the sandbox model as solid and unbreakable, but this vulnerability violates the entire sandbox model," he told us.

Forristal's blog posting said that the flaw had been around since Android 1.6 Donut in 2009, and is still present in most Android devices. (One exception, Forristal told IDG News Service, is the Samsung Galaxy S4 smartphone.)

To add to the danger, Forristal noted in his blog posting, a corrupted version of an app released by an Android device maker could gain elevated access to other processes on the device, letting it "take over the normal functioning of the phone and control any function thereof."

"Samsung, LG, Motorola — all the manufacturers' signatures could be affected," he told TechNewsDaily.

[ 10 Tips to Keep Your Android Phone Safe ]

If I did it, here's how it might have happened

A commenter on the tech discussion forum Slashdot made the first good guess at what Bluebox's vulnerability might be.

"An APK [Android app installation file] is a zip file composed of two main parts," explained Israeli Linux developer Shachar Shemesh in a comment posted Thursday (July 4), adding that the actual app installation code is "a file called classes.dex."

"All of those files are listed in a directory inside the APK with their hash, and that file is digitally signed," Shemesh said. "This is the Android signing process."

But, Shemesh explained, an Android device can't directly install a .dex file. Instead, the classes.dex file has to be "optimized" and turned into an ".odex" file — which, unlike the .dex file, isn't verified.

"The odex is not hashed and is not signed," Shemesh said. "If you change it, Android will load your modified code without complaining."

Shemesh made clear that he was only guessing at what Bluebox had discovered, and that his own exploit would require root access to a device.

Told of Shemesh's guess, Forristal wouldn't say how close it was, but stated that Bluebox's vulnerability didn't need root access or any other kind of pre-existing compromise. (As it turned out, Shemesh's guess wasn't far off.)

"Our vulnerability affects pure, vanilla Android," he told TechNewsDaily.

Asked what the attack vector was — a corrupted firmware update, a single corrupted app, a malicious text message or any of a dozen possible scenarios — Forristal wouldn't say.

"We'll be revealing that in August," he said.

No need to panic, if you've got this year's model

As Forristal noted in his blog posting, Bluebox had already done the responsible thing and notified Google of the flaw in February.

Google, according to what Forristal told IDG, subsequently tweaked the Google Play Store app store — a major update was pushed out in April — to eliminate the issue from that end.

Forristal told us that restricting installations to only apps from the Google Play Store would prevent exploitation.

(To do so, users need to go into Android's Settings menu, then into Security, and make sure "Unknown sources" is not checked. Users of Android 4.2 Jelly Bean should also check "Verify apps" as an additional precaution.)

However, Google's tweaks won't protect devices against "side-loaded" apps from markets other than the Google Play store.

To truly be immune, Forristal told Threatpost, each Android device will require a firmware update — "two lines of code in a very specific location," as he put it.

That's where the real problem lies. Android device manufacturers make all sorts of changes to Android before putting it on their devices, and tend to be negligent in keeping their devices updated to the latest, most secure version of the operating system, which only about 5 percent of devices currently run.

Just last week, for example, HTC announced that its One S smartphone, released in April 2012, would get no more software updates and will never receive Android 4.2 Jelly Bean, released in November 2012.

That means a major manufacturer is abandoning a 15-month-old phone, leaving its users, many of whom have close to a year left on their cellular contracts, exposed to future Android security exploits. (Imagine if PC makers stopped updating Windows on laptops and desktops after less than two years.)

"It's up to device manufacturers to produce and release firmware updates for mobile devices," Forristal said in his blog posting. "The availability of these updates will widely vary depending upon the manufacturer and model in question."

"Of course," he told us, "some devices will get it now, some will get it later, and, frankly, some may never get it."

[ 5 Smartphone Security Features We'd Like to See ]

Roll your own, and solve the puzzle

To avoid such problems, many skilled Android users replace the operating systems on their devices with a hacker-made and -maintained version of Android that draws from the Google-led Android Open Source Project (AOSP).

To protect those users from Bluebox's vulnerability, Google recently added a fix to AOSP, which over this past weekend turned up in the widely used Android variant CyanogenMod.

Sutton had a look at the CyanogenMod patch yesterday and deduced the vulnerability.

"From what I can see, the issue Bluebox are reporting is a bit misnamed," Sutton wrote on his Google+ page. "It's not so much of a 'master key,' more a, 'If you have two things with the same name, only one ever gets signature checked, and the one which gets checked gets overwritten by the one that doesn't.'"

"If you have two entries in a zip file with the same name, only one of the entries will be returned when you do a look-up for that name," Sutton explained in a subsequent posting. "So what you could do is construct a zip file where the entry which is verifiable is the one returned by [the verification process], and the one with the evil code is the one which ends up on the device."

In other words, not one, but two installation files are placed in an Android app package — one legitimate, which is verified, and other other malicious, which is not verified.

But because the Android installation process can't distinguish between two files of the same name, the second file encountered will overwrite the first one and will end up being installed.

Later yesterday, Barcelona researcher Pau Oliva Fora, who works for Chicago-based Via Forensics, posted a " quick and dirty proof of concept " exploit of the vulnerability on the code-sharing site Github.

Ohio mobile-security specialist Ryan Welton today (July 9) improved on Oliva Fora's proof of concept, and made his code spit out file listings that clearly showed two different files named "classes.dex," with different sizes and different hashes, co-existing inside a single Android app package.

Regretfully, you got it

In comments to Sutton's Google+ postings, Forristal didn't challenge the assertion that Sutton had found the vulnerability. Instead, he eloquently defended his own company's notification process, one that other commenters praised.

"Whether you agree with it or not, consider how this issue is playing out," Forristal wrote. "The media (hype or otherwise) got people's attention, worldwide. It informed them there is something there."

In reply, Sutton argued that he himself had a responsibility to the greater Android community to disclose the vulnerability.

"I'm sure this may have taken some anticipation from [Forristal's Black Hat] presentation, but to me it's more important to move to protect the hundreds of thousands of users who are using builds from people who aren't in Google's inner security circle, than it is to keep the anticipation alive," he wrote.

For his part, Oliva Fora left things on a positive note.

"I find it sad that the details have been disclosed before the BH talk," Oliva Fora tweeted today, "but I'm sure Jeff will be able to impress the audience anyway!"

Follow Paul Wagenseil @snd_wagenseil. Follow us @TechNewsDaily Facebook  or Google+.

© 2012 TechNewsDaily


Discussion comments


Most active discussions

  1. votes comments
  2. votes comments
  3. votes comments
  4. votes comments