Tag Archives: Equifax

Have you patched these top 10 routinely exploited vulnerabilities?

16 May 2020

On Tuesday, CISA published the alert (AA20-133A) on the „Top 10 Routinely Exploited Vulnerabilities“(1). A day later, Zeljka Zorz raised the absolutely legitimate question „Have you patched these top 10 routinely exploited vulnerabilities?“(2) on HELPNETSECURITY.

A query against the NIST NVD and the Exploit-DB shows a gloomy picture:

Top 10 Exploited Vulnerabilities

Top 10 Exploited Vulnerabilities

For the red highlighted vulnerabilities the exploit was available at the day of publication in the NVD. For the green highlighted vulnerabilities the exploit was published shortly after the vulnerability. So, the question should be:

How fast did you patch these top 10 routinely exploited vulnerabilities?

These are telling examples and they are not isolated:

Exploit Publication Date relative to CVE Publication Date

Exploit Publication Date relative to CVE Publication Date

The data from 2013 – 2019 for critical vulnerabilities show:

  • 41% of exploits were published before or at the same day the CVE was published, and
  • 43% of Exploits were published in the range between 10 days before and 10 days after the CVE.

Time is crucial in cyber space operations. In high risk domains, critical vulnerabilities should be patched at least 24 hours after the patch is available. If a vendor cannot provide a patch in time mitigting measures should be applied, in the worst case, systems must be removed from the internet.

Remind the Equifax case (CVE-2017-5638) from 2017.

Have a good weekend.

References

  1. CISA. Top 10 Routinely Exploited Vulnerabilities [Internet]. National Cyber Awareness System. 2020 [zitiert 16. Mai 2020]. Verfügbar unter: https://www.us-cert.gov/ncas/alerts/aa20-133a

  2. Zorz Z. Have you patched these top 10 routinely exploited vulnerabilities? [Internet]. Help Net Security. 2020 [zitiert 14. Mai 2020]. Verfügbar unter: https://www.helpnetsecurity.com/2020/05/13/routinely-exploited-vulnerabilities/

Mean Time to Hardening: The Next-Gen Security Metric falls short in tackling the patching problem

12 January 2020

In report “Mean Time to Hardening: The Next-Gen Security Metric”,(1) published at 12/30/2019 on ThreatPost, Richard Melick proposes a new metric MMTH (Mean time to Hardening) to tackle the patch problem. I like the 24/72 MTTH approach. But when it comes to attacks of APTs on critical infrastructures this approach is from my point of view not effective.

Let me illustrate this with an example. CVE-2017-5638, a remote command execution vulnerability in the Apache Struts framework, was used in the Equifax attack (2) in 2017. In the case of remote command execution vulnerabilities, especially if the systems are operated in the DMZ, the 24/72 MTTH approach is the best strategy to survive. But let us look on the timeline.

NVD Exploit-DB Exploit-DB
CVE-2017-5638 EDB-ID 41570 EDB-ID 41614
Published NDV Published Exploit-DB Published Exploit-DB
3/11/2017 3/7/2017 3/15/2017

Exploit 41570 was published 4 days before the CVE was published. The 24/72 MTTH strategy will fail in this case. Exploit 41614 was published 4 days after the CVE was published, so the 24/72 MTTH strategy is successful.

Figure 1

Figure 1

This is not an isolated case. Between 2013 and 2019 56% of the exploits were published before or at the same day the vulnerability was published in the NVD. For mapping the exploits in the Exploit-DB to the CVEs the NVD reference map for the Exploit-DB (3) is used. Figure 2 shows the details in the range 30 days before and after the CVE publication date.

Figure 2

Figure 2

Figure 3

Figure 3

34% of the exploits for Remote Code/Command Execution (RxE) vulnerabilities like CVE-2017-5638 or CVE-2017-0144 (WannaCry) were published before or at the same day the vulnerability was published. Figure 4 shows the details. RxEs are selected from the NVD as follows: CVSS V2.0: Attack Vector: Network, Attack Complexity: Low + Medium, Authentication: None, Loss of Integrity: Complete, Keywords “remote code execution” or “exec arbitrary”.

Figure 4

Figure 4

So, the 24/72 MMTH approach falls short if the exploit is published before the vulnerability.

Please keep in mind that we only investigated published vulnerabilities and exploits. We can expect, that many yet unpublished, and unused, vulnerabilities exist in the arsenals of the APTs.

