Wenn ich mir überlege, dass die heutige Generation Tablet gar nicht mehr in den Kontakt mit Dateisystemen kommt, keine ausführbaren Dateien kennt und nun auch auf Android vom Sideloading befreit wird, sehe ich auch ein Stück Computergeschichte verloren: Die Zeit der Virenscanner. Diese waren in den 2000ern kaum wegzudenken. Viele der verbreiteten Scanner verwandelten sich dann irgendewann zu Bloatware und ab 2015 mit dem Aufkommen von Windows Defender und dem Siegeszug der mobilen Endgeräte verschwanden sie allmählich in ihrer bisherigen Form. Viele der AV-Hersteller haben sich dann auf Endpoint Security und Mobile Device Management konzentriert. Auf den beiden großen mobilen Plattformen iOS und Android gibt es durch das Sandboxing und die regulierte App-Verteilung sowieso Bedingungen, unter denen das Konzept des Virenscanners einfach nicht mehr funktioniert.
Was aber auch zur goldenen Ära der Virenscanner dazugehörte, war das Argument, dass es Viren auf Linux nahezu nicht gäbe. Das System habe von Haus eine strikte Rechtevergabe und da die Verbreitung des Systems im geringen Prozentbereich liegt, ist es für Angreifer schlicht zu irrelevant für die Entwicklung, als dass es ein lohnenswertes Ziel sei.
AUR
Diese Erklärung greift allerdings zu kurz, wenn wir die aktuellen Beobachtungen im Arch User Repository (AUR) einbeziehen. Angriffswellen in bisher beispiellosem Ausmaß zwangen das Projekt bereits, die Registrierung neuer Benutzer abzuschalten. Am 13. Juli wurde die Nutzerregistrierung zwar wieder erlaubt, aber die Gegenmaßnahmen erwiesen sich in der ersten Iteration als wirkungslos. Aktuell wurde die Übernahme von Paketen deaktiviert, da legitime AUR-Pakete immer mehr von Malware befallen werden.
Das Konzept von Arch Linux, die Paketbereitstellung in die „offiziellen Repositories“ von den vertrauenswürdigen Entwicklung und in eine freie Skriptesammlung (AUR) zu unterteilen, erweist sich rückblickend als gute Entscheidung und Balance zwischen Flexibilität, die bisher immer hervorgehoben wurde, und Sicherheit, wie sie jetzt benötigt wird. Glücklicherweise sind die offiziellen Repositories bisher auch nicht betroffen.
Zwei Punkte sprechen meiner Meinung nach dafür, dass Linux immer mehr ein Ziel wird. Erstens ist die Verbreitung von Linux in den letzten Jahren gestiegen, u. a. auch durch integrierte Systeme wie SteamOS. Das ist für den Desktop eine super Sache, aber macht das System für Malware-Autoren immer attraktiver.
Zweitens werden auf Linux-Systemen immer wertvollere Daten verarbeitet. Die Systeme werden überwiegend von Entwicklern genutzt, die wiederum sich damit auf Server, Cloudumgebungen oder LLM-Kontingente schalten. Im Risikozone-Podcast berichten wir mit einer besonderen Hingabe über Supply-Chain-Attacken und hier trifft es besonders oft die SSH-Keys, CI-Variablen, Wallets oder Cloud-Credentials.
Angreifer, die diese Daten erbeuten, können Informationen kopieren – gut, das konnten sie unter Windows auch. Aber speziell unter Linux-Systemen finden sich durch die ganzen Credentials Daten, mit denen Angreifer Rechenzeit klauen können. Das ist quasi wie moderner Kreditkartenbetrug, nur mit einer Indirektion mehr: Während man einen fremdgetätigten Einkauf vor dem Versand noch mit Mühe rückgängig machen kann, ist die Rechenzeit schon verbraucht und der Cloud-Provider treibt einfach nur das Geld ein.
Bei Credentials handelt es sich auch nicht um Daten, vor denen die klassische Rechtevergabe auf dem lokalen Computer schützt. Wenn die Entwicklungsumgebung, die mit Benutzerrechten arbeitet, die Angabe verarbeiten muss, hat Malware, die unter den gleichen Rechten läuft, zwangsläufig auch Zugriff darauf. Hier haben wir es nicht mit Malware zu tun, die Software systemweit installieren möchte. Man könnte zwar einen Proxy einführen, der die API-Keys in einem geschützten Nutzer wegsperrt und durch den man die Anfragen leiten muss, aber das wären nach heutigem Stand individuelle Speziallösungen.
Geschichte wiederholt sich
Linux steht möglicherweise an einem ähnlichen Punkt wie Windows vor drei Jahrzehnten. AUR und aus dem Internet heruntergeladene Skripte sind natürlich grundsätzlich nicht vertrauenswürdig. Das ist ähnlich wie die .exe-Dateien unter Windows, bevor Signaturen und Smart Screen umfangreich ausgerollt wurden. Besonders fies sind allerdings Package-Adoptions, da ehemals vertrauenswürdige Pakete feindlich übernommen werden.
Paketmanager werden ja sowieso im AUR auf eigene Gefahr bereitgestellt und gute Paketmanager lassen die PKGBUILD vorher noch diffen. Aber genau das Vertrauen in die bekannten Prozesse wie Paketupdates lässt Malware in Form einer Supply-Chain-Attacke durch Updates zu.
Wir werden beobachten müssen, wie das AUR-Team mit den Angriffskampagnen umzugehen lernt und wie der Umgang mit solchen Repositories zukünftig aussehen wird.
Aus Viren wurden Exploits
Bleibt abschließend die Frage, was eigentlich aus Windows und macOS wurde. Sind die Systeme malwarefrei geworden? Mitnichten. Der Fakt, dass der Virenscanner obsolet wurde, begründet sich auf der Eindämmung des Verbreitungsweges des freiwilligen Downloads.
Lädt das Opfer die Viren nicht freiwillig herunter oder wird schlicht der Weg durch das Betriebssystem versperrt, werden härtere Geschütze aufgefahren. Das wären konkret Sicherheitslücken, im aggressivsten Fall Zero Days. Und auch hier sehen wir eine deutliche Zunahme und niederschwellige Verfügbarkeit eben solcher, nicht zuletzt durch LLMs.
Für potentiell Betroffene Nutzergruppen ist nun erhöhte Wachsamkeit bei AUR gefragt: PKGBUILDs auch bei Updates individuell kontrollieren, unbekannte Software höchstens in Containern oder VMs auszuführen und Überlegungen anstellen, wer überhaupt auf Credentials zugreifen kann. Wer z. B. Testing und Entwicklung in getrennte Systeme oder VMs auslagert, verringert das Risiko, dass Daten gestohlen werden können.
