In 2021 I discovered several high and critical vulnerabilities in the Kaseya Unitrends backup appliance. This research was conducted and published as part of my day job. Part one details a chain of vulnerabilities by leveraging an insecure PostgreSQL database to ultimately gain shell access to the remote server. Visit https://www.cyberonesecurity.com/blog/exploiting-kaseya-unitrends-backup-appliance-part-1 for the the full write-up. Stay tuned for part two.
I noticed the following changelog entry in sudo 1.9.5p1. This caught my attention so I decided to look further. I was unable to find an advisory, PoC, or CVE for this vulnerability. Using the details from the changelog message and fix, I decided to write an exploit for it.
Using an Ubuntu 20.04.1 VM, I created a low privileged user named “lowpriv” and added a sudoedit rule for a root owned file /etc/test.txt. I also downloaded the source for sudo 1.9.5, compiled it, and installed it to /opt/sudo.
Show sudoedit rule.
Show the sudo version is 1.9.5.
With the test environment ready I ran sudoedit /etc/test.txt. I executed !id as a quick test which executes the id command in a shell however privileges are dropped by bash when the UID != EUID. Back to the drawing board.
I was able to successfully edit arbitrary files simply using the :e /etc/sudoers or :e /etc/shadow commands to escalate privileges, however that was too easy.
Looking for esoteric features that could potentially be leveraged, I discovered the libcall and libcallnr functions which allow you to execute a function from an external library. The one caveat is there can only be a single argument. There are a crazy amount of functions available to vim that I never realized. Check out https://vim.help/41-write-a-vim-script#41.6 for the full listing.
I tried calling a variety of functions with varying degrees of success but found a simple method by calling setuid() directly.
call libcallnr("libc.so.6","setuid",0)
After running sudoedit, use the following vim/ex command to change the UID to zero. This will ensure that shelling out will retain privileges because now UID==EUID.
Execute a bash shell with !bash.
Interactive root shell obtained. Woot!
I tested the same proof of concept with 1.9.5p1 and sudoedit properly drops privileges as expected.
Summary
If you upgraded to sudo 1.9.5 to fix CVE-2021-23240 or CVE-2021-23239, a new privilege escalation vulnerability was introduced in sudoedit and you should upgrade to 1.9.5p1.
Once in a while I look at recently fixed vulnerabilities to see if I can bypass the fix. In this case, the sudo project knew about this vulnerably but to my knowledge no advisory or CVE was created. I think this is odd that the issue was not communicated since a valid privilege escalation was patched. It’s unclear if another researcher reported it or if maintainers discovered it during their own testing. I also could not find a proof of concept so I decided to write one as a fun exercise.
I hope you enjoyed the short write up. Hit me me up on Twitter @0xm1rch if you have any questions or comments.
Pi-hole v5.2.1 is vulnerable to a critical stored cross site scripting vulnerability. An attacker with the ability to directly or indirectly query DNS with a malicious hostname can cause arbitrary JavaScript to execute when the Pi-hole administrator accesses the Query Log or Long-term Query Log pages on the web portal.
The Pi-hole project released a fix on 12/24/2020 in v5.2.2. Shodan reports over 7,500 Pi-hole instances. This could be remotely exploited if these instances permit external DNS queries. Other possibilities may exist if a malformed DNS query is allowed.
No payloads are being published at this time to give users time to patch.
References
Timeline
Today, a Metasploit module was merged for a vulnerability I found in 2018 with VyOS. This vulnerability was my first public InfoSec blog post. I appreciate bcoles for developing the exploit/linux/ssh/vyos_restricted_shell_privesc module. Read the Metasploit Wrapup for 9/25/2020. The full write-up can can be found on this blog at CVE-2018-18556 – VyOS Privilege escalation via sudo pppd for operator users.
I discovered several vulnerabilities in the MoFi4500 LTE router. Several vulnerabilities have not been patched, including an unauthenticated remote command injection and several undocumented backdoors. The full write-up can be viewed at https://www.criticalstart.com/critical-vulnerabilities-discovered-in-mofi-routers/.
Media Coverage
Follow the conversation on Twitter
VMware Fusion 11.5.12 and prior are vulnerable to an elevation of privilege vulnerability. For more details please review the advisory and proof of concept on my Github page CVE-2020-3950.sh. VMware released a the patch last week and a public advisory VMSA-2020-0005 today however it has been determined that the patch does not properly fix the vulnerability. I reached out to the VMware security team and received a response at 10:31 UTC 2020-03-18 – “We are aware of the situation and working on the next steps”.
I also learned today that Jeff Ball at GRIMM also independently discovered and reported the vulnerability to VMware. This is a first for me. Make sure to read their excellent detailed write-up https://blog.grimm-co.com/post/analyzing-suid-binaries/. You can also follow the thread on Twitter.
Signal Desktop v1.29 on Windows is vulnerable to an elevation of privilege vulnerability. During the startup the application will execute the c:\node_modules\.bin\wmic.exe binary if it exists. By default on Windows, low privileged users have the privilege to create folders under root level drives. A low privileged user can create a malicious wmic.exe which will be executed every time Signal Desktop starts by any user of the system. The malicious binary is executed in the background without the users knowledge. This is an example of horizontal privilege escalation.
The vulnerability has been patched in v1.29.1 in commit 2da39c which was released 12/17/2019. Kudos to the Signal security team for fixing in less than two weeks! Unfortunately, at this time the they do not feel this warrants an advisory or CVE so the vulnerability was silently fixed. 12/24/2019 Update: Mitre assigned CVE-2019-19954
In a cmd window
mkdir c:\node_modules\.bin copy c:\windows\system32\calc.exe c:\node_modules\.bin\wmic.exe
Now any user that opens Signal, the Windows calculator will be popped.
The pg_ctlcluster script in the postgresql-common package in Debian and Ubuntu is vulnerable to a local privilege escalation attack. pg_ctlcluster is a script used to manage PostgreSQL instances. A malicious actor with access to the postgres account can create arbitrary directories during startup or reload when called via systemd. This vulnerability can be leveraged to escalate privileges to root.
It’s important to note this is not a vulnerability in PostgreSQL and is specific to Debian, Ubuntu, or any system that consumes the Debian postgresql-common package.
A fix is now available. Administrators should upgrade to the latest version of the postgresql-common package. See the Debian security tracker for details.
The vulnerability appears to have existed since 2013 based on the Debian Git history (9dc97b, e97d16). I attempted to reproduce it on Wheezy but was unable to verify it due to unrelated technical issues standing up a test environment.
This proof of concept will show the ability to gain root privileges using the default
installation of postgresql-common v200+deb10u2 along with postgresql-11 on Debian Buster. I have also verified the vulnerability on Ubuntu 19.04 with version 199 of the postgresql-common package.
The postgresql init script(/etc/init.d/postgresql) sources init.d-functions which contain functions that call the pg_ctlcluster script. pg_ctlcluster loads the following configuration files determined by the Pgcommon module.
These files are owned by the postgres user. The postgresql.auto.conf file will override the settings from /etc/postgresql. This file is created when the alter system command is executed.
pg_ctlcluster contains logic to create directories for socketdir(defined in pg_ctl.conf) and stats_temp_directory(defined in postgresql.conf). During a start or reload, if the directories defined in either of these variables do not exist, pg_ctlcluster will create it and set the owner to the postgres user.
IBM MQ for Linux and UNIX systems is vulnerable to a privilege escalation attack by forcing a setuid root binary to load a malicious library. A local attacker with access to the mqm account can execute arbitrary code as root. In October 2018 IBM published an advisory along with patches for several versions.
The goal of this post is to show how the RPATH/RUNPATH value could potentially be leveraged for privilege escalation. When specified at compile time this path is embedded in the binary and is the first path searched when searching for a library if the dependent library specified does contain a slash. Details on how this works can be found in the ld.so man page.
As with most file path type vulnerabilities, if you control the path, you may control the application in some way. In this case the mqm user is the owner of the directories listed in the RUNPATH.
List setuid root applications.
[mqm@localhost]$ find /opt/mqm -perm -4000 -user root|xargs ls -l -r-sr-x---. 1 root mqm 13384 Jul 9 07:09 /opt/mqm/bin/security/amqoamax -r-sr-x---. 1 root mqm 13704 Jul 9 07:09 /opt/mqm/bin/security/amqoampx
Use readelf to read the dynamic section to extract the RPATH/RUNPATH.
[mqm@localhost ~]$ readelf -d /opt/mqm/bin/security/amqoamax |grep -e RPATH -e RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/opt/mqm/lib64:/opt/mqm/gskit8/lib64:/
Using my favorite utility strace, we can see the open() calls for libm.so.6 fails with ENOENT under /opt/mqm/lib64 and /opt/mqm/gskit8. We’re using libm.so.6 for this PoC but other libraries can be used. The dependency is ultimately resolved at /usr/lib64/libm.so.6. This gets interesting because the mqm user owns the directories under /opt/mqm.
[mqm@localhost ~]$ strace -f /opt/mqm/bin/security/amqoamax 2>&1|grep libm.so
open("/opt/mqm/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/opt/mqm/gskit8/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
During startup the PIA Windows service(pia-service.exe) loads the OpenSSL library from C:\Program Files\Private Internet Access\libeay32.dll. This library attempts to load the C:\etc\ssl\openssl.cnf configuration file. By default on Windows systems, authenticated users can create directories under C:\. A low privileged user can create a openssl.cnf configuration file to load a malicious OpenSSL engine library resulting in the arbitrary code execution as SYSTEM when the service starts.
The root cause is when the OpenSSL libraries were built, the OPENSSLDIR parameter was set to a path which a low privileged user can modify or create. I believe this issue is lurking in many Window applications that bundle OpenSSL libraries. I have discovered the same vulnerability in several other Windows applications and will be disclosing those findings when patches are available.
I created a simple tool to help identify potentially vulnerable OpenSSL libraries –https://github.com/mirchr/openssldir_check.
CVE-2019-12572 has been patched in v1.2.1. The latest Windows desktop client can be upgraded automatically via the application or manually from the download page at Private Internet Access.
While hunting for potential vulnerabilities in the Windows Private Internet Access desktop application I noticed a failed call to open the c:\etc\ssl\openssl.cnf file during the service startup.
This caught my attention and I needed to research this further. But before I get into the details of that, let’s take a step back and see how I arrived there.
Rich Mirch 