Hundreds of companies’ internal data exposed — Part 2: The FreshService misconfiguration

One misconfiguration, hundreds of companies, thousands of dollars in bounties… again.

Mohammed Moiz Pasha
InfoSec Write-ups
10 min readMay 13, 2024

Note: This is NOT a vulnerability in Freshservice. This is a misconfiguration affecting a subset of companies using Freshservice, and is caused by a misconfiguration on part of the company using Freshservice for ITSM, not Freshworks.

Introduction:

About a year ago, I found a misconfiguration in Atlassian Cloud instances, which affected hundreds of companies worldwide. The misconfiguration allowed attackers to view internal and sensitive information of the affected company, with no authentication whatsoever. You can read my article on this misconfiguration here.

This finding of mine prompted me to research other such IT service management platforms, which are widely used by teams to coordinate internal IT tickets, share help articles with employees, and request services from the company. That was when I first stumbled across Freshservice.

Freshservice is an ITSM tool used by over 60,000 customers all over the world. It enables organizations to simplify and integrate their IT operations, by offering features that include a ticketing system, self-service portal and knowledge-base. You can read more about Freshservice here.

Since the Freshservice infrastructure appeared to be very similar to my previous Confluence finding, I decided to take a look and see whether any similar misconfigurations/vulnerabilities existed here as well.

In this article, I will describe how a misconfiguration in Freshservice caused (and is still causing) the exposure of internal and sensitive information of various organizations and companies. I will also be sharing the results of my research, which uncovered hundreds of companies with the same misconfiguration, and led to thousands of dollars in bug bounties, including my highest one ever :)

The misconfiguration

In my research, I found that a lot of companies opt for Freshservice cloud servicedesk instances over on-premise. These cloud instances are usually of the form:

https://<company_name>.freshservice.com

This immediately piqued my interest, since it would make automation easy for any surface-level detection I had to perform. With this knowledge in mind, I began to take a look at the Freshservice portal itself.

After a few minutes of inspection, what I realized was that the test instance I created had a “Log in” and “Sign up” option in the support portal by default. I immediately tested the “Sign up” functionality, and found that registration was enabled (for any domain name, not just @ company.com). This means that if proper login checks were not put in place by the company on their instance, an attacker could potentially sign up and then login with any email address and gain access to the portal.

Apart from signup, I also found that the login page contained a “Log in with Google” functionality, which allowed me to log in to the service portal with my Google account, without signing up beforehand.

I then realized that this login and sign up functionality, if enabled on an organization’s Freshservice instance, can very easily lead to unauthorized access. In order to test out my theory, I whipped up a quick Python script and started checking public Freshservice instances. Since all I had to do was check if the sign up or login functionality existed, I could easily automate this for thousands of domains, also without getting into legal trouble.

The results

The results of my automation were astonishing: hundreds of companies had their Freshservice instances open to the public, allowing anyone to sign up and gain access to their internal service desk. A small subset of companies had their sign up page disabled, but allowed login through Google, which led to the same result. After checking if a particular domain was actually owned by the company, and if they had a vulnerability disclosure policy or bug bounty policy with all assets in scope (see footnotes), I decided to sign up for these service desks to see what I could find.

Here’s a summary of what I found:

There are three major services of Freshservice which I found almost all the companies to be using. The first is the solutions section, where self-support articles are posted. Second, the service catalog, where employees can request commonly used services. The third is the general ticketing service, where any requester can raise an issue with the support team.

In the solutions section (over all instances), I found the following:

  • Detailed help articles regarding common problems and activities, from setting up 2FA to connecting to the office printer and everything in between
  • Troubleshooting procedures, incident management documents, and internal policies
  • Employee onboarding procedures (More on this below)
  • Default passwords, meeting recording links (and their passwords), Client project details and other confidential information, etc.
An example articles page. Most of the screenshots I have contain confidential information, which would need to be heavily blurred, so this one is the best I can do.

The service catalog page allowed me to request common services used by HR and IT, such as:

  • Employee onboarding and offboarding
  • Access to various services such as AWS cloud, Looker, Active Directory, VPN, etc.
  • Payroll support
  • Order a new work computer and other hardware
  • Change user privileges, and much more

Another interesting feature I found was that you could provide your own email address while requesting a service, which an attacker can easily fill in with a fake company email address to make the request seem genuine. This would create an extremely effective attack vector for social engineering, especially since the portal is supposed to be for internal use.

The service catalog for one of the affected instances

After experimenting on a test instance for a bit, I also made another major discovery:

If you click on the User icon (in the top right corner) and select
Edit Profile, you will be taken to a page to edit your profile.
On this page, by default, there is an option to “Delegate Approvals”. This option is intended for agents to delegate their tickets for a short period of time to another agent.

Freshservice allows you to delegate your ticket approvals not just to another agent, but to any user registered in the portal. In order to do this, you have a convenient search box, to search for the requester by name or email.

After discovering this, I wrote another quick Python script which would extract all the name and email addresses from this search box for me. I then ran this Python script against the misconfigured portals (with permission, of course).

Delegate Approvals

The results? Hundreds of email addresses and names including those of service agents, employees of the company and even employees of client companies registered with guest accounts.

How serious can this get?

