Mobile Rootkit Protection Is a Leprechaun

Mobile security is in it’s infancy. There are a number of players out there, and as is such with any new technology type, there’s no “one size fits all.” Some of these technologies cover mobile access control, some cover “rogue apps”, others cover the characteristics of the operating system itself, and whether or not it has been “jailbroken.” I recently sat through a vendor demo where they claimed that they could “detect jailbroken iphones and prevent them from operating via policy.”

Hi, I'm Mobile Rootkit Protection!

 

Let’s talk about “jailbreak detection and protection” for a minute. Maybe I’m missing something. When you jailbreak your iphone, you’re effectively running an exploit for a known security vulnerability in the phone, and subsequently installing a rootkit on it. In most cases, the iphone’s running kernel is replaced with one that can support unsigned apps.

So, if hacked iphones are modifications to the kernel, and anyone can write their own jailbreak code once a vulnerability is found, then how is this magical “mobile security technology” supposed to work?

In fact, there was a presentation by Eric Monti in 2010 where he demonstrated a stealth rootkit that could hijack existing processes and turn basic feature utilization on and off.

Ok so, to recap:

·      Jailbreaking isn’t magic.

·      The kernel is an unknown quantity.

·      Existing processes can be hijacked or replaced.

·      Certain features of running processes can be altered.

I fail to see how anyone can be expected to run an application or a kernel level process that claims to be able to control security in an environment with this degree of hostility.

I know I haven’t discussed which vendors we’re talking about here, but that’s almost a moot point when features like “lockdown security (camera, SD, Bluetooth, Wi-Fi)” are more science fiction than computer science.

Reflecting on ICS/SCADA Software and Hardware Security Vulnerabilities

On a fairly regular basis someone will send me a link about a newly disclosed vulnerability in ICS/SCADA control system software or hardware and ask me what I think about it.  Recent examples include backdoor remote access embedded into hardware with trivial authentication and weak cryptography, systems that are left unpatched due to lack of vendor support, control system software and hardware with a myriad of security holes and vulnerabilities, etc.  The list is long, and seems to be increasing at an alarming rate.  My guess is because there are an increasing number of security researchers who are actively trying to get the message out about the insecurity of these systems.  Many of these, like trivial authentication and lack of patch management, are dirty little secrets that are not surprising to those that work in the industry.  What is different is the press and attention they are receiving of late.

I won't comment on the motives of these researchers, but some of them definitely have a vested interest in the attention it draws to the security problems in ICS/SCADA, in the hopes that it will generate buzz and attention to their company and to the security problems in general with the ICS/SCADA equipment.  Nevertheless, these vulnerabilities and problems do exist, are pervasive, and neither the industry nor the vendors seem to be acting very quickly to correct the situation.  Trying to correct these security issues after the fact just doesn't work very well.  As security professionals, we understand that security must be integrated into the entire development life-cycle of hardware and software.  

So who is responsible for the security of these systems and what can we do?  ICS/SCADA manufacturers and integrators need to step up their game and create solutions that meet security best practice standards, at the very least. If they want to continue providing products and services in the Electrical Energy Sector (or many other SCADA environments), they also need to be able to demonstrate that their products are not only secure but are compliant with, and facilitate compliance with, NERC CIP and other regulatory standards.

End user entities of ICS/SCADA hardware and software need to "Trust, but verify", to coin a phrase.  These entities should be asking questions.  Lots of questions.  Create and ask for validation and verification testing that the equipment, designs, and other solutions are going to meet your operational, security, and compliance requirements.  Do this early in the process of selection and procurement.  Engage with your vendors and let them know your concerns and find out what their path forward is for creating and supporting security throughout the life-cycle of their products.

If you aren't comfortable with putting your vendors to task, enlist the services of a company like Critical Assets.  We can help you develop design selection and testing criteria that meets your specific needs as well as facilitate testing in your facility or ours.  Ensuring that your ICS/SCADA hardware and software is secure, compliant, and operational can be a difficult task, but it can be done and there is help available.