Linux vulnerabilities: How unpatched servers lead to persistent backdoors

Vulnerability management is a challenge

Humans make mistakes, software has bugs and some of these bugs are exploitable vulnerabilities. The existence of vulnerabilities in software is not a new problem, but as the volume of software in existence grows, so does the number of exploitable vulnerabilities.

In the last couple of years, over 22,000 new vulnerabilities have been discovered each year. This does not include all of the vulnerabilities that have been previously discovered and reported. Currently, over 139,000 CVEs exist, and not every publicly disclosed vulnerability is assigned a CVE.

Keeping up with the flood of new vulnerabilities is a challenge for any organization. In 2019 alone, an average of 61 new vulnerabilities were reported daily. Even though an organization would likely be affected by a fraction of these, it is necessary to check if each vulnerability is applicable; if it is, the organization must test the patch, apply it and verify that it is applied successfully. This assumes that an organization is currently up-to-date on patching, and many are not.

To alleviate the patching burden, many organizations use a triage process to prioritize patch application. However, it seems that often “the squeaky wheel gets the grease” and some systems are overlooked, making them and the organization vulnerable to exploitation.

Linux servers are a prime target of exploitation

When planning a cyberattack, the best targets are those that are easily exploited yet have a wealth of valuable information stored on them. Linux servers are an excellent target for cybercriminals for a variety of different reasons:

  • Not user-facing: Linux servers typically are located in a data center or server room somewhere and have little or no direct interaction with users. This lack of direct interaction means that they often receive less of a security focus. If no one is logging (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: