Supply Chain als Angriffsvektor
Mal wieder nur indirekt zugehörig zum Thema Datenschutz, aber etwas, was mich seit Jahren irritiert und umtreibt, inbesondere im Bereich der Webentwicklung: Wie sich Firmen mit ihren Produkten und Dienstleistungen von externen Software-Repositories abhängig machen.
Mir ist ein Artikel über den Weg gelaufen, der eine schon im vergangenen Jahr von Alex Birsan entdeckte Problematik mit offenen Paket-Repositories für verschiedene Programmiersprachen beschreibt. Alex Birsan ist ein Security Researcher und wurde für seinen Fund reichlich belohnt. Der Kerl hat nämlich u.a. einfach mal Unerwünschtes in Läden wie Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp und Uber durch so genannte Dependency Confusion eingeschleust.
Geht im Prinzip darum, dass man - um Entwicklungszeit zu sparen - sich auf externe Produkte/Module verlässt und diese in eigene Projekte integriert. Im Bereich der Webentwicklung besonders gern gemacht, wenn es um kompliziertere und sicherheitskritische Sachen wie Datenvalidierung geht. Der oben genannte Fall ist etwas spezieller, aber treten wir mal einen Schritt zurück und betrachten das Problem allgemeiner.
Einfaches Beispiel: Jemand baut ein Formular, mit dem Daten irgendwo hin übermittelt werden sollen. Nun wird üblicherweise der User-Input auf Wohlgeformtheit bzw. auf maliziöse Inhalte geprüft. Und da viele Webentwickler aus Agenturen nicht das Know-how und/oder die Zeit haben, sich mit der Validierung von Daten zu befassen, werden irgendwelche externen Module eingebunden, die diese Datenprüfung abhandeln. Meist ohne, dass der Entwickler sich diesen Fremdcode mal richtig gut angeschaut oder verstanden hätte, was der eigentlich tut.
Ich habe zwei Dekaden lang für Agenturen gearbeitet, die u.a. Webanwendungen auf Basis von Typo3 entwickeln. Eines der aus meiner Sicht größten Probleme der letzten Jahre (nicht nur bei Typo3, aber hier konnte ich es besonders gut beobachten) ist composer, eine Paketverwaltung für die Programmiersprache php.
Die meisten neuen Typo3-Projekte werden mit composer aufgesetzt. Wenn es nun jemand hinkriegt, weit verbreitete composer-Pakete mit Schadecode zu versorgen, ist davon auszugehen, dass gleich zahllose Typo3-Webanwendungen davon betroffen sind. Oder übergeordnet: Symfony-Projekte. Oder wasweißich alles.
Halbwegs kompetente Agenturen haben noch einen Deployment-Workflow, der wenigstens Dev- und Testsysteme beinhaltet, auf denen Updates geprüft werden, bevor sie in eine Produktionsumgebung geraten. Aber ich möchte mal behaupten, dass ein nicht geringer Anteil dieser Updates nicht auf Herz und Nieren untersucht wird, sondern nur ein schneller Funktionscheck stattfindet. Sofern die Anwendung aus Usersicht noch so läuft wie sie soll, ist alles in Butter und die Updates werden ins Livesystem übernommen. Und Bumm.
Einen Schritt zurück: Die Problematik der Auto-Updates betrifft auch Wordpress. Oder gar Apps auf Handys. Betriebssystem-Updates. Software in Autos, Krankenhäusern, Regierungen. Siehe auch SolarWinds. Eine Abwärtsspirale, entstanden durch Kosten- und Zeitdruck (unfertige Produkte ausliefern, Updates nachschieben), Milchmädchen-Rechnungen, schlechtere Ausbildung, zusammengekürztes Qualitätsmanagement, blablabla...
*schnauf* *jammer*
Eigentlich müssten sich Entwickler weigern, diese Spirale mitzugehen. Aber... Kapitalismus.