Using SAST To Prevent Zero Day Vulnerabilities
Brought to you by Gilad David Maayan
What Is SAST?
Static Application Security Testing (SAST), also known as static code analysis, scans an application's source code, bytecode, or binary files for security vulnerabilities. SAST analyzes an application's code patterns, control flow, and data flow, to identify security weaknesses that attackers could exploit, and help developers remediate them.
SAST works by examining source code and looking for patterns that indicate code quality issues or security vulnerabilities. SAST tools model the underlying source code and evaluate it using a set of rules, both predefined and custom rules defined by the user, to identify vulnerabilities.
Why Is SAST Important?
Many organizations understand the need to test software for vulnerabilities, but only do so at later stages of the development process—for example, when the application is already deployed to a testing or staging environment. Any vulnerabilities discovered need to be communicated to the development team, who have already moved on to other features. They need to reopen their source code, discover the bug, fix it, and redeploy a new version. This wastes time for developers, increases costs, and slows down software delivery.
Another way organizations test for vulnerabilities is through penetration testing. Ethical hackers test applications and code, typically while running in production, report any vulnerabilities they find, and provide proofs of concept showing how attackers can compromise systems. While this is a powerful way to find exploitable vulnerabilities, it is not comprehensive (penetration testers can miss some vulnerabilities due to lack of knowledge of the underlying systems), and again, requires a large effort from developers to identify and fix the issues.
Vulnerability scanning or testing after application deployment is crucial, but it is not enough. Organizations must have a way of discovering vulnerabilities much earlier, making it faster and less expensive to remediate them, and reducing the chance that vulnerabilities make it to production in the first place.
SAST tools encourage a “shift left” mindset. Instead of deploying code and waiting for vulnerabilities to be discovered, every time developers compile code and push it through the CI/CD process, or even as they write code in an integrated development environment (IDE), they can continuously scan it with a SAST tool. The SAST tool provides real-time feedback for developers, just like development tools provide feedback on code that is incorrect or fails to compile. With this information at hand, developers can identify and quickly fix vulnerabilities in their coding environment, in a fraction of the time it would take them to resolve the problem when it is discovered after deployment.
Identifying vulnerabilities in early development stages reduces security risks, decreases the development effort required to address security issues, and accelerates software delivery.
What Is A Zero-day Vulnerability?
Zero-day vulnerabilities are unknown security issues that expose software or hardware to malicious attack. What makes these vulnerabilities so dangerous is that attackers can take advantage of them before the system vendor is aware of them, and before a security patch is available.
When attackers discover a zero-day vulnerability, they release a zero-day exploit—malware designed to exploit the vulnerability. If a system is attacked by a zero-day exploit before a patch is available to fix the vulnerability, the attack is virtually guaranteed to succeed.
Perhaps the largest zero-day attack of recent years was Log4Shell. Log4j is a very popular logging library used by Java applications. A vulnerability was discovered that allowed attackers to remotely execute code on any system running Log4j. This led to exposure of millions of high profile business applications and websites to zero-day attacks.
Zero-day Attack Stages
Here are the steps that lead to a zero day attack:
- Developers unknowingly release software or hardware that contains vulnerabilities.
- Attackers discover the vulnerability before developers fix them.
- Attackers create and implement exploit code while the vulnerability is still not addressed.
This period of time, after the availability of a zero-day exploit, but before the release of a patch, is known as the “zero-day window”. In this period, affected systems are completely vulnerable to attack.
- Only after the exploits are available, the vendor provides a security patch.
Even at this time, when a patch is available, there is an additional window of time in which system owners may not be aware of the vulnerability, or may be slow to implement the patch.
Preventing Zero Day Vulnerabilities With SAST
According to research published by the SANS Institute, there are three techniques which can be at least partially effective in detecting zero-day exploits:
1. Statistical Techniques: Algorithms like semantics aware statistic (SAS) use attack profiles from past exploits to detect new ones. The algorithm identifies normal patterns using static code analysis, and identifies anomalies, setting thresholds that determine whether they are malicious or not.
2. Signature-based Techniques: A “signature” is a mathematical representation of a binary file, which can be used to identify known malicious files. It is traditionally thought that signature techniques are ineffective against zero days. But according to the SANS research survey, some signature-based techniques can be effective against polymorphic worms:
- Content-based signatures compare the content of a packet to the content of known malicious packets. A new exploit might have a similar implementation to previous ones, making it possible to detect.
- Semantic-based signatures analyze the meaning of expressions within the code, looking for rules that can identify the relationship between code elements. They make it possible to produce a generalized signature from only a small number of inputs. For example, based on a few suspicious inputs from an organization’s honeypots or monitoring systems, it might be possible to identify a new exploit.
3. Behavior-based Techniques: Behavior-based techniques do not consider the underlying code—rather, they analyze the behavior of a running program. Using techniques such as Hidden Markov Models (HMM), these algorithms can analyze past and current interactions and predict a future state. The goal is to detect malicious software that is in early attack stages and has not cause damage yet, but is likely to do damage at a later point in time.
How SAST Can Help
Many SAST tools include both statistical and semantic analysis techniques (#1 and #2 above). As such, depending on their implementation, they might be useful in detecting certain types of zero-day exploits.
However, an important caveat is that it must be possible to analyze the source code of the exploit. This is the case for script-based exploits, or those that are implanted within an organization’s development environment—but not for many executable-based exploits.
The behavioral technique (#3) is traditionally not covered by SAST, because it relies on interacting with a running application. However, many vendors are offering hybrid solutions known as interactive application security testing (IAST), which combines static analysis with dynamic analysis. IAST solutions could potentially use all three techniques and thus might have the best chance of identifying an unknown, zero-day threat.
Conclusion
SAST solutions are widely agreed to be an important part of a secure software development lifecycle (SDLC). While they are by no means a guarantee or a sufficient protection against zero-day attacks, they can help in detecting unknown threats.
By combining SAST with other protective measures, in particular patch management, threat hunting, active monitoring and dynamic application security testing (DAST), organizations can turn the severe threat of zero-day vulnerabilities into a manageable risk.
Image: Vecteezy
You Might Also Read:
How IAST Improves Application Security & Six Steps to Effective Deployment: