How PwC found a zero-day vulnerability during a penetration test for a client (CVE-2021-21234)

As the world grows increasingly interconnected, leveraging third parties is becoming increasingly important to achieve necessary agility. It’s not necessary to reinvent the wheel; software developers often focus their time on adding value rather than finding new ways to do old tricks. Thanks to the open source software community, there is a massive ecosystem of libraries that help solve most of the common problems they face. Reusing this type of code, is, however, not without risk. Sometimes it introduces risks that are challenging to manage unless controls are in place to verify whether the software you’re relying on meets the standards you’d set for your internally developed code.

PwC’s Red Team has discovered an easy to exploit unauthenticated directory traversal vulnerability in the spring-boot-actuator-logview library, which is used by some applications in the Spring Boot ecosystem. A threat actor that has access to the log endpoint provided by this library would be able to read arbitrary files on the server hosting the application. This kind of vulnerability would usually allow a threat actor to get access to at least all data sources (e.g. databases or cloud services) used by the vulnerable application. Depending on the purpose of the application, these data sources might include sensitive data that a threat actor might want to either acquire or manipulate. Spring Boot applications relying on this library should be updated to include the patched version immediately.

Discovery

During a penetration test for one of our clients, we were testing a number of Java web application servers based on the widely-used Spring Boot framework¹. After performing initial reconnaissance on them, we noticed that they expose an endpoint (/log) for viewing log files. Some investigation showed that this endpoint was provided by the Maven package eu.hinsch:spring-boot-actuator-logview²³.

After selecting a log file, we were directed to a URL of the following form: /log/view?filename=somefile.log&base=

Seeing this, our first attempt was to inject ../ into the filename parameter to access files outside of the intended target directory. This, however, did not work, as that parameter appeared to be sanitized.

We did, however, have more luck trying to inject something into the base parameter. This parameter indicates the subfolder of the log file to be displayed. Furthermore, the developers appeared to have overlooked it while sanitizing user input. Instead of a failed assertion, we were now presented with a much more promising “no file provider found” error message.

Assuming that the target was running a version of the GNU/Linux operating system, we went for the /etc/passwd file to confirm that we can read arbitrary files on the server’s filesystem.

While this is not a full-blown Remote Code Execution vulnerability, this sort of vulnerability is in many cases just as devastating. Depending on the user and group the vulnerable application is running under, a threat actor abusing this might have access to a wide range of local files containing secrets or similar. These almost always include all external data sources used by the application in question (for example database backends). On Linux, a threat actor can additionally read the environment variables of the running process by accessing them through the proc-filesystem using the /proc/self/environ file. These variables can often also contain sensitive information.

Disclosure process

After verifying the presence of the vulnerability, we immediately contacted the client to coordinate the disclosure process with them. We agreed to delay any disclosure until after they had a chance to mitigate this vulnerability in their own systems. After receiving the confirmation that they were no longer directly affected, we moved forward according to PwC’s internal responsible disclosure guideline and informed the developer of the spring-boot-actuator-logview library. Seeing as this library appears to be a hobby project and its latest release at that time being from 2016, we were initially unsure whether he was still interested in maintaining and releasing a fixed version. We were very happy to hear, however, that he intended to publish an updated version. Version 0.2.13 of the library, which should now no longer be vulnerable, was released on January 1st 2021. PwC would like to thank the developer for his cooperation on this issue during his free time.

Timeline

• 02. Sep 2020: Discovery of the vulnerability
• 04. Sep 2020: Meeting with affected client to discuss this issue
• 01. Oct 2020: Initial attempt of contacting the developer via email after go-ahead from client
• 21. Oct 2020: Reply from developer after a second contact attempt was made via an alternate channel (original email was in spam folder); acknowledgement of vulnerability and intent to release fix
• 01. Jan 2021: Patched version 0.2.13 released
• 04. Jan 2021: CVE assigned & GitHub security advisory published

Discussion

PwC’s purpose is to build trust in society and solve important problems. Our ambition is therefore to responsibly disclose all previously unknown vulnerabilities we discover. For vulnerabilities discovered during a penetration test or red teaming exercise, this is oftentimes at the discretion of the client in question. We are always happy when a client agrees with and supports our decision to responsibly disclose a vulnerability that has affected their environment. We want to thank the client during whose project this issue was discovered for working together with us on this.

Without the work done by developers of open-source software, modern IT and especially the internet would be impossible. A lot of this work happens unpaid in the developers’ spare time, which puts limits on their ability to continue to provide maintenance. Organizations relying on external components for their solution need to ensure that all of these are maintained and that they are aware of any potential risks that are introduced by relying on them. Furthermore, they should consider supporting these developers of the software components they rely on.

Recommended Action

Spring Boot applications using a vulnerable version of spring-boot-actuator-logview (version 0.2.12 and before) should update to the patched version (0.2.13) immediately. This update should be a drop-in replacement, as, according to the maintainer of the library, no other changes were made in this version.

As a temporary mitigation, access to the /log endpoint can be restricted (for example by using a reverse proxy) until a patch can be deployed.

Web server access logs should be audited for queries to the vulnerable path (/log/view) that also contain ../ (or equivalent encoded versions of this string) in the base parameter.

¹ https://spring.io/projects/spring-boot
² https://mvnrepository.com/artifact/eu.hinsch/spring-boot-actuator-logview
³ https://github.com/lukashinsch/spring-boot-actuator-logview