Top 15 Software Security Weaknesses Or Why are there so many zero days (Part 3)

Zero Day Vulnerabilities

Zero day vulnerabilities are merely software bugs that affect the security of applications.? ? More software = more bugs.? MITRE has studied the correlation between zero-day/security flaws and the programming and design errors that lead to them.

This is the last of three articles on the most common reasons that zero days find their way into software.? ? If you have not, please start with Part 1 and Part 2. it sets the scene.

5)? Out-of-Bounds Read

An out-of-bounds read occurs when your software reads data past the end, or before the beginning, of the intended buffer.? This can allow attackers to read sensitive information from other memory locations or cause a crash.?

A crash can occur when the code reads a variable amount of data and assumes that a marker exists to stop the read operation, such as a NULL (0x00) terminating a string. The expected marker might not be located in the bounds of allocated memory, causing excessive data to be read, leading to a segmentation fault or a buffer overflow.?

The software may modify an index or perform pointer arithmetic that references a memory location that is outside of the boundaries of the buffer. A subsequent read operation then produces undefined or unexpected results.

Mitigation: Always assume that input is malicious. ? ? This is going to be a repeating theme for the balance of this article. ? Only accept inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

4)? Improper Input Validation

An interesting follow-on from the last software design weakness, MITRE identifies and calls out improper input validation as one of their “Common Weakness Enumeration” (CWE) entries: CWE-20.? ? Input validation is so important because lack of it leads to so many other problems.

MITRE enumerates several input attributes that should be check every time:

• Specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
• Implied or derived quantities, such as the actual size of a file instead of a specified size
• Indexes, offsets, or positions into more complex data structures
• Symbolic keys or other elements into hash tables, associative arrays, etc.
• Well-formedness, i.e. syntactic correctness - compliance with expected syntax
• Lexical token correctness - compliance with rules for what is treated as a token
• Specified or derived type - the actual type of the input (or what the input appears to be)
• Consistency - between individual data elements, between raw data and metadata, between references, etc.
• Conformance to domain-specific rules, e.g. business logic
• Equivalence - ensuring that equivalent inputs are treated the same
• Authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data

Undoubtedly there could be complete book chapters written about thorough input validation. It is important and should be a part of the code inspection process.

3) SQL Injection

Without sufficient input validation, SQL syntax introduced in user inputs can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of commands.

SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

Related: The world is moving on from universal use of SQL based databases to a class of databases known as NOSQL, the most common is probably MongoDB.? ? You might think that use of these newer databases will protect you from injection attacks, that is not the case. While these databases are immune from SQL injection, they are just as susceptible to other forms of input injection attacks.???

2)? Cross-site Scripting Attacks

Cross-site scripting (XSS) vulnerabilities occur when:

Untrusted data enters a web application, typically from a web request.

The web application dynamically generates a web page that contains this untrusted data. ? During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.

A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.? Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.

This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

There are three main kinds of XSS:

• Type 1: Reflected XSS (or Non-Persistent) - The server reads data directly from the HTTP request and reflects it back in the HTTP response. Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces a victim to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the victim, the content is executed by the victim's browser.
• Type 2: Stored XSS (or Persistent) - The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.
• Type 0: DOM-Based XSS - In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection. DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as Javascript that performs sanity checks on a form before the user submits it. If the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML), then DOM-based XSS is possible.

Once the malicious script is injected, the attacker can perform a variety of malicious activities. The attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. The attacker could send malicious requests to a website on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim's account on that web site. Finally, the script could exploit a vulnerability in the web browser itself possibly taking over the victim's machine, sometimes referred to as "drive-by hacking."

In many cases, the attack can be launched without the victim even being aware of it. Even with careful users, attackers frequently use a variety of methods to encode the malicious portion of the attack, such as URL encoding or Unicode, so the request looks less suspicious.

Mitigations:

Use a vetted library or framework that makes this weakness easier to avoid. Examples of these are Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.? For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on the output :

• HTML body
• Element attributes (such as src="XYZ")
• URIs
• JavaScript sections
• Cascading Style Sheets and style property

OWASP has created a XSS Prevention Cheat Sheet? with more details on the types of encoding and escaping that can help prevent these weaknesses. I strongly recommend that you download it and make it required reading for your developers.

1)? Out-of-Bounds Write (Heap and Stack corruption)

This is an old one, but MITRE still ranks it as number 1.? ? You might think that it doesn’t really happen anymore, and if it does, it is done by some obscure software company that doesn’t worry too much about software quality.? ? How about Google? (Insert your own personal opinions about them here).? ? CVE-2021-21220 is just such a case.??

The official title is “Insufficient validation of untrusted input in V8 in Google Chrome prior to 89.0.4389.128 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.” ? ? There is the big gotcha, insufficient validation of untrusted input. ? ? Kind of a repeating theme this week.? ? This particular CVE was not only present in Chrome, but in the Chromium library on which Microsoft Edge is based as well.

Bottom Line

As long as there are humans developing software, there are always going to be bugs in that software.? ? As long as there are bugs in software, there will be zero day exploits.? ? As long as there are zero day exploits, networks will be vulnerable.

If you are in the software development business, don’t skimp on the code inspection (I know, it is boring and painful. ? I hate it too). ? ? If you are responsible for the security of a network, it is critical to monitor CISA and other organizations that track and inform about zero day exploits so that you can take appropriate action.