385.000 Webseiten wegen leichtsinnigen Drittanbieter-Abhängigkeiten gehackt: Das polyfill Disaster

[DMW007]

Erst ist von 100.000 Betroffenen Webseiten die Rede, später stieg die Zahl auf rund 385.000: Beim Angriff über das CDN von polyfill[.]io hätte es sich schon bei "nur" 100.000 Hosts um den größten Lieferketten-Angriff im Web gehandelt. Nicht nur die bloßen Zahlen sind gigantisch. Es handelt sich bei den gehackten Seiten keineswegs "nur" um kleine Blogs und 1-Mann Betriebe. Bereits auf den ersten Seiten befinden sich zahlreiche mittelgroße Unternehmen bis hin zu Konzernen. Zum Angriff kam es durch den Verkauf der Domain, von der die Polyfill-Bibliothek kostenfrei eingebunden werden konnte. Das mag leichter sein, als sie lokal einzubinden. Doch damit geht man ein deutlich höheres Risiko ein: Der CDN-Anbieter kann die Nutzer verfolgen und durch das eingebundene JavaScript in vielen Fällen beliebigen Code auf den Seiten der Betreiber, die sie einbinden, ausführen. Besucher berichten, wie sie dadurch beim Aufruf von legitimen Seiten auf völlig andere Erwachseneninhalte umgeleitet wurden. Noch weitaus schlimmere Szenen sind technisch ein Klacks: Beispielsweise Zugangsdaten auf einer offiziellen Seite abgreifen, deren Erkennung für Nutzer nahezu unmöglich ist. Oder die Besucher mit Schadsoftware infizieren.

Die Seitenbetreiber sind hier allerdings nicht nur arglose Opfer. Sie haben sich - bewusst oder unbewusst - dazu entschieden, Code von fremden Domains nachzuladen. Das ist grundsätzlich ein Sicherheitsrisiko, dem sich offensichtlich viele nicht bewusst sind. Insbesondere für kleinere und mittelgroße Seiten bietet das nicht mal Vorteile, wodurch die Gefahren völlig unverhältnismäßig sind. Für Sicherheit und Datenschutz wäre das lokale einbinden auf dem eigenen Server viel besser. Selbst wenn weltweit agierende Großkonzerne ein CDN benötigen: Durch das Verwenden von Prüfsummen lässt sich die Gefahr zumindest minimieren. Im Beitrag gehe ich darauf ein, wofür Polyfills eingesetzt werden und mit welchen einfachen Maßnahmen die Seitenbetreiber das Disaster hätten verhindern können. U-Labs verzichtet zum Schutz der Sicherheit & Privatsphäre aller Nutzer bewusst auf das Einbinden von CSS/JS durch fremde Domains und war daher nicht betroffen.

Zum kompletten Beitrag im U-Labs Portal

[U-Labs YouTube]

Antwort von @kaffeetasse2461:
ich kenne auch so leute, die sich lieber ein plugin einbauen, nur damit sie sich 2-3 zeilen code sparen...es is einfach unfassbar.

[U-Labs YouTube]

Antwort von @philhasacomputer:
das Problem sind oftmals nicht die Developer selbst, sondern die, die die Developer bezahlen. Ich denke, unter den meisten Devs sind solche Thematiken klar, wenn man nicht grade blutiger Anfänger ist. Aber die Frage ist, wie macht man sowas einem voll-ignoranten Marketing-Fuzzi klar, dass er ned beim möglichst billigsten Dev sein fancy web-klicki-bunti einkauft? Das Problem ist, dass dort nur zählt wie es ausschaut, sonst NICHTS. Wirklich gar nichts. 20 Jahre bin ich jetzt in dieser dreckigen Branche und ich bin überzeugt davon, dass diese Leute es nicht mal checken würden, wenn sie deren eigene Großmutter durch ihre eigenen ranzigen Schrott doxen würden ... dann würden sie von professionellen Hackern sprechen

[DMW007]

