Linux known exploit detection

The integration of a new patch into the Linux kernel has been proposed to enable the successful detection of exploitation attempts.

The principle is very simple: when a security fix is added to the kernel, a new code will be added to call the “ exploit” function (with the CVE number of the exploit that is being patched, for example). Then, if someone tries to exploit this vulnerability, the attempt will be unsuccessful because the vulnerability has been patched, but the exploit function will be called in order to log the exploitation attempt.

This concept has several advantages because when a malicious attacker successfully roots your Linux system, chances are that your system wouldn’t log anything, but if an exploitation attempt fails, you will be able to log some information in the system.

So the argument in favor of this functionality is that most hackers will try multiple exploits before they succeed in breaking into your system for many reasons, such as not knowing your Linux kernel version, or probably  because they are script kiddies who use exploitation kits that will try to run multiple exploits.

The main detractors of this new security function claim that attackers, after successfully exploiting the system (with an exploit that is not patched), will be able to delete the logs that have been created by the exploit function. A suggestion would be to log it immediately on an external syslog server (or directly to a SOC if the organization has one).

Another potential issue is that after years of patching the kernel, a lot of annotations and exploit function calls would be present in the Linux source code. In order to keep the kernel as clean as possible, an idea would be to delete these annotations after a few years (a vulnerability has few chances of being tested if is 3 years old).

What is interesting is that even if it is based on signatures and has no chance of proactively detecting a 0day exploitation, this technique would give you precious information about hacking attempts in your organization.

Also, you might think that if you have a NIPS (Network Intrusion Prevention System) you would be able to detect these attempts without having such features in your kernel.

The problem is that your NIPS engine will be based on a signature approach, and there are plenty of techniques to bypass this approach. Advanced Evasion Techniques (AET) are a good example.

The Linux known exploit detection is also beneficial because it won’t analyze the shellcode of the exploitation (which might change or might use polymorphism to easily bypass the detection engine) but would detect the vulnerability exploitation directly. In this case you will prevent false positives.

This functionality is not considered a “must-have” that would solve all your problems: you won’t be protected against 0day attacks and you will still need to patch your operating system. It would not replace one of your security layers, but it can be considered a “nice-to-have”.

These precious logs have a value only if you know what to do when such an alert is raised: you have to define a manual or automated process that will, for example, investigate on what’s going on in order to block the attacker.

We hope that third party vendors will copy this initiative, and it would also make a lot of sense that Adobe Acrobat warns you about vulnerability exploitation attempts in your system.