Child pages
  • Jenkins Security Advisory 2015-10-01
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Updated 2015-10-13: The /script URL appears to be how machines get infected. Clarified that enabling security isn't enough, anonymous users must not be able to run scripts.

Description

The Jenkins project has received multiple credible reports indicating that unsecured, publicly accessible instances of Jenkins are being targeted and infected with malware. This advisory publishes the information we have about this situation and may be updated once we learn more.

By default, Jenkins listens to all interfaces and does not require user authentication, allowing anyone on the network to run arbitrary processes as the user running Jenkins. If you're running a Jenkins instance on a public network, make sure security is enabled, and that anonymous users have read access at most. To do this, follow the instructions in the Jenkins wiki.

While this is not a bug in Jenkins, we are planning to change the Jenkins setup in a future release to be secure by default to prevent something like this from occurring in the future.

Infections

Reports indicate that affected machines have one or more of these files in their Jenkins home directory (e.g. /var/lib/jenkins):

  • RcsHTone
  • XiosElom
  • XiosElomL

According to some reports, the malware uses the /script URL to install the malware on affected machines, i.e. it is using regular Jenkins functionality.

We currently neither know the exact nature of this malware, nor how to remove it.

Fix

If you're running a Jenkins instance on a public network, follow the instructions in the Jenkins wiki to set up security on your Jenkins instance.

It is important that it is not possible for anonymous users to perform administrative actions or run scripts. This means:

  • Do not use the Anyone can do anything authorization strategy.
  • Do not use the Logged-in users can do anything authorization strategy while allowing users to sign up when using Jenkins’ own user database.
  • Do not give significant permissions (beyond read access) to the authenticated group when using a more complex authorization strategy such as Matrix-based security while allowing users to sign up when using Jenkins’ own user database.

Call to Action

If you have more information about these infections, please share what you know and create an issue in the SECURITY project on issues.jenkins-ci.org (requires account).

  • No labels