Recently, we identified security issues in the Nexus Repository Manager software developed by Sonatype. The tested versions were OSS 3.12.1-01 and OSS 3.13.1-01.
The following issues could be identified:
- Multiple Cross-Site Scripting (CVE-2018-16619)
- Missing Access Controls (CVE-2018-16620)
- Java Expression Language Injection (CVE-2018-16621)
The vulnerabilities are fixed in version 3.14.0. See the release notes and security advisories for further information.
We identified a Java Expression Language Injection in the role and user creation function. In order to exploit this issue, the attacker needs to be authenticated with high privileges, the standard anonymous user is not sufficient.
Furthermore, we identified several Cross-Site Scripting vulnerabilities. An authenticated administrator can create a so-called “Blob Store”, the name of the “Blob Store” is neither checked nor escaped. This allows an authenticated administrator to place a Cross-Site Scripting payload that is triggered when a user visits the “Blob Stores” page.
Additionally, we also identified a Cross-Site Scripting vulnerability in the SSL Certificate Fetch Functionality for websites and the SSL Certificate Fetch Functionality of the Email Server Configuration. In order to exploit this issue, an attacker needs to perform social engineering on an administrator. By sending an administrative user of the Nexus Repository Manager a host-port combination to fetch a certificate from, the Cross-Site Scripting can be triggered in the administrative interface. Therefore, the cookie of the administrator can be extracted and used for a privilege escalation. Furthermore, since the administrative interface also allows to create groovy scripts, operating system commands can be executed as well, by e.g. sending an XMLHttpRequest.
The Nexus Repository Manager could be misused to enumerate the structure of the internal network or hosts with open ports due to missing access controls. As the application allows arbitrary ports and hosts as parameter to fetch SSL certificates from this can be used to enumerate the internal network. By supplying IP addresses of the private IP address space (see RFC1918) e.g. from the space 192.168.0.0/16 an attacker can distinguish between open and closed ports of a system. That’s also possible for the loopback address 127.0.0.1. The gathered information (networks as well as running hosts with open ports) helps an attacker to prepare further and more specific attacks. Furthermore, this issue can be triggered without any session, which means that an unauthenticated user can perform such requests.
Best,
Dominik and Tillmann
Timeline:
2018-08-17 Vendor was notified
2018-08-17 First response from vendor
2018-08-20 Vendor acknowledged vulnerabilities and started working on fixes
2018-10-13 Release of the fixed version
2018-10-17 Vendor issues security advisories