Patch management can be a complex and time-consuming process, and because of this, patches to fix vulnerabilities may not be applied before a hacker is able to breach an organization's security. The majority of organizations are not aware of these vulnerabilities until they have experienced a breach, at which point it is frustrating to learn that deploying a simple patch could have prevented the breach altogether. . You cannot deploy a patch until it has been tested, and patches often require IT professionals to reconfigure and reboot systems that are difficult to take offline for long. A Ponemon survey showed that 88 percent of IT professionals are not solely responsible for patches but rather they usually have to coordinate with other teams, which can delay patching by an average of 12 days. Another issue organizations run into is that once a new patch is announced, hackers begin working to exploit the vulnerability before it is patched. The Ponemon survey also indicated that it can take an average of "43 days to see a cyberattack once a patch is released for a critical... vulnerability". OpenSSL Shared Library Vulnerabilities OpenSSL patch management is ridden with challenges. The open-source software is a library of cryptographic applications that are intended to secure networks, and it is used on the majority of HTTPS websites. Research has indicated that OpenSSL is the most targeted software in the world, accounting for approximately 19% of hostile activity globally. The Heartbleed Bug is a major vulnerability in OpenSSL software. It attacks a memory handling bug in versions 1.0.1 to 1.0.1f of OpenSSL that allows hackers to decode 64 kilobytes of encrypted data in each heartbeat. "The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software." Hackers can obtain access to the names and passwords of users, cookies, communications, content, and more by exploiting this dangerous vulnerability. Heartbleedcan be a devastating attack because it can impact both the client and the server itself. In 2014, when Heartbleed came to light, an estimated 17 percent of the secure web services on the internet were vulnerable. The Challenges of Identifying Vulnerable Libraries One of the biggest challenges in identifying vulnerable servers is that they often end up in the application indirectly, instead of being directly used in the code. The applications themselves have dependencies on other applications, so they are not as easy to identify as applications that are being directly used. These are a transitive dependency, where the library depends on code in other libraries to run properly. So, a developer may choose one specific library, but it is dependent on another library, which, in turn, is dependent on code in another library. The more complex the application, the more dependencies the library has. If one of these libraries is vulnerable, it can be harder to identify because it is not being used directly, so an admin may not know to check the others when looking for vulnerabilities in the system. This is why many admins will simply reboot the entire server when they need to update a patch to handle a vulnerability. They may not know which services are using which libraries - making rebooting the entire server feel like the easier route to take. However, rebooting the system involves service degradations and outages. A server may take time to stabilize after a reboot, causing major disruptions to service. Sometimes, the servers will not come back properly once they have been rebooted. Another problem with reboots is that they can leave a server vulnerable to attack. Even if the servers are patched manually, if the server is not rebooted, vulnerabilities may still exist in the shared libraries. Identify Libraries that are Still Vulnerable to Attacks After Updates with an Open-Source Scanner In order to assist the FOSS community and help administrators manage hundreds of servers using shared libraries, KernelCare released Uchecker - a scanner that examines Linux network servers and detects out-of-date libraries used by running processes both on disk and in memory. Uchecker was created during the development process of live patching service for shared libraries – KernelCare+. The scanner is free and open-source, distributed under the GNU General Public License. The Uchecker (short from "userspace checker") works with all modern Linux distributions starting from the 6th versions. You can scan your systems for outdated shared libraries by running a single command: curl -s -L githubusercontent | python In the scan results, administrators receive a list of outdated libraries with the following information: Process ID Process Name Shared library build ID Figure 1: Uchecker Scan Results Figure 2: Uchecker Activity Diagram Visit Uchecker's Github page to learn more about the free and open-source scanner that identifies outdated shared libraries residing both on disk and in memory. Watch a demonstration of how Uchecker works in this video. Conclusion Administrators who patch libraries manually without a reboot run the risk of vulnerabilities persisting in-memory. Library patching often remediates vulnerabilities on disk, but outdated vulnerable libraries still remain in memory and can be exploited, even after being patched. For example, research suggests that OpenSSL is the most targeted software in the world, accounting for 19% of hostile activity globally , although patches for this vulnerability have been available for years. KernelCare’s Uchecker will find false negatives by correctly reporting vulnerable libraries running in memory that could be reported as updated by other scanners. About the Author Aleksandra Mitroshkina takes care of product marketing at KernelCare, CloudLinux Inc.. Facebook , LinkedIn . Identifying libraries that remain susceptible after updates helps administrators enhance security, especially through toolssuch as Libwatcher.. Library Vulnerabilities, OpenSSL Exploits, Patch Management Tools, Transitive Dependency Issues, Linux Vulnerability Scanner. . Brittany Day
There are a number of security scanners out there. Most of them are vendor specific, and each boasts a number of vulnerability checks to determine what is secure on your system and what is not. So what if you are a hardcore open source paranoid like myself who wouldn't think to spend a dime on the latest commercial security scanner from CyberSlueths or CrackerCops? Well there is a superior alternative that is regularly updated, free, and open source. It's called Nessus, and it is by far the best scanner available. . The first time I encountered Nessus was when I was looking into what crackers use to scan for vulnerabilities of systems that they plan to exploit. The logic here is that by first scanning yourself using their tool of choice, you are taking the initative in preventing the exploitation, since you are aware of what they are looking for and have already taken steps to prevent it. That is the beauty of Nessus. It is an incredibly versitile and extremely efficient application that not only identifies nasty vulnerabilities that could be exploited, but tells you how to prevent hackers from taking advantage of your system, and even gives you a risk level for each vulnerability it discovers. There are many tricks and tweeks that that can used within Nessus, including its own scripting language, the Nessus Attack Scripting Language (NASL), which you can use to write your own security tests. But those subjects are beyond the scope of this article. At first, I intended just to download and install Nessus, do a quick scan of my systems, and be on my merry way, safer and a little more secure, just like I would do with Nmap, the excellent port scanner from insecure.org. But what happened was a little more complicated. Nessus is composed of two parts: a client and a server. The server is in charge of the attacks, whereas the client is the front end, so that you can perform scans of your whole network via your local workstation. So there is a little more to setting it up than your typical application. That is what this article covers. I'll show you how to get Nessus onto your machine as quickly and painlessly as possible, without having to spend hours fiddling with it or pulling out your hair due to the fact that you missed one little thing. I began with a fresh installation of Red Hat 7.0. Make sure when you install that you select the custom option and choose the development load so that you'll have all the necessary libraries and compilers. Then follow these instructions step by step in order to get Nessus up and running. 1. Make sure /usr/local/bin is in your path. To check, at the command line, type echo $PATH If it is not in your path, add usr/local/bin to the /etc/profile file. Remember: If you have to add this to your path, you have to log out and log back in for the change to take effect, or you can type: export PATH=$PATH:/usr/local/bin 2. Add /usr/local/lib to the /etc/ld.so.conf file. Then go to /sbin and type: ./ldconfig 3. Nessus uses Nmap for port scans so you'll want to go to https://insecure.org/ and download the Nmap tarball and untar it. tar -zxvf nmap-VERSION cd nmap ./configure make su (to super user) make install To make sure that it is properly installed, type nmap at the command line and you should get a list of options and flags. This shows you that it has been properly installed. 4. In your home directory, create a new sub-directory ' mkdir Nessus ' 5. Download the Nessus tarballs into your new Nessus directory. 6. In the Nessus directory, you should have four tarballs. You absolutely must have all four for Nessus to work. You want to untar, configure, make, andmake install in this order exactly. su (into superuser) tar -zxvf nessus-libraries-VERSION cd nessus-libraries ./configure make make install After you finish the make install of the libraries, you get a prompt to make sure that you have /usr/local/lib in the /etc/ld.so.conf file, and to type ldconfig . But since we already covered this in step two, all you need to do is go back to /sbin and run ./ldconfig again. 7. Go back to the Nessus directory, and just like in step six, untar, configure, make, and make install the other three downloaded files in this order. libnasl nessus-core nessus-plugins 8. At this time go back to /sbin and run ./ldconfig again. 9. Go to /usr/local/sbin and, as superuser, type: ./nessus-adduser This runs a script that starts by generating some primes. Then you should see a prompt that asks you to add a user. You will get another prompt for Authentication method, cipher or plaintext. The default is cipher, so just hit Enter. It should then ask you if your user name is a local user. Type y and hit enter. It then tells you that it is treating your user name as a local user. After this, the add-user program prompts you to add rules such as where you can or cannot scan. I leave this blank since I am the only one using my machine and I want to scan everything in my network. And since this is a quick start guide, we don't want to complicate things. Then hit Ctrl - d, and the program will ask you if your selections are correct. If they are, type y and hit Enter. Once more the program generates some primes. Now you will be asked for a passphrase and you will be prompted to repeat it twice more. Then you will get a confirmation that theuser was added and you will be returned to a shell prompt. 10. To run Nessus the Nessus daemon must be running. In the /user/local/sbin type ./nessusd which will start the daemon. (It will continue to run while you are using the scanner. When you finish using the scanner, kill it by typing Ctrl - c). If you choose to have the daemon running in the background all the time type ./nessusd -D and then you can close that terminal window without killing the process. 11. Return to your home directory as a normal user and not superuser. Type: nessus and the nessus program begins with a password prompt. Your login name should be the same user name that you entered in the nessus-adduser program. Then click the login button and you are ready to go. You then see different option tabs that you can click through: Nessusd host, Plugins, Preferences, Scan options, Target selection, User, and Credits. These options are generally preconfigured so that while you are getting aquainted with Nessus you don't have to worry about changing the settings.There is one exception: if you are planning to run a scan against your own local host where you have Nessus running, you must only use the Nmap TCP scan and disable the other five. According to the man pages, there is a bug that will prevent them from working properly. There you have it. A quick and easy step-by-step guide to getting Nessus up and running on your system. As I mentioned earlier, Nessus is extemely versatile and there are an infinite number of ways that it can be configured and utilized. In no way is this article a substitute for the man pages, README files or the online instructions found at the nessus.org site. I strongly encourage you to read all availible documentation so that you'll have a better understanding of thescanner itself since such a powerful and diverse tool can be used just as easily to exploit systems as to secure them. Resources: Nessus Homepage https://www.tenable.com/ Nmap Homepage https://insecure.org/ Author Bio: Paul Christensen currently works for Penguin Computing as a Linux Support Specialist. He is a regular contributor to "Best of Technical Support" in the Linux Journal and spends the rest of his free time working with Open Source security applications. . Learn how to set up Nessus, the open-source scanner, with strategic steps for effective vulnerability assessment and improved network security. Nessus Setup Guide, Open Source Scanning Tool, Network Vulnerability Assessment. . Brittany Day
Get the latest Linux and open source security news straight to your inbox.