Using Components with Known Vulnerabilities
These days, even simple websites such as personal blogs have a lot of dependencies.
We can all agree that failing to update every piece of software on the backend and frontend of a website will, without a doubt, introduce heavy security risks sooner rather than later.
For example, our hacked website report for 2017 has a dedicated section around outdated CMSs. This report shows that at the time of the infection:
- 39.3% of WordPress websites were out of date;
- 69.8% of Joomla! websites were out of date;
- 65.3% of Drupal websites were out of date;
- 80.3% of Magento websites were out of date.
The question is, why aren’t we updating our software on time? Why is this still such a huge problem today?
There are some possibilities, such as:
- Webmasters/developers cannot keep up with the pace of the updates; after all, updating properly takes time.
- Legacy code won’t work on newer versions of its dependencies.
This might be a little too dramatic, but every time you disregard an update warning, you might be allowing a now known vulnerability to survive in your system. Trust me, cybercriminals are quick to investigate software and update changelogs.
Whatever the reason for running out-of-date software on your web application is, you can’t leave it unprotected. Both Sucuri and OWASP recommend virtual patching for the cases where patching is not possible.
Virtual patching affords websites that are outdated (or with known vulnerabilities) to be protected from attacks by preventing the exploitation of these vulnerabilities on the fly. This is usually done by a firewall and an intrusion detection system.
Vulnerable applications are usually outdated, according to OWASP if:
- You do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies
- The software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
- You do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
- The software developers do not test the compatibility of updated, upgraded, or patched libraries.
- You do not secure the components’ configurations.
How to Prevent Using Components with Known Vulnerabilities
Some of the ways to prevent the use of vulnerable components are:
- Remove all unnecessary dependencies.
- Have an inventory of all your components on the client-side and server-side.
- Monitor sources like Common Vulnerabilities and Disclosures and National Vulnerability Database for vulnerabilities in the components.
- Obtain components only from official sources.
- Get rid of components not actively maintained.
- Use virtual patch.
10. Insufficient Logging and Monitoring
The importance of securing a website cannot be understated. While 100% security is not a realistic goal, there are ways to keep your website monitored on a regular basis so you can take immediate action when something happens.
Not having an efficient logging and monitoring process in place can increase the chances of a website compromise.
Here at Sucuri, we highly recommend that every website is properly monitored. If you need to monitor your server, OSSEC is freely available to help you. OSSEC actively monitors all aspects of system activity with file integrity monitoring, log monitoring, root check, and process monitoring.
Example of Attack Scenarios
According to OWASP, here are some examples of attack scenarios due to insufficient logging and monitoring:
Scenario #1: An open-source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version and all of the forum contents. Although source could be recovered, the lack of monitoring, logging, or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.
Scenario #2: An attacker scans for users with a common password. They can take over all accounts with this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.
Scenario #3: A major U.S. retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before detecting the breach due to fraudulent card transactions by an external bank.
How to Have Efficient Website Monitoring
Keeping audit logs are vital to staying on top of any suspicious change to your website. An audit log is a document that records the events in a website so you can spot anomalies and confirm with the person in charge that the account hasn’t been compromised.
We know that it may be hard for some users to perform audit logs manually. If you have a WordPress website, you can use our free Security Plugin which can be downloaded from the official WordPress repository.
The Sucuri Website Security Platform has a comprehensive monitoring solution that includes:
- remote scanner
- website blacklist scanner
- server-side scanner
- DNS scanner
- SSL scanner
- uptime scanner
In this post, we tackled OWASP Top 10 vulnerabilities number 9 and 10: using components with known vulnerabilities and insufficient logging and monitoring.