Deployment credentials on the Nexus Repository Manager have accidentally leaked in GitHub. The issue received broad attention when a vulnerability report was submitted on February 16th, 2021. The deployment credentials were encrypted, however, the master password was leaked as well. Although the master password wasn’t stored in plain text, it was relatively easy to decode and be used to decrypt the deployment credentials. These secrets were exposed for about 350 days since being stored in the Git repository on March 18th, 2020.
After the vulnerability report was submitted, the secrets were revoked and new secrets were configured for all Jenkins instances that deploy to Nexus.
The credentials provided full control over the Maven repositories hosted on the Nexus Repository Manager. It was possible to exploit this security leak in various ways. With the credentials, all artifacts could be removed, however, the effect would have been minimal since backups were maintained. Artifacts, such as JAR files could be modified to contain malicious code. Build files, such as pom.xml, could also be modified to add dependencies with malicious code.
After an extensive audit, the Eclipse Foundation is confident that no release artifacts were modified. However, auditing all snapshot artifacts is more difficult and they can’t prove that those artifacts weren’t modified.
Mikaël Barbero, release engineering manager at the Eclipse Foundation, stated that there was no guarantee everything is safe despite the thorough audit, writing:
We managed to validate — to the best of our knowledge — that no release artifacts were tainted because of this leak. Unfortunately, we can’t do much for the snapshot artifacts. We know that about 13k of them are signed jars, but for the rest, it’s impossible to deny or confirm anything.
The credentials only provided full control via the REST interface. This means potential attackers couldn’t modify the last modified time of the files. The credentials were exposed for about 350 days and in that period roughly a hundred thousand files were created or changed.
About ten thousand files came from the Maven central proxy and couldn’t be changed by the leaked credentials. Next to that most files are JAR files and 21168 of them were signed with the Eclipse Foundation’s certificate which means they are safe as well. Some artifacts were also published to Maven central, which is immutable. 1548 unsigned release JAR’s were identical and thereby not tainted. JarDiff was used to make a binary comparison of artifacts that were slightly different.
That still leaves some JAR files and other files that needed further investigation such as file comparisons for pom.xml files again compared with Maven central. They also made some assumptions such as that attackers wouldn’t modify multiple artifacts for the same release. So a check was made to see if all the artifacts with the same GroupId, ArtifactId, Version, the same GroupId, Version pair, and the same version have a comparable last modified time.
The Eclipse Foundation considers the released JARs as safe, but they’re removing snapshots that haven’t been used for 60 days. They also advise users to create new snapshots for all applications.
To prevent this from happening in the future, secrets are no longer generated in a Git folder. Next to that code reviews are enforced for all Common Build Infrastructure Git repositories. Lastly, permissions will be given more fine-grained to reduce the blast radius of a potential future issue.