Wachsende Risiken durch Improper Authentication

Bei dem US-amerikanische Hersteller von Fitnessgeräten Peloton ist es aufgrund einer fehlerhaft konfigurierten API zu einem Datensicherheitsvorfall gekommen. Ein Kommentar von Ben Sadeghipour, Head of Hacker Education bei Hackerone.

Erst vor wenigen Tagen wurde bekannt, dass der US-amerikanische Hersteller von Fitnessgeräten Peloton seine Laufbänder nach einer zum Teil tödlich verlaufenden Unfallserie mit Kleinkindern zurückruft. Neben den bereits zuvor in Verruf geratenen Laufbändern hat das Unternehmen nun jedoch noch mit einem weiteren Problem zu kämpfen: Wie die auf Cybersicherheit spezialisierte US-Webseite Threat Post berichtet, kam es aufgrund einer fehlerhaft konfigurierten API zu einem Datensicherheitsvorfall in Verbindung mit den Fitness-Bikes von Peloton, bei dem Kundendaten einsehbar waren.

Das Unternehmen reagierte erst viel zu spät auf die ihm zuvor gemeldete Sicherheitslücke, wie der Sicherheitsforscher von Pen Test Partners, Jan Masters, in einem Blog-Beitrag darlegt. Darin erläutert Masters zudem umfassend die zugrundeliegende Problematik und beschreibt die Sicherheitslücken anhand dreier Schwächen (Issues) der API.

Ben Sadeghipour, Head of Hacker Education bei Hackerone, hat diesen Vorfall nun zum Anlass genommen, um auf die Risiken in Verbindung mit fehlerhaft konfigurierten APIs hinzuweise:

„Der Hauptgrund für dieses Problem ist die unsachgemäße Authentifizierung – oder Improper Authentication–, eine der von Hackern auf Hackerone meistgemeldeten Schwachstellen. In dieser Hinsicht konnten wir feststellen, dass der Betrag, den Unternehmen für die Meldung von Schwachstellen im Zusammenhang mit unsachgemäßer Authentifizierung zahlen, von Jahr zu Jahr um 36 Prozent zunimmt. Wenn sich Entwicklungszyklen beschleunigen, steigt unweigerlich auch die Wahrscheinlichkeit dafür, dass sich Schwachstellen in den Code einschleichen. Daher überrascht es kaum, dass bei der Geschwindigkeit moderner Softwareentwicklung Schwachstellen wie diese immer wieder auftreten. Bei einer unbekannten Domäne wie der in diesem Fall referenzierten, braucht es einen gegnerischen Ansatz mit einer angemessenen Untersuchung, um die Assets und das Risiko zu identifizieren, das sie für die Benutzer darstellen.

Bei ‚Issue 3‘ war der Hacker in der Lage, eine Backend-API, bzw. ein Backend-System, zu identifizieren, in dem die Schwachstelle zu finden war. Da diese Domäne Graphql nutzt, ist es nicht sehr schwer, auf ihr Schema zuzugreifen und es zu spezifizieren, sofern man über ein fundamentales Verständnis für Graphql verfügt – was bei vielen guten Hackern der Fall ist. Aber der Erfolg aller Prüfungen auf Sicherheitslücken hängt davon ab, dass auch Maßnahmen ergriffen werden, um die Schwachstellen zu schließen. Unternehmen können die beste Technologie und die besten Systeme zum Einsatz bringen, jedoch funktionieren diese nur so lannge, bis jemand darin einen Fehler entdeckt und diesen direkt ausnützt.

Deshalb ist es wichtig, dass die Sicherheitsteams der Unternehmen in der Lage sind, schnell und effektiv auf Meldungen von Schwachstellen und Sicherheitslücken zu reagieren, um zu verhindern, dass diese von böswilligen Akteuren ausgenutzt werden. Denn diese könnten die nächsten sein, die das Problem ebenfalls erkennen. Eine Richtlinie zur Offenlegung von Schwachstellen ist ein wichtiger und weithin akzeptierter Ansatz, um sicherzustellen, dass gefundene Sicherheitslücken in die richtigen Hände gelangen und auch behoben werden.“