# Exploit Title: Jenkins Stored XSS vulnerability in 'Trigger builds remotely'
# Date: 11/12/2020
# Exploit Author: gx1
# Vendor Homepage: https://www.jenkins.io/
# Software Link: https://updates.jenkins-ci.org/download/war/
# Version: <= 2.251 and <= LTS 2.235.3
# Tested on: any
# CVE : CVE-2020-2231
Jenkins 2.251 and earlier, LTS 2.235.3 and earlier does not escape the remote address of the host starting a build via 'Trigger builds remotely'.
This results in a stored cross-site scripting (XSS) vulnerability exploitable by users with Job/Configure permission or knowledge of the Authentication Token.
Jenkins 2.252, LTS 2.235.4 escapes the remote address of the host.
Technical Details and Exploitation:
When a build of a project is completed, Jenkins returns a message in completed build process. Build process is present in build history view.
The message reflects the username, for example "Started by user gx1".
Anyway, when 'Trigger builds remotely feature' is enabled, instead of the username the remote client IP is reflected, i.e.:
Started by remote host '<client-ip-address>'.
To understand how remote build trigger works, have a look at this post: https://narenchejara.medium.com/trigger-jenkins-job-remotely-using-jenkins-api-20973618a493
The message "Start by remote <client-ip-address> is not escaped. This could seem without security issues because the user cannot change the remote IP, right? This is not completely true... when the application server is behind a proxy, "remote client IP" is not available, as the request comes from the proxy.
In these cases, X-Headers are used to allow the application server to understand the real client information. A common header is X-Forwarded-For: X-Forwarded-For HTTP header is inserted by load balancers into the data stream to identify the address of the connecting client system.
To exploit the vulnerability several conditions should be met:
- Remote build should be enabled and if needed the attackers should have obtained API authentication token or should have Job/Configure permission
- Application server that hosts Jenkins should use some X-Header to override client IP. This happens often, because usually the application server is under proxy, and in order to obtain client IP, override mechanisms are used.
For example, in Apache Tomcat, it is possible to configure X-Forwarded-For heaer processing, as described in https://dacurry-tns.github.io/deploying-apereo-cas/setup_tomcat_configure-xforwardedfor-header-processing.html.
Proof Of Concept:
1. Identify the X-Header that is used by the Application Server to override proxy ip. Let's suppose that "X-Forwarded-For" is used. In this condition, the attacker can inject malicious payloads in "X-Forwarded-For" header value to exploit the vulnerability;
2. Send the following request:
GET /job/<project_name>/build?token=<token> HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=88DD2A6297E0E0FE9A59B310CA271715; screenResolution=1220x686
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Date: Fri, 11 Dec 2020 17:04:06 GMT
<project_name> is the project that can be remotely built by using <token>.
3. To trigger the XSS, navigate the build item present in the build history when the build is finished. For example, if the build current finished process is #16, stored XSS is present in
The following releases contain fixes for security vulnerabilities:
* Jenkins 2.252
* Jenkins LTS 2.235.4