Introduction to Artifactory
Artifactory is a “binary repository manager”
that stores software packages and other binaries.
As with Ansible for DevOps,
we’ll focus on Artifactory as we’ve encountered it frequently
during penetration testing engagements.
Most of the time, the same general concepts
explained in this section can be applied to different products.
Binary repository managers act as a “single source of truth”
for organizations to be able to control which versions
of packages and applications
are being used in software development
or infrastructure configuration.
This prevents developers from getting untrusted
or unstable binaries
directly from the Internet.
Users with write access to Artifactory
can place packages or binaries in the Artifactory server.
End users or automated processes
can have Artifactory configured as a package repository
to be used in a normal installation process on Linux
or can pull files directly from Artifactory
when needed.
Because Artifactory is meant to be a single source
for acquiring necessary binaries,
it is a prime target
for supply chain compromise attacks.
If an attacker can compromise the Artifactory server
or get access to an Artifactory user’s account
that has write access to important packages,
there is potential to compromise a large number of users.
Artifactory is also an excellent target because it is considered a trusted source.
As such, it is not often considered a source
for malicious binaries or activity.
Normally, Artifactory would be run on a production system as a service.
Unfortunately, the service is resource-intensive.
To conserve resources for other activities in the module,
we’ll start and stop it as needed
and run it as a daemon process only.
The open-source version of Artifactory is installed on the controller VM
in the /opt/jfrog directory.
We can run it as a daemon process through the artifactoryctl start command.
Let’s take a few moments to become familiar with Artifactory
and how it works before we begin our attack.
We can access the login page,
and log in with “admin” as the username and “password123”
as the password.
While the commercial version of Artifactory
supports a variety of repository types,
including Debian packages,
the open-source version is limited.
The version of Artifactory we’re using only offers Gradle,
Ivy,
Maven,
SBT,
and Generic repository types.
Gradle, Maven, and SBT are all software build systems or tools
and Ivy is a dependency manager for software builds.
The Generic repository is for generic binaries of a non-specified type,
essentially a simple file store.
In the lab environment, we can examine a generic repository called “generic-local”.
We can access it by clicking to Artifactory >
Artifacts on the left sidebar.
The Set Me Up button at the top right of the page,
gives information about how to use Curl
to upload and download binaries to the repository.
There is also a Deploy button,
that will let us upload files to the repository
and specify the paths we want users to access
to download them.
Clicking on generic-local expands the tree
where we find a “vi” artifact listed.
If we click on it,
we can inspect various statistics about the file,
such as the download path,
who it was deployed by,
when it was created and last modified,
and how many times it’s been downloaded.
Now that we have a working knowledge of Artifactory,
its interface, and how to use it,
let’s take a look at potential exploits.