Varonis debuts trailblazing features for securing Salesforce. Learn More

Wir stellen vor: Die Least Privilege Automation für Microsoft 365, Google Drive und Box

Mehr erfahren

Varonis Threat Labs entdecken SQLi- und Zugriffsschwachstellen in Zendesk

3 minute gelesen
Veröffentlicht 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 you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Testen Sie Varonis gratis.
Detaillierte Zusammenfassung Ihrer Datensicherheitsrisiken
Umsetzbare Empfehlungen, die auf Ihre Bedürfnisse zugeschnitten sind
Ohne Bedingungen und Auflagen
Keep reading
entdeckung-von-sicherheitslücken-in-outlook-und-neue-möglichkeiten,-ntlm-hashes-zu-leaken
Entdeckung von Sicherheitslücken in Outlook und neue Möglichkeiten, NTLM-Hashes zu leaken
Varonis Threat Labs hat einen neuen Outlook-Exploit und drei neue Möglichkeiten entdeckt, auf NTLM-v2-Hash-Passwörter zuzugreifen.
microsoft-office-„im-sturm“-erobern
Microsoft Office „im Sturm“ erobern
Die Ransomware-Gruppe „Storm-0978“ nutzt aktiv eine ungepatchte Sicherheitslücke in Microsoft Office und Windows HTML zur Remote-Ausführung von Code aus.
ghost-sites:-datendiebstahl-aus-deaktivierten-salesforce-communitys
Ghost Sites: Datendiebstahl aus deaktivierten Salesforce-Communitys
Varonis Threat Labs hat entdeckt, dass inkorrekt deaktivierte „Ghost Sites“ auf Salesforce von Angreifern leicht gefunden, darauf zugegriffen und mit Exploits ausgenutzt werden können.
vmware-esxi-im-ransomware-visier
VMware ESXi im Ransomware-Visier
Server, auf denen der beliebte Virtualisierungshypervisor VMware ESXi läuft, wurden in der vergangenen Woche von mindestens einer Ransomware-Gruppe angegriffen. Das geschah wahrscheinlich im Anschluss an Scan-Aktivitäten, um Hosts mit OpenSLP-Schwachstellen (Open Service Location Protocol) zu identifizieren.