Sicherheitsbericht: SQL-Injection-Sicherheitslücke


Art der Sicherheitslücke: SQL-Injection
Meldedatum: 10. März 2025
Status: Behoben und gepatcht
Offenlegungsmethode: Verantwortungsvolle Offenlegung durch Searchlight Cyber/Asset Note
Stabile Version
2.174.94 (oder jede Version, die mit 2.174 beginnt und mit einer Zahl größer als 94 endet – zum Beispiel 2.174.103)
Kandidatenversion
2.184.23 (oder jede Version, die mit 2.184 beginnt und mit einer Zahl größer als 23 endet – zum Beispiel 2.184.35)
Beta-
2.186.2 (oder jede Version, die mit 2 beginnt und auf die eine Zahl größer als 186 folgt – zum Beispiel 2.187.1)
Die Sicherheitslücke ermöglichte eine SQL-Injection auf einem nicht authentifizierten Endpunkt über eine speziell gestaltete Nutzlast. Im Rahmen einer umfassenden Ursachenanalyse wurde festgestellt, dass die Sicherheitslücke in Version 2.11.13, die am 12. 06. 2020 veröffentlicht wurde, eingeführt wurde. Trotz mehrerer interner und externer Penetrationstests blieb das Problem aufgrund der Komplexität der erforderlichen Nutzlast unentdeckt. Dies verringerte die Wahrscheinlichkeit eines Missbrauchs oder einer Datenkompromittierung erheblich.
Es sei darauf hingewiesen, dass diese Sicherheitslücke im Jahr 2020 auftrat und sich unsere internen Entwicklungsabläufe seitdem erheblich verbessert haben. Zudem wurden im Rahmen der Untersuchung keine weiteren Sicherheitslücken dieser Art entdeckt.
Es wurde eine Untersuchung der Protokolle von Azure Application Insights und AWS WAF für Cloud- und Hosting-Kunden durchgeführt. Auf Grundlage dieser Überprüfung wurden keine Anzeichen für eine Kompromittierung von Kundendaten festgestellt. Die Analyse legt nahe, dass eine Ausnutzung dieser Schwachstelle ein hohes Maß an Spezifität erfordern würde, was die Wahrscheinlichkeit eines erfolgreichen, großflächigen Missbrauchs einschränkt.
Searchlight Cyber/Asset Note veröffentlichte seine Ergebnisse früher als erwartet, wodurch einige Kunden mit lokalen Installationen für kurze Zeit einem Sicherheitsrisiko ausgesetzt waren.
Wir haben eine Reihe dieser Kunden bei Untersuchungen unterstützt, um Hinweise auf eine Kompromittierung oder einen Angriff zu finden, konnten jedoch bislang keine solchen Hinweise feststellen.
Wir führen jährlich umfassende Authentifizierungs- und API-Penetrationstests durch ein CREST-zertifiziertes externes Sicherheitsunternehmen durch, um unabhängige und qualitativ hochwertige Bewertungen zu gewährleisten. Zusätzlich zu diesen externen Überprüfungen werden vor jeder vierteljährlichen stabilen Version interne Penetrationstests durchgeführt, wodurch wir potenzielle Schwachstellen proaktiv innerhalb unseres Entwicklungszyklus identifizieren und beheben können.
Unser Penetrationstestverfahren umfasst sowohl authentifizierte als auch nicht authentifizierte Tests, um eine lückenlose Abdeckung aller Zugriffsebenen zu gewährleisten. Diese Prüfungen werden gemeinsam von internen Sicherheitsteams und externen Spezialisten durchgeführt, wodurch eine umfassende Bewertung unserer Systeme aus verschiedenen Perspektiven gewährleistet wird.
Am 10. Januar 2025 wurde ein umfassender Penetrationstest durchgeführt. Die Zusammenfassung des Berichts steht zur Verfügung und kann auf Anfrage zur Gewährleistung größerer Transparenz zur Verfügung gestellt werden.
Alle Entwickler bei Halo werden in den Standards für sicheres Programmieren geschult und befolgen branchenweit anerkannte Best Practices, darunter auch die von OWASP festgelegten. Diese Schulungen werden regelmäßig aktualisiert, um sicherzustellen, dass sie den neuesten Bedrohungen und Abwehrmaßnahmen Rechnung tragen.
Alle Codeänderungen durchlaufen einen strengen, mehrstufigen Genehmigungsprozess, der eine Überprüfung durch ein leitendes Mitglied des Sicherheitsteams umfasst, das speziell für die Bewertung potenzieller Sicherheitsrisiken zuständig ist. Darüber hinaus setzen wir während des gesamten Entwicklungsprozesses SAST-Tools (Static Application Security Testing) ein, die eine frühzeitige Erkennung von Schwachstellen ermöglichen und von Anfang an sichere Programmierpraktiken fördern.
Zwar lässt sich die Anzahl der API-Endpunkte aufgrund wesentlicher funktionaler Anforderungen – wie beispielsweise der Notwendigkeit, Webhook-Antworten zu akzeptieren – nicht reduzieren, doch liegt unser Fokus weiterhin auf der Aufrechterhaltung und kontinuierlichen Stärkung unserer allgemeinen Sicherheitslage. Im Rahmen unserer regelmäßigen Sicherheitsmaßnahmen führen wir bereits strenge Überprüfungen nicht authentifizierter Endpunkte durch. Aus diesem Grund wurden bei der jüngsten Überprüfung trotz des Vorhandenseins mehrerer nicht authentifizierter Endpunkte keine weiteren Schwachstellen festgestellt. Diese Endpunkte werden sorgfältig bewertet, überwacht und nur dann genutzt, wenn dies zur Risikominimierung unbedingt erforderlich ist.
In unseren gehosteten Umgebungen wird eine funktionale Trennung zwischen den Schlüsselkomponenten – darunter die API, die Authentifizierung und die Integrationsdienste – durchgesetzt, um das Risiko einer lateralen Bewegung im Falle einer Kompromittierung zu verringern. Darüber hinaus sind Datenbanken und Datenbankserver von den Anwendungsebenen isoliert, und alle verschlüsselten Daten werden ausschließlich von der API und den Authentifizierungsdiensten entschlüsselt, wodurch eine strenge Trennung zwischen Datenspeicherung und Zugriffsmechanismen gewährleistet wird.
Um unsere allgemeine Sicherheitslage zu stärken, beauftragen wir mehrere externe Sicherheitsunternehmen mit der zusätzlichen Überwachung und unabhängigen Überprüfung unserer Systeme. Parallel dazu bauen wir unsere internen Sicherheitskontrollen aus und verbessern sie, um eine umfassendere Abdeckung, eine gründlichere Analyse und eine kontinuierliche Verbesserung in allen Phasen der Entwicklung und Bereitstellung zu gewährleisten.
Wir sind uns bewusst, dass einige Kunden durch eine Veröffentlichung eines externen Sicherheitsforschers von dieser Sicherheitslücke erfahren haben, noch bevor sie eine direkte Mitteilung von Halo erhalten hatten. Dies war zum Teil auf den unerwarteten Zeitpunkt der Veröffentlichung des externen Berichts zurückzuführen, der erfolgte, während wir noch aktiv Kunden mit lokalen Installationen bei ihrem Upgrade-Prozess unterstützten.
Wir sind uns der Bedeutung einer proaktiven und zeitnahen Kommunikation bewusst und haben seitdem Maßnahmen ergriffen, um unsere internen Abläufe zu verbessern. Künftig werden wir sicherstellen, dass alle Hosting-Kunden umgehend benachrichtigt werden, sobald ein Patch installiert wurde – unabhängig vom Stand der Einführung vor Ort.