1

Protecting the IoT Against Targeted Attacks

Avishai Ziv

Vice President of Cyber Security Solutions

Lynx Software Technologies, Inc.,

As the Internet of Things vision of 15 Billion connected devices by 2015 gets closer to reality, major concerns emerge around quite how secure is the infrastructure that makes it all happen. High profile targeted attacks through connected devices (think Target breach through point of sale terminals) have highlighted that whilst the industry was broadly aware of the need to protect against common malware attacks there has been insufficient awareness of the need and the challenges of dealing with direct and targeted attacks on specific pieces of infrastructure – be it terminals or servers. When connected embedded devices use the same OSes as IT endpoints (e.g. ATM and POS terminals), then well tried attack techniques can be used to attack the embedded infrastructure, which is particularly alarming when connected embedded devices are being used to control strategic infrastructure, on the national grid for example, and become attractive targets both for individual hackers and for foreign governments. Welcome to the world of Advanced Persistent Threats (APTs).

The corporate IT world has been looking at this issue for some time with little success. New solutions to tackle APTs are continuously introduced, yet the detection gap remains alarmingly long. Main reason: Common security solutions fail to detect the actual APT infection. Instead they focus on failed prevention attempts (using conventional anti-malware technologies) and on monitoring the already infected targets.

How can such attacks be effectively detected and averted in the embedded world, where timely detection is paramount? Utilizing new unconventional methods of detection – namely secure embedded hypervisor – can resolve that problem.

The APT detection gap:

Security vendors respond faster than before to APTs new methods of infection and evasion, yet the average time it takes to detect APTs is still numbered in months (the industry’s accepted average being 6 to 9 months).

The main reason for the APT detection gap (i.e., the time from when the APT first infects to when it is detected) is the sophistication of infection techniques utilized by the attackers. Most of the infections occur below the infected OS, and as such cannot be detected in real-time by common detection technologies – anti-malware applications and sandboxes alike.

A closer look at the principle stages of APT attack:

The “preparatory stages” (reconnaissance, identifying the target, obtaining users contacts etc.) prepare the ground for the actual attack. However, the actual APT attack begins only when it reaches the intended target – usually an endpoint.

APT attack consists of 3 phases:

1. Penetration:

Exploiting OS and/or application vulnerability in order to allow installation of the actual APT on the endpoint. In the embedded space, this is a glaring weakness as the embedded terminals typically run outdated OS (e.g. Windows XP), which is not

2

frequently updated with security patches. These ATM and POS terminals are far mmore vulnerable than ordinary PCs.

2. Infection:

Installation of the APT itself, commonly referred to as “dropping”, whereas the APT component (mostly with a rootkit module) is titled “the payload”.

This is THE critical stage where the target is compromised: The APT gains enough control over the target machine in order for it to freely carry out its malicious activity.

3. APT activity:

The intended malicious activity on the infected & compromised machine (communicate with the C&C server, gather personal information, delete data, wipe MBR, turn the machine into a zombie etc.).

The gaping hole of APT detection:

How APT detection is currently done:

Common anti-malware products (client applications, gateways, sandboxes and cloud services) try to detect and prevent the penetration (stage #1) within the context of their host OS – Windows.

Existing anti-APT solutions focus their detection on the actual activity of the APT on the already infected machine (stage #3), by discovering and monitoring the APT’s network activity (mostly outbound-only traffic). They do not prevent the infection, nor are they capable of detecting the infection prior to its network activity.

There doesn’t exist any solution capable of detecting the actual APT infection, the most critical and vital stage of APT attacks, and alert about it at the time it actually happens.

Hence the APT detection gap.

The APT detection gap (schematic):

The challenges of detecting an APT infection

Most APTs utilize low-level and sub-OS rootkits, which are specifically designed to be undetectable by the OS or any security application installed in or on the OS (and thus gain the “P” -- persistence).

In order to be undetectable, yet gain enough control over vital functions of the infected OS, a rootkit would typically need 2 things:

1. Install itself in parts of the hard disk that are hidden from view and access of the OS (the un-partitioned sectors located between the disk partitions, and the last disk sector).

3

2. Obtain superior security privilege over the infected OS (subvert the boot sequence of the OS, launch itself before the OS by altering OS original boot sectors -- MBR, VBR, UEFI).

These 2 vital traits of rootkits are deadly effective: While the infectors used to penetrate the OS are polymorphing frequently, rootkits change much slower. New versions of these rootkits appear once every 12-18 months. Being so stealthy and undetectable they face little need to change.

Hypervisor-based honeypot: Sub-OS detection of sub-OS threats

A new approach is needed, one that must be capable of performing 2 critical tasks: Detect the actual infection of the APTs in real-time, and provide threat response personnel with live forensics data to allow significant reduction of their analysis and response time.

Detection:

Given the evasive and stealthy nature of the APT’s, the detection must be carried out at a lower level than their level of infection and activity. That level can only be a bare-metal hypervisor (such as LynxSecure), separating the hardware from the software, presenting only bare virtual hardware to the installed OS. Effectively a “virtual motherboard”, such a hypervisor will be invisible to the APTs and undetectable by them.

The hypervisor must be specifically designed to serve as the means detection (e.g., a honeypot), and rigorously hardened so that it will not become target for these attacks. Doing this also remove any OS-dependency (a glaring deficiency of some existing solutions), turning the detection OS-agnostic. The most privileged monitor in the platform, it will be able to detect any changes to the monitored hardware.

Furthermore, a properly designed embedded hypervisor, with very small inherently secure code-base, allows it to be installed on typical PC-based embedded systems, as these tend to be very humble in terms of compute power and size of memory. The small size of the hypervisor will further strengthen the security posture of the entire system and significantly reduce the attack surface.

This way, the stealthiest rootkits will be intercepted immediately: MBR wipers (e.g., Dark Seoul), MBR infectors (e.g., TLD4), VBR infectors (e.g., XPAJ), Malware using hidden file systems (e.g., ZeroAccess), etc..

How APT detection should be done (schematic):

4

Live forensics: Detailed, focused clean & infected views of monitored hardware

Currently, finding the exact details of such infections require arduous and lengthy forensic analysis: It doesn’t have the forensics data of the un-infected hardware, and is required to analyze the entire hardware for the infection. Literally – looking for needle in the haystack.

However, this hypervisor, allows the generation of immediate fine-tuned forensics reports, containing only the infected sections, with an automated analysis of clean vs. infected states (a hypervisor always maintains a “gold image”, in this case – a clean uninfected image).

In short:

To successfully contain APT attacks, an out-of-the-box approach is required. Using an embedded secure hypervisor as a proactive detection layer, literally takes the security out of that box (attacked OS..).

---