15-jähriger Junge findet einen Backdoor-Bug in Zendesk und verdient 50.000 US-Dollar

• Ein 15-jähriger Junge, der in seiner Freizeit gern Bugs jagt, entdeckte in Zendesk, das von Fortune-500-Unternehmen genutzt wird, einen Bug im Zusammenhang mit der E-Mail-Verifizierung
• Durch Meldungen an mehrere Unternehmen verdiente er damit mehr als 50.000 US-Dollar, während Zendesk den Fehler zwar patchte, dem Melder jedoch keinerlei Prämie zahlte

Einführung in Zendesk

• Zendesk ist ein Kundenservice-Tool, das von einigen der größten Unternehmen der Welt verwendet wird
• Wenn man Support-E-Mails mit Zendesk verbindet, verwaltet Zendesk eingehende E-Mails und erstellt Tickets
• Erstaunlich ist, dass viele große Unternehmen sich auf Zendesk verlassen, statt ein eigenes Ticketsystem aufzubauen

Das schwächste Glied

• Wie das Sprichwort sagt: Ein System ist nur so stark wie sein schwächstes Glied. Zendesk wird oft nur als einfaches Ticket-Tool betrachtet und ohne sorgfältige Konfiguration eingesetzt
• Wird die Domain @company.com für Single Sign-on (SSO) verwendet und mit Zendesk verknüpft, kann dadurch eine Sicherheitslücke entstehen
• Da Zendesk E-Mails der Domain verarbeitet, kann jemand mit Zugriff auf Zendesk interne Systeme missbrauchen, wenn das SSO-System E-Mail-Adressen nicht korrekt überprüft

E-Mail-Spoofing

• Es wurde eine schwerwiegende Schwachstelle in Zendesk entdeckt, durch die ein Angreifer Kundensupport-Tickets von Unternehmen lesen konnte, die Zendesk nutzten
• Zendesk hatte keine wirksamen Schutzmechanismen gegen E-Mail-Spoofing
• Wenn ein Angreifer die Support-E-Mail-Adresse und die Ticket-ID kannte, konnte er sich per E-Mail-Spoofing als ursprünglicher Absender ausgeben und auf das Ticket zugreifen
• Der Autor meldete den Bug, doch Zendesk zeigte zunächst kein Interesse
  • Es kam die Antwort, E-Mail-Spoofing (SPF-, DKIM-, DMARC-Probleme) liege außerhalb des Scopes
• Die Meldung wurde über HackerOne bearbeitet; eine direkte Meldung an ein Zendesk-Teammitglied wurde angefragt, aber abgelehnt

Ausweitung des Problems zur Übernahme von Slack

• Der E-Mail-Spoofing-Bug hätte auch einzelnen Unternehmen gemeldet werden können, doch der Autor wollte eine größere Wirkung erzielen
• In der Vergangenheit hatte bereits ein anderer Forscher über Zendesk Hunderte Unternehmen über Slack kompromittiert (TICKETTRICK)
• Der Autor versuchte, dies mit seinem eigenen Bug zu reproduzieren, stieß jedoch auf einige Schwierigkeiten
• Slack hatte die Verifizierung geändert und fügte E-Mail-Adressen nun einen zufälligen Token hinzu
• Beim Login mit einer Apple ID über OAuth wurde dieser Token jedoch nicht verwendet, wodurch sich die Schutzmaßnahme umgehen ließ

Reproduktionsschritte: Apple → Zendesk → Slack

