In a recent external network engagement, which had a fairly large number of external services, I found a Jira login page available on the client’s external network. The login page belonged to a Jira Software service, an issue-tracking system used in project management and software development.
https://jira.example.com
The Jira Software version was just few versions behind, and by looking at the publicly available CVEs I couldn’t find any vulnerability that would allow me to gain authenticated access in the application. I tried some light password spraying using the email addresses identified during reconnaissance, however that didn’t reveal anything more useful.
As the scope was quite large, I moved on and tried to look for the keys to the kingdom in another place. As most of the other vulnerabilities required client-side interaction or didn’t have any practical exploits available, I returned to the Jira Software service. I performed a content discovery attack to check for any default files. Luckily, I’ve found that besides Jira Software, a Jira Service Desk login page was also running on the same server. Jira Service Desk is a ticketing system for end-users to submit tickets to a help desk team.
In this case, a self-registration link was also available in the login page, as shown in the screenshot below.
https://jira.example.com/servicedesk/customer/user/login
The user that I could register had limited permissions, just to create issues and there was not much you can do other than launching client-side attacks against site administrators via malicious attachments. Because this wasn’t a red team engagement, I didn’t try to exploit this any further.
While reviewing some screenshots I realised there was one functionality I initially overlooked, which was sharing a Jira Service Desk issue with an existing user, as shown in the screenshot below:
https://jira.example.com/servicedesk/customer/portal/{PortalID}/create/{IssueID}
In the background, this functionality calls the following REST API which searches for existing users:
https://jira.example.com/rest/servicedesk/1/customer/participants/SD-12345/search?q=a
[
{
"id": "[email protected]",
"userKey": "[email protected]",
"displayName": "a.b",
"emailAddress": "[email protected]",
[…]
},
{
"id": "[email protected]",
"userKey": "[email protected]",
"displayName": "a.c",
"emailAddress": "[email protected]",
[…]
}
As the REST API output is limited to only 20 users, I wrote a quick Python script to extract all the usernames. To my surprise this included ~2000 users, including Active Directory usernames and local Jira users. Armed with this list, I did a light password spraying attack using the infamous “Password1” and got access to 10 Jira user accounts. Among them, there was one powerful Jira user which seemed to be a shared account used by the service desk team.
I browsed through the issues and found an absolute wealth of sensitive information, including credentials for various servers and applications. Among them, also a default password set for new Active Directory users. I reiterated the password spraying attack with the default password and unsurprisingly there were quite a few users having this password.
Although the client had 2FA on their main VPN endpoint, they also had a Citrix environment externally available which lacked multi-factor authentication. As Citrix hardening was not in place, I could easily spawn a CMD shell to get interactive console access on the Citrix server, which is almost equivalent to compromising the entire domain. In this case it was agreed with the client to stop any further exploitation against the internal network, and just compile and report the identified issues.
https://citrix.example.com
Mitigation
There are a couple of things that organizations can do to protect their external network. First, minimise the attack surface by either disabling any services which are not required externally or by applying access control to allow only connections from authorised IP address or by publishing services behind a VPN connection. For those services which remain available on the internet, perform a risk assessment and ensure that any sensitive services require multi-factor authentication.
Secondly, ensure a password hygiene is maintained by enforcing strong password policies and periodic password security audits. Where possible, login pages should also be protected by a strong CAPTCHA mechanism to hinder brute-force attacks. These should be coupled with user training on choosing strong pass-phrases, especially for help-desk staff.
Finally, review configuration management procedures to ensure that production systems are effectively hardened. In the case of Jira, ensure a strong password policy is configured, public self-registration is disabled and that security patches are timely installed. The vendor has documented some of these security best practices here and here.