CHAPTER 6

THE FUTURE OF ROOTKITS

As with other technologies today, rootkits are developing and evolving. As new versions of target operating systems are released, rootkit developers must find a way to keep up and adapt to the changing operating system environment. They must understand the different techniques needed to take that new operating system hostage. This is an important endeavor because rootkits give attackers the upper hand in maintaining their unauthorized access.

We’ve discussed the various attacks and methods rootkits use and how rootkits modify the user environment to fool the user into believing the attacker is not present. Rootkits have evolved into a more complicated technology that is harder to mitigate, just as simple viruses have morphed into much more dangerous malware that has even greater potential to be destructive.

Developing rootkits requires a level of skill that not all attackers have. Rootkits involve circumventing or augmenting existing system functionality, which necessitates an understanding of kernel-level programming, driver development, or in-depth userland programming that is not taught in traditional programming courses. Specifically, the environment required to build rootkits is not readily available to the traditional programmer. Developers must install special software development kits (SDKs) and build environments to compile and distribute the rootkits.

However, rootkit developers also package their rootkits into modules and educate rootkit users on how to modify and adapt them for specific purposes. Furthermore, the availability of public rootkit code at different hacker forum sites lowers the technical knowledge required to integrate a rootkit into another piece of software successfully. It’s often as easy as copying and pasting code and then testing to ensure it works, making rootkits much more accessible to lower-skilled malware authors and the rootkit technology readily available to those who want to use it.

Kernel-based rootkits and the technology used to detect rootkits in Microsoft Windows environments have been based on proven techniques. Attempts to move away from kernel-level System Service Descriptor Table (SSDT) hooking and the addition of specific functionality to prevent detection by popular rootkit detection software have been the real innovations in the rootkit arena. Sadly, this has been enough to keep the attackers ahead of the game. Each increase in complexity, sophistication, technology, or innovation is reactively fought in the never-ending arms race. As rootkits become more readily available to lesser-skilled attackers, the types and purposes of rootkits are adapting as well. Innovative attackers have started to leverage rootkit concepts such as stealth and new deployment vectors to keep their exploitation of databases, entire PCs, and systems undetectable.

Increases in Complexity and Stealth

Since the arms race is a constant struggle between attacker and defender, the future of rootkits will most likely parallel that of malware; innovation will come in small steps that involve deception, stealth, and the elimination of detection from stand-alone rootkit detection tools produced by the community. Code snippets and easily available rootkits rely on technology that was introduced into the community in the early 2000s when operating system vendors such as Microsoft and Linux did not have such a strong security focus. With recent releases of Windows Server 2008, Windows 7, Windows 8, and Windows 10, and the integration of kernel patches for Linux into core distributions, rootkits have had a harder time operating at the kernel or user level and have been forced into the system’s application level. Security vendors and software developers such as Microsoft have implemented security architecture reviews, source code reviews, and other security measures to ensure that rootkit-like applications are not able to take advantage of the kernel-mode or user-mode portions of the operating system. They have stepped up the arms race, so attackers have had to move away from embedding rootkits in the OS and userland to providing rootkit-like functionality such as stealth and backdoor capabilities into applications themselves such as a CRM or database.

As rootkits have merged into the application layer, more and more blended threats or those threats that contain different types of malware, such as a worm that uses a virus to infect files or, in this case, a virus that uses a rootkit to stay hidden, are now the norm. Rootkit detection technology is a requirement for anti-malware vendors; otherwise, they are unable to detect these threats.

Rootkit installation vectors will also change with the blended threats and diverge from being separate installs into deeper integration with existing malware, especially the type of malware that is purposefully installed by the user, such as a screensaver, peer-to-peer application, or adware-supported applications. Rootkit infection will involve much smaller injection vectors, enabling drive-by download rootkit installation, which feeds modularity and reuse of rootkit functionality for low-skilled attacks.

Detecting a rootkit is only one part of the problem. Removing the rootkit so that another threat—like a Trojan, adware, or virus protected by the rootkit—can be dealt with may not be possible or, if attempted, can cause significant data loss or system instability. More and more antivirus and security vendors will need to follow a disarming process rather than the “cleaning” process that many of us know and use today. For example, you could delete the actual files used by the rootkit such as the kernel driver or .dll and then reboot. This cleaning process is the normal one performed by security vendor software; however, it requires that the company’s researchers know every file, registry key, and so on, that must be removed to ensure the threat is properly cleaned. This task is time intensive and prone to error. What if one missed file causes the rootkit to be reinstalled? The cleaning process can also create system instability that causes blue screens, application errors, or data corruption. Disarming the rootkit by preventing its core functionality from operating by disabling or preventing hooking or setting permissions on directories to prevent the rootkit’s subcomponents from executing will ensure success. This way researchers won’t have to worry about missing a file or registry key that needs to be cleaned.

