- Googles Threat Analysis Group (TAG) hat kürzlich Angriffe auf Sicherheitsforscher bestätigt und festgestellt, dass dabei eine ausgenutzte Zero-Day-Schwachstelle im Spiel war.
- Die Zero-Day-Schwachstelle wurde dem betroffenen Anbieter gemeldet, ein Patch ist in Arbeit.
- Nordkoreanische Angreifer führten über soziale Medien wie Twitter aktiv Gespräche mit ihren Zielen und bauten so Beziehungen auf.
- In einem Fall unterhielten sie sich über mehrere Monate mit einem Sicherheitsforscher über gemeinsame Interessengebiete und gewannen so dessen Vertrauen.
- Anschließend wechselten sie zu einer verschlüsselten Messaging-App und verschickten eine bösartige Datei, die mindestens eine Zero-Day-Schwachstelle in einem populären Softwarepaket enthielt.
- War die Ausnutzung erfolgreich, prüfte der Shellcode auf virtuelle Maschinen und übermittelte verschiedene Informationen an die Server der Angreifer; die Umsetzung ähnelte dabei früher entdeckten nordkoreanischen Angriffen auf Schwachstellen.
- Zusätzlich zu den gezielten Angriffen über Zero-Day-Schwachstellen entwickelten sie auch ein Open-Source-Tool für Reverse Engineering und veröffentlichten es auf Github.
- Das Programm wurde erstmals am 30. September 2022 veröffentlicht und anschließend aktiv weiterentwickelt und mehrfach aktualisiert.
- Das Tool enthielt jedoch eine Backdoor, mit der beliebiger Code vom Server der Angreifer heruntergeladen und ausgeführt werden konnte.
- TAG empfiehlt, Systeme zu überprüfen und das OS bei Bedarf neu zu installieren, wenn dieses Tool verwendet wurde.
- Alle identifizierten bösartigen Websites und Domains wurden zu Google Safe Browsing hinzugefügt, und an möglicherweise betroffene Google-Konten wurde eine Warnung vor staatlich unterstützten Angriffen gesendet.
- Außerdem wurden alle bösartigen Domains, Dateien und Konten wie dbgsymbol, blgbeach und @Paul091_ offengelegt.
5 Kommentare
Gezielte Angriffe sind schon beängstigend, aber bei dem Teil, bei dem bösartiger Code in Open-Source-Projekte eingeschleust wurde, sollte man wohl noch vorsichtiger sein.
Der Quellcode des betreffenden Tools war offenbar unauffällig, aber in den in den GitHub Releases enthaltenen Dateien befand sich Schadcode.
Es soll mehr als 200 separate GitHub-Sterne gegeben haben ...
Plötzlich häufen sich die Sicherheitsmeldungen. Alle sollten wohl stärker auf Sicherheit achten.
Ich dachte, den Quellcode könnte man immerhin noch verifizieren, aber dass er sich von dem Release unterscheiden könnte, daran habe ich gar nicht gedacht. Sicherheit kennt wirklich kein Ende..
Das scheint auch eine Art Supply-Chain-Angriff zu sein.
Gerade im Fall von Go 1.21.0, das vor einem Monat veröffentlicht wurde, haben sie damals erstmals einen Blogbeitrag veröffentlicht, in dem stand, dass die Build-Ergebnisse ihrer Toolchain vollständig reproduzierbar seien. Die ersten beiden Absätze dieses Artikels lauten wie folgt.
Perfectly Reproducible, Verified Go Toolchains
> Einer der wichtigsten Vorteile von Open-Source-Software ist, dass jeder den Quellcode lesen und seine Funktionen prüfen kann. Da die meiste Software, selbst Open-Source-Software, jedoch als kompilierte Binärdatei heruntergeladen wird, ist sie sehr viel schwerer zu überprüfen. Wenn ein Angreifer einen Supply-Chain-Angriff auf ein Open-Source-Projekt durchführen will, ist das unauffälligste Vorgehen, die bereitgestellte Binärdatei auszutauschen, ohne den Quellcode zu verändern.
>
> Der beste Weg, sich gegen diese Art von Angriff zu schützen, besteht darin, Open-Source-Software-Builds reproduzierbar zu machen — also sicherzustellen, dass ein Build, der mit derselben Quelle startet, bei jeder Ausführung dieselbe Ausgabe erzeugt. Dadurch kann jeder direkt aus dem tatsächlichen Quellcode bauen und prüfen, ob die neu erzeugte Binärdatei bitgenau mit der veröffentlichten Binärdatei übereinstimmt, sodass sich verifizieren lässt, dass die veröffentlichte Binärdatei keine versteckten Änderungen enthält. Dieser Ansatz beweist, ohne die Binärdatei zu zerlegen oder ihr Innenleben zu untersuchen, dass sie keine Backdoor oder sonstige Änderungen enthält, die nicht im Quellcode stehen. Da jeder die Binärdatei überprüfen kann, können unabhängige Gruppen Supply-Chain-Angriffe leicht erkennen und melden. (DeepL-Übersetzung)
Ich habe mich gefragt, warum man sich über so etwas Sorgen macht, und offenbar wurden Angriffe dieser Art bereits seit ungefähr einem Jahr heimlich durchgeführt. Ach, was für eine gefährliche Welt …
Ich neige auch dazu, Dingen etwas mehr zu vertrauen, wenn sie zusammen mit Code auf GitHub hochgeladen wurden … Man muss wohl trotzdem vorsichtig sein.
Bleibt am Ende nur, den Code immer zu prüfen und selbst zu bauen …
KI-Zusammenfassung des HN-Threads