- Das Paket Lotusbail ist ein Fork der legitimen WhatsApp-Web-API-Bibliothek Baileys und enthält Schadcode; es wurde in sechs Monaten mehr als 56.000 Mal über npm heruntergeladen
- Es stellt normal funktionierende API-Funktionen bereit, während es gleichzeitig WhatsApp-Anmeldedaten, Nachrichten, Kontakte und Mediendateien exfiltriert und an Server der Angreifer sendet
- Die Daten werden über mehrere Schichten aus RSA, AES, Base-91 und LZString verschlüsselt und verschleiert übertragen, wodurch Sicherheitsüberwachung umgangen werden kann
- Das Paket installiert eine Backdoor, die über einen hartkodierten Pairing-Code das Gerät des Angreifers dauerhaft mit dem WhatsApp-Konto des Nutzers verbindet
- Der Fall zeigt die zunehmende Raffinesse von Supply-Chain-Angriffen und unterstreicht die Notwendigkeit verhaltensbasierter Sicherheitsüberwachung, da eine Erkennung allein durch statische Analyse nicht möglich ist
Überblick über das Lotusbail-Paket
lotusbailist ein Fork von@whiskeysockets/baileysund bietet dieselben WhatsApp-Web-API-Funktionen- Das Senden und Empfangen von Nachrichten funktioniert ordnungsgemäß, weshalb Entwickler es wahrscheinlich ohne Verdacht installieren
- Es war sechs Monate lang auf npm registriert und konnte zum Zeitpunkt der Erstellung weiterhin heruntergeladen werden
- Hinter der eigentlichen Funktion verbergen sich jedoch bösartige Aktivitäten wie Diebstahl von WhatsApp-Anmeldedaten, Abfangen von Nachrichten, Sammeln von Kontakten und Installation einer Backdoor
Welche Informationen gestohlen werden
- Dazu gehören Authentifizierungs-Token und Sitzungsschlüssel, der gesamte Nachrichtenverlauf, Kontaktlisten inklusive Telefonnummern, Mediendateien und Dokumente sowie dauerhafter Backdoor-Zugriff
- Alle Daten werden vor der Übertragung an den Server der Angreifer verschlüsselt
Funktionsweise
Tarnfunktion, die tatsächlich arbeitet
- Die meisten bösartigen npm-Pakete funktionieren fehlerhaft oder lassen sich durch verdächtigen Code leicht identifizieren, doch Lotusbail tarnt sich als normal funktionierende API
- Es basiert auf der legitimen Baileys-Bibliothek und verfügt über eine vollständig implementierte Nachrichten-Sende- und Empfangsfunktion
- Dadurch kommt ein Social-Engineering-Ansatz zum Einsatz, bei dem Entwickler in „normal funktionierendem Code“ keine bösartigen Aktivitäten vermuten
Datendiebstahl und Übertragung
- Das Paket arbeitet, indem es den WebSocket-Client für die Kommunikation mit WhatsApp umschließt
- Bei der Authentifizierung werden Anmeldedaten erfasst, und beim Empfang und Versand von Nachrichten werden sämtliche Inhalte dupliziert
- Die legitime Funktion bleibt unverändert erhalten; lediglich alle Daten werden zusätzlich an die Angreifer weitergeleitet
- Die gestohlenen Daten werden mittels einer benutzerdefinierten RSA-Implementierung verschlüsselt übertragen
- Diese existiert getrennt von der Ende-zu-Ende-Verschlüsselung von WhatsApp selbst und dient als Verschlüsselung zur Umgehung der Netzwerküberwachung
- Die Serveradresse wird nicht direkt im Code offengelegt, sondern in einer verschlüsselten Konfigurationszeichenfolge verborgen
- Dabei kommt eine vierstufige Verschleierung mit Unicode-Variablenmanipulation, LZString-Komprimierung, Base-91-Kodierung und AES-Verschlüsselung zum Einsatz
Installation der Backdoor
- Die Funktion für Geräte-Pairing-Codes von WhatsApp wird missbraucht, um das Gerät des Angreifers mit dem Konto des Nutzers zu verbinden
- Im Paket ist ein mit AES verschlüsselter hartkodierter Pairing-Code enthalten
- Wenn sich der Nutzer authentifiziert, wird gleichzeitig auch das Gerät des Angreifers verbunden und erhält dadurch dauerhaften Kontozugriff
- Der Angreifer kann dadurch das gesamte Konto kontrollieren, also Nachrichten lesen und versenden, Medien herunterladen und auf Kontakte zugreifen
- Selbst wenn das npm-Paket gelöscht wird, bleibt das Gerät des Angreifers weiterhin verbunden; eine Sperrung ist nur möglich, wenn in den WhatsApp-Einstellungen manuell alle Geräteverbindungen getrennt werden
Techniken zur Analyseumgehung
- Der Code enthält 27 Fallen mit Endlosschleifen, die bei Erkennung von Debugging-Tools die Ausführung stoppen
- Es werden Debugger, Prozessargumente und Sandbox-Umgebungen erkannt, um die dynamische Analyse zu behindern
- Die bösartigen Codebereiche sind kommentiert, was auf Spuren systematischer Entwicklungsverwaltung hinweist
Fazit und sicherheitsrelevante Implikationen
- Die Verfeinerung von Supply-Chain-Angriffen schreitet voran, und Fälle nehmen zu, in denen sich Schadcode als normal funktionierender Code tarnt
- Eine Erkennung allein durch statische Analyse und reputationsbasierte Verifikation ist schwierig; erforderlich ist eine Verhaltensanalyse zur Laufzeit (behavioral analysis)
- Der Fall Lotusbail zeigt, wie eine Sicherheitslücke ausgenutzt wird, die darauf beruht, „Code für sicher zu halten, nur weil er funktioniert“, und verdeutlicht die Bedeutung von Systemen zur Überwachung des Laufzeitverhaltens
- Das Forschungsteam von Koi Security identifizierte durch solche laufzeitbasierten Erkennungstechniken Bedrohungen, die bestehende Prüfverfahren umgehen
1 Kommentare
Hacker-News-Kommentare
Es ist frustrierend, dass Sicherheitsteams bei jedem Malware-Vorfall dazu tendieren, Daten übermäßig abzuriegeln
Der Auslöser war zwar das Leaken von WhatsApp-Nachrichten, aber am Ende wäre vermutlich ohnehin etwas anderes gestohlen worden
Wenn man Apps so einschränkt, dass nur bestimmte Signaturen sie lesen können, werden auch legitime Backups oder Datenzugriffe unmöglich
Mehr Sicherheit ist gut, aber eine Überverteidigung, bei der einfach alles verriegelt wird, ist meiner Meinung nach ein weiteres Problem
Nutzer greifen darauf zu, ähnlich wie wenn sie einen anderen Client mit ihrem WhatsApp-Konto verbinden, und dadurch ist Zugriff auf die gesamten Daten möglich
Wenn WhatsApp eine vernünftige offizielle API bereitgestellt hätte, wäre so etwas seltener
Relevante Dokumentation: Baileys Wiki
Früher gab es zwar mehr Malware, aber dafür auch deutlich mehr Freiheit und Interoperabilität
Solche Angriffe sind inzwischen ein vorhersehbares Ergebnis
Paketmanager wie NPM holen Abhängigkeiten direkt vor dem Build, was sie strukturell verwundbar macht
Problematisch ist, dass dabei Versionsverwaltung umgangen wird und zugleich eine Kultur herrscht, unzählige Abhängigkeiten ungeprüft zu übernehmen
Nicht nur NPM, auch Cargo, Docker, CI/CD und praktisch alle Ökosysteme haben ähnliche Probleme
Das Modell „nach Namen installieren und fertig“ basiert auf viel zu viel Vertrauen
Eine echte Lösung ist schwer zu finden — auf Zusammenarbeit verzichten kann man nicht, vollständige Sicherheit ist aber auch unmöglich
Am Ende ist das Monster schon im Haus
Selbst wenn man eine git-URL direkt angibt, wäre das Ergebnis dasselbe
Letztlich ist es ein strukturelles Problem des Abhängigkeitsmanagements
Es wirkt, als bräuchten wir einen standardisierten Paketmanager, der nicht an eine Sprache gebunden ist
Funktionen wie Signaturprüfung, Herkunftsnachweis und standardisierte APIs wären essenziell
Wie der xz-Vorfall gezeigt hat, können auch infizierte Pakete unverändert verteilt werden
Außerdem unterstützen System-Paketmanager aktuelle Versionen oft zu langsam und sind daher für die Entwicklung ungeeignet
Deshalb braucht man am Ende doch Tools wie npm, cargo oder pip
Das Problem war nicht der Paketmanager, sondern dass der Code von vornherein nicht vertrauenswürdig war
Es ist schon komisch, dass der Malware-Autor Funktionsnamen wie exfiltrateCredentials so offen gewählt hat
Ironisch, dass sogar Debugger-Erkennung eingebaut war, aber keine eigentliche Code-Obfuskation
Wir leben wohl in einer Zeit, in der sogar Malware-Tests eine Form von Entwicklung geworden sind
Die Formulierung „Abhängigkeiten, die Entwickler gedankenlos installieren“ ist ziemlich unheimlich
Außer in Organisationen mit strengen Sicherheitsrichtlinien ist das realistisch kaum zu verhindern
Vielleicht besteht die Lösung am Ende nur darin, npm weniger zu benutzen
Wer nur nach Tags referenziert, ist jederzeit Supply-Chain-Angriffen ausgesetzt
Die Branche läuft auf weit mehr blindem Vertrauen als man denkt
Automatisierte Deployments haben nicht einmal die Gelegenheit, „noch einmal nachzudenken“
Es wäre schön, wenn es für JavaScript so etwas wie Apache Commons als große, vertrauenswürdige Bibliothek gäbe
Apache Commons Einfuehrung
Das Paket lotusbail ist ein bösartiges npm-Paket, das sich als WhatsApp-Web-API ausgibt
Es wurde sechs Monate lang verteilt und führte verschiedene Angriffe aus, darunter Diebstahl von Zugangsdaten, Abfangen von Nachrichten und Installation von Backdoors
Entwickler, die vom JS-Ökosystem abhängen, brauchen in der Praxis Strategien zur Risikominderung
Genannt wurden dabei Docker oder VMs
Wir haben alle Entwicklungsumgebungen containerisiert und Abhängigkeiten auf feste Versionen gelockt
Keine globalen Installationen, keine automatischen Updates, manuelle Prüfung als Pflicht
Für sensible Projekte wurden dedizierte Workstations regelmäßig zurückgesetzt
Das ist lästig, aber eine realistische Form von Sicherheit
Oder man verlässt eben das JS-Ökosystem ganz
Auf OS- oder Docker-Ebene müsste man bestätigen können, ob Netzwerkverbindungen erlaubt werden
Der Kernel wird zwar geteilt, aber um Angriffe aus dem JS-Ökosystem abzuwehren, reicht das völlig
Wenn irgendwann ein Container-Escape-Angriff über npm auftaucht, steige ich dann auf VMs um
Anfangs hielt ich das für übertriebene Sicherheit, aber inzwischen ist es schnell und stabil
Bis dahin zeigt sich meist, ob sie bösartig sind
Dieses Paket war von Anfang an ein Sicherheitsfehler
Es nutzte keine offizielle API, sondern eine nachimplementierte Client-Authentifizierung, und die geheimen Schlüssel der Nutzer wurden von Dritten verarbeitet
Nutzer hätten vorsichtiger sein sollen, aber man kann ihnen nicht die ganze Schuld geben
API-Zugriff bekommt man nur nach Registrierung für die „WhatsApp Business Platform“
Wenn es eine echte API gegeben hätte, wäre das wohl nicht passiert
Gefährlich wird es erst, wenn man bei der Authentifizierung geheime Schlüssel an Dritte weitergibt
Solche Pakete installiert man normalerweise, um den eigenen Account zu automatisieren
In letzter Zeit gibt es massenhaft von LLMs erzeugte Blogposts
Die Qualität ist niedrig, aber die Kosten sind null, also ist das aus Marketingsicht effizient
Traditionelles Schreiben ist inzwischen fast schon Legacy
Supply-Chain-Angriffe scheinen zuzunehmen. Wie sollten Entwickler darauf reagieren?
Solche Muster sollte man automatisiert erkennen und die Prüfprozesse verschärfen
Containerisierung, Dependency Locking, Security-Scans und verzögerte Updates sind Pflicht
Globale npm-Installationen sind die schlechteste Wahl
Container oder VMs wie rootless podman helfen, das Risiko zu minimieren