Varonis Threat Labs entdecken SQLi- und Zugriffsschwachstellen in Zendesk

Varonis Threat Labs haben eine Schwachstelle für SQL-Injection und für den logischen Zugriff in Zendesk Explore gefunden, dem Berichts- und Analytics-Dienst der beliebten Kundenservice-Lösung Zendesk.
Tal Peleg
3 minute gelesen
Letzte aktualisierung 24. November 2022

Varonis Threat Labs haben eine Schwachstelle für SQL-Injection und für den logischen Zugriff in Zendesk Explore gefunden, dem Berichts- und Analytics-Dienst der beliebten Kundenservice-Lösung Zendesk.

Es gibt keine Hinweise darauf, dass Zendesk-Explore-Kundenkonten angegriffen wurden, und Zendesk hat noch am Tag, an dem der Vorfall gemeldet wurde, mit der Arbeit an einem Fix begonnen. Das Unternehmen hat mehrere Fehler in weniger als einer Arbeitswoche behoben, ohne dass Maßnahmen seitens der Kunden erforderlich wurden.

Vor dem Patch hätten Angreifer über die Schwachstelle auf Gespräche, E-Mail-Adressen, Tickets, Kommentare und andere Informationen von Zendesk-Konten mit aktiviertem Explore zugreifen können.

Um die Schwachstelle auszunutzen, konnte sich ein Angreifer zunächst als neuer externer Benutzer für den Ticketdienst des Zendesk-Kontos seines Opfers registrieren. Diese Registrierung ist standardmäßig aktiviert, da bei vielen Zendesk-Kunden die Endbenutzer Support-Tickets direkt über das Internet einreichen. Zendesk Explore ist standardmäßig nicht aktiviert, wird aber stark beworben, als Voraussetzung für die Seite „Analytics-Erkenntnisse“.

Ausführung, verschachtelte Kodierungen und XMLs … ojemine!

Zendesk verwendet mehrere GraphQL-APIs in seinen Produkten, insbesondere in der Admin-Konsole. Da GraphQL ein relativ neues API-Format ist, haben wir mit unseren Nachforschungen dort angefangen. In Zendesk Explore haben wir einen besonders interessanten Objekttyp namens „QueryTemplate“ gefunden.

Das Feld „querySchema“ stach hervor, weil es ein Base64-kodiertes XML-Dokument mit dem Namen „Query“ innerhalb eines JSON-Objekts enthielt. Viele der Attribute im XML waren selbst Base64-kodierte JSON-Objekte. Übersetzung? Hierbei handelt es sich um ein Base64-kodiertes JSON-Objekt in einem Base64-kodierten XML-Dokument in einem JSON-Objekt. Puh!

image1-1

Bei mehrfach verschachtelten Kodierungen werden wir immer hellhörig, denn viele Wrapper um einen Datensatz herum bedeuten in der Regel, dass viele verschiedene Dienste (die höchstwahrscheinlich von verschiedenen Entwicklern oder sogar Teams erstellt wurden) diese Daten verarbeiten. Und mehr Code bedeutet normalerweise mehr potenzielle Orte für Schwachstellen.

Aus diesem Grund haben wir uns eingehender mit Zendesk Explore befasst, mit dem Admin-Benutzer unseres eigenen Lab-Kontos in Zendesk. Bei der Visualisierung eines Berichts in Zendesk Explore haben wir eine API namens „execute-query“ gefunden. Diese API-Methode nimmt ein JSON-Objekt mit der Query-XML sowie mehrere andere XML-Parameter an, von denen einige in Base64 kodiert sind.

SQL-Injection

Eines der an die API weitergegebenen Felder ist „extra_param3_value“ – hierin ist das Klartext-XML-Dokument „DesignSchema“ enthalten, das nicht in Base64 kodiert ist. Dieses Dokument definiert die Beziehung zwischen einer AWS RDS (verwaltete relationale Datenbank) und dem oben erwähnten XML-Query-Dokument.

Es wurde festgestellt, dass alle Namensattribute in diesem XML-Dokument, die die abzufragenden Tabellen und Spalten definieren, anfällig sind für einen SQL-Injection-Angriff. Die Herausforderung für unser Team bestand nun darin, die SQLi-Schwachstelle auszunutzen, um Daten zu exfiltrieren.

image2

Die XML-Parsing-Engine im Backend war bereit, Attribute in einfachen anstatt der standardmäßigen doppelten Anführungszeichen anzunehmen. So konnten wir die doppelten Anführungszeichen im Tabellennamen umgehen.

Nun brauchten wir eine Möglichkeit, Strings in die Abfrage zu schreiben, ohne einfache oder doppelte Anführungszeichen zu verwenden. Glücklicherweise bietet PostgreSQL – die von Zendesk Explore verwendete Datenbank – eine praktische Methode zur Bezeichnung von Strings: String-Konstanten mit Dollarzeichen. Die Zeichen „$$“ können verwendet werden, um einen String zu definieren, anstelle der standardmäßigen einfachen Anführungszeichen in einer SQL-Anweisung.

