Posts

Vulnerability Summary 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. Walkthrough 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.

The barracudavpn component of the Barracuda VPN Client prior to version 5.0.2.7 for Linux, macOS, and OpenBSD runs as a privileged process and can allow an unprivileged local attacker to load a malicious library, resulting in arbitrary code executing as root. This post will walk through the process on how I found and exploited the vulnerability on Linux. The full PoC will also work on macOS. When researching for potential vulnerabilities with privileged binaries a test system should be used to avoid causing damage or negative impacts.

A rarely used feature on Linux and UNIX systems is the ability to add a password to a group. The concept is similar to how users are handled. An encrypted hash is stored in the second field of the gshadow(5) file. Anyone with the password can execute the newgrp(1) command to temporarily change their GID without having to be a member of the group. The goal of this post is show how this feature can be leveraged to create persistence on a server in a semi stealthy way.

Recently I started using Keybase which is a Slack like application but provides end-to-end encryption. Version 2.8.0.20181017144746.3efc4cbf3c is vulnerable to a privilege escalation vulnerability allowing a low privileged user to execute arbitrary commands as root. After executing the application using a low privileged account I noticed a process named keybase-redirector running as root. I was interested and wanted to understand how this worked. After checking the file permissions I found that the keybase-redirector was setuid root. I enjoy the challenge of finding vulnerabilities in privileged binaries so I started my research. ...

While reviewing my Twitter feed I noticed a recent popular tweet from @0xdea. https://twitter.com/0xdea/status/1070308598146850818 I was intrigued and wanted to see if there was a way to leverage this to execute arbitrary code as root. First we need to understand what the value of INT_MAX is. Fortunately the getconf command can be used to find the value or you can find it in /usr/include/limits.h. [root@localhost ~]# getconf INT_MAX 2147483647 [root@localhost ~]# grep 'define INT_MAX' /usr/include/limits.h # define INT_MAX 2147483647 To exploit the vulnerability the user must have a UID value larger than 2147483647. I used the same value of 4000000000 that @0xdea posted. ...

Recently I found several ways to escape the restricted shell for an operator user in VyOS 1.1.8. VyOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. I plan to post information on the restricted shell escapes in the near future; For now read the blog by @dmbaturin detailing some of the methods. This post will focus how root access was obtained using sudo after the restricted shell was escaped. One of my first post exploitation steps on Linux after a low privileged shell is obtained is to check if the user has sudo rules configured. Sudo is designed to limit privileges but often times it can be leveraged to elevate access.