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
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Mozilla, Internet Society and Others Pressure Retailers to Demand Secure IoT Products
Curtis Franklin Jr., Senior Editor at Dark Reading,  2/14/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8948
PUBLISHED: 2019-02-20
PaperCut MF before 18.3.6 and PaperCut NG before 18.3.6 allow script injection via the user interface, aka PC-15163.
CVE-2019-8950
PUBLISHED: 2019-02-20
The backdoor account dnsekakf2$$ in /bin/login on DASAN H665 devices with firmware 1.46p1-0028 allows an attacker to login to the admin account via TELNET.
CVE-2019-8942
PUBLISHED: 2019-02-20
WordPress before 4.9.9 and 5.x before 5.0.1 allows remote code execution because an _wp_attached_file Post Meta entry can be changed to an arbitrary string, such as one ending with a .jpg?file.php substring. An attacker with author privileges can execute arbitrary code by uploading a crafted image c...
CVE-2019-8943
PUBLISHED: 2019-02-20
WordPress through 5.0.3 allows Path Traversal in wp_crop_image(). An attacker (who has privileges to crop an image) can write the output image to an arbitrary directory via a filename containing two image extensions and ../ sequences, such as a filename ending with the .jpg?/../../file.jpg substring...
CVE-2019-8944
PUBLISHED: 2019-02-20
An Information Exposure issue in the Terraform deployment step in Octopus Deploy before 2019.1.8 (and before 2018.10.4 LTS) allows remote authenticated users to view sensitive Terraform output variables via log files.