Sonicwall Gms Trying to Get Database Connection Again

The Advanced Research Team at CrowdStrike Intelligence discovered ii vulnerabilities in SonicWall Global Management Organization 9.iii (GMS) that, when combined, allow unauthenticated attackers to remotely execute arbitrary code with root privileges. SonicWall issued a patch for the vulnerabilities in question in Apr 2021 and immediately notified impacted customers and partners. For more information, delight refer to SonicWall PSIRT Informational ID SNWLID-2021-0009 .

In this weblog mail, nosotros outline the technical details and walk you through the steps from discovery to exploitation. And, nosotros explain which indicators of compromise to await for in forensic evidence and how to foreclose the attack.

Overview

Product	Global Management System (GMS) 9.3
Affected Versions (without claim for completeness)	9.3.9314
Fixed Version	GMS 9.3 MAR-22474.1-HotFix (2021-04-07)
CVE	CVE-2021-20020
Root Cause	Password-less PostgreSQL service on port 5029/tcp ("Trust Hallmark") and earth-writable/etc. directory
Impact	Unauthenticated remote code execution every bit postgres and local privilege escalation to root
SonicWall Resources	Advisory: "SonicWall GMS 9.3 Unauthenticated Remote Command Execution Vulnerability"

Technical Details

Every bit a starting point for our research, we gear up a SonicWall GMS appliance in its default configuration. Once the initial setup was completed and the regular spider web interface became reachable, the remote assail surface was analyzed by conducting a port scan. It was institute that the appliance exposes a PostgreSQL service on TCP port 5029. Further analysis showed that the database operates in " Trust Authentication " way for all database users connecting from arbitrary IPv4 addresses. This finer allows anyone to authenticate as an arbitrary database user, including the superuser postgres , without providing a password.

On the appliance, the corresponding configuration line can be institute in the file pg_hba.conf :

          [root@gms ~]# tail -northward 14 /var/lib/infobright_pg/pg_data/pg_hba.conf  # Type  DATABASE        USER            Accost                 METHOD [...]            host     all            all             0.0.0.0/0               trust                  

Using the psql tool, we can easily confirm that remote superuser access is indeed possible without any authentication:

          $ psql -h 192.168.135.131 -p 5029 -U postgres -c "SELECT version()"                                                              version                                                                ---------------------------------------------------------------------------------------------------------------------------- ------  PostgreSQL nine.2.2 (IB_33928), shared on x86_64-unknown-linux-gnu, compiled by gcc (GCC) four.ane.2 20080704 (Ruddy Chapeau 4.ane.2-44), 6 4-scrap (ane row)        

The command initiates a connexion to the database (at 192.168.135.131) as the superuser postgres and invokes the congenital-in version() function, which returns the database'due south version information as a issue. This pace should usually crave authentication, for example by providing the superuser password.

Remote Code Execution

Generally speaking, superuser access to a PostgreSQL database is equivalent to remote code execution. Every bit a superuser, code execution tin can exist achieved by abusing two features of Postgres. The first characteristic, " Large Objects ," effectively allows uploading arbitrary files while the second feature allows loading capricious (attacker-controlled) shared libraries into the remote Postgres procedure. Under Linux, a simple mode for an attacker to execute arbitrary code when a malicious library is loaded is to mark a function containing that lawmaking equally a constructor . Thereby, merely loading that library leads to arbitrary code execution without whatsoever further requirements.

In the context of GMS, attackers tin obtain native code execution as the postgres system user by applying this technique. The procedure has been implemented as the first part of an exploit.

Escalating Privileges

After obtaining initial access every bit postgres to the appliance, opportunities for escalating privileges to root were explored. It apace turned out that the directory /etc on the apparatus is earth-writable:

          [postgres@gms ~]$ id uid=104(postgres) gid=104(postgres) groups=104(postgres) [postgres@gms ~]$ ls -lad /etc drwxrwxrwt   17 root     root          1040 February  v ten:09 /etc [postgres@gms ~]$ ls -la /etc/this_is_a_test ls: /etc/this_is_a_test: No such file or directory [postgres@gms ~]$ bear on /etc/this_is_a_test [postgres@gms ~]$ ls -la /etc/this_is_a_test -rw-------    1 postgres postgres         0 Feb  5 10:09 /etc/this_is_a_test        

