In this Post, I show how I have create the Proof Of Concept for CVE-2020-2229 . I found a vulnerable version Jenkins 2.249 during a Penetration Test, I was trying to investigate available exploits for this vulnerability, but I did not find anything. Well, Jenkins is an amazing wonderful project, the best way that I can use to study it is … by looking at vulnerabilities! Let’s prepare the environment.

Our proof of concept is actually available in exploitdb repository:

Do not look before studying this post! You need to find it by yourself!

Prepare Vulnerable Environment

To find how it is possible to exploit a vulnerability, you need to reproduce the vulnerable environment. Obvious, isn’t πŸ™‚ ?

Using Docker Security Playground

You can use our to run the vulnerable environment. I have created a specific vulnerable env to develop this project.

You can start the vulnerable jenkins by command line:

  1. Install docker
  2. Run docker run -p8081:8080 –rm dockersecplayground/jenkins:2.249

Or by using Docker Security Playground application:

cd DockerSecurityPlayground
npm start

Navigate http://<dsp>:8080/lab/use/DSP_Projects/CVE-2020-2229_Jenkins-Tooltip-XSS

And start lab:

Now you can navigate jenkins at <dsp_url>:8081/jenkins url.

Using virtual machine

Of course, you can also created a local virtual machine containing a tomcat server and install vulnerable Jenkins version. Here some useful links:

Study the vulnerability

Jenkins is an open-source project, so you can use information from github repository, security advisors, project documentation to obtain information to understand the vulnerability. the first thing that I have searched is … the description of the vulnerability:

Jenkins 2.251 and earlier, LTS 2.235.3 and earlier does not escape the tooltip content of help icons, resulting in a stored cross-site scripting (XSS) vulnerability.

“tooltip content of help icons”. As usually, it is very generic :), and we do not have any knowledge about Jenkins… but Jenkins is a great tool, and there is a larget documentation. We will investigate after.

1 – Search information in source code

The combination of security advisor and code fixes is excellent. A good starting point to understand the vulnerability and where it occurs is by searching fixes in source code. In open-source projects, you can search it by using diff between commits, if the project is hosted on github and other version control systems. If the source code is not public available you can try deobfuscation techniques and other techniques to obtain source code … navigate in assembly code if nothing works!!! If you cannot obtain the code… you can still use fuzzing techniques, study the communication with proxy tools (Burp, ZAP in web applications), and study client-side code techniques.

2 – Search cve in github

Which information is available in github repository?

Search in PR with “CVE-2020-2229” keyword find useful information?

I started the vulnerability discovery, by looking for available epxloits and googling. Search for CVE in google “CVE-2020-2229 Jenkins” you can see that there are not avilable exploits (before our exploitdb submission πŸ™‚ ) , but there is an interesting information: Jenkins uses a Security Advisor that maps every vulnerability with a Jenkins Security ID:

CVE-2020-2229 has the following security ID : SECURITY-1955.

We have more information in the Jenkins 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.

The information “tooltip values can be contributed by plugin” is interesting: maybe we need to upload a vulnerable plugin to create our Proof Of Concept? We will investigate later.

Step 3: Search Jenkins SECURITY ADVISOR ID in github

Can Jenkins Security ID be useful to find information about the vulnerability in Github?

Something WORKS!!! Search internal pull requests gives us more information:

We have found a very interesting information!!!! The fix is escaping tooltip attribute of something called svgIcon.jelly located in core/src/main/resources/lib/layout/dir! Do you remember initial description?

Jenkins 2.251 and earlier, LTS 2.235.3 and earlier does not escape the tooltip content of help icons, resulting in a stored cross-site scripting (XSS) vulnerability.

But there are still missing information:

  • What is “jelly”?
  • What is core/src/main/resources/lib/layout/ and how is it used?
  • Do we need to create a plugin?

Now it is time to study our source code.

Study Jenkins source code

Configure github source code

Ok, download github source-code, set git vulnerable branch and study it.

Most important command … git clone πŸ™‚

