Ein Leser hat uns kontaktiert und einen konkreten Fall auf einem Marktplatz geschildert, der Unternehmen und Freelancer zusammenbringt. Dort erhielt er ein Jobangebot, das mit einem Zugang zu einem Git-Repository versehen war. Ein beim Start des Projekts aufgerufenes, unscheinbares Node-Script lädt dann Schadcode nach und verankert diesen persistent im System.

Das Klonen des beim Jobangebot mitgeteilten Repositories ist noch harmlos. Erst beim Starten, etwa mittels „npm run“, kommt das bösartige Skript zur Ausführung. Der Analyse des Lesers zufolge lädt das Node-Script mittels HTTP JavaScript-Code aus dem Netz nach. Den wertet es mittels eval() aus – das übersetzt eine übergebene Zeichenkette in Code, der schließlich ausgeführt wird und sich im Benutzerverzeichnis des Systems einnistet. Der Schadcode startet im Hintergrund und verbindet sich zu einem Command-and-Control-Server.

Der nachgeladene Schadcode umfasst Infostealer-Funktionen. Er durchsucht den Rechner nach Profilen von Webbrowsern wie Brave, Chrome, Edge, Opera und weiteren und entschlüsselt die darin abgelegten Zugangsdaten mittels Windows-Data-Protection-API (DPAPI). Zudem sucht und sammelt er Cookies, Wallets etwa von Electrum, Exodus und MetaMask sowie .env-Dateien und überträgt sie dann an die Command-and-Control-Server, ergab die Auswertung unseres Lesers. Die Angreifer können zudem Backdoor-Funktionen zum Ausführen von Shell-Befehlen, das Hochladen von Dateien und das Herunterladen weiterer Dateien nutzen.

GitHub kann im konkreten Fall nichts ausrichten, da es sich um ein privates Repository handelt, teilte Microsoft dem Leser offenbar mit. Im konkreten Fall gab es für das vermeintliche Projekt keine öffentliche Ausschreibung, etwa auf Freelancermap oder bei anderen vergleichbaren Anbietern. Der Betrüger hat sich jedoch die Mühe gemacht und einen Namen ausgewählt, der zu einem Entwicklerprofil passt, wenn man mit der Suchmaschine danach sucht.

Masche global bereits gesichtet

Derartige Git-Repositories kennt Kaspersky seit etwa drei Jahren und nennt die Masche „GitVenom“, für vergiftete Git-Repositories. Ein Artikel auf dev.to beschreibt die Masche im englischsprachigen Raum. Dort nennt der Autor auch einige Alarmzeichen, die auf möglicherweise unheilvolle Jobangebote hindeuten. Etwa unaufgefordert angebotene Jobs, die einfach zu gut klingen, oder Druck, Aufgaben so schnell wie möglich zu erledigen. Die Aufforderung, Code als Teil eines Vorstellungsgesprächs herunterzuladen und auszuführen, ist ebenfalls eine „Red Flag“.

Auf technischer Ebene sollte „überall verteilter base64-kodierter Müll“ aufhorchen lassen oder mitgelieferte Dateien, die niemals genutzt werden. Stutzig machen sollten Beschreibungen im README, die komplett davon abweichen, was der Code tatsächlich macht oder etwa Abhängigkeiten, die keinen Sinn in dem Projekt ergeben. Ganz neue GitHub-Konten ohne nennenswerten Verlauf sind ebenfalls verdächtig, ebenso mehrere gleichartige Projekte vom gleichen Account.

Entwickler sollen sich schützen, indem sie etwa alles unabhängig überprüfen und nicht der E-Mail blind vertrauen: Gibt es die Firma tatsächlich, wer steckt dahinter? Gibt es die Stellenausschreibung auch auf der Webseite der Organisation? Ist die Firma bereit, auch Video-Anrufe zu machen und antwortet sinnvoll auf Detailfragen zum Unternehmen? Das Isolieren von solchen Entwicklungsumgebungen in virtuelle Maschinen kann helfen, potenziellen Schaden einzuschränken. Auf jeden Fall müssen Entwickler inzwischen ebenfalls sehr vorsichtig sein, um nicht auf fortgeschrittene Malware-Maschen hereinzufallen.

(dmk)

