Automation of software development
practices through applications has become the defacto standard in the security industry. Organizations
are using support applications to reduce the workload in building and updating
software. The basic idea behind this
post is to check how security is structured for software management applications
such as Jenkins in a real time scenarios and what we need to look into while
performing security assessments. Before discussing further, let's talk about
Jenkins. According to the software website: "Jenkins is an application that monitors executions of repeated jobs,
such as building a software project or jobs run by cron.". For more
details, you can read here: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins.
From software development perspective, Jenkins provides an
integrated system which developers can use to manage software changes made
to specific projects. It has been noticed that, although organizations use this
software, but misconfigured interfaces (not running inside firewall and
improper access rights) could have substantial impact. From security
perspective, exposure of an integrated system that manages software development
model could become a sensitive risk. To prove this fact, a case study of
Jenkins application is discussed in which it is shown that how misconfigured
and exposed interfaces could result in potential security glitches.
These tests are conducted in an open environment. It has been
found that several of the big companies use Jenkins and with no surprises the
interfaces are exposed and running with improper authentication. In addition to
this, there are numbers of Jenkins systems that are Internet facing and expose
plethora of information to the attackers (remote users). A misconfigured
Jenkins server results in disclosure of critical information that can be used
in different set of attacks. A number of misconfiguration issues are presented
below that result in information disclosure:
Note: Based on this security issues, a few vulnerabilities have been reported to industry leaders (organizations) which have recognized the issue. I will release the details once the issue is patched.
Developers Information: Exposed Jenkins interface
reveals information about the developers participating in the software
projects. It is possible to extract userids of the registered accounts with
associated names. This is a substantial point of gaining information about the
users of a specific organization. An example of the exposed user details is shown below:
 |
| Exposed Developers Information ! |
Software
Builds Information and Source Codes: It is possible to gain
information about the software builds without any authentication (misconfigured
scenarios). Information about the
changes in the software over a passage of time reveals information about the
development flow of the components. Jenkins application does not ask for any
explicit permission from the administrators to validate the user before
accessing the ongoing software builds. An
example is shown below:
 |
| Exposed Software Build and Version numbers ! |
In
certain scenarios, it is also possible to download the source code from the
Jenkins without any authentication. Although for making changes to the code,
you require credentials but the fun part is you can download code without them.
Take a look at the example shown below:
 |
| Source Code Files ! |
Server-side Information Disclosure in Environment Variables: Access
to environment variables also provides plethora of information. Example
presented below shows the significant information about the configure MySQL
(JDBC) database server. The attacker can easily glean username and password of
the database (SONAR_JDBC_USERNAME & SONAR_JDBC_PASSWORD) including the
internal IP address with port number on which JDBC service is running.
 |
| Revealed Environment Information ! |
Exposure of Application Secret Data: During analysis, it has been found that a
number of server side scripts have hard coded critical information such as
secret-keys and credentials which can be exposed when console-output operations
are performed. The underlined example shows how a secret key is extracted by
accessing the console-output. In this
example, the curl command uses a secret key to connect to a specific domain for
fetching JSON data through GET request. Once this information is exposed, the
attacker can directly perform queries with the target domain.
 |
| Revealed Secret Key ! |
Cron Jobs Execution: It is also possible to start the cron jobs which
reveal plethora of information due to the usage of debugging calls. The
majority of the time cron jobs produce a heck lot of output showing the success
of running software. The example shown below presents the creation of database
by a specific cron job in one of the vulnerable Jenkins configuration. It reveals
how the table of OAUTH tokens is created and index is generated.
 |
| Information Leakage through Cron Jobs ! |
Information Disclosure in
Debug Errors: During a
quick check in certain Jenkins configurations, it has been noticed that the
Jenkins server does not handle the requests to restricted resources in a secure
manner. The attacker can perform additional steps to request access to restricted
resources to generated debug errors as shown below:
 |
| Information Disclosure in DEBUG Errors ! |
Some of the standard requests specific to Jenkins are shown below:
Explicit CSRF Protection: It is always a good practice to analyze the
design of the application from security standards. Some security standards
should be deployed in the application by default. For example: - Jenkins
provides a global security option in which protection against CSRF attacks have
to be explicitly checked. If this option is not checked, the Jenkins
application fails to deploy the protection globally. During our analysis, it
has been noticed a number of Jenkins systems are running without CSRF
protection which makes them vulnerable to critical web attacks.
 |
| Explicit Security Configuration ! |
SSH Endpoint Disclosure: Jenkins implements a SSH random port feature in
which the software randomize the port selection for running SSH service.
Typically, when a client sends a GET request, Jenkins replies back with
"X-SSH-Endpoint" HTTP header which leverages the information in the
form of host: port. It means SSH service is listening on following host with
given port number. If the system is already exposed on the Internet, the
attacker can easily glean information about the port number on which SSH server
is listening. A real time example of a server running Jenkins is shown below:
 |
| SSH Endpoint Disclosure ! |
This information discussed in this post only provides a glimpse of
security risks associated with the poorly administered software managing
applications. These applications can provide a potential beef for the attackers
to gain substantial amount of information about the organization and server
side environment which facilitates the additional attacks.
For replicating the issues, trigger
Google dork as: intitle: "Dashboard [Jenkins]" for getting a
list of Jenkins server available on the Internet.
Impacts: As shown above, the misconfigured software management applications can have
severe impacts as discussed below:
- Information about developers can be used to conduct
Phishing attacks including social engineering trickery to launch targeted
attacks.
- A common mistake for not enabling the CSRF
protection exposes the Jenkins environment to number of critical web
vulnerabilities such as Cross-site File uploading.
- In appropriate error handling discloses information
about the different stack traces and internal components of the software.
- Unrestricted cron jobs will result in successful
running of different builds of the software. As shown above, information
disclosed in the console output results in leakage of sensitive data such as
secret keys. The attacker can use the secret keys to attack target servers.
- Disclosure of software build information provides an
attacker with a complete knowledge of the updates and modification that have
taken place in the software. This information is beneficial for hunting
security vulnerabilities or design analysis.
Recommendations:
- For
software development and management interfaces, restrict the access completely.
It is highly recommended that the server should be configured with complete
authentication. It means no functionality of the application should be allowed
to be accessed without authentication or in a default state.
- Simply
removing the HTTP links from interfaces is not a robust way to restrict access.
The links can be fuzzed easily to gain access to hidden functionality. Deploy
security features using a global configuration.
- Standard
security protection mechanism should be enabled by default without asking any
preferences from the users or administrators.
- Administrator
should verify the new account creation in software like Jenkins before an
access is granted to the registered user.
Configure Well and Be Secure!
