Jenkins 2.235.3 Cross Site Scripting

2020.12.13
Credit: gx1
Risk: Low
Local: No
Remote: Yes
CWE: CWE-79

# Exploit Title: Jenkins 2.235.3 - 'tooltip' Stored Cross-Site Scripting # 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-2229 # References: https://www.jenkins.io/security/advisory/2020-08-12/#SECURITY-1955 https://www.openwall.com/lists/oss-security/2020/08/12/4 Vendor Description: Jenkins 2.251 and earlier, LTS 2.235.3 and earlier does not escape the tooltip content of help icons. Tooltip values can be contributed by plugins, some of which use user-specified values. This results in a stored cross-site scripting (XSS) vulnerability. Jenkins 2.252, LTS 2.235.4 escapes the tooltip content of help icons. Technical Details and Exploitation: As it is possible to observe from patch commit: https://github.com/jenkinsci/jenkins/pull/4918/commits/c991b45b5bae09f9894acdc1f1fb1d8809fe6ef6 The fix to solve the vulnerability is applied to 'core/src/main/resources/lib/layout/svgIcon.jelly' tooltip attribute: <svg class="svg-icon ${attrs.class}" viewBox="${attrs.viewBox != null ? attrs.viewBox : '0 0 24 24'}" focusable="${attrs.focusable != null ? attrs.focusable : 'false'}" aria-hidden="${attrs.ariaHidden != null ? attrs.ariaHidden : ''}" style="${attrs.style}" onclick="${attrs.onclick}" tooltip="${h.xmlEscape(attrs.tooltip ?: '')}"> svgIcon is a layout element belonging to jenkins core: https://reports.jenkins.io/core-taglib/jelly-taglib-ref.html#layout:svgIcon As suggested by Jenkins documentation (https://www.jenkins.io/doc/developer/security/xss-prevention/) "Note that this only affects the use of ${...} among PCDATA, and not in attribute values, so that Jelly tag invocations don’t result in surprising behavior." Tooltip attribute can contain HTML code, as suggested in form section: https://www.jenkins.io/doc/developer/forms/adding-tool-tips/ For this reason, it is possible to inject XSS code in a Jenkins system by uploading a plugin that contains an <j:svgIcon> element containing a malicious XSS payload in tooltip attribute: <l:svgIcon tooltip="<img src=a onerror=alert(1)>">...</l:svgIcon> To build a Jenkins plugin, visit https://www.jenkins.io/doc/developer/tutorial/create/ . To obtain information about Jelly syntax, visit https://wiki.jenkins.io/display/JENKINS/Basic+guide+to+Jelly+usage+in+Jenkins Proof Of Concept: 1. Obtain access to upload Jenkins plugins, or find plugins that can insert svgIcon element. 2. Generate a plugin. For example, you can create a class that implements ModelObjectWithContextMenu interface to create a context menu and implement the method getUrlName() containing a <plugin-url> string that you can navigate by using the link: http(s)://<jenkins_server>/<plugin-url> 3. In jelly file, insert the following element: <l:svgIcon tooltip="<img src=a onerror=alert(1)>"><path d="M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z"></path></l:svgIcon> This creates an icon that triggers the Cross-Site Scripting when the mouse is over and opens tooltip. Obviously, you can use css and large size and height to generate a svg element that covers all the screen in order to trigger the XSS when the user navigates the page. Solution: The following releases contain fixes for security vulnerabilities: * Jenkins 2.252 * Jenkins LTS 2.235.4 ------- # Exploit Title: Jenkins 2.235.3 - 'Description' Stored XSS # 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-2230 # References: https://www.jenkins.io/security/advisory/2020-08-12/#SECURITY-1957 https://www.openwall.com/lists/oss-security/2020/08/12/4 Vendor Description: Jenkins 2.251 and earlier, LTS 2.235.3 and earlier does not escape the project naming strategy description that is displayed on item creation. This results in a stored cross-site scripting (XSS) vulnerability exploitable by users with Overall/Manage permission. Jenkins 2.252, LTS 2.235.4 escapes the project naming strategy description. Technical Details and Exploitation: As it is possible to observe from patch commit: https://github.com/jenkinsci/jenkins/pull/4918/commits/7529ce8905910849e890b7e26d6563e0d56189d2 The fix to solve the vulnerability is applied in activateValidationMessage function to 'war/src/main/js/add-item.js' javascript file: function activateValidationMessage(messageId, context, message) { ... $(messageId, context).html('&#187; ' + message); // AFTER FIX: $(messageId, context).text('» ' + message); ... } The function is called during the creation of a new Item, on "blur input" event (when text element of name input is focused): $('input[name="name"]', '#createItem').on("blur input", function() { if (!isItemNameEmpty()) { var itemName = $('input[name="name"]', '#createItem').val(); $.get("checkJobName", { value: itemName }).done(function(data) { var message = parseResponseFromCheckJobName(data); if (message !== '') { activateValidationMessage('#itemname-invalid', '.add-item-name', message); // INJECTION HERE } else { cleanValidationMessages('.add-item-name'); showInputHelp('.add-item-name'); setFieldValidationStatus('name', true); if (getFormValidationStatus()) { enableSubmit(true); } } }); } else { .... activateValidationMessage('#itemname-required', '.add-item-name'); } }); as "message" param is the injection point, we need to trigger an "invalid item name": when you are creating a new item and the name is not compliant with validation rules, an error is triggered. Error message is not escaped for vulnerable versions, so it is vulnerable to XSS. Validation rules can trigger an error in several ways, for example: - if the current item name is equal to an already existent item name; - if a project naming strategy is defined: in this case, if the project name is not compliant with a regex strategy, a error message is shown. In the first case Jenkins seems to be protected because when a new project is created, it is not possible to insert malicious characters (such as <,>). In the second case, the error message also shows a description, that can be provided by the user during the regex strategy creation. In description field, it is possible to inject malicious characters, so it is possible to insert an XSS payload in description field. When the user insert a name that is not compliant with project naming strategy, the XSS is triggered. Proof Of Concept: 1. In <jenkins_url>/configure create a new Project Naming Strategy (enable checkbox "Restrict project naming") containing the following values: Pattern: ^TEST.* Description: GX1h4ck <img src=a onerror=alert(1)> 2. Go to New element creation section (/<jenkins_url>/jenkins/view/all/newJob). When you insert a character in the name field, alert is triggered. Solution: The following releases contain fixes for security vulnerabilities: * Jenkins 2.252 * Jenkins LTS 2.235.4


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top