I usually use Visual Studio Code to study source code. It is light and powerful. I suggest you to study in depth if you want to explore vulnerabilities in source code. Useful shorcuts :

  • ctrl+shift + f : find in all files a string
  • ctrl + p : find a file in loaded folders

Searching for information in code

Let’s look information about svgicon.jelly file:

It seems a sort of xml file. But … what is Jelly?

Jenkins helps us:

It is a way to create user interface in Jenkins. Jenkins suggests us to download ui-samples-plugin to understand how it is possible to use it.

Ok, clone the project (git clone ) and study it by using Visual Studio code.

What is it? It is a Jenkins Plugin . Is there any documentation about building plugins? Of course: .

Build sample-ui-plugin to study it in our vulnerable environment

Now we upload sample-ui-plugin to study. Build the project:

mvn package

The project is built. How can we upload plugins in Jenkins? Login in our Jenkins server:

By looking at the documentation, we can upload the plugin by using hpi extension. mvn package has created a target dir containing this file:

The installation generates a new Context Menu. By studying the plugin documentation:

it is right because main class ( implements ModelObjectWithContextMenu interface:

List of samples contains two types of templates:

We need to study Jelly templates, so open one:

It contains a “Source Files” string and a “Sample” string: look at one string by using VS Code:

It is presented in a jelly sample file.

Layout importing

What are we looking for? We need to understand how it is possible to “use” svgIcon belonging to layout dir. XSS is present in “tooltip” attribute, as seen in the fix source code. We see in sample.jelly several tags. By studying jelly we understand that it is possible to reuse Jenkins jelly tags in our source code. There is a reference about layout pages:

SVG Icon belongs to the list of reusable components. So, if we understand how it is possible to reuse layout components, and how the XSS vulnerability is related with the tooltip attribute, we can create our Proof Of Concept.

How can we add layout elements to the plugin?

Try to upload a simple TEXT inside the sample.jelly, rebuild the plugins and verify that your changes are uploaded in the GUI:

mvn clean and mvn package to rebuild

Verify that your code is properly updated:

Ok, try now to upload a layout element. Try … svgIcon πŸ™‚ and study tooltip how works. Something like this:

<l:svgIcon tooltip=”mypoc”><path d=”M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z”></path></l:svgIcon>

Now we have a good knowledge about are ready to study svgIcon.

Study svgIcon

Which information does Jenkins gives us about svgIcon ?

Those are attribute components. We can set it by using name=value syntax. Ok, but how it is possible that Jenkins does not protect against XSS ? We need to study.

Study XSS in Jenkins and tooltip attribute

Is there any information about XSS in Jenkins? First github result:

“xss jenkins” in google

Most important information is here:

Jenkins components use escape-by-default=’true’ to protect against XSS … but tooltip is an attribute, right? Look at the Note …

So, if an attribute allows HTML code, we can inject XSS by using img attribute. The major question now is:

Does tooltip attribute allow HTML?

The answer is YES! Search in google:

“jenkins tooltip”

Perfect! We have found our way to inject HTML code in a tooltip attribute.

The combination svgIcon tooltip attribute + HTML in tooltip attribute gives us the XSS.

Final PoC

We know how it is possible to inject HTML , we know that tooltip attribute is present in svg icon… now we just have to write our PoC:

<l:svgIcon tooltip=”&lt;img src=a onerror=alert(1)&gt;”><path d=”M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z”></path></l:svgIcon>

Insert it in your “plugin build toolcain”, build and upload the plugin in Jenkins. Navigates the Jenkins and you will see the icon:

BINGO: XSS alerted

What Now?

The proof of concept is actually available in exploitdb repository:

Now try to use the same methodology for another type of Jenkins vulnerability:

My public exploit for CVE in exploitdb is under review, I think, they do not answer me (maybe two exploits in a day is too much???)

In next post, I am going to show you how we can find this CVE by using a black-box approach, without looking at source code πŸ˜‰

Security is SeCSI πŸ˜‰