Rootkits: security issues and development trends
Nowadays, the vector of computer attacks is clearly shifting from mass infection to targeted, targeted attacks. As E. Kaspersky said: “The nineties were a decade of cyberbulgans, the two thousandth were a decade of cybercriminals, now the era of cyberwar and cyber terror has begun.” This is illustrated by well-known examples: Stuxnet, Duqu, Flamer, Gauss, which many antivirus companies identify as cyber-weapons.
One vivid example of the use of cyber weapons is the Red October spy network, which has been actively extracting information from government organizations, various research institutes, and large international companies for five years. The serious security of these objects did not stop the operation of the malicious system. It was discovered just a few months ago, indicating a growing threat of interference with the operation of any computer system.
')
To ensure a stable and undetectable presence in the computer system, malicious software (malware) uses special mechanisms called rootkit mechanisms. As a result, the malware runs invisibly for both the user and the means of protection.
It would seem that OS developers should with all their might resist the concealment of illegitimate software, but the emergence of a new version of Windows did not change the situation for the better. The G8 adopted from its predecessors some of the already familiar protection mechanisms (UAC, ASLR, DEP, PatchGuard, digital signatures for drivers), for which there is a possibility of circumvention. And introduced several new ones - Secure Boot, SMEP and ELAM, which, however, did not greatly increase the level of security. As evidenced by the Stoned Lite bootkit demo figure Peter Kleissner and UEFI bootkit Andrea Alliev. And A. Shishkin from Positive Technologies has already written about the possibility of circumventing SMEP technology on Windows 8.
Based on the above, it can be concluded that in the latest version of Windows, nothing revolutionary was introduced to combat malware, and there are no worthy mechanisms capable of making life difficult for rootkit developers.
Various methods can be used to conceal malware. For the first time, the classification of concealment mechanisms was carried out by Joanna Rutkovskaya in the work Introducing Stealth Malware Taxonomy. The classification proposed to her can be extended as follows (see Fig. 1).
Steganographic mechanisms hide the true purpose of embedded objects by disguising them as legitimate, for example, by the similarity of their names with the names of system files. As a result, malicious files are visible to the user, but do not cause him suspicion. An example of steganographic concealment is the use of trusted company certificates to sign malicious drivers. Thanks to valid certificates from Realtek and JMicron, the Stuxnet worm went unnoticed for a long time, and the Flame worm components were digitally signed by Microsoft itself.
The operation of steganographic mechanisms does not require elevated privileges, they are also transferred to different versions of Windows. However, due to the lack of technical concealment mechanisms, such malware can be easily detected and removed. Most dangerous are combinations of steganography with other concealment mechanisms.
The second group includes technical concealment mechanisms, as a result of which the information about the hidden object becomes inaccessible to the means of detection (“the object is not visible, which means that it does not exist”). These mechanisms can be divided into rootkit mechanisms that operate "inside" and "outside" the OS.
In the case of the “inside OS” rootkit mechanism, an object can be a process, a driver, a disk file, a network port, and a key in the registry. For their work, the rootkit mechanisms can change both execution paths and memory structures, both in user and system address spaces.
To change the path of execution, the malware intercepts the functions of the regular handler and transfers control to the malicious handler, which makes targeted changes to the returned result. Ways of detecting the described concealment mechanism have already been covered in the pages of the magazine.
The second subgroup of the rootkit mechanisms working “inside” the OS does not add new processors to the system, but in a special way changes the memory structures that store information about the hidden object. Examples of such structures located in the system address space and of interest to rootkits: KRPCB, ETHREAD, EPROCESS, MODULE_ENTRY, _DRIVER_OBJECT, plus the database of registered drivers and services located in the user space of the SERVICS.EXE process.
The out-of-OS rootkit mechanisms are based on installing your own or modifying an existing event handler in a particular processor operation mode or additional hardware. These mechanisms often require a chipset that supports the required technology. Rootkit mechanisms based on hardware virtualization mode, system management mode, and code using Active Management Technology and V-PRO technologies can be distinguished. The author of R_T_T, widely known in narrow circles, in his work “Flint of Lawlessness” describes the possibilities and threats to information security not only from the specified technologies, but also from the processor microcode update mechanism ( bit.ly/VRQD6O and bit.ly/104EsRB ).
Most of the malicious tools mentioned earlier used drivers for their work. In this regard, let's consider the most common anti-rootkit tools that can detect the presence of hidden drivers.
The most popular freelance tools that support Windows 8 include the following: Gmer, XueTr, PowerTool, TDSSKiller (Kaspersky Labs).
From the position of detecting hidden drivers, Gmer, XueTr and PowerTool have similar operation algorithms that use byte-by-by-by-by-by-“s ”search in memory of fragments of driver structures. The TDSSKiller tool for detecting drivers uses a slightly different list, the information in which is entered when loading drivers through standard Windows tools.
Changing the fields in the required structures and removing them from the corresponding lists will ensure that the driver is hidden from these tools without disturbing the operation of the system and the malware itself. This makes it possible to state the absence in open access of anti-rootkit tools resistant to counteraction.
Software-hardware rootkits function "outside the OS." The most interesting are instances based on hardware virtualization technology. Why? First, they can be installed with the help of drivers - a regular mechanism of various operating systems. Secondly, such rootkits can intercept events of a higher level than others. Thirdly, they are better documented. Therefore, we take a closer look at them.
Since 2006, Intel and AMD have begun to produce processors with hardware virtualization technology. Software using hardware virtualization technology (or just the hypervisor), works in a new mode, more privileged than the OS. Hardware virtualization technology allows you to run several different hypervisors in an embedded form.
On the one hand, the hypervisor, which serves as a monitor of virtual machines, increases the service capabilities of the computer and reduces its operating costs. Thanks to him, several operating systems can be run simultaneously on different computers in the same computer (Fig. 2).
But, on the other hand, you can tacitly implement a hypervisor, a software tab that has uncontrolled capabilities and carries a threat to information security.
In the open access, there are two software tools - BluePill and Vitriol, implemented as drivers that install the hypervisor transparently to the user.
Whole companies (Komoku, North Security Labs and others) and individual specialists were involved in the detection of hypervisors. Even Microsoft itself has published an interface for detecting hypervisors, according to which it is necessary to execute a CPUID instruction, having previously written one in the EAX register. Next, you need to check the value of 31 bits of the register ECX; if it is set, the hypervisor is present in the system, and information about its capabilities is transmitted in the HV_CPUID_RESULT structure. However, this method is not protected from compromise.
Despite the high prevalence of hypervisors, there are no standard means for detecting them, and the published ones have significant drawbacks: the inability to detect the hypervisor if it counteracts detection, as well as the inconvenience of using and replicating a number of tools. Convenience of replication is understood as the absence in the detection tool of an external hardware component that is required for the entire duration of operation.
In connection with the widespread use of various software using hardware virtualization technology, an illegal hypervisor poses a particular danger, which uses legitimate means of hiding with the help of nested virtualization. In open sources information about how to detect multiple nested hypervisors is missing.
The issue of detection of hypervisors has been repeatedly discussed. In fig. 3 shows the classification of methods for detecting hypervisors, according to which all methods are divided into proactive and signature-based ones.
Temporal detection methods are based on the fact that the statistics of the processing time of specified guest OS events significantly depend on whether the hypervisor is loaded or not: in the presence of the hypervisor, the duration of event processing is much longer. This feature was used by Comrade R_T_T when detecting a Chinese hypervisor ( xakep.ru/post/58104 ). It allows relatively easy detection of hypervisors only in those cases if the intruder did not take measures to conceal them. In situations where there is a deliberate compromise of the counter or temporary unloading of the hypervisor from memory (the so-called BlueChicken technology, which was used in the BluePill), known temporary methods do not allow to detect the hypervisor.
A detailed description and comparative analysis of these detection methods is presented in bit.ly/ik_volume . We will pay attention to the temporary detection method using a list of unmasking events.
For the chosen method, such an event of the guest OS will be the execution of an instruction in which control is always transferred from the OS to the hypervisor. One of these instructions is CPUID. The hypervisor detection system, which will be described later, uses this method.
In order to evaluate each of the methods, the means of detecting hypervisors were analyzed, the comparison of which is presented in Table. 1. A non-hidden hypervisor means the absence of a component in this sample that counteracts detection. Under the hidden sample means the presence in this sample of such a component. In tab. 1, the signs “+” and “-” indicate the presence (absence) of the indicated characteristic, respectively.
The results of the analysis show that the existing methods for detecting hypervisors have a number of drawbacks:
The following is the author's method of detecting an illegitimate hypervisor, which is devoid of these shortcomings. A hypervisor will be considered, which can be implemented using:
It takes into account that the hypervisor implemented by the intruder can counteract detection by compromising the processor clock counter, temporary uninstallation from memory, as well as prevent receiving a copy of the memory dump containing the hypervisor structures.
To identify the factors that can be used to detect the hypervisor, a comparative analysis of the processor operation with hardware virtualization support was carried out when executing a set of instructions intercepted by the hypervisor in cases of its absence and presence (Fig. 4, a and 4, b).
In the case of the presence of a hypervisor, not only the absolute execution time of the trace increases, but also the values of the statistical characteristics of the execution duration, such as variance. This distinctive feature formed the basis of the proposed detection method (a detailed analysis of the switching schemes between processor operation modes and the mathematical justification can be found here bit.ly/10nPPlY .
The essence of the detection technique consists in calculating and comparing the statistical characteristics of the duration of the execution of the route with threshold values.
The measurement of the duration of the trace was carried out for ten CPUID instructions using the processor TSC clock counter at an elevated 31st priority level IRQL. The results of the experiments were matrices with a size of 1000 x 10, containing measurement data for the duration of the run, for which various statistical characteristics were calculated.
For illustrations in the table. Table 2 shows the threshold values of a sequential combination of indicators such as dispersions D ̅ f and moment of the 4th order M ̅ f obtained on different PCs for cases of absence (OT) and presence (PR) of hypervisors.
In the first column of the table. 2 numbers designate models of processors of the examined PCs:
The first two PCs used a hypervisor developed by the author (whose source code you can find on the disk), implemented as an OS driver, in the third case a specialized hypervisor that gets control when the PC is booted from the BIOS.
The proposed method of detecting an illegitimate hypervisor consists of two stages: preliminary and operational, as presented in Table. 3 (detailed description of the technique: bit.ly/ik_volume ).
To counteract this technique, the hidden hypervisor must compromise the reads of the clock counter not by a constant value, but by a random one, so that, on the one hand, it equalizes the average duration of the trace, and on the other, stabilizes the variation of the duration of the trace. However, the question of choosing the distribution law of such a random variable remains open.
True, this technique is not without flaws (Table 4).
All that we have talked about before, all these methods of concealment and detection relate to today. And what should we expect from tomorrow? What path of development will rootkit technology take? It is possible to give free rein to the imagination and it is highly likely that they will develop in the following areas:
I can not again mention the work R_T_T, dedicated to bookmarks in military notebooks Getac ( bit.ly/Sf23yP ). There, the software bookmarks were made in the form of software from the company Compuware, the one that produced the powerful SoftICE debugger. Currently, similar bookmarks of this company can be found in the tablets. For example, new ThinkPad 2 with an advanced level of protection are already sold with preinstalled software - “Enterprise-level security, with Trusted Platform Module and Computrace Mobile”.
As you can see, rootkit creation technologies are not standing still, making the task of detecting them all the more difficult. This makes them a very dangerous cyber weapon, able to go unnoticed, but at the right moment to deliver an accurate and deadly blow. Understanding all their dangers, overseas have created special companies engaged in research in the field of concealment and detection of software bookmarks, such as: DARPA and IARPA (USA), DSTL (United Kingdom), DRDC (Canada), COSTIND (China). Let's hope that soon there will be full-fledged cyber-warriors in our country, but for now the level of security in the military departments leaves much to be desired.
First published in Hacker magazine dated 05/2013.
Publication on ISSUU.com
Subscribe to "Hacker"
PS Can you share knowledge and interesting ideas by writing for] [? Let me know :). We pay fees, but this should not be the main motivation.
Key trends in computer security
One vivid example of the use of cyber weapons is the Red October spy network, which has been actively extracting information from government organizations, various research institutes, and large international companies for five years. The serious security of these objects did not stop the operation of the malicious system. It was discovered just a few months ago, indicating a growing threat of interference with the operation of any computer system.
')
To ensure a stable and undetectable presence in the computer system, malicious software (malware) uses special mechanisms called rootkit mechanisms. As a result, the malware runs invisibly for both the user and the means of protection.
It would seem that OS developers should with all their might resist the concealment of illegitimate software, but the emergence of a new version of Windows did not change the situation for the better. The G8 adopted from its predecessors some of the already familiar protection mechanisms (UAC, ASLR, DEP, PatchGuard, digital signatures for drivers), for which there is a possibility of circumvention. And introduced several new ones - Secure Boot, SMEP and ELAM, which, however, did not greatly increase the level of security. As evidenced by the Stoned Lite bootkit demo figure Peter Kleissner and UEFI bootkit Andrea Alliev. And A. Shishkin from Positive Technologies has already written about the possibility of circumventing SMEP technology on Windows 8.
INFO
According to a recent report by the British National Audit Office (NAO), there has been an increase in the number of cybercrimes, which cost the United Kingdom 18-27 billion pounds per year ( bit.ly/14O9xy5 ).
Based on the above, it can be concluded that in the latest version of Windows, nothing revolutionary was introduced to combat malware, and there are no worthy mechanisms capable of making life difficult for rootkit developers.
Hiding mechanisms in the system
Various methods can be used to conceal malware. For the first time, the classification of concealment mechanisms was carried out by Joanna Rutkovskaya in the work Introducing Stealth Malware Taxonomy. The classification proposed to her can be extended as follows (see Fig. 1).
Steganographic mechanisms hide the true purpose of embedded objects by disguising them as legitimate, for example, by the similarity of their names with the names of system files. As a result, malicious files are visible to the user, but do not cause him suspicion. An example of steganographic concealment is the use of trusted company certificates to sign malicious drivers. Thanks to valid certificates from Realtek and JMicron, the Stuxnet worm went unnoticed for a long time, and the Flame worm components were digitally signed by Microsoft itself.
The operation of steganographic mechanisms does not require elevated privileges, they are also transferred to different versions of Windows. However, due to the lack of technical concealment mechanisms, such malware can be easily detected and removed. Most dangerous are combinations of steganography with other concealment mechanisms.
The second group includes technical concealment mechanisms, as a result of which the information about the hidden object becomes inaccessible to the means of detection (“the object is not visible, which means that it does not exist”). These mechanisms can be divided into rootkit mechanisms that operate "inside" and "outside" the OS.
In the case of the “inside OS” rootkit mechanism, an object can be a process, a driver, a disk file, a network port, and a key in the registry. For their work, the rootkit mechanisms can change both execution paths and memory structures, both in user and system address spaces.
To change the path of execution, the malware intercepts the functions of the regular handler and transfers control to the malicious handler, which makes targeted changes to the returned result. Ways of detecting the described concealment mechanism have already been covered in the pages of the magazine.
The second subgroup of the rootkit mechanisms working “inside” the OS does not add new processors to the system, but in a special way changes the memory structures that store information about the hidden object. Examples of such structures located in the system address space and of interest to rootkits: KRPCB, ETHREAD, EPROCESS, MODULE_ENTRY, _DRIVER_OBJECT, plus the database of registered drivers and services located in the user space of the SERVICS.EXE process.
The out-of-OS rootkit mechanisms are based on installing your own or modifying an existing event handler in a particular processor operation mode or additional hardware. These mechanisms often require a chipset that supports the required technology. Rootkit mechanisms based on hardware virtualization mode, system management mode, and code using Active Management Technology and V-PRO technologies can be distinguished. The author of R_T_T, widely known in narrow circles, in his work “Flint of Lawlessness” describes the possibilities and threats to information security not only from the specified technologies, but also from the processor microcode update mechanism ( bit.ly/VRQD6O and bit.ly/104EsRB ).
An interesting technique of hiding rootkits
At the ZeroNight conference in 2012, the work of D. Oleksyuk (aka Cr4sh) was presented, which described an interesting way of placing the rootkit not in files, but in the registry using the Differentiated System Description Table (DSDT). The advantage of this method is that no tool for detecting rootkits does not take into account this possibility.
Anti-rootkit
Most of the malicious tools mentioned earlier used drivers for their work. In this regard, let's consider the most common anti-rootkit tools that can detect the presence of hidden drivers.
The most popular freelance tools that support Windows 8 include the following: Gmer, XueTr, PowerTool, TDSSKiller (Kaspersky Labs).
From the position of detecting hidden drivers, Gmer, XueTr and PowerTool have similar operation algorithms that use byte-by-by-by-by-by-“s ”search in memory of fragments of driver structures. The TDSSKiller tool for detecting drivers uses a slightly different list, the information in which is entered when loading drivers through standard Windows tools.
Changing the fields in the required structures and removing them from the corresponding lists will ensure that the driver is hidden from these tools without disturbing the operation of the system and the malware itself. This makes it possible to state the absence in open access of anti-rootkit tools resistant to counteraction.
Software and hardware rootkits
Software-hardware rootkits function "outside the OS." The most interesting are instances based on hardware virtualization technology. Why? First, they can be installed with the help of drivers - a regular mechanism of various operating systems. Secondly, such rootkits can intercept events of a higher level than others. Thirdly, they are better documented. Therefore, we take a closer look at them.
Since 2006, Intel and AMD have begun to produce processors with hardware virtualization technology. Software using hardware virtualization technology (or just the hypervisor), works in a new mode, more privileged than the OS. Hardware virtualization technology allows you to run several different hypervisors in an embedded form.
Hypervisor Source Codes - Drivers for Windows x86 OS
The fastest and easiest way to create your own hypervisor, based on one of the existing ones. On the disk attached to the magazine, you can find the following sources:
- BluePill (versions 0.11 and 0.32) is a demo of the hypervisor for AMD systems, after the publication of which a broad discussion of information security threats from hardware virtualization began.
- vmxcpu is the source code of the hypervisor Sh. Embleton (Sh. Embleton) for Intel processors, which is ready for use.
- Invisible Lane (il) - the source code of the author's hidden hypervisor, built on the basis of vmxcpu. Concealment is accomplished by compromising the TSC processor clock counter; the amount of compromise can be set with an accuracy of one clock cycle.
On the one hand, the hypervisor, which serves as a monitor of virtual machines, increases the service capabilities of the computer and reduces its operating costs. Thanks to him, several operating systems can be run simultaneously on different computers in the same computer (Fig. 2).
But, on the other hand, you can tacitly implement a hypervisor, a software tab that has uncontrolled capabilities and carries a threat to information security.
In the open access, there are two software tools - BluePill and Vitriol, implemented as drivers that install the hypervisor transparently to the user.
Whole companies (Komoku, North Security Labs and others) and individual specialists were involved in the detection of hypervisors. Even Microsoft itself has published an interface for detecting hypervisors, according to which it is necessary to execute a CPUID instruction, having previously written one in the EAX register. Next, you need to check the value of 31 bits of the register ECX; if it is set, the hypervisor is present in the system, and information about its capabilities is transmitted in the HV_CPUID_RESULT structure. However, this method is not protected from compromise.
Despite the high prevalence of hypervisors, there are no standard means for detecting them, and the published ones have significant drawbacks: the inability to detect the hypervisor if it counteracts detection, as well as the inconvenience of using and replicating a number of tools. Convenience of replication is understood as the absence in the detection tool of an external hardware component that is required for the entire duration of operation.
Hypervisor Debugging Tools
The specificity of the hypervisor does not always allow the use of popular debugging tools such as vBox (VMware) with WinDbg; instead, you can use Bochs or AMD SimNow emulators, but they are rather complicated to configure.
What can be used:
- Display debug messages via DbgPrint and view them using DbgView. However, such a method can be used to demonstrate the correct operation of the hypervisor, rather than to debug it.
- Send debug messages to the COM port. This method was used by the authors of BluePill, retaining the source implementation of these functions.
- Use a debug card, for example, "PTI8 Diagnostic Post Test Card Debug Card PCI Analyzer". When you turn on the computer, you will see BIOS POST messages on the LCD display of this board.
In connection with the widespread use of various software using hardware virtualization technology, an illegal hypervisor poses a particular danger, which uses legitimate means of hiding with the help of nested virtualization. In open sources information about how to detect multiple nested hypervisors is missing.
Review and classification of methods for detecting hypervisors
The issue of detection of hypervisors has been repeatedly discussed. In fig. 3 shows the classification of methods for detecting hypervisors, according to which all methods are divided into proactive and signature-based ones.
Temporal detection methods are based on the fact that the statistics of the processing time of specified guest OS events significantly depend on whether the hypervisor is loaded or not: in the presence of the hypervisor, the duration of event processing is much longer. This feature was used by Comrade R_T_T when detecting a Chinese hypervisor ( xakep.ru/post/58104 ). It allows relatively easy detection of hypervisors only in those cases if the intruder did not take measures to conceal them. In situations where there is a deliberate compromise of the counter or temporary unloading of the hypervisor from memory (the so-called BlueChicken technology, which was used in the BluePill), known temporary methods do not allow to detect the hypervisor.
A detailed description and comparative analysis of these detection methods is presented in bit.ly/ik_volume . We will pay attention to the temporary detection method using a list of unmasking events.
For the chosen method, such an event of the guest OS will be the execution of an instruction in which control is always transferred from the OS to the hypervisor. One of these instructions is CPUID. The hypervisor detection system, which will be described later, uses this method.
In order to evaluate each of the methods, the means of detecting hypervisors were analyzed, the comparison of which is presented in Table. 1. A non-hidden hypervisor means the absence of a component in this sample that counteracts detection. Under the hidden sample means the presence in this sample of such a component. In tab. 1, the signs “+” and “-” indicate the presence (absence) of the indicated characteristic, respectively.
The results of the analysis show that the existing methods for detecting hypervisors have a number of drawbacks:
- temporary methods do not allow to detect hypervisors in the case of using a compromise of a clock counter or a temporary unloading from memory;
- behavioral methods cannot detect new hypervisors and are not functional on new processor models;
- methods based on a trusted virtual machine monitor are vulnerable to a man-in-the-middle attack;
- signature-based hardware is inconvenient to use and replicate, and software is unstable to counter the hypervisor;
- All published detection methods and tools do not allow detecting multiple nested hypervisors.
The following is the author's method of detecting an illegitimate hypervisor, which is devoid of these shortcomings. A hypervisor will be considered, which can be implemented using:
- install the operating system driver;
- modifications to the master boot record of the hard disk;
- make changes to the firmware BIOS hardware.
It takes into account that the hypervisor implemented by the intruder can counteract detection by compromising the processor clock counter, temporary uninstallation from memory, as well as prevent receiving a copy of the memory dump containing the hypervisor structures.
Prerequisites for detection
To identify the factors that can be used to detect the hypervisor, a comparative analysis of the processor operation with hardware virtualization support was carried out when executing a set of instructions intercepted by the hypervisor in cases of its absence and presence (Fig. 4, a and 4, b).
In the case of the presence of a hypervisor, not only the absolute execution time of the trace increases, but also the values of the statistical characteristics of the execution duration, such as variance. This distinctive feature formed the basis of the proposed detection method (a detailed analysis of the switching schemes between processor operation modes and the mathematical justification can be found here bit.ly/10nPPlY .
Detection technique and its analysis
The essence of the detection technique consists in calculating and comparing the statistical characteristics of the duration of the execution of the route with threshold values.
The measurement of the duration of the trace was carried out for ten CPUID instructions using the processor TSC clock counter at an elevated 31st priority level IRQL. The results of the experiments were matrices with a size of 1000 x 10, containing measurement data for the duration of the run, for which various statistical characteristics were calculated.
For illustrations in the table. Table 2 shows the threshold values of a sequential combination of indicators such as dispersions D ̅ f and moment of the 4th order M ̅ f obtained on different PCs for cases of absence (OT) and presence (PR) of hypervisors.
In the first column of the table. 2 numbers designate models of processors of the examined PCs:
- Intel Core 2 Duo E8200 with Windows 7,
- Intel Core 2 Duo E6300 with Windows 7,
- AMD Phenom X4 945 with Windows Live CD XP (DDD).
The first two PCs used a hypervisor developed by the author (whose source code you can find on the disk), implemented as an OS driver, in the third case a specialized hypervisor that gets control when the PC is booted from the BIOS.
The proposed method of detecting an illegitimate hypervisor consists of two stages: preliminary and operational, as presented in Table. 3 (detailed description of the technique: bit.ly/ik_volume ).
To counteract this technique, the hidden hypervisor must compromise the reads of the clock counter not by a constant value, but by a random one, so that, on the one hand, it equalizes the average duration of the trace, and on the other, stabilizes the variation of the duration of the trace. However, the question of choosing the distribution law of such a random variable remains open.
True, this technique is not without flaws (Table 4).
A look into the future
All that we have talked about before, all these methods of concealment and detection relate to today. And what should we expect from tomorrow? What path of development will rootkit technology take? It is possible to give free rein to the imagination and it is highly likely that they will develop in the following areas:
- Rootkits in the clouds and supercomputers. Often, hardware virtualization is used to improve cloud computing performance. At the same time, there is no information about checking such systems for the absence of illegitimate hypervisors.
- Rootkits in embedded systems. Various embedded systems are gaining immense popularity, these are the systems “Smart Home”, “Smart City”, systems in cars and many others. The new IBM Smarter Cities initiative requires special attention, as the numerous components of the system provide the livelihoods of a large number of people, while presenting themselves as prey to violators.
- Rootkits in mobile OS. The introduction of rootkits in mobile operating systems is no longer a novelty.
- Rootkits in the form of pre-installed software in tablets
I can not again mention the work R_T_T, dedicated to bookmarks in military notebooks Getac ( bit.ly/Sf23yP ). There, the software bookmarks were made in the form of software from the company Compuware, the one that produced the powerful SoftICE debugger. Currently, similar bookmarks of this company can be found in the tablets. For example, new ThinkPad 2 with an advanced level of protection are already sold with preinstalled software - “Enterprise-level security, with Trusted Platform Module and Computrace Mobile”.
Www
An interesting paper on EFI rootkits, but under OS X, was done by Loukas K: bit.ly/Pe1Dkl .
Results
As you can see, rootkit creation technologies are not standing still, making the task of detecting them all the more difficult. This makes them a very dangerous cyber weapon, able to go unnoticed, but at the right moment to deliver an accurate and deadly blow. Understanding all their dangers, overseas have created special companies engaged in research in the field of concealment and detection of software bookmarks, such as: DARPA and IARPA (USA), DSTL (United Kingdom), DRDC (Canada), COSTIND (China). Let's hope that soon there will be full-fledged cyber-warriors in our country, but for now the level of security in the military departments leaves much to be desired.
about the author
Igor Korkin ( igor.korkin@gmail.com ) - Candidate of Technical Sciences in the specialty 05.13.19 “Methods and systems of information protection, information security”. Works at MEPhI, manages the scientific work of students, trains graduate students. He has been engaged in the detection of software bookmarks for more than six years, the author of more than ten scientific papers, the winner of the “Hackers against Fornsica” competition on the Positive Hack Days 2012 forum.
First published in Hacker magazine dated 05/2013.
Publication on ISSUU.com
Subscribe to "Hacker"
- 1 999 . for 12 numbers of paper version
- 1249r. for an annual subscription to iOS / iPad (Android'a release soon!)
- "Hacker" on Android
PS Can you share knowledge and interesting ideas by writing for] [? Let me know :). We pay fees, but this should not be the main motivation.
Source: https://habr.com/ru/post/186072/
All Articles