Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Apache maven is a common build tool for Java. Artifacts needed for the code are in an XML file. During the build process, the Maven console will download the deps it needs for local use. When it does this, a call to the Maven Artifact Resolver is made.

Maven Central is the main place where Java libraries are downloaded from. Thie site is public and has group ids to publish artifacts. For instance, org.springframework.boot repos can only be written to by the owner of this group. To host these, they are done by a global portal or through a legacy OSS repository hosting. JFrog, JBoss and many others are used under the hood to resolve these.

There is a proxy mode that allows for private Maven repo usage. Two of the in-house repo hosting software where vulnerability to XSS via rendering a malicious XML file. Since the XML file is controlled by the attacker and renders on the local browser, this leads to executing arbitrary commands as the logged in user for the page.

When a repo manager makes a request to download artifacts, it provides all of the information in the URL - group id, artifact id, etc. What would happen if this information contained slashes or pounds? It's not escaped at all. So, it would be possible to change the meaning of the URL. Additionally, the values after the artifact are truncated by all of the servers.

For some reason, JFrog supports semi-colons in the URLs as a deliminator. The semi-colon ends the parsing for JFrog but not other things. So, we can effectively do cache poisoning when proxies are being used! The proxied request will get things after the directory traversal then the next cached request will get the poisoned values.

Both Nexus and JFrog support URL query parameters for proxy repos. Messing around with these was a good attack surface as a result. The Nexus host was doing authorization checks based upon some route matching. By appending an extra slash in the URL path, this verification was bypassed. This allowed for overwriting unintended files on the server.

To make exploitation easier, they found that the contentGenerator tag could be set to velocity. This is a templating engine! So, by overwriting the file with velocity template, RCE is achieved but with authentication.

Overall, a pretty awesome post. The author has a good insight for how they found many of these bugs: "This [architecture] may introduce a second-order vulnerability when an attacker uploads a specially crafted artifact to the public repository first, and then uses it to attack the in-house manager." Integrators multiple pieces of software is complicated.