In the case of critical infrastructures, we are well advised to invest in solutions which increase the resilience against cyber-attacks. A simple Apparmor profile would probably have prevented the attack on Equifax. Whitelisting solutions should be considered in environments where industrial control systems are operated. This makes the 24/72 MTTH approach to patching not obsolete. We just buy time.

Have a great week.

References

  1. Melick R. Mean Time to Hardening: The Next-Gen Security Metric [Internet]. threatpost. 2019 [cited 2020 Jan 12]. Available from: https://threatpost.com/mean-time-hardening-next-gen-security-metric/151402/
  2. Brook C. Equifax Confirms March Struts Vulnerability Behind Breach [Internet]. threatpost. 2017 [cited 2020 Jan 12]. Available from: https://threatpost.com/equifax-confirms-march-struts-vulnerability-behind-breach/127975/
  3. NIST NVD. CVE – CVE Reference Map for Source EXPLOIT-DB [Internet]. [cited 2020 Jan 12]. Available from: https://cve.mitre.org/data/refs/refmap/source-EXPLOIT-DB.html

Concerns about using open source libraries from an IT security point of view

18 December 2017

Some days ago I participated in a discussion about the necessity of using open source libraries in industrial software development and the data scientist workbench. IT security is often perceived as spoil sport in such discussions …

To be honest, I like open software. I prefer for example Firefox on Windows 10 because the configuration of Edge is really annoying. However, when it comes to the use of open software libraries in scientific or industrial software development projects or by data scientists I have two major concerns:

1. I have just no clue what the open software libraries do in addition to their intended use.

This sounds a bit paranoid. The question is:

Can we make sure, that no malicious code snippets are hidden in an open software library which send the company’s secrets to a cyber criminal’s command and control server, or which encrypt all data?

In my opinion this is not possible. Reviewing e.g. the 300 thousand lines of code of the OpenSSL-1.0.2 project is a herculean task, which has to be repeated for every patch and release. We can automate the software review process with advanced code analyzers. With such analyzers, we can make sure that open source code has no or few critical errors. But analyzers cannot find malicious code snippets, they just make sure that such snippets cause no critical errors during program execution.

Advanced Persistent Threat (APT) solutions may detect malicious behavior. But when a developer or data scientist includes open software into his code, the threat type changes from external to insider threat, thus APT solutions are no longer effective.

Eventually, we have to trust the developers of open software. Thus, the use of open software depends largely on the risk appetite of an organization.

2. I have no idea how to fix vulnerabilities in software which uses open software libraries.

Firefox gets security patches immediately after vulnerabilities are published. For example, the remote code execution vulnerability CVE-2017-7827, published 11/15/2017, was patched on the morning of 11/17/2017. When I logged in to my Linux box in the evening, even a patch for the Firefox ESR version was installed.

The OpenSSL-1.0.2 library mentioned above can be used potentially in many applications, in the worst case, some of them may be connected directly to the internet. The developers of Firefox take care of security bugs in this library. Who cares in the case of self-developed software? And how fast? Just remember the Equifax data breach some months ago. The reason for this really costly data breach was an unpatched vulnerability in the Apache Struts framework …

The focus of open software developers is innovation. Thus, the use of open software will be a major driver in the digital transformation, and we should foster this use to stay at the cutting edge of digital transformation.

Nevertheless, we must be aware of the risks of this use and take proper precautions for their mitigation.

Have a great week.

Congress hearing brings light into the Equifax darkness – Trust in the results of vulnerability scans a possible cause for the Equifax data breach?

8 October 2017

On October 3rd, 2017 a hearing titled “Oversight of the Equifax Data Breach: Answers for Consumers.” was conducted by the Subcommittee on Digital Commerce and Consumer Protection of Committee on Energy and Commerce of the 115 U.S. congress.

Sarah Buhr’s report “Former Equifax CEO says breach boiled down to one person not doing their job” posted on October 3rd, 2017 on TechCrunch gives a good summary of the hearing results.

And a surprisingly plain cause for the data breach:

‘“The human error was that the individual who’s responsible for communicating in the organization to apply the patch, did not,” Smith, who did not name this individual, told the committee.’

To be honest, this sounds somewhat too easy.

In the witness statement of Mr. Smith one reads:

[1] “On March 9, Equifax disseminated the U.S. CERT notification internally by email requesting that applicable personnel responsible for an Apache Struts installation upgrade their software. Consistent with Equifax’s patching policy, the Equifax security department required that patching occur within a 48 hour time period.

[2] “We now know that the vulnerable version of Apache Struts within Equifax was not identified or patched in response to the internal March 9 notification to information technology personnel.”

