Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics

9/14/2007
01:15 AM
50%
50%

Mobile Insecurity

It's just a matter of time before mobile devices fall victim to new - and major - exploits

Security professionals have been talking about mobile device security – or rather, the lack thereof – for years now. Back in June 2005, I wrote an article entitled, "Are Cell Phones the Next Target?" I guess the real answer turned out to be "yes, but not yet."

But even though nothing urgent or awful has happened in the wireless world, things seem to be changing for the worse. Current trends in mobile devices are raising the probability of attack. Devices have much more functionality than they used to – they have become small computers. They are more connected than ever, supporting more communications protocols and even offering full-blown Web access. And there are tens of millions of them on every continent on earth – even most criminals have cellphones.

Mikko Hypponen, chief research officer at F-Secure, gave a great invited talk to all of the scientists attending Usenix Security in Boston this year, in which he described the current state of mobile security.

Among the most striking facts in Hypponen's presentation: The Cabir virus that debuted in 2005 has now infected phones in over 30 countries, and is one of 370 known mobile viruses, most of which target the Symbian platform. While we're busy eavesdropping on ourselves over here in the United States, mobile code threats seem to be moving on without us in Europe.

Lessons From the iPhone Exploit
Johns Hopkins professor Avi Rubin and his team at Independent Security Evaluators announced an exploit for Apple’s popular iPhone in July. Their exploit could be packaged for delivery over a WiFi link or from a malicious Web page.

The main lesson from the iPhone hack is that it only takes one security hole to compromise an entire cellphone. Simple cellphones don't have kernels that separate root level privileges and critical system functionality from other kinds of userland code. This is a similarly awful security stance to the one built into Windows 95, Windows 98, and WindowsME more than a decade ago.

Fortunately, Windows has come a very long way from a security standpoint. Vista may still have massive security challenges, but at least it has a kernel and a real security design. Cellphone operating systems, by and large, do not.

In the real world, most cellphone payloads propagate through direct user download (think of a Trojan killer app on some random Website). The second-most popular propagation mechanism is Bluetooth, and the third is SMS. Propagation really matters when it comes to malicious code, because getting to the victim is more than half the battle. But propagation is not everything.

User interface problems have also helped the spread of the Cabir virus. Since Cabir is fairly tame (if not lame), it actually asks permission from a user before it runs on a victim's phone. It propagates through Bluetooth, and once it arrives, the user of the phone is queried about whether to receive/run the (infected) message from the already-infected nearby phone.

The problem is that even a security-savvy user can be stumped by Cabir. If you answer "no" to the download, then the first copy of the virus promptly dies as it should. But the virus propagation tool runs again on the nearby infected phone, attaches again, and the poor victim gets yet another query.

Unless the user is clever enough (or paranoid enough) to move out of range physically of the infected phone by, say, walking out of a bar, this constant security query nonsense will keep on happening, rendering the victim's as-yet-uninfected phone virtually useless. On most phones, you can't make a call when a Bluetooth query is waiting for an answer. After saying "no" several times in the attack loop we just described, users in the real world tend to get frustrated and finally hit "yes." Hence Cabir's continued spread.

The makers of Symbian know about this user interface issue, and new versions of their operating system are set up to avoid the attack-loop problem. Eventually, though, a much better security design is needed to stem the coming tide of malicious code for mobiles. We all know how well users do with security decisions!

Count Your Chickens
So far, nothing terrible has happened as a result of cellphone malware. That's because, for some reason, nobody has yet hooked up a real exploit – like the ISE iPhone hack – with a malicious payload that destroys and a hugely popular propagation vector like SMS. The worst case scenario remains the same as it did in 2005: an SMS-spread exploit that turns victim phones into unusable bricks just after it sends itself to everyone in the phone book.

Because of the security work I do here at Cigital, I know this kind of attack is possible today. This is not theory or hand-wringing. I have watched phones turn into bricks, never to work again after they ran certain payloads. In the end, we're just dang lucky that nothing huge has happened yet.

What's worse, there is no central authority to contact if a security problem does crop up on the mobile phone network. We're currently in exactly the same state of security in the cellphone world as the Internet was just before the debut of the Morris worm.

Oh well, I guess we shouldn't worry. If your cellphone is hacked into a brick by malicious mobile system code, how would you call CERT anyway?

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
How Security Vendors Can Address the Cybersecurity Talent Shortage
Rob Rashotte, VP of Global Training and Technical Field Enablement at Fortinet,  5/24/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-7068
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7069
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7070
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-7071
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.
CVE-2019-7072
PUBLISHED: 2019-05-24
Adobe Acrobat and Reader versions 2019.010.20069 and earlier, 2019.010.20069 and earlier, 2017.011.30113 and earlier version, and 2015.006.30464 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .