Jenkins Flaw Can Allow Attackers to Log In as Admins

Jenkins is an open source Java server tool that has found wide use in DevOps methodology, where software development is more automated to allow for testing and continuous updating and delivery.

One can set up Jenkins to automatically watch for any code changes that occur in places such as Apache Subversion (SVN) and GitHub, automatically do a code build using a tool like Maven, run static code tests, as well as utilize container technology such as Docker and Kubernetes. Further, it can take actions on production installs such as rolling back or rolling forward.

Quite the useful item when new versions of software routinely appear.

Using the "x-jenkins" search string in Shodan shows over 78,000 installations world-wide that are Internet-facing. One vendor in the Jenkins community finds there are more than 165,000 active installations and an estimated 1.65 million users around the world as of February.

Jenkins Configure Global Security page
\r\n(Source: CyberArk)\r\n

Now, however, researchers at CyberArk have found that Jenkins has had some serious problems inside of it, even though it has been around since 2005 -- albeit in different forms.

The critical problems would allow attackers to gain admin status or log in with invalid credentials, allowing them to take over the server.

CyberArk researchers first identified the problem -- CVE-2018-1999001 -- which allowed attackers to provide crafted login credentials that would cause Jenkins to move the startup configuration (config.xml) file from the Jenkins home directory.

On restart without the configuration file, it will be running in the "Security Disabled" mode. This mode requires no authentication, and considers any actor with access to the Jenkins master program an administrator.

A problem, to be sure.

How would an attacker force a restart to happen so that they may exploit this?

It can because of another bug that CyberArk found -- CVE-2018-1999043 -- which will crash the Java virtual machine. By using the Curl command with very long usernames, CyberArk showed that they able to crash the Java virtual machine due to low memory. That meant that an attacker could force the Jenkins admin to restart the Jenkins server whenever they wanted after moving the configuration file.

But wait, there's more.

Once restarted, the attacker could then copy the previously moved config.xml file back into its original place. If done at the right time and quickly enough, security configurations would be restored without any trace that there had been a time period where the security master switch was not enabled. Very stealthy and untraceable.

Of course, when security is not in an enabled state attackers can carry out their nefarious activities, including slapping a cryptominer onto it, or installing a backdoor.

Even though these two problems were corrected in recent patched Jenkins distributions, a more targeted search on Shodan shows that thousands of unpatched Jenkins versions are still out there, which are still at risk from these two vulnerabilities.

This is what is so often seen after a security problem has been patched: the patch may not get applied to vulnerable systems. Yet again, security teams need to make sure that the latest versions of a program are the ones that are in use or pay the price.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.