Audit Code
Introduction
Code auditing is the practice of going through the source code of software to ensure that specific rules are respected. The audit can have a legal purpose, or ensure the security of the software by testing its vulnerability, or looking for bugs.
Every issue detected is mapped to a CWE, which stands for Common Weakness Enumeration, which describes in more generic terms the vulnerability. The CWE is part of a list and is indexed by its identifier. The CWE list is maintained by the MITRE corporation.
A severity label is often attached to the issue so that at first sight the user can see the seriousness of a vulnerability. In redpesk, the severity is expressed using the following values, in order of increasing severity:
- Unknown
- Info
- Low
- Medium
- High
- Critical
Analysis tools report everything that they find to be an issue, based on a set of rules that the tool compares against the code being tested. Not everything reported by the tools has to be considered as a security flaw. That’s what the severity is for and the user decides from which severity classification the report is a security flaw. In redpesk, a vulnerability is considered a failure as soon as the severity level is higher than Info.
As a whole, each vulnerability is precisely described by the following bundle of values:
- severity
- CWE identifier
- CWE description
- vulnerability context
- File name
- Line
- Column
- Code responsible for the vulnerability
Analysis Tools
The redpesk environment allows the user to audit its source code, based on several tools whose output follows a standard. Each one of these tools is specific to a programming language.
This section will go through the auditing tools registered to redpesk.
Gosec
Gosec is a Golang security checker which aims to inspect source code by scanning the Golang AST (Abstract Syntax Tree).
The flaws that gosec checks include scanning for hardcoded authentication credentials, SQL query flaws, and unsafe usage of data. This unsafe data usage includes integers, blocks, command execution, temporary files, and more. The tool also includes a blacklist of protocols that are known to be flawed or weak, such as DES, RC5, MD5, and SHA1.
Gosec is coded in Golang and is licensed under the Apache License 2.0.
Gosec source code can be found here
Flawfinder
FlawFinder is a C and C++ code auditing tool which aims to find certain security holes in the area of buffer overflow. To do this, it examines the source code and locates functions in its function database that are considered dangerous.
It then uses this same database to assign a risk level to each function found.
Flawfinder is coded in Python, and was developed by A. Wheeler. It is licensed under the GPL.
Flawfinder source code can be found here.
Usage
This section will present how to use auditing tools in redpesk. Two ways of proceeding will be studied. One using the Web User Interface, the other using the redpesk client tool rp-cli.
Before proceeding a code auditing, you will need to setup correctly an application and launch at least one build. If you are not yet familiar with the redpesk environment, please follow the Web User Interface tutorial to build your first application, or if you would rather use rp-cli please follow its dedicated section.
Web-UI
Once you have successfully built your application, go on the application build tab. There it will be possible to launch an audit based on the latest successful application build. To do so, click on the SECURITY button and select which tool you want your code to be analyzed with. In this tutorial, a C/C++ application is taken as an example, so Flawfinder will be used to perform the code auditing.
You can order the security flaws by their severity by clicking on the arrows up and down next to Severity at the top of the table
The audit result table gathered the values previously presented in this section.
The default audit tools that will be used while performing later application audits can be selected in the application settings.
Thus when launching an application audit, the default audit configuration will be applied.
Default audit configuration is also used as soon as Automatic audit after build is invoked. This option can be activated in the application settings view, and aims to launch the application audit right after a successful build, with the default audit configuration you defined in the application.
In order to keep the logs outside of redpesk environment, the logs can be downloaded under a json format. To do so, go in the application Security Tests tab, then in the far right of the table, column Logs, click on the file icon of the desired audit where you want to keep the logs, as shown in the screenshots down below.
rp-cli
Once you have successfully built your application, you can retrieve the list of auditing tools by typing the following command.
> rp-cli applications audits tools -v
Name: gosec
Version: 2.9.6
Summary: Golang security checker
Language: Go
Type: code
Category: Source Code Analysis
Name: flawfinder
Version: 2.0.19
Summary: Examines C/C++ source code for security flaws
Language: C/C++
Type: code
Category: Source Code Analysis
Auditing tools are stored under the Category Source Code Analysis. For each tool you can get a brief Summary, the tool Version that will be used for future audits and the programming language the tool is meant to analyze.
In this tutorial, a C/C++ application is taken as an example, so Flawfinder will be used to perform the code auditing.
# Launch code auditing with Flawfinder
> rp-cli applications audit canbus-binding --tool flawfinder
-- Application audit requested by user --
Checking the specified audit tools... [OK]
Auditing the "canbus-binding" application...[OK]
# Change default application audit configuration to include flawfinder
> rp-cli applications update canbus-binding --audits flawfinder
-- Application update requested by user --
Processing the distribution(s) settings... [OK]
Update of "canbus-binding" application... [OK]
# Then you can launch audits without specifying the auditing tools
> rp-cli applications audit canbus-binding
-- Application audit requested by user --
Checking the specified audit tools... [OK]
Auditing the "canbus-binding" application...[OK]
Once the application audit is successful, the following commands can be used to retrieve the application audits
# List application audits
> rp-cli applications audits list canbus-binding
ID App. Status Success/Fail/Skip/Total
1 canbus-binding stable 14/173/0/187
2 canbus-binding stable 14/173/0/187
# Get the get audit result based on its ID
> rp-cli applications audits get 1
ID App. Status Success/Fail/Skip/Total
1 canbus-binding stable 14/173/0/187
# Get severity overall report from an audit (verbose option)
> rp-cli applications audits get 1 -v
ID: 1
Application: canbus-binding
Project: audits
Status: stable
Success: 14
Fail: 173
Skip: 0
Total: 187
Creation time: 2022-04-27 15:49:50.007482 +0000 UTC
Update time: 0001-01-01 00:00:00 +0000 UTC
User launcher: redpesk
[Detailed results]
Type: code
Overall results:
Info: 14
Unknown: 0
Low: 160
Medium: 1
High: 12
Critical: 0
Total: 187
Tool: flawfinder
Info: 14
Unknown: 0
Low: 160
Medium: 1
High: 12
Critical: 0
Total: 187
# Display the actual report
> rp-cli applications audits get 1 --rawoutput | jq
{
"result": {
"audit": [
{
"type": "code",
"entry": {
"analyze": [
{
"output": [
{
"cve": [
{
"column": "5",
"context": " vprintf(format, args);",
"cwe": "134",
"definition": "https://cwe.mitre.org/data/definitions/134.html",
"detail": "If format strings can be influenced by an attacker, they can be exploited (CWE-134).",
"line": "29",
"severity": "HIGH"
},
(...)
]
}
]
}
]
}
}
]
}
}
# Download the audit report
> rp-cli applications audits logs 1
------ Retrieving audit logs archive -----
Downloading logs for audit "1"... [OK]
The audit logs for audit "1" are available in: /home/devel/rp-audits-logs/1/canbus-binding-audit-20220427154950.zip