API-Angriffe – warum sie für Telekommunikationsunternehmen eine besondere Herausforderung darstellen

Gegen die angebliche Einfachheit der Angriffe auf Application Programming Interfaces (APIs) hagelte es zuletzt heftige Kritik an Telekommunikationsanbietern. Allerdings stehen Telekommunikationsunternehmen bei der Sicherung ihrer APIs vor besonderen Herausforderungen, da sie im Zuge der Ausweitung des IoT Tausende von Anwendungen über eine ständig wachsende Anzahl von Geräten bedienen. Darüber hinaus sind viele mit einem ausgedehnten IT-Bestand und geerbten Systemen, einschließlich älterer Legacy-APIs, konfrontiert, der dann durch Abonnentenwachstum und M&A-Aktivitäten weiter gestört wird. Folglich läuft im Vergleich zu anderen Unternehmen ein unverhältnismäßig großer Teil des Telekommunikationsökosystems auf APIs.

Auch die jüngsten Schlagzeilen machenden API-Angriffe waren raffinierter, als man auf den ersten Blick vermuten würde. Angreifer kombinieren jetzt mehrere Angriffsmethoden aus dem Menü der OWASP API Top Ten, wobei API2 (Broken User Authentication) mit API3 (Excessive Data Exposure) und API9 (Improper Assets Management) kombiniert wird. Telekommunikationsunternehmen sind in dieser Hinsicht nicht die einzigen, denn im ersten Halbjahr 2022 war ein deutlicher Trend bei Angriffen auf undokumentierte oder „Schatten“-APIs und taktische Angriffe zu verzeichnen, die mehrere OWASP-Bedrohungen oder API10+ nutzen, wie im API Protection Report behandelt. 

Bei einem der diesjährigen Angriffe waren die missbrauchten APIs für eine Entwicklungstestumgebung gedacht, wurden jedoch versehentlich öffentlich zugänglich gemacht. Bei der Erkundung des Netzwerks stellten die Angreifer fest, dass die APIs nicht authentifiziert und nicht autorisiert waren, und antworteten mit Kundendaten aus einer Live-Datenbank. Es gab auch keine Überprüfungen des Schlüsseleingabeparameters, der für jeden Benutzer eine Schlüsselkennung liefert, was es zu einer trivialen Übung machte, dann einen Bot-Angriff zu starten, um verschiedene Benutzer-IDs zu durchlaufen, bevor die Kundendaten zurückgegeben wurden. 

Ein Weckruf

Es ist wichtig zu beachten, dass diese Art von Angriff blitzschnell sein kann und bei unzureichender Sicherheit nur wenige Minuten in Anspruch nehmen kann. Infolgedessen erkennen Betreiber auf der ganzen Welt nun, dass sie die APIs in ihrem Netzwerk erkennen, eine Erkennung einrichten müssen, um zu erkennen, wann und wie sich ein Angriff manifestiert, und ihre APIs verteidigen müssen. 

In einem anderen Beispiel führte ein großer Mobilfunkbetreiber mit über 100 Millionen Abonnenten kürzlich eine Entdeckungsübung durch, um die APIs seiner Infrastruktur zu überprüfen. Es stellte fest, dass über tausend ungeschützte API-Server, was 18 Prozent der Serverbasis entspricht, öffentlich zugänglich waren. Über 30 Prozent der API-Server hatten SSL-Probleme wie ungültige oder abgelaufene Zertifikate, die es einem Angreifer ermöglicht hätten, einen Man-in-the-Middle-Angriff zu starten. 

Das Telekommunikationsunternehmen entdeckte außerdem über 107 Dateien, die private Schlüssel offenlegen könnten, die in den falschen Händen für den Zugriff auf geschäftskritische Geschäftsinformationen hätten verwendet werden können. Darüber hinaus wurden trotz einer früheren rigorosen Patching-Kampagne zur Behebung der Bedrohung durch die Log4Shell-Schwachstelle fünf APIs entdeckt, die weiterhin anfällig für dieses Problem sind.

Bei einem weiteren Angriff gegen einen der größten Telekommunikationsanbieter der Welt wurde der größte OWASP-Exploit – Broken Object Level Authorization – genutzt, um den Zugriff auf die API aufzulisten, um einen Account Takeover (ATO)-Angriff mit dem Endziel des SIM-Tauschs durchzuführen.