Rebooting a system during a cleaning process is unavoidable. Most anti-malware companies hate the fact that a reboot is necessary, directly impacting productivity and business continuity. There is a race to figure out how to remove rootkits without actual reboots. No one has been fully successful yet, and in this, rootkits are still at an advantage.

Database Rootkits

There is always pressure from the U.S. federal government and IT governance frameworks for organizations to protect their data. The database is central to many attackers’ strategies because the data they need to perform data theft, primarily identity theft, is stored within the database. Sadly, not all organizations deploy database security technologies, and many have no active database security protocols or best practices in place, which makes database rootkits a useful way to control a database server.

Database rootkits were introduced in 2005 by Alexander Kornburst at Red Database Security GmbH. The advances in database rootkit techniques and the selling of prebuilt database rootkits have made them more available and fairly easy for attackers to employ. It is possible that the data dumps we have been seeing over the past few years can be attributed to database rootkits being used in these information-stealing attacks.

Database rootkits are possible because database servers have an architecture that is very similar to an operating system. Both databases servers and operating systems have processes, jobs, users, and executables; therefore, the rootkit techniques discussed in the previous chapters in Part II can be directly ported to database servers in order to keep control over the databases within the database server. Table 6-1 details a list of operating system commands and their equivalent database commands.

Table 6-1   Operating System Commands and Their Equivalent Database Commands

Implementing a rootkit within a database can be accomplished in a couple of different ways. The first generation of database rootkits simply modified the execution path of the internal queries and views that the database server relied on. For example, let’s walk through how Oracle executes a query to find a username within the database:

Select username from dba_users;

First, Oracle executes name resolution techniques to determine whether the dba_users object is a local object within the current schema such as a table, view, or procedure. If it is a local object, Oracle will use it. Next, Oracle will verify whether there is a private synonym called dba_users. If there is a private synonym, Oracle will use it; otherwise, Oracle will check whether dba_users is a public synonym and, if it is, use it.

