Download behaviour from a proxy repository when that proxy returns error response in HTML

Sonatype Nexus Repository
, ,
1

Hi,

I am currently investigating an internal security incident, where initially it was believed someone tried to attack a user by tampering with custom artifact content. What I need to understand is how nexus behaves when the answer to a download request from a proxied repo is not the content expected or a HTTP 404, but a webpage containing error responses or redirects.

That was recognized, as a user scanned contents of .module files (Gradle Module Metadata - which is gradles own variant of a maven pom and contains JSON content) and found that its content was an html page with a redirect. That redirect goes to a qt-jambi.org, formerly the site for an open source project, now we suspect a compromised site.

Following setup, we proxy for legacy reasons http://maven.openimaj.org/. On that server runs a nexus 3 instance (unfortunately it seems to not be protected in any way). The web-page content in the artifact contains a redirect to qt-jambi, thus we believe at one point in time qt-jambi hosted a nexus repo themselves that is still proxied by openimaj.

My question is, how does the nexus 3 instance on openimaj behave, when it tries to download an artifact from the qt-jambi site and instead of getting an HTTP 404, it receives a webpage that contains a redirect or another form of html page containing error information.
Does nexus 3 record that as a failed attempt, or happily store that web page content in the file contents of that artifact and thus serves that back to us?

What I saw when browsing the contents of openimaj, is that there were web page contents in an artifacts plus its checksum files (so, in. a .jar file, the .module file, and .sh1, .sh256 and .md5).

If nexus 3 does not behave that way, I would assume someone maliciously placed those crafted files there, because openimaj has no protection whatsoever and I would have to treat this much more seriously. In the other case, I can assume that’s just not very favourable behaviour from nexus 3, but no malicious intent.

Thanks for any help with this in advance.
Christian

2

Christian, a few things:

Nexus Repository doesn’t cache upstream responses when there are proper HTTP header codes indicating an error.

Sometimes, however, remote repositories are misconfigured and return their error messages with an HTTP response code indicating success. To avoid caching these improperly labelled error responses, Nexus Repository does some mime-type checking with the content, filename, and declared mime types in the response headers and rejects mismatches. There are heuristics involved here which may not be foolproof in all circumstances.

Thirdly, it’s possible that someone has uploaded something directly to the repository you’re proxying, or one that it itself in turn is proxying. Malicious (or simply incorrect) content is actually what’s in the respository, and Nexus is faithfully passing that on to you.

For what it’s worth, http://maven.openimaj.org/ appears to be a Nexus 2 instance, not Nexus 3.

3

Thanks for the answer. However, I am not sure I can relax now or not. Because, what you said suggest to me that this mime-type checking mechanism should have prevented that to happen?

I understand that in the communication between our nexus and the openimaj one, we accept what openimaj is passing to us, as openimaj believes the content to be correct.

But, according to your explanation the nexus2 instance on openimaj should not have accepted that content to begin with. Did I get that right? So that leaves malicious intent as the only explanation?

4

Unfortunately, I can’t be completely definitive for you. The mime type validation is useful but not completely watertight; sometimes the library misidentifies content.