Jira RCE (CVE-2019-11581) to Domain Admin

Introduction

This article will talk about a critical vulnerability affecting Jira application which was discovered on 08/09/2019 and how to exploit it. The exploitation is built through a scenario that shows the criticality of the vulnerability on the entire organization.

The Vulnerability

As the article described, the functions "Bulk Email Send" and "Contact Admin" were affected by server-side template injection. The "Bulk Email Send" needs admin privileges on Jira to be exploited, making it a privilege escalation vulnerability that enables Jira admins to run OS commands as SYSTEM (if running on Windows). The "Contact Admin", however, can be exploited by unauthenticated users to run OS commands as SYSTEM as well. This functionality needs to be enabled, however, as it is not enabled with the default installation of Jira, and it requires configuring an SMTP server.

After configuring the SMTP server and enabling the "Contact Admin" feature, the affected form can be accessible on this URL:

The "Contact Admin" page can be accessed through the "Jira administrators" link on the main page.

The vulnerable field of the form is the "Subject".

The article is using a CURL payload that will request a page on the attacker's machine as a PoC:

But, what if you wanted a shell?

Exploitation

I wanted to extend this PoC to an interactive reverse shell on a Windows machine with Windows Defender running. I tried several payloads to get a reverse shell, and one of the ones that worked perfectly was utilizing mshta.exe through a Metasploit module that hosts the payload on a web server on kali.

Now that we have Metasploit set, let's use the payload on the "Contact Administrator" form. The vulnerable field is "Subject". Our payload will be as follows:

After submitting the form, it took some time to execute, but we get our Meterpreter reverse shell after a few seconds.

By typing (sessions), we see that our reverse shell is running as SYSTEM.

Entering our session and running (sysinfo), we see the information about the compromised Windows server.

Server name: WEF
Domain: WINDOMAIN

We have finished the exploitation phase at this point. However, to show a real impact, let's perform some post-exploitation activities to show what attackers may be able to do after exploiting a vulnerable Jira.

Post-exploitation

Since we have SYSTEM privileges on the WEF server, and we are in an AD environment, let's see if there are any domain users on the machine that we can impersonate to escalate our privileges through the domain.

By loading Meterpreter's Incognito (load incognito) and listing user tokens available (list_tokens –u), we see there are two users in the domain, "osama" and "vagrant".

Let's see what groups those two users are member of by typing (net user <user> /domain).

Starting with "vagrant" user, we see he is part of several AD groups.

Checking the other user, "osama". We see he is part of the "Domain Admins" group. This means "osama" is a domain administrator.

Knowing that "osama" is a domain admin, let's impersonate his token instead of "vagrant". By using Incognito, we impersonate his token by running
(impersonate_token WINDOMAIN\\osama)

running (whoami), we can see that we now are running a session as "osama"

Now that we are running as a domain admin, we can pivot to the domain controller "dc" using PowerShell Remoting (etsn is an alias to Enter-PSSession)

This simple scenario is made in a lab environment to show the potential impact of exploiting a vulnerable Jira application, but it could happen in the real environments too.

Mitigation

If you are using Jira application, ensure that you have the latest version installed. To check which versions that are vulnerable to this particular vulnerability (CVE-2019-11581), you can check Jira Security Advisory in the below link:

https://confluence.atlassian.com/jira/jira-security-advisory-2019-07-10-973486595.html