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.

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!

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.

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.

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.

„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.