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.

Wie soll ich vorgehen?

Im Folgenden finden Sie drei Möglichkeiten, wie Sie das Datenrisiko in Ihrem Unternehmen verringern können:

1

Vereinbaren Sie eine Demo mit uns, um Varonis in Aktion zu erleben. Wir passen die Session an die Datensicherheitsanforderungen Ihres Unternehmens an und beantworten alle Fragen.

2

Sehen Sie sich ein Beispiel unserer Datenrisikobewertung an und erfahren Sie, welche Risiken in Ihrer Umgebung lauern könnten. Varonis DRA ist völlig kostenlos und bietet einen klaren Weg zur automatischen Sanierung.

3

Folgen Sie uns auf LinkedIn, YouTubeund X (Twitter), um kurze Einblicke in alle Themen der Datensicherheit zu erhalten, einschließlich Data Security Posture Management (DSPM), Bedrohungserkennung, KI-Sicherheit und mehr.

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.

die-eu-datenschutz-grundverordnung-ist-beschlossen-–-was-sie-jetzt-wissen-sollten
Die EU-Datenschutz-Grundverordnung ist beschlossen – Was Sie jetzt wissen sollten
Inzwischen ist die EU-Datenschutz-Grundverordnung (DS-GVO), die von einigen schon als „Meilenstein des digitalen Zeitalters“ bezeichnet wird, endgültig beschlossen. Wir haben uns bereits häufiger mit der Geschichte der DS-GVO beschäftigt, für...
die-eu-datenschutz-grundverordnung-im-fokus:-pseudonymisierung-als-alternative-zu-verschlüsselung
Die EU-Datenschutz-Grundverordnung im Fokus: Pseudonymisierung als Alternative zu Verschlüsselung
Dass die EU-Datenschutz-Grundverordnung (DS-GVO) ein relativ kompliziertes Gebilde ist, hatten wir bereits erwähnt. Es basiert zwar auf einigen Prinzipien wie Privacy by Design und anderen Konzepten, durch die das Ganze...
expertengespräch-–-was-die-eu-dsgvo-mit-zugriffskontrollen-zu-tun-hat
Expertengespräch – Was die EU-DSGVO mit Zugriffskontrollen zu tun hat
Dr. Ann Cavoukian im Gespräch mit Varonis An dieser Stelle fahren wir mit unseren Expertengesprächen fort und wenden uns gemeinsam mit Dr. Ann Cavoukian dem Thema EU-Datenschutzgrundverordnung und Berechtigungsmanagement zu....
eine-datenzentrierte-strategie:-was-kann-sie-und-welche-voraussetzungen-müssen-erfüllt-sein
Eine datenzentrierte Strategie: Was kann sie und welche Voraussetzungen müssen erfüllt sein
„Big Data“ ist nicht nur ein vielfach gebrauchtes Schlagwort der letzten Jahre. Inzwischen sind damit bereits neue Rollen und Funktionen in Unternehmen verbunden. Eine davon ist der Chief Data Officer...