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.

Risk

10/9/2015
11:00 AM
Adam Ely
Adam Ely
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Jailbreaking Mobile Devices: That’s Not The Real Problem

Despite what mobile operating system vendors say, it's the OS flaws that put everyone at risk.

To say jailbroken devices aren’t a real problem is a strong statement but a true one. There are good reasons to use devices that allow us to remove pre-installed applications, modify the operating system, and install our own tools and patches to improve the security of the operating environment. It’s what we do today on our servers and PCs, and if done properly, there’s no reason it shouldn’t also happen on mobile.

Yet mobile OS vendors continue to tell us jailbroken devices are riskier than their unmodified counterparts when, in fact, jailbreaking is not the risk—it’s the lack of inherent operating system security, a la Windows 98. Mobile OS vendors have done little to protect the internals once the thin layer of security is broken. It’s why mobile operating system vendors try to prevent users from jailbreaking their phones and removing that meager single layer of protection. Not even when we give users administrative rights on their corporate PCs are we completely vulnerable to outside attacks, yet with mobile operating systems, we are by design.

Why are we willing to tolerate the ineffective single line of defense security model on mobile devices? We don’t accept this for any other device in our organization; it’s time we hold mobile to the same standards.

When jailbreaking is the only solution
A seldom-mentioned truth is that it’s not just the end users who are jailbreaking devices. Sometimes it’s done under the control of corporate IT, which has to resort to jailbreaking devices to make them sustainable within the organization after they lose manufacturer and carrier support. For example, if a company has rolled out a fleet of 50,000 devices to their mobile workforce, what happens if the mobile device vendor or carrier stops supporting the hardware or operating system version? Is it reasonable to expect the enterprise to bear the expense of a mandatory software upgrade, or to replace the device?

It’s a significant problem for enterprises. Mobile-powered workforces need to frequently choose between running outdated, vulnerable devices with little management capability or customizing them in order to continue supporting their fleet and get a return on their initial investment. This is due to the economics of mobile in the enterprise being primarily driven by the vendor and carrier, using consumer models that result in great profits for them and bad ROI for us. This problem is not as notable with PC deployments, even though PC operating systems also lose support over time, because it happens much less frequently and allows for a better ROI.

Jailbroken or not, it’s the OS that’s the problem
It’s true that jailbroken devices have the potential to leave organizations with more open, possibly less secure devices. But restricting use to non-jailbroken devices isn’t the answer to security either. These seemingly secure devices have their own set of problems. If they were secure, why would iOS have needed over 100 security fixes from iOS 8 to 9? And how would malware be able to infect a device via AirDrop? The operating system isn’t magic -- it has its own inherent security issues.

My team at Bluebox Security loves to break things—it’s why we all got into security. We routinely break mobile app security measures just to show that it’s possible. From banking apps that leave hidden admin menus allowing us to query the corporate infrastructure in inappropriate ways, to breaking the in-app logic of apps to turn off surge pricing or bypass subscription charges, we’re able to steal service, data, and access within apps on off-the-shelf, fully-patched, non-jailbroken devices. But many app developers have bought into the idea that these non-jailbroken devices are secure as they are. As a result, security measures aren’t put in place to properly test mobile apps during the development cycle—leaving users at risk when using apps of every kind, from travel to banking.

Forget about trust
Despite these known issues, as consumers and enterprise technology providers alike, we have bought into relying on the security of mobile operating systems. We cling to the belief that a thin layer of defense will protect us and our data. But the truth is that the operating system’s security doesn’t extend to the apps where all of the valuable data lies.

To address this risk, we must approach mobile security from the point of zero trust for the device and app environment and instead apply safeguards around the things that matter: apps, data, identity and access. Under this model, it’s not game-over because a device is rooted. That’s an outdated conclusion that, if valid, means we should all give up now and turn our data over to the bad guys because they’ve already won. Risk modeling our mobile ecosystem as developers, administrators, and defenders is important and often not done because of false assumptions. I encourage you to instead assume the operating system security is not trustable and build protections with this zero trust model assumption. We owe it to the end user to provide security that is worthy of their trust.

