OpenJS und OpenSSF warnen vor Social-Engineering-Übernahmeversuchen bei Open-Source-Projekten

OpenJS und OpenSSF warnen vor Social-Engineering-Übernahmeversuchen bei Open-Source-Projekten

• Der jüngste Backdoor-Versuch bei XZ Utils (CVE-2024-3094) ist möglicherweise kein isolierter Vorfall.
• Da die OpenJS Foundation offenbar ähnliche vertrauensbasierte Übernahmeversuche abgewehrt hat, könnte es sich ebenfalls nicht um einen Einzelfall handeln.
• OpenSSF und die OpenJS Foundation fordern alle Open-Source-Maintainer auf, auf Social-Engineering-Übernahmen zu achten, frühe Bedrohungsmuster zu erkennen und Maßnahmen zum Schutz von Open-Source-Projekten zu ergreifen.

Gescheiterte Übernahmeversuche

• Der Cross Project Council der OpenJS Foundation erhielt eine verdächtige Serie von E-Mails mit ähnlichem Inhalt.
• Der Absender forderte OpenJS auf, eines der populären JavaScript-Projekte zu aktualisieren, "um eine kritische Sicherheitslücke zu beheben", ohne konkrete Angaben zu machen.
• Der Absender wollte, obwohl er zuvor kaum am Code beteiligt war, als neuer Maintainer des Projekts eingesetzt werden.
• Dieser Ansatz war dem Vorgehen von „Jia Tan“ im XZ/liblzma-Backdoor-Vorfall sehr ähnlich.
• Den betreffenden Personen wurde kein Zugriff auf von OpenJS gehostete Projekte gewährt.
• Für das Projekt gibt es Sicherheitsrichtlinien, einschließlich der grob beschriebenen Vorgaben der Security Working Group der Stiftung.
• Das OpenJS-Team identifizierte bei zwei weiteren populären JavaScript-Projekten, die nicht von der Foundation gehostet werden, ähnliche verdächtige Muster und meldete mögliche Risiken sofort den jeweiligen OpenJS-Leads und der CISA (Cybersecurity and Infrastructure Security Agency) im US Department of Homeland Security (DHS).

Verdächtige Muster bei Social-Engineering-Übernahmen

• Muster
  • Ein relativ unbekanntes Community-Mitglied fordert den Maintainer oder die Hosting-Organisation (Foundation oder Unternehmen) auf, und zwar in freundlicher, aber aggressiver und hartnäckiger Weise.
  • Es wird verlangt, eine neue oder unbekannte Person zur Rolle eines Administrators zu befördern.
  • Es wird möglicherweise Unterstützung durch andere Community-Mitglieder mit falscher Identität gesucht (sogenannte „sock puppets“).
  • PRs mit Blob-Artefakten
  • Absichtlich obfuskierten oder schwer nachvollziehbaren Source Code
  • Sicherheitsprobleme, die sich schrittweise verschärfen
  • Einschleusen externer bösartiger Payloads in Blob-, Zip- oder andere Binärartefakte außerhalb üblicher Projekt-Compile-, Build- und Distributionsabläufe
  • Besonders wenn Maintainer durch erzeugten Zeitdruck dazu gebracht werden, die Prüfung oberflächlicher durchzuführen oder Kontrollen zu umgehen.
• Solche Social-Engineering-Angriffe manipulieren das Pflichtgefühl von Maintainern gegenüber Projekt und Community.
• Achten Sie darauf, welches Gefühl die Interaktion hervorruft.
  • Interaktionen, die Selbstzweifel, Unangemessenheit oder das Gefühl auslösen, nicht genug zum Projekt beigetragen zu haben, können Teil eines Social-Engineering-Angriffs sein.
• Ein Social-Engineering-Angriff wie bei XZ/liblzma wurde von der OpenJS-Community erfolgreich verhindert.
• Diese Angriffsform ist schwer programmgesteuert zu erkennen oder abzuwehren, da sie auf einem Vertrauensbruch durch Social Engineering basiert.
• Kurzfristig kann es helfen, wenn man die oben genannten verdächtigen Aktivitäten klar und transparent teilt, um anderen Communities zu helfen, wachsam zu bleiben.
• Eine gute Unterstützung der Maintainer ist eine wichtige Gegenmaßnahme gegen solche Social-Engineering-Angriffe.

Schritte zur Sicherheit von Open-Source-Projekten

• Ziehen Sie die Berücksichtigung branchenüblicher Sicherheits-Best-Practices wie des OpenSSF Guide in Betracht.
• Nutzen Sie starke Authentifizierung: 2FA, Passwort-Manager, sichere Aufbewahrung von Recovery-Codes; verwenden Sie Passwörter/Anmeldedaten nicht in mehreren Services erneut.
• Erarbeiten Sie eine Sicherheitsrichtlinie einschließlich eines Coordinated Disclosure-Prozesses.
• Wenden Sie bei der Zusammenführung neuer Codebeiträge bewährte Verfahren an:
  • Aktivieren Sie Branch Protection und signierte Commits.
  • Lassen Sie, wenn möglich, einen zweiten Entwickler den Code prüfen, bevor ein PR gemergt wird, selbst wenn er von einem Maintainer kommt.
  • Legen Sie Lesbarkeitsanforderungen fest, damit neue PRs nicht obfuskiert sind, und minimieren Sie den Einsatz intransparenter Binärdateien.
  • Beschränken Sie Personen mit Berechtigung für Veröffentlichungen auf npm.
  • Identifizieren Sie Committer und Maintainer und prüfen Sie diese regelmäßig. Beispielsweise: Haben Sie sie bei einer Working-Group-Sitzung gesehen oder auf Events getroffen?