Seit über fünfzig Jahren ermöglicht der Interrail-Pass günstige Bahnreisen quer durch Europa. Verwaltet wird das Pauschalangebot, das sich zunächst primär an junge Leute richtete, von der Eurail B.V. im niederländischen Utrecht. Diese warnt nun ihre Kunden vor einem Datenleck: Ein Unbekannter hatte Zugriff auf die Kundendatenbank des Unternehmens und konnte so womöglich Stamm- und Ausweisdaten der Interrail-Nutzer abgreifen.

Viele Einzelheiten gibt es zum Vorfall nicht, doch gibt Eurail an, der unbekannte Angreifer hätte auf folgende Daten zugreifen können:

• Bestell- und Reservierungsinformationen,
• Kontakt- und Identitätsdaten sowie
• Nummer, ausstellendes Land und Ablaufdatum von Reisepass oder Personalausweis.

Man speichere bei Interrail-Kunden keine Kopie des Ausweisdokuments, sondern nur die angegebenen Daten, erläutert Eurail. Das gilt jedoch nicht für alle Kunden. Wer eine Fahrkarte im Rahmen des „DiscoverEU“-Programms erworben hat, muss zusätzlich damit rechnen, dass Ausweiskopien, IBAN-Nummer und Gesundheitsdaten in fremde Hände geraten seien, gibt eine separate Meldung an.

Details sind unklar, Ermittlungen laufen

Wann der Vorfall sich ereignete und wen man konkret des Einbruchs verdächtigt, erläutert Eurail nicht. Offenbar ist das Unternehmen jedoch sicher, es handele sich lediglich um eine Einzelperson. Man ermittle weitere Details gemeinsam mit IT-Sicherheitsspezialisten und Forensikern, habe die Sicherheitslücken geschlossen, missbrauchte Zugangsdaten geändert und Sicherheitsmaßnahmen verstärkt. Alle direkt betroffenen Kunden habe man informiert, auch die zuständige Aufsichtsbehörde, die niederländische Autoriteit Persoonsgegevens, sei im Bilde.

Eurail mahnt seine Kunden zur Wachsamkeit: Die Angreifer könnten mit den erbeuteten Daten Phishing- oder Betrugsversuche starten, auch Identitätsdiebstahl sei denkbar. Das Unternehmen hat eine FAQ eingerichtet, um weitere Unterstützung zu leisten.

Bahntickets zum Pauschal- oder Monatspreis sind attraktive Ziele für Betrüger und Fälscher. Das Deutschlandticket wurde über illegale Shops angeboten, was den Verkehrsunternehmen einen Schaden von bis zu einer halben Milliarde Euro seit 2024 bescherte. Auch Ausweiskopien sind beliebt, weil sie bei Identitätsbetrug helfen – sie werden bisweilen zu Tausenden im Darknet gehandelt.

(cku)

Ende Dezember 2025 haben die Sicherheitsforscher Lexi Groves alias 49016 und Liam Wachter auf dem 39. Chaos Communication Congress in Hamburg Sicherheitslücken in verschiedenen Werkzeugen zum Verschlüsseln und Signieren von Daten demonstriert. Neben einzelnen Lücken in den Tools Age, Minisign und Sequoia-PGP stand die populäre PGP-Implementierung GnuPG im Fokus des Vortrags. Darin fanden die Sicherheitsforscher zahlreiche Probleme unterschiedlichen Schweregrades und mit diversen Ursachen. In den Tagen nach der Präsentation entspannen sich mehrfach Diskussionen über die Bewertung der einzelnen Lücken und die Reaktion der GnuPG-Entwickler darauf.

Weitgehend einig ist man sich bei einer fehlerhaften Schleife, die zu uninitialisiertem Speicher und einem inkonsistenten Programmzustand führt. Seit 1999 schlummerte dieser Bug im GnuPG-Code. Werner Koch, Urheber und maßgeblicher Entwickler von GnuPG, nennt ihn „den einzigen schweren Fehler“ von den vorab an GnuPG gemeldeten Problemen. Behoben wurde der Bug in Version 2.5.14 vom 19. November 2025. Allerdings wurden 2.5.x-Versionen damals vom GnuPG-Projekt noch als Entwicklungszweig („devel“) geführt. Übliche Linux-Distributionen lieferten daher 2.4.x-Versionen aus und waren von der Lücke zum Zeitpunkt der Veröffentlichung betroffen. Erst am 30. Dezember, drei Tage nach dem Vortrag, veröffentlichte das GnuPG-Projekt Version 2.4.9 mit demselben Bugfix. Ebenfalls kurz nach dem Vortrag wurde der 2.4.x-Zweig auf der GnuPG-Hompage als „oldstable“ deklariert und 2.5.x wurde zu „stable“.

