The Libmemrk shall enable rootkit developers to hide processes and files and also interfere in network goings-on. What it really does is that it employs the /dev/mem device driver, without the need for rights, to write into the main memory an arbitrary code from the users space. This driver shows an interface that allows the use of the memory that can be physically addressed. The Xserver and DOSEmu are now using it. Lineberry emphasized that getting things rolling with rootkits through /dev/mem is less distinguishable than the usual route which is through loadable kernel modules or LKMs.

This latest library will get the load off the backs of rootkit programmers by not requiring them anymore to go through the translation of virtual memory addresses into physical addresses and recognizing the memory bounds that can be studied before the attack. This way, the attacker will not be able to overwrite whatever system calls exist and replace them with another code up to the moment that the right ranges used by the kernel have been found. The actual contents found in the memory by the kernel are concurrently being shifted into a buffer.

For an attack to be successful, careful and detailed procedures are required which can be done by Libmemrk. These steps are described by Lineberry in his paper entitled “Malicious Code Injection via /dev/mem.” Lineberry furthers says that attacks usually do not succeed in virtual systems since hypervisors behave in a different way as compared to unvirtualized environments. He reminded everyone that even with libmemrk, the attack should still be programmed manually using assemble language. He intends to use libcc in the future so that whatever impact it creates should be lessened.

Lineberry usefully gave some tips how Linux users can protect themselves against these kinds of rootkits. He thought that modifying the memory driver is enough to disallow the write/read pointer 1seek to find at least 16 kb in the memory. The latest versions of Fedora and Red Hat are secure in a built-in manner since their kernels integrate SELinx or Security Enhanced Linux features into the system.

The publishing is not possible at the moment, according to Lineberry, since he is still in the process of getting rid of the last weaknesses that it has. This is something Linuxers should look forward to to protect themselves from possible attacks.

The H open

ShareThis

The Mebroot kit has the ability to launch itself very early during startup without having to wait for file modification or registry. It is the stealthiest rootkit out there today because of its speed in launching and its ability to hide and not be detected in the infected system. It cannot be spotted easily because it can attach itself deep within the Windows system.

The Mebroot has already done enough damage in the RSA security division of EMC last year when a big bulk of financial data was stolen. Since then, the makers have developed the new variant so that it could hide while it reaches all corners of the drive-by downloads.

The moment Mebroot gets into your Windows PC, it transports a payload that records all keystrokes, insert random HTML into websites, especially banking sites, and detects HTTP and HTTPS post requests. Most vendors would say that what is really amazing about it is how it can infect the system. It does not need to connect to the disk.sys driver, but inspects what type of lower device \Device\Harddisk0\DR0 it is connected to and quickly hooks into the relative driver. Whether it is atapi.sys or acpi.sys, it can attack the driver. Therefore, results differ between PCs and virtual machines.

The makers were also able to integrate into the malware the ability for it to fix a bug that, in the past, has made it easier to become aware of anomalies with the MBR.

The most dangerous feature of Mebroot is that it is not present in the hard drive as a file after the first infection. It remains invisible. It only becomes injected into the kernel drivers during the start-up process and eventually becomes injected into svchost.exe and services.exe. Via IAT, processes will become compromised so that it can access all the internal data. Mebroot, for that reason, will not be found in the hardware. The only clue is its presence in the temp drive for only a short time.

Thankfully, though, the malware has not been widespread so far. It has popped up in several servers but is not present again as of the moment. But the problem remains that it may appear anytime because the authors know exactly the machinery behind the security industry. But of course, these people wouldn’t want to make it a global threat like what conficker.c did before. It may not be present today but we all have to be wary and prepared when it comes again.

The rootkit stores data that’s required to survive reboots in physical sectors instead of files. This means that the data, including the real payload, is not visible or in any way accessible to normal applications. Therefore the rootkit does not have to hook the normal set of interfaces to keep them hidden.

The MBR is the rootkit’s launch point. Therefore it doesn’t need to make any registry changes or to modify any existing startup executables in order to launch itself. This means that the only hooks it needs to make are used to hide and protect the modified MBR. Essentially this means that the rootkit hooks only two DWORDs from the disk.sys driver object which is shown in the picture below.

eWEEK

image credits to Sophos D/A/CH Presseinfo

ShareThis