Being curious

25 Sep 2019

Code Injection Attacks

Copy of a paper I wrote as part of my postgraduate studies on Code Injection Attacks.

Executive Summary

Code injection attacks are a way of introducing unintended code into a computer program (Mitropoulos & Spinellis, 2017). Attackers can insert code by exploiting vulnerabilities in program input handling. Programs exist to take input, process it, and provide output. This gives significant opportunities for code injection attacks to be used. Due to the scope code injection attacks are considered one of the most damaging types of attacks (Mitropoulos & Spinellis, 2017).

Significant code injection vulnerabilities are being regularly found. These include SIGred (Tzadik, 2020) and CableHaunt (Krog et al., n.d.), Ripple20 (JSOF, n.d.) & CVE-2020-5902 found in F5 BIG-IP appliances (Positive Technologies, n.d.). Losing data from an incident enabled by failure to address these will leave an organisation with a significant clean-up bill and ongoing damage (Equifax, 2017).

When reviewing and understanding code injection vulnerabilities inside an organisation there are several risk factors to consider. First of these is there is active security research work being done. Second is to that organisations need to be online to function – but by being online the organisation exposes itself to attack by multiple parties. Last is it is not always clear where an organisations weakness may lie. Products may include vulnerabilities that were introduced by poor practices in upstream suppliers. Last and most importantly these things are outside of an organisations control. Simply refusing to act upon them will not make them go away.

There are several key recommendations to address code injection vulnerabilities. First of these is to be prudent when designing and operating systems. Place things online cautiously, layer security controls to remove the impact of single points of compromise and actively patch and manage vulnerabilities. Second is to use follow secure coding standards and use modern memory safe languages when doing development work. Last is practice and improve upon incident response.

Overall, it’s key to understand that code injection vulnerabilities do create risk for all businesses. Business stakeholders need to understand that this class of vulnerability exists, it can be used to compromise them and that cleaning up from a security incident can cost significant amounts of time and generate considerable brand damage (Equifax, 2017).

Code Injection Attack Overview

Code injection attacks are a way of introducing unintended code into a computer program (Mitropoulos & Spinellis, 2017). Attackers can insert code by exploiting vulnerabilities in program input handling. Injection based attacks are part of multiple items on the OWASP Top 10 Web Application security risks (OWASP, n.d.).

Programs exist to take input, process it, and provide output. This gives significant opportunities for code injection attacks to be used. Code injection attacks can be loosely grouped into two main areas – binary and source code attacks. These are summarised below.

Binary Code Attack

Binary code attacks are where machine code is inserted into a compiled running application. The application executes the injected instructions as if it was part of the initial executable. Examples include (Younan et al., 2012):

  • Stack based buffer overflows
  • Heap based buffer overflows
  • Dangling Pointer references

Source Code Attack

Source code attacks are where new values are inserted into a running application. These attacks differ from binary code attacks by using values or source code instead of machine code. The new values provided cause the application logic to behave in an unintended way. Examples include (Alnabulsi et al., 2018):

  • Cross site scripting (XSS) attacks
  • SQL injection attacks
  • Shell injection attacks
  • Remote or local file inclusion attacks

These attacks are either targeted at dynamic languages (i.e. Javascript, PHP) or domain specific languages (i.e. SQL, XML).

SIGRed

SIGred is a vulnerability identified inside the Windows DNS service (Tzadik, 2020). DNS is used to translate human friendly names (i.e. www.google.com) into network addresses. A summary of the process is shown below.

DNS resolution process

When using the SIGRed vulnerability an attacker will control a client and DNS server. The attack works by using a client to lookup a malicious DNS record. The malicious record is not handled by the DNS resolver correctly. This can cause the DNS resolver to either crash or execute arbitrary code included in the malicious record. The nature of DNS means it is placed in exposed network locations where it is straight-forward for attackers to access.

Cablehaunt

Cablehaunt is a vulnerability identified in cable modems using Broadcom processors (Krog et al., n.d.). The attack targets the spectrum analyser service which is normally used to troubleshoot radio frequency issues. Researchers found the spectrum analyser service implementation failed to correctly process input received.

The vulnerability allows for an attacker to insert and run binary code on the modem. The vulnerability exists in underlying components used as part of the modem. This means the vulnerability impacts multiple types of devices. The flaw being in the modem supply chain means each device manufacturer needs to develop and release a fix.

Ripple20

Ripple20 is the name for 19 vulnerabilities found in a widely used software library developed by Treck, Inc (JSOF, n.d., p. 20). The vulnerable library is confirmed as used in products from over 26 vendors. The vulnerabilities exist in multiple areas of the Treck software library and support multiple types of code injection. The flaw being in the supply chain means each device manufacturer needs to develop and release a fix.

CVE-2020-5902 (F5 BIG-IP appliances)

CVE-2020-5902 is a code injection vulnerability found in a management interface of F5 BIG-IP devices (Positive Technologies, n.d.). The exploit works by sending a crafted message to the BIG-IP traffic management user interface (TMUI). Due to improper input handling in the BIG-IP device the command inserted in the crafted message is executed. The management interface is not designed to be placed in public networks.

Risk Factors

When evaluating the risk of code injection attacks, it is worthwhile to consider several factors.