Es liegt sicherlich nicht ausschließlich an den Entwicklern, in dem Punkt gebe ich dir Recht. Lediglich fertige Komponenten zusammen zu kleben, ist ja relativ verbreitet. Am Ende hat man schnell zig Pakete und Frameworks drin, die grundsätzlich auch funktionieren. Aber zusätzlich halt noch zig weitere Funktionen abdecken. Das bringt Komplexität, die am Ende keiner mehr durchblickt und zu Katastrophen wie log4j führt. Wenn das besser werden soll, müssen wir also mehr das Gegenteil machen: Falls Abhängigkeiten notwendig sind, muss man sie verstehen. Wer sich die Log4j Konfigurationsparameter angeschaut und JNDI versteht, dem hätte klar sein können, dass es ein Problem ist. Baut man das Paket ein, übernimmt per C&P den Beispielcode, funktioniert der Code. Aber mit solchen schnell zusammengebastelten Sachen hat keiner ein Verständnis davon. Weder der Inder, der auf Fiver & co. billig irgendwas zusammen bastelt. Der Käufer, der im schlimmsten Falle noch weniger davon versteht, erst Recht nicht. Wenn so was jedoch die Strategie der Führungskräfte ist, hat man ohne Umdenken keine Chance.

Dass die Problematik vielen Entwicklern klar sein soll und die auf Anweisung des Chefs wider besten Wissens handeln, bezweifle ich jedoch unabhängig davon. Ich sehe das hier regelmäßig, wo die Entwickler recht viel Einfluss darauf haben, was sie nutzen. Die entscheiden sich für zig externe Bibliotheken und nehmen das dann gerne universell. Es wird also weniger darauf geschaut, was für den jeweiligen Anwendungszweck sinnvoll ist. Sondern man erschlägt alles mit z.B. Angular & co. Zu meinem Log4j Beitrag gab es Kommentare, bei ihnen sieht es ähnlich aus.

Alleine die zwei Pakete is-even und is-odd belegen, dass es sich dabei leider nicht um verzerrende Einzelfälle handelt. Die haben mehrere hunderttausend Downloads pro Woche. Und das sind nur zwei Beispiele, bei denen es anhand der gezeigten Kriterien für jeden in wenigen Sekunden nachprüfbar ist, wie schwachsinnig das ist. Wer nach z.B. "NodeJs check is even" sucht, findet eine Stackoverflow-Frage mit derzeit 519.000 Aufrufen in 13 Jahren. Weitaus weniger klicken also auf die Frage, als das Modul herunterladen. In der ersten Antwort wird gezeigt, wie man mit jeweils einer Zeile Code prüfen kann, ob eine Zahl gerade oder ungerade ist. Wenn da schon so viele drauf rein fallen, wie wird es erst bei weniger offensichtlichen Dingen aussehen? Wahrscheinlich noch schlimmer.

Als gelernter FiAE wundert mich das leider auch nur bedingt. In der Ausbildung war das nie ein Thema. Dort haben schon andere essenzielle Dinge (z.B. Versionsverwaltung oder Dokumentation) gefehlt. Dort lernt man nicht die notwendigen Grundlagen, um vernünftig arbeiten zu können. Sondern eine Teilmenge, die einen für die Grundlagen vorbereitet. Der Unternehmensteil hängt stark davon ab, wie interessiert die Leute in den Abteilungen sind, vernünftig zu arbeiten. Bei SAP z.B. habe ich ärger gekriegt, weil ich Git vorgeschlagen habe, statt Änderungen in einem riesigen Template am Anfang des Codes zu dokumentieren. Andere Azubis sind nicht mal mit derartigen Systemen in Berührung gekommen, weil die großteils Support oder VBA-Schweinereien in MS Excel zusammengebastelt haben. Bei den Studenten klang es etwas weniger schlecht. Die haben zumindest die Zeit, um das eine oder andere zusätzliche relevante Thema zu behandeln sowie manches zu vertiefen.

