How Hackers Found a Security Startup's Secret Android Flaw

Below:

Next story in Tech and gadgets

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.

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.

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.

"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.

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."

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!"