Security researchers actively review products for vulnerabilities (Edgar & Manz, 2017). The SIGred, Cablehaunt, Ripple20 & CVE-2020-5902 vulnerabilities were identified by researchers. Work done by researchers can have a positive or negative impact. From a positive perspective researcher can identify and disclose vulnerabilities for them to be fixed. From a negative perspective vulnerability found can be actively used to exploit targets or sold for profit. The EternalBlue vulnerability was actively used by the NSA against targets until it was stolen during a security incident (Greenberg, 2019).

In neutral terms Security Researchers will share knowledge and contribute to the ongoing development of tools. Like the vulnerabilities themselves these can be put to dual use. Tools like Metasploit https://www.metasploit.com/ or instructions to exploit CVS-2020-5902 (Shivam, 2020) can be used to identify and resolve these vulnerabilities. Alternatively, they can be used by malicious parties to exploit targets.

Society has become heavily dependent on being connected to the internet (Reed, 2019). In the rush to be online multiple things will be exposed to the public internet. Unfortunately, items placed online will be identified, scanned for accessible services, and catalogued for later access or exploitation. Tools like Shodan will catalogue what is accessible via the internet. As at drafting of this report there are still over 200 devices publicly accessible which may be vulnerable to CVS-2020-5902 (F5 BIG-IP).

TMUI services on public internet

Products will incorporate software from multiple sources. An upstream vulnerability can affect an application leaving the user open to compromise (Kaczorowski, 2020). The CableHaunt and Ripple20 vulnerabilities discussed are examples of these. Understanding exposure from the software supply chain is not straight-forward. Getting fixes requires multiple parties to act in concert.

Due to the combination of factors code injection attacks are being found and used. Use of these with ill intent will cause security incidents. The following section outlines a public incident affecting Equifax.

Equifax Case Study

From May to July 2017 Equifax systems were compromised and personally identifiable information (PII) was stolen (Equifax, 2017).

Malicious actors obtain access to Equifax ACIS system via an Apache Struts vulnerability (CVE-2017-5638). This allowed attackers to execute commands using crafted web requests (Mitre, 2018). Example shown below (includes request for site to execute ‘whoami’ command’).

CVE-2017-5638 being compromised

Attackers used this access to gain a foothold in Equifax infrastructure. From there they were able to gain access to customer databases and steal sensitive customer information.

Equifax Incident summary

Items that contributed to Equifax failing to prevent the incident were:

  • Failure to address a known vulnerability (CVE-2017-5638) inside an appropriate timeframe. This in part came Equifax lacking an understanding of all places Apache Struts was used in the domain.
  • Failing to maintain monitoring infrastructure which may have detected the vulnerability.
  • Failing to respond to the incident in an effective manner. It took 117 days after detecting the break for Equifax to notify the public. The response when provided was insufficient to address the severity of the breach (RBS, 2017).

Recommendations

Recommendations on how to mitigate the risk of being affected by code injection attacks are summarised below. Overall as part of any solution design it’s important to remember that perfection has been reached when there is nothing left to take away (Callon, 1996).

Allowing connectivity to a network service over the internet or publicly accessible network should be done with caution and only by necessity. Connecting services like remote desktop protocol (RDP) to the internet is consider bad security practice (Constantin, 2020). Despite this as at writing of the report over four million exposed RDP services have been observed by shodan.io:

RDP Services on Internet

Ensure prompt patching of operating systems and applications (ACSC, 2020). Also have a solid vulnerability management program. These steps will ensure known vulnerabilities are identified and mitigated in a timely manner. By removing exposure to known vulnerabilities opportunities for attackers is similarly reduced.

Adopt secure coding standards and guidelines as part of development work (Bellairs, 2019). Where possible aim for the use of memory safe languages (Younan et al., 2012). Also use static and dynamic analysis tools as part of software development (Mitropoulos & Spinellis, 2017). These automate the finding of known software vulnerabilities during development.

Taking these approaches removes the likelihood of injection attacks being introduced.

Understand the software supply chain for key assets in use. Individual software components will normally not be written by scratch from a single supplier. They will instead utilise multiple third-party components (Kaczorowski, 2020). A vulnerability in these components may not be immediately obvious to a vulnerability scanner.

Finally have a well-developed and practiced incident response plan. Understand that at some point an attack will be successful. Being able to respond well can see an organisation return quickly to business (Basford, 2020). Responding poorly will see an organisation suffer extended impacts at multiple levels (RBS, 2017).

Conclusions

Through writing this report several key conclusions have been drawn.

It’s important for an organisation to take a wider view when managing security risk. Basic security controls need to be in place before applying mitigations against specific vulnerability classes. Appropriate designs need to be deployed, patch and vulnerability management underway and incident detection and response capability needs to be in place. Attackers will focus where an organisation is weakest.

Software supply chain is a hard but important problem to address. Individual systems will normally incorporate software from multiple sources. Where a vulnerability is found in upstream components the resulting exposure can be widespread (JSOF, n.d., p. 20) (Krog et al., n.d.). Organisations need to take steps to gain transparency in this area (Kaczorowski, 2020). Where they can’t the associated devices need to be trusted accordingly.

Solutions for code injection attacks do exist. There is no need for an organisation to try and roll their own (Mitropoulos & Spinellis, 2017). Secure coding standards exist, there are memory safe languages and tools available to find these types of vulnerability. While with security nothing is fool proof, adopting these measures will raise the attack difficulty to thwart all but the most determined adversary.

Last is it’s important for people to be aware of this vulnerability class and understand what is possible. While what an attacker does may appear to be ‘magic’, it is rooted in well understood practices and capabilities. While significant compromises are unlikely, when they do occur cleaning up from them can be disastrous (Equifax, 2017).

References