In Kombination mit der von dir erwähnten, oft stattfindenden Erwartungshaltung "nur das Ergebnis zählt" haben die auch wenig Motivation, sich mit so was auseinander zu setzen. Ich hatte die Diskussion ebenfalls schon, weil (Sicherheits-) Updates aufgeschoben werden sollten, um funktionelle Sachen umzusetzen. Der Tenor: Sicherheit ist schon wichtig, aber das sieht keiner. Außerdem ist es ja nur intern, machen wir später irgendwann. Wenn wir die anderen Sachen später machen, bekommen wir Stress. In den Unternehmenswerten steht aber, Sicherheit und Integrität gehören zu den wichtigsten Werten. So was sind am Ende PR-Aussagen, wie es nach jedem Hack heißt "Der Schutz ihrer Daten hat oberste Priorität". Meistens hatte er das nicht, wenn die Daten weggekommen sind. Nachdem das beinahe zu einem Angriff geführt hat, stieg die Sensibilisierung. Hat über die Zeit allerdings wieder nachgelassen, insbesondere seit dem gespart werden soll.

Passiert was, kann man es auf die "hohe kriminelle Energie" der "extrem professionellen Hacker" schieben. Mich wundert ja, dass anscheinend keinem auffällt, wie gefühlt nahezu jeder von absoluten Profi APT Hackern angegriffen wird. Ich habe noch nie gelesen, dass gewöhnliche 0815 Kriminelle leichtes Spiel haben, weil die Umgebung schlecht gesichert war. Das kommt nur indirekt im Nachhinein raus, als z.B. SolarWilds eingestehen musste, ihr Passwort war "solarwinds123" und wurde auch noch versehentlich im Netz veröffentlicht. Bei anderen Delikten macht so was das Meiste aus. Die meisten Diebstähle sind schließlich auch keine Profi-Gans, welche das wie im Film 3 Jahre vorher bis ins Detail planen. Gibt es natürlich auch, aber der weitaus größere Teil sind durchschnittliche Taschendiebe, die nach einfachen Gelegenheiten suchen.

[U-Labs YouTube]

Antwort von @Helge_Podschaske:
Die Frage ist doch, was kann ich als Benutzer von Webbrowsern machen, damit diese Drittanbieter es gar kein Zugriff haben?

[U-Labs YouTube]

Antwort von @hugoschmitz6649:
Mit uMatrix konnte man das blocken, aber das Plugin wird leider nicht mehr aktiv gepflegt (funktioniert aber noch)

[U-Labs YouTube]

Antwort von @hugoschmitz6649:
Anscheinend wird der Hinweis auf das Plugin geblockt. Es gibt eines mit einem u am Anfang und Matrix danach, das genau das kann. Damit kannst du, genau einstellen, von welchen Seiten du externe Inhalte laden und ausführen möchtest. Es verhindern also genau das in dem Video beschriebenen Szenario (aber wenn du der Seite an sich vertraust und möchtest das sie funktioniert, dann hätte dir das auch nichts geholfen, da ja die Seitenanbieter den CDN vertraut haben)

[U-Labs YouTube]

Antwort von @iamwitchergeraltofrivia9670:
Auf sichere Seiten gehen die secure storage anbieten

[U-Labs YouTube]

Antwort von @hugoschmitz6649:
@iamwitchergeraltofrivia9670 Niemand sucht sich Seiten nach diesem Kriterien aus. Zumal du i.d.R. nicht weißt, welche Servertechniken und Dienste ein Anbieter nutzt.

[DMW007]

Als Benutzer wird es wesentlich schwieriger. Du kannst mit Erweiterungen wie uMatrix einstellen, dass Drittanbieter-Bibliotheken nicht geladen werden. Das wird allerdings bei einigen Seiten dazu führen, dass die nicht mehr (richtig) funktionieren. In dem Fall müsstest du die händisch prüfen oder im Zweifel auf den Besuch der Seite verzichten. Schlussendlich macht das einiges an Arbeit und ist keine Lösung die still im Hintergrund arbeitet, wie das z.B. bei Werbeblockern meistens der Fall ist. Aus diesem Grunde habe ich es nicht mit in den Beitrag aufgenommen. Für die meisten Nutzer wird das nicht alltagstauglich sein. Die beste Lösung wäre, wenn die Seitenbetreiber sich ernsthaft mit dem Thema Sicherheit befassen und die genannten Maßnahmen umsetzen.