Introduction to the Ticketing SaaS Landscape

Things are ever-changing, aren't they? It’s been long enough that most of us could agree that we’ve found ourselves comfortably in a newly established paradigm—working from home. The downstream effects of this aren’t lost on organizations, employees, communications, and the relationship between them and how work actually gets done. As the former set continues its upward trend, the latter again evolves.

More specifically, the services, software, and infrastructure required to support this new paradigm mean an evolution in ticketing, help desk, management platforms, and the associated infrastructure.

So, what’s the penetration testers’ approach to this evolution?

At Sprocket, we encounter ticketing systems both internally and externally. While we do encounter these systems internally, they tend not to lend themselves to higher-impact risks. Externally, things can get interesting. This is where we encounter SaaS the most, where the risk & impact are greater, and where Sprocket really shines.

There are many popular ticketing systems, but we’ll look at the most common three we come across during our engagements. For this blog, we’ll start with Zendesk. If there’s any interest, I’ll continue with Salesforce and Atlassian Jira.

This won’t be a typical blog post. I set out to accomplish a few things:

• Taking stock of the ticketing landscape in 2024
• Researching common trends and design paradigms
• Hacking along the way

As I write this, there won’t be anything particularly new or groundbreaking. It’s a semi-organized brain dump of thoughts, testing methodologies, observations, and general hackery. The hope is that through writing, we can uncover uncommon functionality, exploitation primitives, and expose additional attack surfaces. As we work through this and the other areas described above, we’ll add to our larger knowledge base.

We can boil the introduction above & the remaining content below as:

A quick side note, as I was writing this I came across Push Security’s excellent introduction to SaaS attack techniques and the landscape they inhabit. I recommend the article as it contains not just attack techniques used to target SaaS, but the higher level context needed to really provide situational awareness.

As I work through this research, I’ll be submitting PR’s myself and I encourage you to make contributions to their repo below as well:

https://github.com/pushsecurity/saas-attacks

Alright, let’s dive into our first target.

Zendesk

I’ll start by giving kudos and props to Snapsec for their recent work that details some cool Zendesk-related hacks.

I won’t introduce or explain what Zendesk is. You can do that. Instead, let’s dive right in on some early musings from an offensive approach.

Recon - Identifying Zendesk

After creating a free trial, I started down my typical web application methodology checklist taking note of anything that might help us identify new ways of discovering Zendesk applications. At Sprocket, whether it’s supplementing our attack surface management (ASM) solution, expanding, or uncovering additional client attack surface - identifying new and creative ways to fingerprint such common platforms remains crucial to our goal.

Take a look at the following screenshot, which is found under the “Embed Web Widget” during the onboarding tutorial. This little piece of code allows us to, well, embed the Zendesk messaging and live chat widget on another domain or website under our control:

For ease of copying, here is the relevant line that got me thinking:

• “Is this distinct enough to properly identify Zendesk applications on a large scale”?
• “Can we use anything here to correlate or expand an attack surface?”

<!-- Start of dsphackery Zendesk Widget script -->
<script id="ze-snippet" src="<https://static.zdassets.com/ekr/snippet.js?key=f7b5b8ef-6706-41e9-9b0e-adb0ea046076>"> 
</script><!-- End of dsphackery Zendesk Widget script -->

Let’s spin up a quick Cloudflare Worker to see this in action. I deployed the following code with the widget embedded. I wanted to see how this widget behaves and interacts not just within the platform itself, but interrogate & explore any odd or interesting behaviors:

addEventListener('fetch', event => {
 event.respondWith(handleRequest(event.request))
})

/**
 * Respond with hello worker text
 * @param {Request} request
 */
async function handleRequest(request) {
 const html = `<!DOCTYPE html>
<html>
<head>
 <title>Zendesk Widget</title>
</head>
<body>
 <!-- Start of dsphackery Zendesk Widget script -->
 <script id="ze-snippet" src="<https://static.zdassets.com/ekr/snippet.js?key=f7b5b8ef-6706-41e9-9b0e-adb0ea046076>"></script>
 <!-- End of dsphackery Zendesk Widget script -->
</body>
</html>`;

 return new Response(html, {
 headers: {
 'content-type': 'text/html;charset=UTF-8',
 },
 });
}

Then I visited the deployed page, and so far so good:

Then back in the Zendesk platform, we can see the conversation, along with other housekeeping items:

So far a fairly standard chatting platform. You can send messages as Internal Notes :

This of course does not show from the customer's perspective.

Okay, with a target Zendesk application with some functionality deployed, let’s take a step back and start from the beginning of any hackers journey - reconnaissance.

The next section will wind us through a new way of identifying Zendesk & it’s embedded chat widget.

Turns out, a fairly simple string match using Project Discovery’s HTTPX works pretty well. Here I’ll just specify a URL (my Cloudflare worker) and use string matching (ms) on the code snippet I mentioned earlier:

httpx -silent -u <https://worker-spring-sea-52bd.chromatic-isolate.workers.dev/> -ms "Zendesk Widget script" -title

<https://worker-spring-sea-52bd.chromatic-isolate.workers.dev/> [Zendesk Widget]