„Not a bug“

Gar nicht beheben wollen die GnuPG-Entwickler dagegen ein anderes Problem: Die Forscher demonstrierten einen Angriff, bei dem das Opfer scheinbar einen Schlüssel des Angreifers dechiffriert und das Resultat auf einen Schlüsselserver hochlädt; beispielsweise im Glauben, damit dem Angreifer im Kampf gegen Zensurmaßnahmen zu helfen. In Wahrheit dechiffriert GnuPG bei dem Angriff dagegen eine an das Opfer verschlüsselte (und für den Angreifer unlesbare) Datei – und platziert einen Teil des gewonnenen Klartextes in der generierten Schlüsseldatei. Wer die nun tatsächlich auf den Schlüsselserver hochlädt, dessen URL der Angreifer ebenfalls setzen kann, exfiltriert unwissentlich vertrauliche Daten an den Angreifer.

Für den Angriff nutzen die Forscher eine geschickt manipulierte Datei, die GnuPG mehrfach fundamental aus dem Tritt bringt. Statt einer deutlichen Sicherheitswarnung, dass die Datei manipuliert wurde, meldet GnuPG lediglich, dass es auf ein „ungültiges Paket“ gestoßen sei, das nicht entschlüsselt werden konnte. Eine scheinbar korrekte Schlüsseldatei produziert es dennoch, was Opfer plausiblerweise dazu verleiten könnte, die Datei wie gewünscht hochzuladen. Doch weil GnuPG grundsätzlich ein Problem meldet, halten seine Entwickler keine Gegenmaßnahmen für erforderlich.

Viele weitere der demonstrierten Probleme betreffen „Cleartext Signatures“, ein altes und von grundsätzlichen Problemen geplagtes Signaturformat. Die meisten dieser Probleme wollen die GnuPG-Entwickler ebenfalls nicht beheben, weil sie ohnehin grundsätzlich von Cleartext Signatures abraten und empfehlen, die verbreiteteren „detached signatures“ zu nutzen, die üblicherweise auch bei E-Mails zum Einsatz kommen. Entfernen könne man das problematische Format allerdings nicht, weil es noch zu verbreitet sei, so Werner Koch, und zudem gebe es kein Problem, wenn man Cleartext Signatures richtig nutze.

Grundsätzliche Kritik an PGP

Alle weiteren von Lexi Groves und Liam Wachter demonstrierten Probleme zu beschreiben, würde den Umfang dieses Artikels deutlich sprengen; wir haben Ihnen eine Übersicht mit weiterführenden Links zusammengestellt. Der Umfang der Probleme und die teilweise als unzureichend wahrgenommenen Reaktionen der Entwickler ließen jedenfalls grundsätzliche Diskussionen zum Zustand von GnuPG und dem PGP-System insgesamt wieder aufflammen.

An PGP wird seit geraumer Zeit viel kritisiert, etwa dass das Kryptosystem kompliziert in der Handhabung sei und es Nutzern leicht mache, fatale Fehler zu begehen. Ein zentraler Kritikpunkt ist, dass PGP zu viele Aufgaben erfüllen wolle, um irgendeine davon wirklich gut zu erfüllen. Außerdem tragen PGP-Implementierungen viele veraltete Algorithmen und Formate mit sich herum, derer sie sich aus Gründen der Kompatibilität nur schlecht entledigen können.

Hinzu kam vor etwa zwei Jahren ein Richtungsstreit, der in zwei neuen, zueinander inkompatiblen Standards mündete: OpenPGP (RFC 9580), dem die meisten PGP-Implementierungen folgen, und LibrePGP, der von Werner Koch für GnuPG definiert wurde. Dass man im Alltag von diesen Inkompatibilitäten oft wenig merkt, liegt unter anderem an einem FreePG genannten Patchset, mit dem einige große Linux-Distributionen das von ihnen ausgelieferte GnuPG modifizieren und standardmäßig weitgehende Kompatibilität wiederherstellen. Die jetzt demonstrierten Probleme lassen Aufrufe, PGP insgesamt oder zumindest GnuPG hinter sich zu lassen, wieder lauter werden.

(syt)