In this article, we want to share with you the cases that happened with our customers, and tell / show / answer the question why vulnerability management is almost always not about vulnerabilities, and a simple one – “we will filter for you from 1,000,000 vulnerabilities to the really important minimum ”is not enough.
Case # 1 “Oh, we ourselves know that everything is bad here!”
Object: remote management module (IPMI) installed on critical servers – more than 500 pcs.
Vulnerability: severity level (CVSS Score) – 7.8
CVE-2013−4786 is an IPMI vulnerability that could allow an attacker to gain access to user password hashes, leading to unauthorized access and potential account hacking by an attacker.
Description of the case: the customer knew about the vulnerability himself, however, for a number of reasons described below, the matter did not go beyond “risk acceptance”.
The complexity of the case itself is that patches are not available for all motherboards that use this module, and updating firmware on such a large number of servers is extremely resource-intensive.
There were also alternative mitigation methods – access lists (ACL) on network equipment (it is very difficult since admins are highly distributed and use IPMI from where they come from) and disable IPMI, here, I think, comments are unnecessary (just in case: 500 distributed servers)
This is where the story usually ends, however, on our part, an additional analysis of the vulnerability was carried out and it became clear that the hash of the account password is returned by the server only in case of a request with a login that exists on the server, so a decision was made:
1. Change account IDs to hard-to-find ones
This is certainly not a panacea. And if, without hurrying, sort out the logins, then sooner or later it will be possible to pick it up. But most likely it will take long enough to have time to implement additional measures.
2. Change the password so that the hash would take longer to brute force
The situation is similar to 1 – it will take an infinitely long time to brute force the SHA1 hash of a 16-character password.
As a result, a dangerous vulnerability that was known and could be easily exploited even by the Script kiddie was closed with minimal resources.
Case # 2 “We can download OpenVAS without you!”
Object: all routers and switches within the company – more than 350 devices.
Vulnerability: severity level (CVSS Score) – 10.0
CVE-2018-0171 is a vulnerability in the functionality of Cisco Smart Install, the exploitation of which leads to a change in the configuration of the equipment, including a change in the password and its disappearance from a legal administrator, that is, loss of control over the device. Thus, the attacker will gain full access to the device.
Case description: despite the use of several scanners, including commercial ones, none of them showed this vulnerability. Perhaps the signatures at that time were far from ideal for this vulnerability, or the network topology affected, one way or another – a precedent. We, as a company that provides this service for a certain time, have our own database with really dangerous vulnerabilities, which we additionally check.
The customer did not use the Smart Install functionality, so the solution itself, due to the complexity of updating the firmware (even taking into account some of the out-of-date equipment), boiled down to providing the client with a list of IP addresses by which the vulnerable service was disabled by the script.
As a result, a critical vulnerability on the vast majority of network equipment, which could go unnoticed, and in the case of an attack, would lead to a complete shutdown of the entire company, was fixed.
Case # 3 “If someone wanted to, we would have been broken already!”
Object: domain controller, mail server and a numbeZr of other devices / servers / hosts critical for the company
Vulnerability: severity level (CVSS Score) – 9.3
CVE-2017-0144 is a vulnerability in the SMB protocol that allows remote execution of arbitrary code on the server (the WannaCry ransomware was distributed through the group of vulnerabilities, which includes the considered one).
Description of the case: at the start of the provision of services, a critical vulnerability was discovered during scheduled scanning, the only possible recommendation is to install OS updates. The customer agreed on this solution, but the vulnerability remained after the control scan. After the escalation of the situation and a personal meeting with the Customer, it turned out that the reason was the human factor – the task was not performed by a specialist.
Consequences: within several days, as a result of ignoring the task, the user’s workstation received malware that successfully spreads over the network, this vulnerability was exploited, which led to the failure of the domain controller.
As a result, the company incurred heavy losses (infrastructure restoration work took several months).
In the described cases from our practice, we wanted to draw attention to the fact that vulnerability management is a complex and not as straightforward process as it might initially seem. Vulnerability management is not only about scanners and identifying threats critical to the infrastructure, it is a full-fledged management that requires knowledge, experience and sometimes an unconventional approach from specialists, as well as streamlined processes within the company, which are inseparable from the technical part.