Mit dieser Bezeichnung für Strings konnten wir die Liste der Tabellen aus der RDS-Instanz von Zendesk extrahieren und alle in der Datenbank gespeicherten Informationen exfiltrieren, also E-Mail-Adressen von Benutzern, Leads und Abschlüsse aus dem CRM, Live-Agentengespräche, Tickets, Help-Center-Artikel usw.

image3-1

Die Schwachstelle im logischen Zugriff

SQL-Injections sind immer interessant, aber als Admin Daten exfiltrieren zu können ist nicht besonders spannend. Wir wollten unsere Möglichkeiten weiter ausbauen, also haben wir untersucht, wie genau diese Execute-query-API funktioniert.

Die API-Methode „execute-query“ akzeptiert JSON-Nutzdaten, die ein „content“-Objekt mit den Eigenschaften „query“, „cubeModels“ und „datasources“ enthalten.

image4-1

„Query“ enthält ein Query-XML-Dokument mit den Spalten, Zeilen, Ausschnitten, Maßen und Explosionen der Abfrage, sowie die Visualisierungskonfiguration im JSON-Format. Das Dokument enthält außerdem einen Verweis auf die Eigenschaft „cubeModels“. „CubeModels" enthält ein XML-Dokument namens „OLAPSchema“, das die Tabellen definiert, die in der ausgewählten Datenquelle abgefragt werden können.

Die Execute-query-API hat mehrere logische Prüfungen für Anfragen nicht durchgeführt:

  1. Die Integrität der Dokumente wurde nicht überprüft, so dass unser Team sie so manipulieren konnte, dass sie die innere Funktionsweise des Systems offenlegten.
  2. Die IDs „query“, „datasources“ und „cubeModels“ wurden nicht ausgewertet, um festzustellen, ob sie dem aktuellen Benutzer gehören.
  3. Und schließlich – und das ist der kritischste Punkt – prüfte der API-Endpoint nicht, ob der Aufrufer die Berechtigung hatte, auf die Datenbank zuzugreifen und Abfragen auszuführen. Ein neu erstellter Endbenutzer konnte also diese API aufrufen, die Abfrage ändern und Daten aus einer beliebigen Tabelle im RDS des Zendesk-Zielkontos stehlen – ganz ohne SQLi.

Zusammenfassung

Varonis Threat Labs haben Zendesk geholfen, eine SQLi-Schwachstelle und eine Zugriffskontrollschwachstelle in Zendesk Explore zu beheben, über die Angreifer Daten aus Zendesk-Kundenkonten mit aktivem Explore exfiltrieren konnten. Zendesk hat das Problem schnell behoben und diese Schwachstellen aus Explore entfernt. Von Seiten der Kunden sind aktuell keine Maßnahmen erforderlich.

What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:

1

Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.

2

See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.

3

Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Testen Sie Varonis gratis.

Detaillierte Zusammenfassung Ihrer Datensicherheitsrisiken
Umsetzbare Empfehlungen, die auf Ihre Bedürfnisse zugeschnitten sind
Ohne Bedingungen und Auflagen

Weiter lesen

Varonis bewältigt Hunderte von Anwendungsfällen und ist damit die ultimative Plattform, um Datenschutzverletzungen zu stoppen und Compliance sicherzustellen.

ccsp-oder-cissp:-welche-zertifizierung-soll-es-werden?
CCSP oder CISSP: Welche Zertifizierung soll es werden?
Erhalten Sie einen Überblick über die CCSP- und CISSP-Prüfungen und erfahren Sie, welche Zertifizierung am besten für Sie und Ihre Karriere geeignet ist.
was-ist-zero-trust?-ein-umfassender-leitfaden-mit-sicherheitsmodell-|-varonis
Was ist Zero Trust? Ein umfassender Leitfaden mit Sicherheitsmodell | Varonis
Das Zero-Trust-Framework vertraut niemandem und überprüft jeden – sogar die Benutzer innerhalb Ihrer eigenen Organisation. Erfahren Sie mehr über Zero Trust und wie Sie es in Ihrem Unternehmen implementieren können.
das-vollständige-handbuch-zu-phishing-angriffen
Das vollständige Handbuch zu Phishing-Angriffen
Das vollständige Handbuch zu Phishing-Angriffe Phishing-Angriffe plagen Einzelpersonen und Unternehmen gleichermaßen seit der Erfindung des Internets. In letzter Zeit sind diese Angriffe jedoch zunehmend raffinierter und schwieriger zu erkennen. Phishing-Angriffe...
das-mirai-botnetz-oder-die-rache-des-iot
Das Mirai-Botnetz oder die Rache des IoT
Anfang 2016 haben wir mit Penetrationstester Ken Munro ein Gespräch über die Sicherheit von IoT-Geräten geführt: Funkgesteuerte Türklingeln oder Kaffeemaschinen und all die zahlreichen Haushaltsgeräte mit Internetanbindung. Seine Antwort auf...