[3] “On March 15, Equifax’s information security department also ran scans that should have identified any systems that were vulnerable to the Apache Struts issue identified by U.S. CERT. Unfortunately, however, the scans did not identify the Apache Struts vulnerability. Equifax’s efforts undertaken in March 2017 did not identify any versions of Apache Struts that were subject to this vulnerability, and the vulnerability remained in an Equifax web application much longer than it should have.”

[4] “The company knows, however, that it was this unpatched vulnerability that allowed hackers to access personal identifying information.”

From [1] we learn that Equifax has a good vulnerability management process in place.

From [2] and [3] we learn that Equifax’s vulnerability scanner did not find the systems with the vulnerable version installed, although the company knew that the vulnerable Apache Struts framework was installed on some systems.

There are many reasons for this. Just two examples:

  1. Vulnerability scanners must be updated regularly to keep pace with the threat market. But there is often a gap between the release of a scanner update and the disclosure of a vulnerability.
  2. Even up-to-date vulnerability scanners provide no 100% detection. In addition, the results are often somewhat puzzling.

From my point of view, the trust in the results of the vulnerability scanners is the cause for the data breach. Because of the gap between the release of a scanner update and the disclosure of a vulnerability an up-to-date asset repository, at least for the systems facing the internet, is of desperate need for fast identification of vulnerable systems.

The reduction to a human error is just too plain. This sounds more like a systematic error. And provides some interesting food for thought for the next week.

Have a great week.

Critical vulnerabilities require immediate action – How to prevent Equifax like attacks

23 September 2017

Critical Vulnerabilities are

  • exploitable from the network (Access Vector: Network),
  • require only low or medium skills to exploit (Access Complexity: Low or Medium),
  • require no authentication (Authentication: None),
  • cause great damage (Severity: High), and
  • allow remote attackers to execute arbitrary code on the victims’ computer

Among the vulnerabilities with CVSS vector (AV:N/AC:L/Au:N) or (AV:N/AC:M/Au:N) which cause great damage the last property makes the difference.

The infographic below shows that the number of critical vulnerabilities (320) is very small compared to the total number of vulnerabilities in 2016.

Critical Vulnerabilities 2016

Critical vulnerabilities 2016. Click to enlarge.

Nevertheless, immediate action is required because the reach of attacks is technically unlimited if critical vulnerabilities can be exploited.

Once an attacker has exploited a critical vulnerability in the DMZ he is able to execute arbitrary code on this computer. With this, he can probe the network for other computers with critical vulnerabilities or leverage Windows built-in weaknesses, configuration issues, and tools to explore the network until he finally gets to a computer which has a connection across a firewall to the company network.

Both, NotPetya and WannaCry exploited critical vulnerabilities. While WannaCry was just annoying, NotPetya caused multi-million dollar damage in companies across the world.

Mitigation

The TEAM approach for handling risks shows the direction for dealing with critical vulnerabilities.

Transfer: No insurer will take the risk because in the case of a critical vulnerability on a server in the DMZ both the probability of occurrence and the impact are high.

Eliminate: Is not possible, because this will result in loss of business.

Accept: No option because the probability of occurrence and the impact are high.

Mitigate: Patching is the only possible response in this case. Isolation of the system from the network will result in loss of business.

Urgency

Under normal conditions, patches are available at the time of disclosure.

Rule: Critical vulnerabilities should be patched faster than exploits show up on the market.

With this, immediate action is required because very often exploits are available yet at the time of disclosure. In addition, we cannot expect that only ethical hackers publish vulnerabilities.

Equifax

Critical Vulnerabilities Mitigation Process

Critical vulnerabilities mitigation process.

In the Equifax attack the critical vulnerability CVE-2017-5638 in the Apache Struts framework was used. A patch was available at the time of disclosure but apparently not applied.

Patching the Apache Struts framework is a challenging job.

Firstly, it is a challenge to identify the systems with the vulnerable framework installed.

Secondly, patches must be carefully tested prior implementation to avoid business loss.

Finally, the patches must be implemented manually because automated patch management is not available.

Thus, an up-to-date asset repository, a current QA system, and actual automated test routines are required to get the job done in the required short time frame.

To be honest, the Equifax attack remains a mystery for me. The IT shop of a billion dollar company should be able to deal with critical vulnerabilities in the required short time. Perhaps someone simply underestimated the risk.

For more details on the Equifax attack see Steven Bellovin’s post Preliminary Thoughts on the Equifax Hack published at CircleID.

Have a great weekend.