Compromising Artifactory Backups
Even if we can get root access to the repository server,
that doesn’t necessarily mean we have access to the Artifactory application,
which has its own authentication mechanism.
Let’s explore a situation in which we have root access to the server,
but we do not have Artifactory credentials.
At first glance, it may seem logical to try and replace artifact binaries on disk
wherever they are stored.
However, it is difficult to identify the files we want
because they are not stored by name,
but by their file hash.
Additionally, if we replace the binary on disk with something else
and then log into Artifactory and retrieve it,
we notice that the file is not changed in the repository,
so there are other mechanisms in place to maintain file integrity.
Dince replacing the binaries doesn’t seem like a viable option at this point.
Let’s examine a different approach.
Artifactory stores its user information,
such as usernames and encrypted passwords,
in databases
as most applications do.
The database depends on the configuration and version of Artifactory.
Larger organizations with a commercial version of Artifactory may use
Postgres databases.
The open-source version of Artifactory defaults to an included Apache Derby
database.
This doesn’t necessarily represent all potential configurations,
but the general concept needed for this exploit
are essentially the same
regardless of which database is being used.
We can comprise Artifactory via a database in a couple different ways.
The first is through backups.
Depending on the configuration,
Artifactory creates backups of its databases.
The open-source version of Artifactory creates database backups
for the user accounts in JSON format.
We can inspect the user entries
by reading the contents of one of these files in the controller VM.
These files have full entries for each user
along with their passwords hashed in bcrypt format.
We’ll switch back to our Kali tab,
place the developer hash in a text file,
and use John the Ripper to try and crack it.
According to the output, JTR was able to crack the hash
and we retrieved the developer user’s password.
Let’s verify it was cracked correctly.
Excellent,
the credentials were cracked successfully.