1. Eine Apple ID mit [e-mail] erstellen und einen Verifizierungscode anfordern; dadurch wird ein Zendesk-Ticket erstellt
2. Im Support-Portal von company.com mit der eigenen E-Mail ein Ticket erstellen, um den ID-Bereich nachzuverfolgen
3. Mithilfe des E-Mail-Spoofing-Bugs versuchen, sich zu allen Tickets in diesem ID-Bereich hinzuzufügen
4. Mit dem Konto [e-mail] im Support-Portal dieses Unternehmens anmelden und die Tickets prüfen, bei denen man in CC gesetzt wurde
5. Den Verifizierungscode in die Apple ID eingeben
6. Mit der Funktion „Mit Apple anmelden“ von Slack mit der Apple ID einloggen, die mit einer @company.com-E-Mail verknüpft ist, und sich bei Slack anmelden
   Der Autor wandte diese 6 Schritte auf Hunderte Zendesk- und Slack-Instanzen an

Die Folgen des Vorfalls

• Eine Woche lang meldete er die Schwachstelle an einzelne Unternehmen; einige reagierten sofort, andere behaupteten, es sei ein Zendesk-Problem
• Nachdem einige Unternehmen Zendesk kontaktiert hatten, bat Zendesk schließlich darum, den Bericht vertraulich zu halten, und verlangte Reproduktionsschritte für die Slack-Schwachstelle
• Nach Bereitstellung eines PoC zur Slack-Übernahme bestätigte Zendesk das Problem, brauchte jedoch 2 Monate bis zur Behebung
• Viele Unternehmen schützten ihre Instanzen, indem sie die E-Mail-Kollaborationsfunktion deaktivierten
• Über diese Bug-Bounty-Meldung erhielt der Autor von einzelnen Unternehmen auf HackerOne und anderen Plattformen insgesamt mehr als 50.000 US-Dollar an Prämien
• Einige Unternehmen kündigten ihre Verträge mit Zendesk

Zendesks Fix und meine 0-Dollar-Bounty

• Zwei Monate später bestätigte Zendesk die Behebung des Problems
• Zwar wurden die Spam-Filter Cloudmark und Rspamd EAP verwendet, doch da der Rspamd-Score nicht genutzt wurde, wurden viele E-Mails nicht zurückgehalten
• Zunächst wurde das Problem behoben, indem unter bestimmten Bedingungen automatisch auf Rspamd umgestellt wurde
• Später wurde ein Filter implementiert, der Verifizierungs-E-Mails von Apple und Google automatisch zurückhält
• Trotz der Behebung entschied Zendesk letztlich, für diese Bug-Bounty-Meldung keine Prämie zu zahlen
  • Begründung: Der Autor habe gegen die Offenlegungsrichtlinien von HackerOne verstoßen, indem er die Schwachstelle mit betroffenen Unternehmen geteilt habe

Fazit

• Ein kleiner E-Mail-Bug führte letztlich zur Kompromittierung interner Systeme einiger der größten Unternehmen der Welt
• Zendesk beseitigte die Schwachstelle zwar am Ende, doch der Prozess mit Ablehnung, langsamer Reaktion und Ignorieren war schwierig
• Das ist die Realität des Bug Hunting: Manchmal gewinnt man, manchmal verliert man

Meinung von GN⁺

• Der Zendesk-Vorfall zeigt die Risiken, wenn Third-Party-Lösungen unkritisch eingeführt werden. Selbst bei Produkten bekannter Unternehmen ist eine Sicherheitsprüfung unerlässlich.
• Die Übernahme interner Systeme großer Unternehmen kann enormen Schaden anrichten, daher war Zendesks zögerliche Reaktion äußerst unverantwortlich. Auch die Verweigerung einer Bounty demotiviert Sicherheitsforscher unnötig.
• Unternehmen sollten SSO-Domains sorgfältig auswählen und ihre Prozesse zur E-Mail-Verifizierung stärken. Technologien zur E-Mail-Authentifizierung wie DMARC, SPF und DKIM sollten aktiv genutzt werden.
• Die Offenlegungsrichtlinien von HackerOne wirken aus Sicht von Forschern zu starr. Bei schweren Schwachstellen sollte eine schnelle Weitergabe möglich sein, daher scheint eine flexiblere Anwendung je nach Situation sinnvoll.
• Bug Hunting sollte für Unternehmen und Forscher gleichermaßen ein Win-win sein. Es bleibt zu hoffen, dass sich eine Kultur etabliert, die guten Willen und Aufwand von Forschern respektiert und angemessen vergütet.

