- Critical Thinking - Bug Bounty Podcast
- Posts
- [HackerNotes Ep.94] Zendesk Fiasco & the CTBB Naughty List
[HackerNotes Ep.94] Zendesk Fiasco & the CTBB Naughty List
In this week's HackerNotes, we dive into the recent Zendesk fiasco and the ethical considerations surrounding it. We also have the launch of AuthzAI and some research from Ophion Security.
Yujilik
October 25, 2024
Hacker TLDR;
AuthzAI is a new free tool developed by @ngalongc that automates API testing and permission analysis. It analyses context and generates meaningful output, customised attacks are often a lot better than the typical wordlist fuzzing approach.
Definitely worth checking out. It’s available through their website and GitHub page, but you’ll need an OpenAI API key to use it.
Misconfigured User Auth Leads to Customer Messages:
Cool research from Ophion Security on how live chat systems work and authenticate users.
They found out that some of these systems were authenticating the user with only a custom cookie with the user’s email in it. All the attacker had to do was to get a valid email and it would return a valid
auth_token. Simple, but clever! It’s always important to check if the client side can tinker with the auth.
A 15-year-old hacker found a critical bug which involved email spoofing, in an application in which the entire business model revolves around exchanging emails, what could go wrong?
After some attempts to make Zendesk address the issue through triage and mediation, the researcher resorted to directly contacting Zendesk’s clients to inform them about the vulnerability. Although Zendesk didn’t offer any bounty, the researcher still got rewarded with over $50k from other programs for reporting this bug.
The White House has recently banned the use of Kaspersky products across the United States, citing concerns over potential data access risks and allegations of incorporating "backdoors" in their software.
Learn More About the ThreatLocker® Cyber Health Report Here
You may or may not know @ngalongc, but after a 3-year hiatus, he’s back on the X bug bounty scene, and he also dropped a cool tool called Authz AI. In his X thread, he talks about a $10k bounty he got exploiting a SAML SSO. Then, out of nowhere, he drops a link to his new tool, which is even available on GitHub!
The main goal of AuthzAI is to automate API endpoint testing and detect permission model violations and other security issues. Here are the key features:
It’s really cool to see people creating tools like this, especially since analysing context and generating content based on that context is something AI excels at. These tools take a huge amount of work off our plates when we have them to assist us. Go check it out!
Links:
Rojan and his team at Ophion Security recently conducted an extensive security research project focusing on various organisations that use Live Chat systems. They found some security concerns related to how these systems are set up and how they operate, highlighting potential vulns that affected the end users.
They focused on two primary areas of concern:
Direct vulnerabilities in the chat service providers themselves
Misconfigs resulting from incorrect architecture or setup on the customer’s end
There are three main types of live chat systems commonly used by organisations:
GenAI-based chatbot that is fed customer data + FAQ and answers questions based on user input. (System 1)
Simple FAQ bot that only answers based on internal and external documentation. (System 2)
Live Agent chat systems where you interact with a support agent. (System 3)
The research primarily focused on chatbot and live agent systems (Systems 1 and 3) that store user-related information such as messages, past orders, and other sensitive data. These systems require robust authentication mechanisms to protect user information.
Live Chat Systems and Authentication
Most Live Chat service providers offer built-in authentication features that allow organisations to track user messages and information securely. A common authentication mechanism involves the organisation using the logged-in user’s ID or email to generate a salted hash, which is then communicated to the live agent service provider via an API call to authenticate the chat session.
Rojan’s team examined the authentication flow of various providers, including HelpShift and Intercom. They found that organisations typically use a pre-generated Secret Key provided by the service provider to generate an HMAC based on either the user_id or email. This is then communicated back to the service provider through its SDK. While this approach can be secure if implemented correctly, misconfigurations in the implementation of these SaaS solutions can lead to significant vulnerabilities.
Accessing Millions of Users’ Chats Without Authentication
Their investigation focused on chat systems with agent communication and authenticated user history storage. The goal: find ways to access other users’ chats through provider vulnerabilities or organisational misconfigurations.
In one of the chats they were testing, they noticed a critical flaw in how the user_hash or auth_token was generated for an authenticated chat session, the auth_token was being generated based on a user’s email provided in a cookie.
This misconfiguration enables sending a request to the organisation’s messaging endpoint with any "target" email address, which would return an auth_token. This token could then be used to interact with the service provider’s API and access all chat messages sent by the target user to the support team.
So, it’s always important to check how the authentication flow is working, because sometimes it’s not happening on the server side and we all know that’s always a huge mistake. For more details, check out their blog post. Maybe their follow-up posts will be out too, depending on when you’re reading this!
Links:
A 15-year-old researcher found a bug in Zendesk, but as we know, when there are things such as "spoofing" in a report, they are usually closed as "not applicable" or "informative" and this happened to him too. But the bug was so critical, not only to Zendesk but all their customers, that the researcher had to keep trying to make them fix the issue.
He tried asking the triage team to forward the report to Zendesk, because surely they’ll take it seriously even though spoofing was out of scope, right? Not really.
It turns out you only need a support requestor’s email address and the ticket ID to perform the attack. Since ticket IDs are incremental, an attacker could easily brute-force them. When Zendesk refused to address this issue, the researcher took matters into his own hands and contacted their clients directly to inform them about the vulnerability. (ahahahahah)
This finally caught Zendesk’s attention.
After this interaction, Daniel provided them with his POC but ended up still not getting any reward from Zendesk, even though he got over $50k from other programs. You can read his post by clicking here.
This raises an important question: If a program dismisses a report as out-of-scope or informative, but we’re certain the bug is critical because it compromises confidentiality, what options do we have?
This behaviour from companies not only discourages researchers from digging deeper into an app but also makes them reluctant to report issues they discover them either by chance or by exploring something interesting, even if it’s out of scope. Why should people put themselves in a difficult position by trying to convince a company to care about a critical vulnerability in its own product?
It’s a tough spot to be in, but we can’t disagree that Daniel made the next best ethical decision by alerting Zendesk’s clients about the issue.
Nice find, and congrats!
Links:
That’s it for the week.
And as always, keep hacking!