While existing files cannot be modified or removed (due to the directory'southward mucilaginous bit), new files inside /etc can exist created by unprivileged users. As many privileged processes source their configuration files from /etc , manipulating these files is a frequently used technique for attackers to escalate privileges. One file that may be repurposed in that mode and usually does not exist is /etc/ld.so.preload . Its purpose is to store a list of paths to shared objects that the dynamic linker automatically loads into the process whenever a dynamically-linked binary is run. This includes processes running as root , even if they are instantiated from root -endemic SUID binaries, such equally /bin/ping . The ownership of the shared object that is to exist injected is non considered by the dynamic linker and therefore may be owned by any user. As a outcome, unprivileged users tin inject arbitrary code into a root -owned procedure such equally ping , thereby escalating privileges.

The privilege escalation has been implemented as the 2nd stride of the exploit.

Exploit

Both exploitation steps take been automated in the Python script sgms-rce.py and the shared object pwn.and so . The Python script takes the hostname or IP address of the targeted GMS instance equally a command line argument:

          $ ./sgms-rce.py --help usage: sgms-rce.py [-h] [--port PORT] [--dbname DBNAME] [--pwn-so-file-local PWN_SO_FILE_LOCAL]                    [--pwn-and so-path-remote PWN_SO_PATH_REMOTE] [--lpe-so-path-remote LPE_SO_PATH_REMOTE]                    host  positional arguments:   host  optional arguments:   -h, --help            show this assist message and exit   --port PORT, -p PORT   --dbname DBNAME, -d DBNAME   --pwn-and so-file-local PWN_SO_FILE_LOCAL   --pwn-so-path-remote PWN_SO_PATH_REMOTE   --lpe-so-path-remote LPE_SO_PATH_REMOTE        

It then connects to the PostgreSQL database, uploads the precompiled shared object pwn.so and loads it into the postgres procedure. The shared object code determines the socket file descriptor that belongs to the database connection of the exploit and redirects all further output to it. It so renames the shared object to lpe.so , prepares /etc/ld/then.preload accordingly and finally executes /bin/ping which will run equally root with lpe.so injected. The LPE code cleans up the created files and starts an interactive Bash beat out, which has stdin/stdout/stderr redirected to the connection's erstwhile PostgreSQL socket (via dup2() ).

Indicators of Exploitation

During exploitation, multiple PostgreSQL features are driveling in order to somewhen execute attacker-controlled lawmaking within the postgres process. Therefore, ane may await artifacts of the assail to be found in the database ( /var/lib/infobright_pg/pg_data/base ) itself or the respective write ahead log ( /var/lib/infobright_pg/pg_data/pg_xlog ). Nonetheless, this assumption heavily depends on the technical details of the exploitation steps. For example, the attached exploit neither leaves a trace in the database nor in the write alee log. In contrast, the Metasploit module linux/postgres/postgres_payload adds a new big object to the database each fourth dimension the exploit is executed and all exploit-related transactions are recorded in the write ahead log. Neither exploit lawmaking attempts to make clean up whatever artifacts in the database (too deleting the shared object from deejay ). The reason for the difference in observable artifacts is that the MSF exploit code forks into a new process before it executes due east.g. the meterpreter payload. This way, the exploited postgres process is able to gracefully terminate handling the customer and thereby implicitly commits the database changes and eventually writes them to disk. The exploit attached to this post does not fork a new process. Instead, it straight invokes the execve syscall for /bin/ping . At that point, the postgres process epitome responsible for handling the customer is replaced with that of /bin/ping . Because the transaction has not been committed upwards to the bespeak that the process image is replaced, it will never be committed in the future either. The exploit we demonstrated therefore does not get out whatever artifacts in the PostgreSQL database.

As whatsoever exploit must at least temporarily store a shared object to the filesystem, malicious shared objects may be plant on disk. Again, successful detection heavily depends on whether the file got deleted afterwards and whether the path used during exploitation was backed past volatile memory.

For rapid analysis of PostgreSQL data folders, we constitute it helpful to grep for strings that are more or less likely to exist in (malicious) shared objects but are normally non establish in any legitimate data that the PostgreSQL database processes in the context of the SonicWall GMS application.

          [user@work rootfs]$ grep -rP '(\x7fELF|\.got|\.plt|\.shstrtab|\.dynamic|\.text|\.init|mmap|mprotect|memcpy|dup2|libc\.and then\.6)' var/lib/infobright_pg/ Binary file var/lib/infobright_pg/pg_data/pg_xlog/000000010000000000000001 matches Binary file var/lib/infobright_pg/pg_data/base/12016/11774 matches Binary file var/lib/infobright_pg/pg_data/base/1/11978 matches Binary file var/lib/infobright_pg/pg_data/base/1/11774 matches Binary file var/lib/infobright_pg/pg_data/base/12021/11978 matches Binary file var/lib/infobright_pg/pg_data/base of operations/12021/11774 matches        

If the grep command returns a non-empty result, it is probable that someone attempted to exploit the database. Manual analysis of the identified files should be conducted to confirm or reject the event. If there are no hits, either no exploit attempts were fabricated or the threat actor was stealthy and exploited the database before changes were persisted to deejay.

Recommendations

In order to prevent the attack, SonicWall has released updates to their Global Management System product. According to their Security Advisory , a hotfix named GMS 9.3 Hotfix MAR-22474.1 is available to accost the effect and should be practical to all vulnerable devices. If the set up cannot be applied, access to TCP port 5029 of affected devices should be blocked.

Boosted Resources

• To learn more about how to contain intelligence on threat actors into your security strategy, visit the Falcon 10™ Premium Threat Intelligence page.
• Get a full-featured gratis trial of CrowdStrike Falcon Prevent™ and learn how true next-gen AV performs against today'south virtually sophisticated threats.
• Learn more on how Falcon Spotlight™ can help you observe and manage vulnerabilities in your environments.

leedume1974.blogspot.com

Source: https://www.crowdstrike.com/blog/how-to-detect-and-prevent-sonicwall-gms-remote-code-execution/

Share this post