[aer0700]

Wenn man solche Vorfälle sieht, wirkt es viel sinnvoller, bei Sicherheitslösungen statt auf zugekaufte Produkte auf Sicherheitsexperten zu setzen und sie intern aufzubauen. seufz

[GN⁺]

Hacker-News-Kommentare

• Ein Nutzer erwähnte, dass er im Juni 2024 denselben Bug an Zendesk, Apple und Slack gemeldet habe und dass sie wahrscheinlich deshalb keine Prämie für den Bug gezahlt hätten, weil er nicht der Erste gewesen sei.

  • Die nicht verzeichnisgebundene SSO-Option Sign in with Apple (SIWA) sei falsch implementiert gewesen, und das gelte auch für große Unternehmen wie Slack.
  • Nicht verzeichnisgebundenes SSO könne nicht dasselbe Vertrauen genießen wie verzeichnisgebundenes SSO, und SSO-Anbieter seien nicht austauschbar, selbst wenn sie dieselbe E-Mail-Adresse verwendeten.

• Ein anderer Nutzer behauptete, Zendesk habe eine Fake-Band namens "Zendesk Alternative" erfunden, um Google-Suchergebnisse zu manipulieren.

  • Das sei zwar nicht illegal, zeige aber ein manipulatives Verhalten, das ihre Denkweise offenlege.

• Ein Nutzer sagte, es sei enttäuschend, dass Zendesk eine Prämie für den Bug verweigert habe, und meinte, genau so bringe man Leute dazu, nicht an großen Bug-Bounty-Programmen teilzunehmen.

  • Er fügte hinzu, dass seine Interview-Erfahrung mit Zendesk sehr schlecht gewesen sei.

• Ein weiterer Nutzer erwähnte, dass ineffiziente Bug-Bounty-Programme sich negativ auf Software-Services auswirkten.

  • Er argumentierte, dass Zendesk zahlen, sich entschuldigen und das Programm anpassen sollte.

• Ein Nutzer kritisierte, dass Zendesk trotz eines Umsatzes von 1,3 Milliarden Dollar keine Prämie zahle, und nannte das kurzfristig gedacht.

  • Das sei keine rationale Entscheidung, und privates Kapital spare Kosten ein und verschleiße dabei die Marke.

• Ein anderer Nutzer erklärte, Zendesk habe es vermutlich ignoriert, weil man die Auswirkungen des Bugs nicht richtig verstanden habe.

  • Ohne klar erkennbare Auswirkungen könnten viele Schwachstellen wie bloße Bugs erscheinen.

• Ein Nutzer wies darauf hin, dass Zendesk nur das Problem mit der E-Mail-Bestätigung des Apple-Kontos behoben habe, nicht aber das zugrunde liegende Problem.

  • In der Standardeinstellung könne möglicherweise jeder Support-Tickets kapern, wenn er die E-Mail-Adresse und die Ticket-ID kenne.

• Es wurde erklärt, dass es zwei getrennte Schwachstellen gebe.

  • Zendesk habe erlaubt, Antworten von der E-Mail-Adresse des ursprünglichen Anfragenden zu senden und dabei CC-Empfänger hinzuzufügen.
  • Slack habe domainweiten Login über Sign in with Apple ohne zusätzliche Verifizierung erlaubt.

• Es wurde kritisiert, dass Zendesk das Problem ignoriert und unter Verschluss halten wollte.

  • Das sei unprofessionell und könnte ein Grund dafür gewesen sein, warum keine Prämie gezahlt wurde.

• Abschließend kritisierte ein Nutzer, dass Zendesk die Prämie für den Bug verweigert habe, und betonte, dass der Meldende alle Verfahren korrekt befolgt habe.