Code Audit Automated Tools
In the previous article we looked at manual code review. While manual code review is an important stage in identifying and fixing potential security flaws, the process is does involve a high amount of overhead. Going through large code bases looking at the start of the review process can require a lot of time.
Automated code audit tools can help reduce some of this workload. These tools can perform either Static Analysis (check the code for well known flaws), or Dynamic Analysis (Run the code and see how it responds to inputs)
Note
You have probably come across some automated code anaysis tools before. Things like pylint1 or eslint can be used to check our source code for common programming errors, formatting mistake etc.
Static Code Analysis
Static code analysis will go through our source files looking for areas where security flaws are commonly found.
This can take some of the workload away from us in the code review stage as it will highlight potentially dangerous functions.
There are a huge number of Static code analysis tools (See the OWASP list for examples) and you may need to use different tools for different languages and frameworks. Recommending a tool is difficult as it can depend on the infrastructure you are analysing. However two useful tools are:
Bandit
Bandit is a security audit tool for Python. Its pretty comprehensive, and can find common flaws based on known security issues.
Lets take a look at Bandit in action. Consider the following code that could be used to allow a user to login to the system.
"""
Check if a password is correct
"""
import hashlib
PASSWORD = "15b29ffdce66e10527a65bc6d71ad94d"
def login(password):
"""
Check if the user specified password matches
the Admin password
"""
hashed = hashlib.md5(password.encode()).hexdigest()
if hashed == PASSWORD:
print("Login Correct")
return True
print("Login Fails")
return False
if __name__ == "__main__":
#Get user input
ipt = input("Enter Password>")
print(ipt)
out = login(ipt)
We Can check for any security warnings using bandit with
env) kali@kali:~/6005/Bandit$ bandit CheckPassword.py
[main] INFO profile include tests: None
[main] INFO profile exclude tests: None
[main] INFO cli include tests: None
[main] INFO cli exclude tests: None
[main] INFO running on Python 3.8.5
[node_visitor] INFO Unable to find qualified name for module: CheckPassword.py
Run started:2020-10-16 16:30:07.563783
Test results:
>> Issue: [B303:blacklist] Use of insecure MD2, MD4, MD5, or SHA1 hash function.
Severity: Medium Confidence: High
Location: CheckPassword.py:15
More Info: https://bandit.readthedocs.io/en/latest/blacklists/blacklist_calls.html#b303-md5
14
15 hashed = hashlib.md5(password.encode()).hexdigest()
16 if hashed == PASSWORD:
--------------------------------------------------
>> Issue: [B322:blacklist] The input method in Python 2 will read from standard input, evaluate and run the resulting string as python source code. This is similar, though in many ways worse, then using eval. On Python 2, use raw_input instead, input is safe in Python 3.
Severity: High Confidence: High
Location: CheckPassword.py:25
More Info: https://bandit.readthedocs.io/en/latest/blacklists/blacklist_calls.html#b322-input
24 #Get user input
25 ipt = input("Enter Password>")
26 print(ipt)
--------------------------------------------------
Code scanned:
Total lines of code: 20
Total lines skipped (#nosec): 0
Run metrics:
Total issues (by severity):
Undefined: 0.0
Low: 0.0
Medium: 1.0
High: 1.0
Total issues (by confidence):
Undefined: 0.0
Low: 0.0
Medium: 0.0
High: 2.0
Files skipped (0):
You can see that Bandit has picked up two potential security issues:
- The use of input. Here wee get a warning that the
inputfunction in python 2 was considered unsafe. - the use of an MD5 hash, which is no longer considered secure.
This gives us a good starting point for refactoring the code to potential security flaws. However we still need to apply some context to the code (are we running python 2 or 3?) to make the correct decision
What have we missed? #banditmistakes
While bandit has picked up the technical flaws, which is a great starting point. There are also some logical errors in the code.
- What Errors can you see
- How Would you fix them
Automated Dynamic Code Analysis
With automated dynamic code analysis, we look at how inputs to the application change its behaviour. This kind of approach is useful for identifying how the program behaves.
Fuzzing is one way of doing this is to send strings of malformed, or malicious data to any user input, and see if the program crashes, or behaves in an unexpected way. This pseudo-random input may include unexpected data types (for example, strings rather than emails, or numbers), random data, potential payloads, use of "bad characters" (such at tabs or spaces), etc.
We can then monitor the response from the server to see how it processes this information. If we start getting error messages, (or our payload activates) then we know the server has potential flaw when handling this type of input.
Tools for Automated Dynamic Analysis
As with the static code analysis tools, there are hundreds to choose from. However, unlike static analysis, as we are dealing with inputs and outputs we don't have the same language or framework specific constraints.
Two useful tools are for general dynamic analysis are: - Burp Suite by portswigger. - OWASP ZAP - wfuzz
Its out of scope for the module to have a detailed look at each of the modules. However, we will have closer look at Burp in the On-Line Lecture.
There are also some tools that can be used for more specific checks include
- Go buster Will scan the website for "hidden" directories
- sqlmap Automated SQL Injection
Burp Suite Introduction
The portswigger acedemy has some fantastic materials on a wide range of topics.
Take a look through the introdcution to Burp Suite to get an idea of what burp can do, and how we might use it for automated analysis.
Automated Vulnerability Scanners
There are also automated tools that can scan your website looking for other well known flaws.
- Nessus is an industry standard for vulnerblity scanning. It will look through your site and generate a report highlighting any CVE
- openvas an opensource project similar to Nessus. The functionality is slightly different, but it is free.
Summary
In this section we have looked at tools for automated code analysis. While these tools are an important part of our process, and can help simplify the code review process. However, while automated tools can to reduce the workload when trying to identify areas for the manual code review. They still require human analysis.
External Reading
-
Disclaimer: I am a Contributor to Pylint. But other python linting tools are available ↩