In the wake of the Equifax breach, a lot of people are wondering how the theft of personal information occurred and how it could have been prevented. Equifax initially reported that a vulnerability in Apache Struts was used to infiltrate their public-facing web server. Apache Struts has faced its fair share of vulnerabilities with 21 having been discovered since the start of 2016. Which Apache Struts vulnerability was used in the Equifax hack? At DOSarrest we researched current and past Apache Strut vulnerabilities and determined that they likely were not hacked using the new CVE-2017-9805 but likely CVE-2017-5638. Equifax released additional details on Sept 13 th 2017 confirming that the vulnerability involved was CVE-2017-5638. The CVE-2017-5638 vulnerability dates back to March 2017, which is why people in the security industry are now questioning how they could be so far behind in patching this well-known exploit. The two vulnerabilities, CVE-2017-5638 and the recently revealed CVE-2017-9805 are very similar in nature and are both considered Remote Code Execution (RCE) vulnerabilities . How does a RCE vulnerability work and how can they be prevented? A RCE vulnerability is exploited when an attacker crafts a packet or request containing arbitrary code or commands. The attacker uses a method to bypass security that causes a vulnerable server to execute the code with either user or elevated privileges. Such vulnerabilities can be prevented with a two-fold approach to web application security: 1) New vulnerabilities will continually be discovered in any web application framework, and it is the duty of IT teams to keep the software patched. This requires regular audits and patches to vulnerable software. Even the most proactive IT teams will not be able to prevent a so-called zero-day attack by patching alone so more must be done to protect the web server from zero-day vulnerabilities. 2) Since there is always a delay between the time a vulnerability is discovered and when a patch is developed by the maintainer of that product, a means to protect your website from undiscovered zero-day vulnerabilities is needed. Web Application Firewall’s (WAF) that typically rely on signatures are unfortunately at a disadvantage because signatures for existing vulnerabilities in most cases do not match newer zero-day vulnerabilities. If I cannot rely on signature-based WAF options, what can I rely on to protect my business? At DOSarrest our WAF is different. The problem with relying on signatures is that it requires constant updates as new vulnerabilities become known. Instead our WAF looks for sets of characters (such as /}/,/“/, and /;/) or phrases (like “/bin/bash” or “cmd.exe”) that are known to be problematic for some web applications. What makes DOSarrest’s WAF even more appealing is that it is fast. Much faster than signature-based solutions that require high CPU use to match signatures–such matching could result in a measurable impact on latency. With DOSarrest’s WAF there is no increase in latency, and vulnerabilities not yet discovered will still be mitigated. Examples of how the Apache Strut vulnerabilities are performed: For the benefit of more technical users, some sample requests will be analyzed below. The first example represents a normal non-malicious request sent by millions of people everyday and the following two exploit RCE vulnerabilities in Apache Struts: We can note the following characteristics in the exploit of CVE-2017-5638: 1. The Content-Type Header starts with %{(, an incorrect format. 2. The payload contains a java function call, java.lang.ProcessBuilder, that is normally regarded as dangerous. 3. The payload contains both windows and Linux command line interpreters: “cmd.exe” (Windows Command Prompt) and “/bin/bash” (Linux Bash shell/terminal). The RCE vulnerability used to infiltrate Equifax, CVE-2017-5638 exploits a bug in the way Apache Struts processes the “Content-Type” HTTP header. This allows attackers to run an XML script with elevated user access, containing the java.lang.ProcessBuilder.Java.lang.ProcessBuilder is required to execute the commands the attacker has placed within the XML request. CVE 2017-9805, announced September 2017, is very similar to the previous RCE vulnerability. With CVE-2017-9805, we can note the following characteristics: 1. The Content-Type is application/xml with the actual content in the request body matching that of the Content-Type. 2) The payload also contains the java function call java.lang.ProcessBuilder. 3) The payload in this case is Linux specific and calls “/bin/bash -c touch ./CVE-2017-9805.txt” to confirm that the exploit works by creating a file, “CVE-2017-9805.txt”. Are the payloads shown the exact ones used by attackers to obtain data from Equifax? Although some of the commands may have been used together as part of the information gathering process, the actual commands used to obtain the data from Equifax may only be known by the attackers and possibly Equifax or an auditing security team directly involved in the case. The examples show how the vulnerability could be exploited in the wild and what methods might be used, e.g., setting Content-Type and sending an XML file with a payload. These examples do not represent the actual payload used to obtain the data from Equifax. Since the payload itself can be completely arbitrary, an attacker can run any commands desired on the victim’s server. Any action the web server software is capable of could be performed by an attacker, which could allow for theft of information or intellectual property if it is accessible from the hacked server. In the case of Equifax, there was likely an initial vulnerability scan that the attackers used to expose Equifax’s vulnerability to this particular attack. This would have been followed by an effort to determine what files were available or what actions could be performed from the Equifax public-facing web server.At some point the attackers came across a method for accessing personal credit details on millions of Americans and citizens from other countries who had credit checks performed on their identities within the United States. If Equifax had been using the DOSarrest WAF, they could have avoided a costly mistake. Don’t let your business suffer a damaging security breach that could result in you being out of business for good. Talk to us about our services. For more information on our services including our Web Application Firewall, see DOSarrest for more information on Security solutions . Source: https://www.dosarrest.com/ddos-blog/apache-struts-vulnerabilities-and-the-equifax-hack-what-happened/

Read More:
Apache Struts Vulnerabilities and The Equifax Hack, What Happened?