Die Anwendungen, die die überwiegende Mehrheit der heutigen hyperkomplexen Technologie-Stacks ausmachen, sind stark vom Code von Drittanbietern abhängig. Leider werden die erheblichen Vorteile, die diese vorgefertigten Komponenten bieten, häufig durch die schwerwiegenden Auswirkungen der Architektur Dritter auf die Sicherheit beeinträchtigt.
Für moderne Unternehmen ist es wichtig, diese Risiken nicht nur zu erkennen, sondern auch aktiv dazu beizutragen, Angriffsströme einzudämmen. Modernste Tools, einschließlich einer WAF-Lösung der nächsten Generation, können möglicherweise die einzige Möglichkeit sein, die Existenz Dritter sicherzustellen.
1. Code von Drittanbietern: Warum das Rad neu erfinden?
Drittcode beschreibt alle Zeilen eines Programms, die in verschiedenen Anwendungen reproduziert werden können. Dies erleichtert den Entwicklungsprozess einer App, da das Code-Recycling die Markteinführungszeit erheblich verkürzen kann. Aber selbst wenn die Grundlage einer App gelegt ist, können die Entwickler Drittanbietercode für Anzeigenverfolgung, Kundenrezensionen, Zahlungen, Chatbots, Tag-Management, Social-Media-Integration oder andere Hilfsbibliotheken nutzen, die allgemeine Funktionen vereinfachen.
Die schiere Nützlichkeit und Verfügbarkeit von Code von Drittanbietern hat dazu geführt, dass er jeden Winkel des Internets infiltriert: Heutzutage macht Code von Drittanbietern bis zu 70 % jeder Website aus. In derselben Umfrage gaben 99 % der Befragten an, dass die von ihrer Organisation genutzten und erstellten Websites mindestens einen Code von Drittanbietern enthalten.
Open Source beschreibt eine Art Drittcode, wobei sich der Begriff „Drittanbieter“ jedoch auch auf extern entwickelten Code bezieht, dessen Nutzungslizenz möglicherweise erworben wurde. Wie hoch der kommerzielle Preis dieses Kodex auch sein mag, Unternehmen haben die sozialen und sicherheitsbezogenen Kosten zu lange ignoriert.
2. Die verborgene Gefahr von Ghostcode
Code von Drittanbietern eignet sich für die Entwicklung leicht zugänglicher Websites und Anwendungen. Während diese No-Code- oder Low-Code-Umgebungen dazu beitragen, die Eintrittsbarriere für Unternehmer und begeisterte Bastler zu senken, ist es wichtig, die Risiken zu verstehen. Cyberkriminelle sind mehr als bereit, naive oder unvorsichtige Entwickler auszunutzen. Manchmal ist es nicht der Mangel an Fähigkeiten, der es ihnen ermöglicht, einzudringen, sondern der starke Druck zu einem schnellen Einsatz.
Unter dem Dach von Magecart zusammengefasste Angreifer machen sich seit 2015 Codes von Drittanbietern zunutze. Dieses Verbrechersyndikat setzt auf den Diebstahl digitaler Kreditkarten, die durch heimliches Einschleusen von JavaScript-Code auf E-Commerce-Zahlungsseiten erbeutet werden. Magecart hat mit beeindruckenden Einsätzen eine Spur der Zerstörung gesät: Ticketmaster, British Airways und unzählige andere Online-Marken sind alle ihren Angriffen zum Opfer gefallen.
Im Jahr 2020 kam es zu zwei aufsehenerregenden Angriffen: Der Kinderbekleidungshersteller Hanna Andersson und der britische Einzelhändler Sweaty Betty wurden ins Visier genommen. Es wird angenommen, dass es sich bei beiden Angriffen um scheinbar harmlose Site-Add-Ons handelte. Allerdings fügen Magecart-Angreifer in diesen Codezeilen einige wichtige Zeilen JavaScript ein.
Dieser Code eines Drittanbieters kopiert häufig legitime Zahlungsformulare auf einer E-Commerce-Website. Es wurden jedoch entscheidende – winzige – Änderungen vorgenommen. Beispielsweise werden Zahlungsinformationen heimlich an einen vom Angreifer kontrollierten Server gesendet. Die Transaktion selbst ist weiterhin autorisiert, sodass Endbenutzer im Dunkeln tappen.
Der Angriff auf Hanna Andersson blieb mehrere Wochen lang unbemerkt – obwohl er relativ schnell entdeckt wurde und andere Opfer fast ein Jahr lang im Dunkeln blieben. Die meisten Opfer werden erst benachrichtigt, wenn gestohlene Kreditkarteninformationen auf Dark-Web-Marktplätzen auftauchen.
Die Kosten sind erheblich: Hanna Andersson wurde zur Zahlung von 400.000 US-Dollar Schadenersatz an mehr als 200.000 Kunden verurteilt; Die genauen Kosten für einzelne Opfer lassen sich schwerer bestimmen, aber der Diebstahl ihres Namens, ihrer Lieferadresse, ihrer Rechnungsadresse und ihrer Zahlungskarteninformationen ermöglicht es Angreifern, unglaublichen Schaden anzurichten. Magecart-Angriffe erfreuten sich während der Covid-19-Pandemie immer größerer Beliebtheit und verzeichneten einen Anstieg um 20 %, während die durchschnittliche Erkennungszeit 22 Tage erreichte.
Magecart stellt möglicherweise bösartigen Code von Drittanbietern dar, aber selbst getesteter Open-Source-Code kann versehentlich eines der größten Sicherheitsprobleme dieses Jahrzehnts verursachen. Log4j beschreibt eine Open-Source-Protokollierungsbibliothek, die zu einem der wichtigsten Teile der Webarchitektur geworden ist und für die Weiterleitung wichtiger Protokollierungsinformationen an das Entwicklungs- und Wartungsteam verantwortlich ist.
Im Jahr 2021 wurde jedoch festgestellt, dass die log4j-Bibliothek stark anfällig für die Ausführung von Remotecode ist. Hunderte Millionen Geräte sind dann ernsthaft gefährdet, da der Fehler zudem relativ einfach auszunutzen ist.
Es ist nicht realistisch, komplett auf Code von Drittanbietern zu verzichten. Mehr als 60 % der Websites weltweit laufen auf Apache- und Nginx-Servern, und 90 % der IT-Manager verwenden regelmäßig Open-Source-Unternehmenscode. Jede moderne Software basiert auf bereits vorhandenen Komponenten, und die völlige Neuerstellung dieser Funktionen würde einen enormen Zeit- und Geldaufwand erfordern, um selbst relativ einfache Anwendungen zu erstellen.
3. Mit einem Patch kommt man nicht davon.
Nach der Integration in eine Anwendung kann es schwierig sein, Code von Drittanbietern zu testen und noch schwieriger zu sichern. Korrekturen liegen ausschließlich bei den Entwicklern. Selbst für aktive, gut gemeinte Entwickler, etwa diejenigen, die die log4j-Funktionalität pflegen, nehmen Korrekturen eine entscheidende Zeit in Anspruch.
Keine Angst: Eine umfassende Sicherheitslösung kann mehrere Tools bieten, um Patches virtuell anzuwenden und Angreifer letztendlich im Keim zu ersticken. Ein solches Tool ist die Web Application Firewall (WAF). Es befindet sich zwischen der Anwendung und dem Endbenutzer und überwacht und filtert den passierenden Datenverkehr. WAFs der nächsten Generation bieten eine automatische Richtlinienerstellung sowie eine schnelle Regelverbreitung, um das Sicherheitsnetz, das Code von Drittanbietern benötigt, explizit zu erweitern.
Während sich die herkömmliche WAF hauptsächlich auf die Überwachung externer Verbindungen konzentriert, beschreibt Web Application and API Protection (WAAP) eine umfassendere Schutzsuite. Es beinhaltet den Firewall-basierten WAF-Ansatz, konzentriert sich jedoch stärker auf APIs. Diese Codeteile ermöglichen den programmgesteuerten Zugriff auf verschiedene Anwendungen und waren in der Vergangenheit eine große Schwachstelle in der Abwehr von Unternehmen.
Schließlich bietet der Runtime Application Self-Protection (RASP) einen überzeugenden nächsten Schritt in Richtung automatisierten Schutz. Anstatt sich außerhalb des Anwendungscodes zu befinden, verhält sich RASP wie ein Plugin, das sich an die Interna der Anwendung anschließt. Durch seine interne Sicht auf eine Anwendung kann RASP deren Verhalten überwachen und typische Anmeldungen und Berechtigungen abbilden, die unter der Haube auftreten. Sobald ein grundlegendes Verhalten festgestellt wurde, kann RASP verdächtiges Verhalten automatisch erkennen und, was noch wichtiger ist, stoppen.
Mit einer proaktiven Reihe virtueller Patching-Maßnahmen kann Ihre Sicherheit mit DevOps Schritt halten und gleichzeitig dazu beitragen, die Bedrohung durch Cyberkriminelle und die daraus resultierenden Klagen abzuwehren.