Inti De Ceukelaire currently works as the Head of Hackers at ethical hacking platform intigriti. In his spare time, Inti identifies and reports security problems to affected companies.

In the light of the COVID-19 crisis, millions of organisations across the globe had to quickly relocate their daily operations from an office to employee’s residences. As expected, this turned out to be a challenging task, even for companies already familiar with remote working solutions. Numerous cybersecurity professionals raised concerns about the potential security consequences the sudden migration from office to household can cause, but very few were able to provide tangible data of the effects of COVID-19 on the global state of cybersecurity.

Internal ticketing tools like JIRA and Asana enable organisations to get work done in a structured way. Most corporations require its employees to create tickets to request, change or get help with something that is out of their control. Whether it is ordering a new ID badge, requesting access to a tool, getting expenses reimbursed or troubleshooting login problems, the solution is often a ticket away in a remote work environment. And so are hacking attempts — if your internal helpdesk is publicly exposed.

An increasing number of Atlassian JIRA Servicedesks have been misconfigured to be accessible for anyone to sign up. In essence, this is nothing to worry about as servicedesks may have legitimate reasons to be public. However, a growing number of instances have been repurposed to serve as an internal service ticket portal, allowing attackers to impersonate employees and create legitimate internal requests. Verifying the legitimacy of these requests has proven to be far less convenient without offline verification channels: you can’t just walk up to your colleague and ask them about it.

The issue

A substantial amount of internal service desks are being exposed to the outside world for anyone to access. In order to join a misconfigured service desk, all an attacker needs to do is navigate to the service desk login page of an Atlassian instance — often just the name of the company.

For the sake of a proof of concept, I have created a service desk at https://yourcompanyname.atlassian.net. The instance itself will load the default Atlassian login page, which is properly protected against external intruders:

Unknowing administrators might think they’re protected, whereas their service desk is in fact, still open to the public. The only thing an attacker needs to do is to navigate to this URL instead:

This link provides access to a second login portal, that allows everyone to sign up in this configuration (click on sign up) and access the support portals:

Our demo environment is obviously empty — so let’s look at some real examples!

Projects can be set up for various purposes, such as IT, HR, Facilities, Finance & Legal, but this does not seem to affect the public registration settings.

Exploitation in the wild

I was curious just how many companies had their internal servicedesks publicly available and decided to automate this process: I took a list of 10.000 popular domain names globally and found out that no less than 288 of 1.972 (roughly 15%) corresponding Atlassian instances were open to the public. This was an increase of 12% compared to tests conducted before the COVID-19 crisis — my earliest scans date back from last summer. This was only a rough estimate: my automated workflow would just extract the domain name and check whether sign ups are enabled for this namespace. It wouldn’t check whether the company name is different from the domain name, or if the service desk actually belongs to the company that shares the same name.

So I went ahead and signed up for some of these service desks. They were public, after all. Pretty soon I discovered that these service desks should never have been exposed, looking at their titles only. The screenshots below are real, but slightly modified in order to remove references to affected companies (with permission).

Just one of the hundreds of ‘internal’ service portals exposed to the internet

The example above is very similar to the numerous instances I tested. The support portals cover various topics, such as HR, internal IT troubleshooting, Developer Operations, Office Helpdesks, Data & Privacy Requests, Information Security, UX, Marketing, Data Science, …

All of these portals would contain various sub-topics with common requests internal employees can create:

I won’t flood this blog with screenshots of company’s internal service portals, but here’s a selection of things I’ve seen:

Getting new access badges to the physical office delivered

Onboarding new employees

Requesting salary changes

Requesting information about employees

Requesting information about customers

Requesting changes to online assets or webpages

Requesting access to social media channels

Requesting access to internal tools

Requesting internal security assessment reports

Unblocking users

Resetting multi-factor authentication

Declaring expenses

Initiating a GDPR request for a customer

VPN whitelisting

Requesting execution of queries on the database

Requesting code to be executed on the company’s web server

…

Misconfigured servicedesks leaking tons of PII

About one third of the servicedesks I joined allowed me to assign tickets to other users. In certain configurations, where users are created for any inbound support e-mail (with their display name automatically set to their e-mail address), this would leak the e-mail addresses of every user that has interacted with the external support channels as well.

Some misconfigured service desks would leak (customer) e-mail addresses through the ‘assign’ functionality

A servicedesk accidentally leaking personal e-mail addresses of its customers

The aftermath: from being ignored to $10,000

Since the only thing I had to do was check whether a signup page existed or not, I could easily test this for hundreds of companies without the risk of getting into legal trouble: the service desks were public, after all. Once I had identified possible victims, the disclosure process was painful to say the least: more than 85% of all vulnerable companies did not have a way for me to responsibly disclose a vulnerability to them. Of course, I could create an internal ticket myself in this case, but I’m not sure how that would have been perceived from a legal perspective. In some cases, I went through the hustle of contacting the external customer service, but about half of all reach-outs did not get escalated.

Over the past few weeks, I have worked with around 25 companies to properly secure their service desk. At least one had noticed other rogue accounts except for mine, so it seems like more hackers are aware of this configuration flaw as well.

The impact assessments greatly varied from accepted risk to critical. Some companies decided to award a monetary reward, ranging from €50 to $10,000 (In the latter case, I would have been able to run malicious code through submitting a code execution request their service desk).

Whether you offer rewards for security bugs or not, every company should have a policy and contact for individuals to report security vulnerabilities to them. Thousands of internal service desks are most likely still exposed, simply because I had no escalate this to the right people, as an outsider.

There is no excuse not to have a vulnerability disclosure process in 2020. They come at all forms and sizes — from implementing something as simple as security.txt to running a bug bounty program at intigriti.com: the choices are endless.

FAQ