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.


11:00 AM
Adam Ely
Adam Ely
Connect Directly
E-Mail vvv

Jailbreaking Mobile Devices: Thats 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

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
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.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/30/2020
'Act of War' Clause Could Nix Cyber Insurance Payouts
Robert Lemos, Contributing Writer,  10/29/2020
6 Ways Passwords Fail Basic Security Tests
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/28/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
How to Measure and Reduce Cybersecurity Risk in Your Organization
In this Tech Digest, we examine the difficult practice of measuring cyber-risk that has long been an elusive target for enterprises. Download it today!
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-30
NVIDIA CUDA Toolkit, all versions prior to 11.1.1, contains a vulnerability in the NVJPEG library in which an out-of-bounds read or write operation may lead to code execution, denial of service, or information disclosure.
PUBLISHED: 2020-10-30
baserCMS before version 4.4.1 is vulnerable to Cross-Site Scripting. The issue affects the following components: Edit feed settings, Edit widget area, Sub site new registration, New category registration. Arbitrary JavaScript may be executed by entering specific characters in the account that can ac...
PUBLISHED: 2020-10-30
baserCMS before version 4.4.1 is vulnerable to Cross-Site Scripting. Arbitrary JavaScript may be executed by entering a crafted nickname in blog comments. The issue affects the blog comment component. It is fixed in version 4.4.1.
PUBLISHED: 2020-10-30
baserCMS before version 4.4.1 is affected by Remote Code Execution (RCE). Code may be executed by logging in as a system administrator and uploading an executable script file such as a PHP file. The Edit template component is vulnerable. The issue is fixed in version 4.4.1.
PUBLISHED: 2020-10-30
vBulletin 5.5.4 through 5.6.2 allows remote command execution via crafted subWidgets data in an ajax/render/widget_tabbedcontainer_tab_panel request. NOTE: this issue exists because of an incomplete fix for CVE-2019-16759. ALSO NOTE: CVE-2020-7373 is a duplicate of CVE-2020-17496. CVE-2020-17496 is ...