Okay….so what? All you did was identify a widget that you explicitly placed on a web application.

Fair enough. But what if we wanted to identify additional domains or targets that may be sharing that default code snippet?

In other words, can we correlate and identify related domains or companies?

Sure! All we need to do is a little scraping and parsing and we can at least answer the question:

Who else is using this code snippet?

If we find a correlation, it could (at least) indicate a shared relationship between the target application and organization and the extracted one.

To illustrate: Let’s say you’ve got your list of subdomains against Uber. Let’s run our string searching against those subdomains:

httpx -silent -l ubersubs.txt -ms "Zendesk Widget script" -title

<https://base.uber.com> [Base design system]

Looks like Uber’s Base Design System is using Zendesk under the hood. We can easily verify this by inspecting the source:

get <https://base.uber.com/|> grep 'Start of.*Zendesk Widget script' | sed 's/.*Start of \\([^ ]*\\) Zendesk Widget script.*/\\1/'

So what is zeroheightsupport? The screenshot below can answer that and validate our finding!

Now, what does this mean? Well…it tells us a couple things:

1. Uber uses Zendesk in a limited capacity.
2. Uber’s Zendesk implementation is facilitated by a company called “zeroheightsupport”
3. This relationship might require further interrogation.

To put it all together, we can run something like this against Abode:

subfinder -silent -d adobe.com|httpx -silent -ms "Zendesk Widget script" | grep 'Start of.*Zendesk Widget script' | sed 's/.*Start of \\([^ ]*\\) Zendesk Widget script.*/\\1/'

Let’s take a look at Project Discovery’s Nuclei dns-saas-service-detection.yaml matcher that enumerates Zendesk applications (along with many others) by inspecting DNS records:

dns:
 - name: "{{FQDN}}"
 type: CNAME

 extractors:
 - type: dsl
 dsl:
 - cname

 matchers-condition: or
 matchers:
 - type: word
 part: answer
 name: zendesk

Super simple, we’re just looking for any string match of “zendesk” in the URI or CNAME DNS record. And it works well, sometimes. Kind of like every Nuclei template.

Given our Cloudflare worker doesn’t have the appropriate DNS records, Nuclei does not report Zendesk in use and that makes sense.

Interestingly, Nuclei doesn’t report that https://base.uber.com/ is using Zendesk either. The reasoning is rather simple though. It does have those records, but not quite in the way Nuclei is looking for them:

CNAME base.uber.com. 7m56s "zeroheight.com."
 TXT zeroheight.com. 1m00s "MS=ms44942321"
 TXT zeroheight.com. 1m00s "detectify-verification=969838a510dd75807234eecda55b8edc"
 TXT zeroheight.com. 1m00s "google-site-verification=4umc_CvDaQxDND9zzPeTDBna58WZAJv4eJQVA76409Y"
 TXT zeroheight.com. 1m00s "google-site-verification=mkBHGAPOxlk6pIgaGoEaFmHT3LRsGp7XjtZSWnztvDM"
 TXT zeroheight.com. 1m00s "google-site-verification=t_LCpWzpUE0xslgqAe-ypZAk6mTXVIvHd5hmPoIcofU"
 TXT zeroheight.com. 1m00s "v=spf1 include:_spf.google.com include:mail.zendesk.com include:19492330.spf04.hubspotemail.net include:sendgrid.net

So if you’re scanning targets who don’t have those DNS records set up, you will likely miss Zendesk!

Here’s a barebones, super simple Nuclei template to catch this behavior:

id: zendesk-widget-detection
info:
 name: Zendesk Chat Widget Detection
 author: clandestination
 severity: info

http:
 - method: GET
 path:
 - "{{BaseURL}}"
 matchers:
 - type: word
 words:
 - "<!-- Zendesk Web Widget -->"

Wrap Up & What’s Next

I intended to keep this series going. To give a glimpse on what’s coming next, here’s a rough outline of potential future articles. We’ll attempt to replicate a similar process against Salesforce and Atlassian Jira, and then move on to exploitation & vulnerability analysis.

The goal is to have an understanding of Zendesk, Salesforce, and Atlassian Jira with topics covering:

• Initial Access - Authentication Flow
• Enumeration & Exploitation - Any Interesting Endpoints or Functionality?
• Privilege Escalation - What Else Can We Do?
• Further Exploration Required - Here Be Dragons

Okay, it’s about time to wrap up this little session. Was anything I covered groundbreaking? Not really. But interesting and fun? Absolutely! With the increase in SaaS platform adaptions, it undoubtedly increases attack surface. Part of being on the service delivery team at Sprocket is to make sure we have visibility into that attack surface. When that visibility wanes, either through increased perimeter security or vendor platform changes, we have to push those constraints to retain that visibility.

We strive on finding unconventional, exotic, and interesting ways of accomplishing those goals above. Uncovering additional attack surface and designing systems to identify, exploit, and remediate portions of that attack surface really helps drive that initiative.

And finally, to answer a lingering question - is this reflected in other ticketing chat systems? I’m not sure just yet, but I intend on finding out :)