…and…How AI Can Revolutionize Code and Regression Testing

Introduction

Artificial Intelligence (AI) is transforming numerous industries, and software development is no exception. One of the critical areas where AI can make a significant impact is in code regression testing. This article explores how AI can streamline these processes, using a recent real-world example of an old vulnerability reintroduced by human error.

Background

On July 1, 2024, a new OpenSSH unauthenticated remote code execution (RCE) vulnerability dubbed regreSSHion was reported, affecting glibc-based Linux systems, which are likely the majority of linux systems out there. This vulnerability, identified as CVE-2024-6387, allows remote attackers to execute arbitrary code as root due to a signal handler race condition in sshd.

If exploited, it could lead to full system compromise, resulting in complete system takeover, installation of malware, data manipulation, and creation of backdoors for persistent access. Yikes!

Versions Affected

• Vulnerable Versions: OpenSSH servers on Linux from version 8.5p1 up to, but not including 9.8p1.
• Non-Vulnerable Versions: Versions 4.4p1 up to, but not including 8.5p1 (due to a patch for CVE-2006-5051).
• Older Versions: Versions older than 4.4p1 are vulnerable unless patched for CVE-2006-5051 and CVE-2008-4109. OpenBSD systems are secure thanks to a mechanism introduced in 2001.

Remediation

OpenSSH patches need to be applied across various Linux distributions. Identifying which systems require a patch involves scanning the network for servers listening for SSH connections. Since it’s a best practice to set up SSH on non-default ports, discovery can be a bit more complicated.

Case Study: OpenSSH CVE Discovery Using Python and NMAP

I wanted to leverage network scanning with NMAP to report on hosts running vulnerable versions of OpenSSH. Since it is often a best practice to change the default port from port 22, it’s also important that the scan catch these scenarios where SSH is running on a custom port.

Scanning a network must also be done in a specific manner. You should only ever scan networks you manage, and it’s often best to scan subnets in “groups” and during off hours.

openssh-cve-discovery.py leverages nmap to scan a specified network range for open SSH services running on any port. It collects the hostname, local IP, and OpenSSH version running. Versions matching the vulnerable versions are logged in ssh_scan_report.csv.

Key Features of the script

• Network Scanning: Scans a specified network range for SSH services using nmap’s version detection feature.
• Chunked Processing: Handles large networks efficiently by scanning in smaller chunks.
• Timeout and Error Handling: Includes timeouts for each scan chunk and robust error handling to manage exceptions gracefully.
• Command-Line Configuration: Allows users to specify the network range to scan via a command-line argument (--cidr).
• Detailed Logging: Logs all scan actions and results to a log file (ssh_scan.log).
• CSV Reporting: Generates a CSV report (ssh_scan_report.csv) summarizing the hostname, IP address, OpenSSH version, and vulnerability status for each detected SSH service.

Script Execution

1. Run the Script: Execute the script with sudo privileges and the desired network range:

   sudo python3 openssh-cve-discovery.py --cidr 192.168.0.0/24

2. Check Logs and Reports:

• ssh_scan.log: Detailed log of all actions and results during the scan.
• ssh_scan_report.csv: Summarized CSV report with hostname, IP address, OpenSSH version, and vulnerability status.

Sample Output

test@ubuntu$ python3 openssh-cve-discovery.py --cidr 192.168.0.1/24
Scanning started at: 2024-07-02 19:19:03.655845
Total hosts to scan: 254
Host: ubuntu-linux-22-04-desktop, Port: 2222, OpenSSH Version: OpenSSH 8.9p1 Ubuntu 3ubuntu0.7, Vulnerability: Vulnerable to regreSSHion
Host: 192.168.0.150, Port: 22, OpenSSH Version: OpenSSH 8.9p1 Ubuntu 3ubuntu0.10, Vulnerability: Vulnerable to regreSSHion
Scanning completed at: 2024-07-02 19:25:23.480468
Duration: 0:06:19.824623
test@ubuntu$
test@ubuntu$$ cat ssh_scan_report.csv 
Hostname,IP Address,OpenSSH Version,Vulnerability Status
ubuntu-linux-22-04-desktop,192.168.0.35,OpenSSH 8.9p1 Ubuntu 3ubuntu0.7,Vulnerable to regreSSHion
192.168.0.150,192.168.0.150,OpenSSH 8.9p1 Ubuntu 3ubuntu0.10,Vulnerable to regreSSHion
test@ubuntu$

Now… what’s this about AI in Regression Testing?

Regression testing ensures that current functionality is retained, and that new changes don’t reintroduce old bugs. In the case of CVE-2024-6387, being essentially a repeat of older CVEs, a developer likely thinks they are working in useful features, unaware of the history of the decades old CVEs. Standard functional tests won’t pick up any issue.

Regression testing with Application Security tools can be static (mostly signature based) or dynamic (relying on behaviours). Whether they would pick up a re-introduction of an old CVE is hard to predict. It depends on their point of reference, baselines and signature base. Some tools will, some won’t.

However, taking a neural network approach to code behaviours associated with CVEs makes the most sense here, where an extensive history of ever vulnerability is not reasonable for a developer to be aware of.

Beyond the neural network map of code, behaviours and CVEs, there are a lot of other benefits to have AI help drive regression testing:

• Automating Test Case Generation: AI can create test cases based on code changes, reducing manual effort.
• Prioritizing Test Cases: AI can prioritize test cases based on the likelihood of failure, optimizing testing efforts.
• Continuous Integration and Testing: AI can integrate with CI/CD pipelines to run tests automatically whenever new code is pushed.

SDLC turnaround will get shorter, and releases more frequent. This is going to be essential going forward, as attackers are already leveraging AI to make their attacks more efficient. It only makes sense to keep up by leveraging AI tools to close security gaps before they are exploited.

*** This is a Security Bloggers Network syndicated blog from Berry Networks authored by David Michael Berry. Read the original post at: https://berry-networks.com/2024/07/03/openssh-regresshion-vulnerability/