In order to demonstrate how seriously this misconfiguration can affect a company, I would like to relate a very unique case, which I believe perfectly demonstrates the extent of damage that can be done, and is also the story of my highest single bug bounty ever.

I found a misconfigured service desk for a fairly large company that had a private Bugcrowd program. This service desk contained two options: one for logging in with JumpCloud SSO, and the second for “Sign in with Google”. Since all assets were in scope for this company, I decided to use a test Google account and log in to the service desk.

The first thing I did was go through the solutions page, to see if I could find anything worthwhile.

This is what I found:

Thanks for the help! Much appreciated

A step-by-step guide for new employees to setup their account for JumpCloud SSO. All their new employees were apparently given an email address with a temporary JumpCloud password, which was supposed to be changed during the onboarding process. This password, as it happens, was conveniently mentioned in plaintext right in the article itself.

Immediately, my mind went towards bruteforcing the JumpCloud SSO with the temporary password and a list of email addresses, and seeing if I could find at least one account which had not been fully activated yet. All I lacked now was a list of valid email addresses to check the password against. Ring a bell?

Sure enough, the “Delegate approvals” panel was visible in the user profile. I ran my Python script, and managed to gather ~100 email addresses, all of which were valid.

I then ran a simple script to bruteforce the password and the list of emails against the JumpCloud login portal. All of the attempts failed, as the employees had enabled 2FA and changed the password.

Except for one email address (not an employee, but a service address I believe), which logged me in to the JumpCloud SSO.

SSO

There were only two applications in here: One for logging into Freshservice and another for logging into Envoy.

Envoy is a solution that allows companies to enable employees to connect with coworkers, schedule meetings, book rooms, etc. If I was able to access the company’s Envoy cloud, I would have been able to view details of all their employees (including phone numbers, email addresses, etc.), get the entire office layout, and much, much more.

I tried to log in to Envoy through the SSO. Sadly, since this was apparently the first time the account was logging in to Envoy, it asked me for an OTP sent to the email address.

Dismayed, I went back to the Freshservice portal to look for other information that could help me.

Directly below the first article with the temporary password, I found this:

Congrats indeed

The temporary password, which I had used to login to JumpCloud, was also the same for the Google Workspace account. I went to Google accounts, entered the email and password, was greeted with a GMail inbox.

One account to access them all

I then found the OTP email from Envoy waiting for me in the inbox. As soon as I entered it, I logged in to the Envoy instance and was presented with details of 566 employees, including their phone numbers, names, and email addresses. I also found that I could schedule meetings and book rooms for the same.

I took one screenshot as a POC (Delving deeper would have resulted in me accessing PII), and then went back to the email inbox to dig for more. I found email invites to Slack, 1Password, and Github.

Still looking to exploit this further, I went to the Freshservice portal again. There, in one of the articles, I found that the company used Google authentication for basically everything internal. One of these internal websites I was able to gain access to website which provided a VPN Admin CA certificate.

I stopped my testing here, and reported this to the company through Bugcrowd. The misconfiguration was quickly triaged and fixed, and I was awarded a bounty, which still happens to be my highest bounty yet.

Final thoughts:

The thing about this that raises the most concerns is that it requires almost zero knowledge of security to find and exploit. This requires very little time and effort to exploit, and hence its danger lies in the simplicity.

As evident from the above, simple misconfigurations like this may not look like a great deal, however can cause tons of damage. Sadly, a lot of companies don’t consider such assets as in scope for their responsible disclosure programs. I hope that this article can help spread the word, and more companies accept reports for all their assets as in-scope.

There are still hundreds of companies with this misconfiguration out there, but with no formal method of responsible disclosure. Once again, I would like to quote Inti De Ceukelaire from his article about a similar vulnerability,

“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.”

Even something as simple as “security.txt” can help an organization uncover security vulnerabilities such as this misconfiguration.

Important notes:

  1. Once again, this is NOT a vulnerability in Freshservice. This is a misconfiguration affecting a subset of companies using Freshservice, and is caused by a misconfiguration on part of the company using Freshservice for ITSM, not Freshworks.
  2. In case you manage to find a misconfigured instance, please check if it is within the scope of a program or not before reporting. Do not download or use any information found within the service portal. Please also check if the instance actually belongs to the company before reporting it as a vulnerability.
  3. Some Freshservice instances are actually meant to be public (ex. public documentation, customer support, etc.). Please do not report such instances.
  4. In some cases, you might be able to escalate impact by using information found within the pages. Please take permission from the organization before attempting any such activity.

Closing remarks:

Thanks for reading this writeup! I am still new to writing, so any feedback will be appreciated.

You can also follow me on Linkedin, where I post some interesting stuff : https://www.linkedin.com/in/mopasha/

Please 👏 if you liked this article and let me know your thoughts in the comments!

If you want to read more, check out my previous article on the Confluence Cloud misconfiguration here. If you find any related vulnerabilities as well, please post them in the comments.

Thanks for reading, and see you with the next big find!

Published in InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. Subscribe to our weekly newsletter for the coolest infosec updates: https://weekly.infosecwriteups.com/

Written by Mohammed Moiz Pasha

Bug hunter | Detectify Crowdsource member | Interested in pretty much anything tech

No responses yet

What are your thoughts?