• Falls Sie ein Open-Source-Paket-Repository betreiben, ziehen Sie die Package Repository Security-Prinzipien in Betracht.
• Prüfen Sie CISAs Leitfaden zur Vermeidung von Social-Engineering- und Phishing-Angriffen und/oder ENISAs Beitrag Was ist Social Engineering.

Maßnahmen von Industrie und Staat zur Sicherheit wichtiger Open-Source-Infrastrukturen

• Der Druck, stabile und sichere Open-Source-Projekte aufrechtzuerhalten, belastet die Maintainer.
• Große Ressourcen werden durch internationale Zusammenarbeit zwischen öffentlichem und privatem Sektor benötigt.
• Organisationen wie Open Source Foundations, der Sovereign Tech Fund und viele andere leisten bereits hervorragende Arbeit.
• Für ein Sicherheitsnetz für Open-Source-Projekte sind Bemühungen durch Organisationen ähnlich der Linux Foundation Family erforderlich.
• Die Investitionen der deutschen Regierung in kritische Open-Source-Infrastruktur über die Initiative des Sovereign Tech Fund sind ermutigend.
• Wir unterstützen weitere globale öffentliche Investitionen in Initiativen wie den deutschen Sovereign Tech Fund, um die weltweite öffentliche Investitionsbereitschaft zu erhöhen.

GN⁺-Meinung

• Angreifer nutzen geschickt das Pflichtgefühl der Maintainer aus, um Entwickler zu verunsichern. Daher ist es sinnvoll, auch auf emotionale Veränderungen bei Projektverantwortlichen zu achten.
• Es ist richtig, dass in Sicherheit investiert werden muss; entscheidend ist jedoch, dass die Entwicklungskultur sich grundlegend in Richtung Sicherheit verändert, damit Sicherheit im Entwicklungsprozess natürlich mitwächst.
• Da Angreifer das Vertrauen der Community nutzen, sollten Open-Source-Projekte kontinuierlich daran arbeiten, Vertrauen zwischen ihren Mitgliedern aufzubauen und zu stärken. Persönlicher Austausch kann dabei ein Anfang sein.
• Mehr Projekte wie das Alpha-Omega-Projekt sollten geschaffen und gefördert werden, die tatsächlich in die Verbesserung von Schwachstellen investieren, damit das Sicherheitsniveau von Open-Source-Projekten tatsächlich steigen kann.

[GN⁺]

Hacker News Kommentar

Zusammenfassung:

• Als Open-Source-Projektverwalter wird man bei PRs neuer Beitragender misstrauischer
  • Es kann gut aussehen, aber man sollte berücksichtigen, dass dahinter versteckte Absichten stecken könnten
• Durch jahrelanges Hinzufügen neuer Funktionen ist die Software extrem komplex geworden
  • Der Code wird immer schwerer lesbar und nur noch von wenigen Menschen wirklich verstanden
  • Wenn erfahrene Entwickler in den Ruhestand gehen, werden viele Teile unverständlich werden
• Für große Projekte braucht es ein System zur Meldung von Änderungsanfragen
  • Es sollte mit Versionen/Releases synchronisiert werden, etwa über npm.js oder Debian-Pakete
  • Wie bei einer europäischen Bank können Aufsichten aus mehreren Ländern kontrollieren
• Wie bei dem Spiel Eve Online ist Vorsicht nötig, wenn man Vertrauen durch wertvolle Beiträge gewinnt und dann verraten wird
• 2FA/MFA sollten nur in selbst gehosteten Systemen eingesetzt werden
  • Bei Drittanbietersystemen kann man sich dauerhaft sperren, wenn man den zweiten Authentifizierungsfaktor verliert
  • Nur durch eigenes Hosting behält man die Kontrolle
• In Open Source wird es eine unangenehme Debatte zwischen Inklusion und langfristiger Sicherheit geben
  • Entwickler aus Ländern wie Iran, Russland und China stehen bereits unter Generalverdacht
  • Vielleicht ist es sinnvoller, zu forken und mit Verbündeten gemeinsam beizutragen
  • Gegner können Änderungen im Original mergen, ohne dass Lizenzen oder Urheberrechte sie aufhalten
• Jedes Projekt sollte eigene Standards festlegen und unmaintained Abhängigkeiten schnell entfernen
  • Es wäre auch denkbar, die Sensitivität des Projekts zu bewerten
• Seit dem XZ-Angriff fragt man sich, wie häufig solche Angriffe werden
  • Open Source könnte verwundbarer sein als Closed-Source-Software
  • weil jeder Code schreiben kann und es bösartige Motive gibt
• Es scheint schwierig zu sein, das frühere Verhalten bestehender Open-Source-Projekte im Nachhinein zu beurteilen
• Seit langem wird gefordert, sich auf einfache Architektur und gute Coding-Standards zu konzentrieren
  • Doch die Leute fügen mit TypeScript, React etc. immer mehr unnötige Abhängigkeiten hinzu
  • Unsere Unwissenheit und Naivität werden von Gegnern belächelt
  • Die gesamte Branche, vielleicht sogar das politische System, könnte kompromittiert sein
• Man hätte nach Projekten mit minimalem Code und wenigen Abhängigkeiten suchen sollen
  • Saubere Projekte verlieren Aufmerksamkeit und Chancen, während überdesignt Projekte nach vorne kommen
  • Sie sind nun leichte Ziele für bösartige Akteure geworden
  • In der Komplexität ist es einfach, Schwachstellen zu verbergen