Adam Ely is the founder and COO of Bluebox. Prior to this role, Adam was the CISO of the Heroku business unit at Salesforce where he was responsible for application security, security operations, compliance, and external security relations. Prior to Salesforce, Adam led ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cgates666
100%
0%
cgates666,
User Rank: Apprentice
10/12/2015 | 12:22:18 PM
Agree with you right up to the last paragraph
Excellent article, except I take exception with your last paragraph.  Making the assertion that the solution lies at the App layer is living in a "fool's paradise".  

"Yes" the App has to have mitigations for its vulnerabilities as they exist at the App level, but that is a far cry from actually securing the operating environment. And without securing the OS operation the App can be made to believe that anything is occurring (or not occurring) as desired to exploit a weakness in the system.

Security is a chain that has to have 'strong links' at every level.

There has been a marketing trend of late, claiming that "their product" can magically secure the operating environment by running it on your App.  Managers love this type of easy solution; it is just a shame that they are largely ineffective, at best just securing some limited aspects of App operation.  At worst they are a lot of 'security theater' and hand waving.

In my opinion, the best approach is a multi-layered solution with a hardware root of trust.  The use of TrustZone is a good first step towards this, and with all the security company acquisitions that ARM is making lately apparently they must be headed in that direction as well.

Now all we have to do is to convince the OS manufacturers that security is important enough to us that they will then start to use some of these hardware security tools that are available to them.

Instead they are releasing "new features" like 'upper / lower case keyboards' and 'long press', as if these are some new revolutionary concepts.  We need them to focus on the real issues, not the fluff.

Maybe voting with our wallets will get their attention.
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
The Cold Truth about Cyber Insurance
Chris Kennedy, CISO & VP Customer Success, AttackIQ,  11/7/2019
Black Hat Q&A: Hacking a '90s Sports Car
Black Hat Staff, ,  11/7/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industry’s conventional wisdom. Here’s a look at what they’re thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5230
PUBLISHED: 2019-11-13
P20 Pro, P20, Mate RS smartphones with versions earlier than Charlotte-AL00A 9.1.0.321(C00E320R1P1T8), versions earlier than Emily-AL00A 9.1.0.321(C00E320R1P1T8), versions earlier than NEO-AL00D NEO-AL00 9.1.0.321(C786E320R1P1T8) have an improper validation vulnerability. The system does not perform...
CVE-2019-5231
PUBLISHED: 2019-11-13
P30 smartphones with versions earlier than ELLE-AL00B 9.1.0.186(C00E180R2P1) have an improper authorization vulnerability. The software incorrectly performs an authorization check when a user attempts to perform certain action. Successful exploit could allow the attacker to update a crafted package.
CVE-2019-5233
PUBLISHED: 2019-11-13
Huawei smartphones with versions earlier than Taurus-AL00B 10.0.0.41(SP2C00E41R3P2) have an improper authentication vulnerability. Successful exploitation may cause the attacker to access specific components.
CVE-2019-5246
PUBLISHED: 2019-11-13
Smartphones with software of ELLE-AL00B 9.1.0.109(C00E106R1P21), 9.1.0.113(C00E110R1P21), 9.1.0.125(C00E120R1P21), 9.1.0.135(C00E130R1P21), 9.1.0.153(C00E150R1P21), 9.1.0.155(C00E150R1P21), 9.1.0.162(C00E160R2P1) have an insufficient verification vulnerability. The system does not verify certain par...
CVE-2010-4177
PUBLISHED: 2019-11-12
mysql-gui-tools (mysql-query-browser and mysql-admin) before 5.0r14+openSUSE-2.3 exposes the password of a user connected to the MySQL server in clear text form via the list of running processes.