This process is vital to understanding how manipulation of certain database objects affects the results returned by the Oracle name resolution routine. Figure 6-1 shows the various groups of Oracle objects from Alex Kornburst’s Defcon 14 presentation, which is available on the Black Hat website (http://www.blackhat.com) and can also be viewed at https://www.youtube.com/watch?v=7Xwe9xeknVY.

Figure 6-1   Oracle Database name resolution synonyms

As you can see from the name resolution process shown in Figure 6-1, you can change the results of the original SQL query if you can control any of the synonyms. Therefore, to adjust the results you could

•   Create a local object with the identical name

•   Create a private synonym pointing to a different object

•   Create a public synonym pointing to a different object

•   Switch to a different schema

The most effective way to execute this execution path modification attack is to remove a user from the list of users within the database. For example, if an attacker added a new user named HACKER to the database so he or she could log back at any time, the attacker could modify the dba_users object, which is a view in Oracle, to exclude the user any time an application or administrator executes a query to list the users in the database:

Now, the attacker simply adjusts the dba_users view by adding a conditional statement that filters out the new username, HACKER, in the WHERE clause in the view. For Oracle, the attacker could simply add <BF102>AND U.NAME != 'HACKER'<MF255> and save the view.

Anytime a graphical tool, or administrator, that trusts the dba_users view queries the view, the tool, or administrator, it will not see the HACKER user. This method, although simple, is not perfect because other views that also list users must be updated to exclude the HACKER user as well as the ALL_USERS view.

Within the Oracle execution path, objects can also be modified to hide processes and objects owned by the HACKER user by altering the various session objects, including V_$SESSION, V_$PROCESS, GV_$SESSION, and FLOW_SESSIONS.

PL/SQL packages can also be modified to execute code, making sure the rootkit is still installed or reinstalling the rootkit if it is not installed. Although Microsoft SQL and Oracle have techniques to ensure core packages or stored procedures, which are a set of SQL statements clustered together and executed in a group, are not altered, many database or application-specific packages created by the Oracle Database user can normally be modified. Furthermore, applications exist for some versions of Oracle to unwrap, modify, rewrap, and reinstall Oracle packages. This problem does not exist in Microsoft SQL where the views are digitally signed.

Kornburst released examples of an Oracle rootkit that can hide users, processes, and jobs from the management tools shipped with Oracle. Modification of the database executables themselves can also be used to change the functionality of the database server to employ a different set of tables, views, or stored procedures when executing specific queries. Controlling the path of execution provides the attacker with the ability to adjust or fake the results returned within a query or function.

Database Rootkit Countermeasures

A variety of tools are available that look for these types of attacks, such as Red-Database-Security’s repscan and Trustwave’s DbProtect. These tools execute a scan of all database objects, and MD5 (hash) each table, view, and so on that is identified within the scan. A view is a virtual table, which is based on a SQL query, but it does not store data like a table. The view’s data is generated dynamically each time you access the view. When the database security detection tool runs, it compares the MD5 hashes to the baseline to determine if the database has been altered. Although tools can detect these rootkits, the best countermeasure is to utilize the underlying tables, not the views, when querying the database.

Luckily, memory-based attacks are platform dependent and have only been discussed and seen on Oracle on the Windows platforms, which most enterprises do not run Oracle on. Even though the majority of the work in database rootkits has been within Oracle, Microsoft SQL Server is also susceptible to attacks, but Microsoft has added more security features starting in SQL Server 2005 to help prevent database rootkits. These changes include digitally signing views and the capability to digitally sign packages.

Hardware-Based Rootkits

Since their inception, rootkits were software based, and they have continued to fight a never-ending battle for control of the operating system. This has been a software versus software fight that, in the end, is usually won by who gets loaded first. Furthermore, rootkit cleanup software from different security vendors have forced malware writers to look into new avenues to use to store, load, and execute their rootkits. Hardware, such as your PC’s BIOS, graphics card, and expansion ROMs, like the PXE-booting capabilities of enterprise NIC cards, are places where rootkit code can be stored safely away from the prying eyes of software-based detection tools.

Hardware-based rootkits have progressed rapidly, however, because they have had many years of hardware-based virus data to learn from. In 1998, the first hardware-infecting virus, CIH, flashed the BIOS with random garbage and rendered the machine useless because all PCs require the BIOS to boot. Rootkit developers have looked at leveraging the same methodology to store rootkit code or data that can survive a reboot, reformat of the hard drive, or reinstallation of the host operating system. The benefits of infecting the BIOS include additional stealth functionality as traditionally forensic and incident response investigations do not analyze the hardware of a machine such as the BIOS or onboard memory for evidence.

Currently, no such hardware rootkit exists in the wild; most are used for experiments and formulating security solutions in controlled malware research labs. John Heasman from NGS Consulting has developed proof-of-concept code that leverages the Advanced Configuration and Power Interface (ACPI) to force the motherboard hardware to modify memory spaces that are off-limits to traditional operating system processes. For example, using this technique, an attacker can disable all security access token checking in Windows and Linux. Heasman also demonstrated how the ACPI interface could be used to execute native code such as that of a rootkit loader or installer. The ACPI approach is not perfect, as it is a hybrid rootkit that requires software and hardware to work together to implement the rootkit, but it does provide a great example of where rootkit development is heading.

In addition to ACPI as a loading mechanism, Heasman pioneered research into the use of PCI expansion ROMS such as the EEPROMs on a PCIe graphics card or the EEPROMs on network cards. Heasman contended that through the adaptation of open-source PXE software like Etherboot/gPXE, an attacker could implement modified gPXE ROM to download a malicious ROM and boot a rootkit such as the eEye BootRoot, a boot-sector rootkit that can subvert the Windows operating system.

At Black Hat in 2015, Christopher Domas disclosed a design flaw in x86 architecture that has gone unnoticed since 1997. This flaw allows attackers to plant a rootkit in the deepest level of the processor. You can read Domas’ research paper at https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation-wp.pdf.

Hardware-Based Rootkit Countermeasures

The greatest hurdle for BIOS- and PCI-based rootkits is the large number of BIOS variants and PCI ROM variants they need to integrate with. One rootkit developed for one NIC or BIOS will not work on another version of the BIOS. Furthermore, chipmakers such as Intel and AMD are not taking this sitting down. There are initiatives such as the Trusted Platform Module (TPM) to fight these types of attacks. TPM is a microcontroller that exists on the motherboard that provides cryptographic and key management functions for the host. The TPM also contains platform-specific measurement hashes that could be leveraged to ensure that only digitally signed ROMs from the original manufacturer are executed. Lastly, the TPM offers a secure startup capability that can ensure an unmodified boot occurs.

Many comments and articles have been written about the advanced research into rootkits that make use of the Graphical Processing Unit (GPU). Graphic cards from companies such as Nvidia offer amazing processing power and actual code execution capabilities without using the host’s CPU or memory. Being able to execute a rootkit or hide data away from the host’s RAM and CPU would be a great stealth capability. Because the CPU rootkit will not access host memory or CPU, current hardware and software detection mechanisms will not work. Research is evolving to include other processing units such as Physics Processing Units (PPU) and Artificial Intelligence Processing Units (AIPU) as the gaming industry’s continued demand for custom-processing capabilities expands the footprint of these processing units to the average PC.

In 2015, a couple of malware were released publicly that use a GPU: Jellyfish rootkit and Demon keylogger. The authors, known as Team Jellyfish, state that these are proof-of-concept malware and should be used for educational purposes only. The authors describe Jellyfish as “a Linux-based userland GPU rootkit proof-of-concept project utilizing the LD_PRELOAD technique from Jynx (CPU), as well as the OpenCL API developed by Khronos group (GPU). Code currently supports AMD and NVIDIA graphics cards. However, the AMDAPPSDK does support Intel as well.” More information about this rootkit can be found at https://github.com/x0r1/jellyfish.

Demon keylogger is another proof-of-concept creation by Team Jellyfish. According to the authors, the Demon keylogger utilizes code injection to achieve its goal. More information about it can be found at https://github.com/x0r1/Demon.

Custom Rootkits

Customization is still one of the latest realized benefits of technology. You can buy almost anything and convert it to match your personality and requirements. From electronics such as mobile phones and personal music players to athletic apparel like shoes, customization is leading the new technology revolution. Rootkits won’t miss out on this trend. Like malware construction kits, rootkits, specifically user-mode rootkits, will be built using automated tools. We have already seen malware construction kits that include the capability to deploy a rootkit along with malware. In the future, that rootkit will be customized to provide specific types of stealth, execution path changes, and reinfection options in real time. The rootkit will evolve from a simple camouflage jacket around malware to being an offensive tool that the attacker will leverage to keep his or her infection or exploitation of a server active.

Rootkits that are sold in the cyber underground have also come up with service-level agreements (SLAs) in which the rootkit is guaranteed to be undetected. If detected, the buyer shall get a new rootkit for free or their money back.

Imagine being an administrator trying to remove a piece of malware only to find that after you remove the malware and reboot the machine, the hardware rootkit causes a reinstall of the software rootkit within the operating system in a new and different form that perhaps your antivirus or anti-spyware product cannot detect. Rootkits will start to become an infection manager for the machine, ensuring the malware is undetectable or reinstalled if functionality is compromised.

Antivirus and anti-malware tools will need a significant upgrade to handle these types of attacks. As we have already discussed, antivirus and anti-malware software operate at the same level as most kernel-mode rootkits; therefore, these tools have difficulty adequately removing or detecting the rootkit. In addition, the functionality implemented in malware to detect, stop, or circumvent security technologies will move into the rootkit as it traditionally runs at a higher privilege level than the malware and will have more control and access to the machine.

Digitally Signed Rootkits

Today, 64-bit systems are the norm. When the first 64-bit systems came out, rootkit authors were challenged to subvert these systems. Nowadays, a 64-bit system is a mere speed bump, which reminds me of a shirt I got at BlackHat a few years ago. It said, “Your firewall is just a speed bump.”

The most common way rootkits are able to subvert these systems is to use stolen digital-signing certificates from legitimate companies. These certificates are then used to sign their rootkits. According to McAfee, there are at least 21 unique 64-bit rootkits that have used stolen digital-signing certificates since 2012. One of the malware that used this technique is W64/Winnti. Additional information can be found at http://www.mcafee.com/cf/security-awareness/articles/rise-of-rootkits.aspx.

Expect more of this to come. The stealing of digital-signing certificates is one thing that the security vendors don’t have control of. It falls to the owners of these certificates to protect them. They must be able to secure these assets, or attackers can easily steal them and use them in their campaigns. How can you stop a digitally signed driver from installing in the kernel? By that time, it is too late. The malware has already taken hold of the system.

Summary

Like the evolution of viruses into aggressive identity-stealing malware, rootkits continue to evolve; they are harder to detect, customizable, and automated. Rootkits are adapting to new environments such as databases and applications and moving away from the operating system software and into the PC hardware in order to remain installed and functional. Currently, proof-of-concept malware has been released publicly that shows these things are possible.

The customization of rootkits will drive new detection requirements similar to the antivirus and anti-malware technologies of today. The recent public release of hardware rootkits has given researchers notice: there is a new playground, and new technologies for detection must be created. Personally, we feel that the best rootkit detection technology will be a hybrid that uses hardware and software.

Aside from the different techniques rootkits have employed to subvert an operating system, some rootkits that attackers deploy are now digitally signed using stolen digital-signing certificates, which makes it more challenging for researchers to deal with the threat.

The rootkit war has gotten dirty, and the end user is now caught in the cross fire as advanced rootkit technology is leveraged by malware. Malware infections will last longer and cause more damage as they will be protected by rootkits and reinstalled when removed. Rookits have moved into new areas that can cause much more destruction than ever before. Supervisory Control and Data Acquisition (SCADA) networks, car computers, cell phones, and the Internet of Things (IoT), which encompasses the connected home and connected manufacturing processes, among others, are the next areas to be hit with rootkits. Imagine the effect of a rootkit installed on a car computer that prevents the use of antilock brakes or causes your GPS software to no longer find certain addresses.