Die Kriminellen wollten Informationen über ein Kundenkonto erhalten, indem sie aufzählten, ob Mobilfunknummern in das Netz des Anbieters übertragen werden könnten. Nachdem der Angreifer übertragbare Telefonnummern entdeckt hatte, versuchte er, sich als Kontoinhaber auszugeben, um einen Mitarbeiter dazu zu bringen, die Handynummer auf eine SIM-Karte im Besitz des Angreifers zu übertragen. Ab diesem Zeitpunkt könnte der Angreifer dann die Kontrolle über die sensiblen Konten des Opfers übernehmen, indem er eine SMS-basierte 2FA durchführt.

Die Erkennung solcher Angriffe ist schwierig, da der Datenverkehr über mehrere IP-Bereiche von bekanntermaßen bösartigen Bulletproof Proxies rotiert. Es gibt jedoch verräterische Werbegeschenke. Das Timing der Anfrage war zu perfekt, da die Angreifer in Abständen von zwei Sekunden eine einzelne API-Endpunktanfrage pro IP initiierten, was zu neun Millionen böswilligen Anfragen führte, und es gab ein hohes Verhältnis von IP zu Anfrage, da jede Telefonnummer von vorne versucht wurde 200 IP-Adressen. Da das Telekommunikationsunternehmen diese verdächtige Aktivität erkennen konnte, konnte der Angriff während der zehn Stunden, in denen er andauerte, erfolgreich blockiert werden.

Verbesserung der API-Sicherheit

Da Angreifer eine größere Vielfalt an Taktiken, Techniken und Verfahren (TTPs) einsetzen, liegt die Verantwortung nun bei den Telekommunikationsanbietern. Aber wenn diese Angriffe entgegen der Meinung raffiniert sind und der Telekommunikationsbereich schwer zu sichern ist, was kann dann getan werden, um diese APIs zu sichern?

Finden Sie zunächst heraus, womit Sie es zu tun haben, indem Sie Ihre APIs dokumentieren und mithilfe einer Laufzeitinventur sicherstellen, dass alle APIs bekannt sind. Wenn APIs hochgefahren und vergessen werden, kann der Angreifer sie nach Belieben und unentdeckt analysieren.

Zweitens ist es wichtig zu beachten, dass selbst perfekt codierte APIs immer noch anfällig für Missbrauch sein können. Obwohl die Einbeziehung von Sicherheitstests in den Entwicklungsprozess (auch bekannt als „Shift Left“) von entscheidender Bedeutung ist, sollten alle APIs als anfällig betrachtet werden. Dies liegt daran, dass der Missbrauch der Geschäftslogik, bei dem der Angreifer die API ausspioniert und legitime Anfragen verwendet, um Zugriff zu erhalten, gegen diese APIs eingesetzt werden kann. 

Aus diesem Grund ist es wichtig zu wissen, wie das „normale“ Verhalten dieser API aussieht, und durch eine Verkehrsanalyse Abweichungen davon zu überwachen. Viele der vorhandenen API-Sicherheitsmechanismen wie WAFs oder API-Gateways basieren auf einer signaturbasierten Erkennung, wenn eine verhaltensbasierte Analyse erforderlich ist, die verdächtige Anfragen erkennen kann.

Das letzte Puzzleteil ist die Verteidigung. Die Möglichkeit, Ihre API-Infrastruktur durch die Augen eines Angreifers zu betrachten, kann es dem Unternehmen ermöglichen, seine öffentlich zugänglichen APIs und deren Hostingort zu identifizieren, wichtige Patches durchzuführen und sie kontinuierlich zu überwachen. Sollte es zu einem Angriff kommen, kann mit dem Vorfall auf vielfältige Weise umgegangen werden, von Echtzeitblockierung bis hin zum Einsatz von Täuschungs- und Ablenkungstechniken, um den Angreifer zu frustrieren und ihn zum Abbruch des Angriffs zu bewegen.

Im Fall des oben erwähnten vielschichtigen API10+-Angriffs würde die Erkennungsphase beispielsweise alle Schatten- oder öffentlich zugänglichen APIs aufdecken, während die Erkennung feststellen würde, ob eine Authentifizierung vorhanden war und ob die APIs in ihrer Antwort vertrauliche Daten verarbeiteten. Schließlich würde das Verteidigungselement auf das Wissen reagieren, dass ein Angreifer einen Bot-Angriff ausführt, und den Datenverkehr automatisch blockieren und den Angreifer abwehren.

Die einzige Möglichkeit für Telekommunikationsanbieter, diesen Angriffen entgegenzuwirken, ist die Einführung einer Sicherheitsstrategie, die den gesamten API-Lebenszyklus abdeckt und darauf abzielt, diese Angriffe zu erkennen, zu erkennen und abzuwehren, insbesondere angesichts der Komplexität ihres API-Bestands und ihrer Serviceangebote.