3 Punkte von GN⁺ 18 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Download-Links der beliebten System-Utilities HWMonitor und CPU-Z wurden vorübergehend manipuliert, um Malware zu verbreiten
  • Die Angreifer kompromittierten Teile des Backends der CPUID-Website und lieferten dadurch zufällig bösartige Dateien anstelle der regulären Installer aus
  • Die bösartige Version enthielt eine gefälschte CRYPTBASE.dll, kommunizierte mit einem Command-and-Control-Server und schleuste per PowerShell eine .NET-Payload ein, die im Arbeitsspeicher ausgeführt wurde
  • CPUID bestätigte den Vorfall und erklärte, das Problem sei innerhalb von 6 Stunden behoben worden; die signierten Originaldateien seien nicht verändert worden
  • Der Vorfall zeigt als Fortsetzung von Supply-Chain-Angriffen, dass schon der Verteilungsweg Schaden verursachen kann, auch ohne Änderungen am Code selbst

HWMonitor-Download nach Hack der CPUID-Website durch Malware ersetzt

  • Die CPUID-Website wurde vorübergehend kompromittiert, wodurch die Download-Links von HWMonitor und CPU-Z auf einen Malware-Verteilungsweg umgebogen wurden
    • Die Angreifer übernahmen Teile des Backends und ersetzten reguläre Links zufällig durch bösartige Dateien
    • Einige Nutzer berichteten, dass der Installer Antivirenwarnungen auslöste oder mit ungewöhnlichen Dateinamen angezeigt wurde
  • Es wurde bestätigt, dass der Update-Link für HWMonitor 1.63 auf die falsche Datei „HWiNFO_Monitor_Setup.exe“ zeigte, was auf eine Manipulation in einer vorgelagerten Stufe hindeutet
    • In Communities wie Reddit bemerkten zahlreiche Nutzer das Problem und warnten andere
  • CPUID bestätigte den Einbruch später offiziell und erklärte, dass nicht der Software-Build selbst, sondern eine unterstützende API (Backend-Komponente) für etwa 6 Stunden kompromittiert gewesen sei
    • Der Vorfall ereignete sich zwischen dem 9. und 10. April und ist inzwischen behoben
    • Zudem wurde ausdrücklich erklärt, dass die signierten Originaldateien nicht beschädigt wurden
  • Die bösartige Installationsdatei zielte auf 64-Bit-HWMonitor-Nutzer und enthielt eine gefälschte CRYPTBASE.dll, die wie eine Windows-Komponente aussah
    • Diese DLL verbindet sich mit einem Command-and-Control-(C2)-Server, um weitere Payloads herunterzuladen
    • Um keine Spuren auf der Festplatte zu hinterlassen, wird die Malware per PowerShell im Arbeitsspeicher ausgeführt, kompiliert auf dem Opfersystem eine .NET-Payload und injiziert sie in andere Prozesse
    • Beobachtet wurde auch ein Zugriff auf im Browser gespeicherte Zugangsdaten über das Chrome-IElevation-COM-Interface
  • Die Analyse ergab, dass der Angriff dieselbe Infrastruktur nutzte wie eine frühere Kampagne gegen FileZilla-Nutzer
    • Laut der Analyse von vx-underground gibt es Hinweise darauf, dass dieselbe Angreifergruppe mehrere Software-Verteilungsnetze missbraucht hat
  • CPUID erklärte, das Problem sei behoben, doch der API-Zugriffsweg und die Zahl der infizierten Nutzer wurden bislang nicht veröffentlicht
    • Der Vorfall gilt als Beispiel dafür, dass Angreifer auch ohne Änderungen am eigentlichen Code allein über den Verteilungsweg Schaden anrichten können

1 Kommentare

 
GN⁺ 18 일 전
Hacker-News-Kommentare
  • Der Maintainer Sam von CPU-Z hat die Situation selbst erklärt. Während Franck derzeit abwesend ist, überprüft er den Server und hat anhand des VirusTotal-Links bestätigt, dass die Serverdateien in Ordnung sind. Allerdings wurden einige Links manipuliert und führten zu einem bösartigen Installer; dadurch bestand etwa 6 Stunden lang (09/04–10/04 GMT) ein Risiko. Inzwischen wurden die Links wiederhergestellt und die Website für weitere Untersuchungen in den Read-only-Modus versetzt

    • Als jemand, der früher CPU-Reviews geschrieben hat, kann ich bestätigen, dass sowohl Sam als auch Franck vertrauenswürdige Personen sind. Franck ist eine Schlüsselfigur bei CPUID, und Sam ist auch durch Canard PC und das Memtest-Projekt bekannt
    • Gut, dass das Problem schnell erkannt und die Links korrigiert wurden. Zuerst dachte ich tatsächlich, die Werbebanner auf cpuid.com seien das Problem. Auf der Download-Seite gibt es zu viele gefälschte Buttons wie „Download Now“ oder „Install for Windows 10/11“. Deshalb bevorzuge ich in solchen Fällen den Befehl winget install CPUID.CPU-Z
    • In den letzten Wochen ist das bereits das dritte Mal, dass ich gesehen habe, wie Verfügbarkeitsbenachrichtigungen in Discord oder anderen Chats für Timing-Angriffe missbraucht wurden
    • Ich frage mich, wie dieser Angriff genau durchgeführt wurde
  • Ein Fall, in dem Windows Defender den Virus direkt nach dem Download erkannt hat, dies aber ignoriert wurde, weil es sonst oft Fehlalarme gibt. Solche False Positives haben den Nebeneffekt, das Sicherheitsbewusstsein abzustumpfen

    • Ich denke, Microsoft trägt ebenfalls einen Teil der Verantwortung. Wenn Defender Crack-Dateien einfach mit Gründen wie „Win32/Keygen“ blockiert, gewöhnen sich Nutzer daran, Antivirus zu deaktivieren. Am Ende führt das dazu, dass auch echte Malware durchkommt
    • Source-basierte Distribution oder reproduzierbare Builds könnten helfen, dieses Problem abzumildern
    • Um solche Situationen zu verhindern, braucht es einen vertrauenswürdigen Windows-App-Store oder Paketmanager
  • Spöttische Bezeichnung für Menschen, die neue Softwareversionen sofort installieren: „menschliche Schutzschilde

    • Allerdings werden CPU-Z oder HWMonitor nach der Einrichtung eines neuen PCs oft direkt genutzt, um die Hardware zu prüfen. Das ist nicht wie bei npm-Paketen, wo experimentelle Updates getestet werden, sondern schlicht das Herunterladen der neuesten Version
    • Es wäre gut, wenn es Werkzeuge gäbe, die Nutzern den Sicherheitsruf einer Software anzeigen. Crowdstrike oder SAST-Tools erkennen Probleme schließlich erst nach der Installation
    • Andererseits ist auch eine einen Monat alte Version nicht automatisch sicher. Angreifer könnten bösartiges Verhalten erst nach mehreren Monaten aktivieren
  • Betroffen war diesmal HWMonitor; die offizielle Seite und HWInfo sind unterschiedliche Programme. Auch auf Reddit wird dasselbe Thema diskutiert

  • Die Installationsdatei selbst war in Ordnung, aber der Link auf der Website wurde manipuliert und verwies auf eine bösartige ausführbare Datei in Cloudflare R2. Eine Ursachenanalyse wird mit Interesse erwartet

    • Das ist weniger ein Supply-Chain-Angriff als vielmehr ein Watering-Hole-Angriff. Für Entwickler ist die Nutzung von Paketmanagern wie winget oder chocolatey sicherer
  • Für Windows-Nutzer ist die Installation per winget relativ vorteilhaft. Im offiziellen Manifest wird eine Signaturprüfung durchgeführt, und mit winget install --exact --id CPUID.CPU-Z lässt sich die Installation sicher ausführen

    • Allerdings ist WinGet kein vollständiger Schutz. Der Prüfprozess ist oberflächlich, und wenn die Quelle bereits kompromittiert ist, könnten auch bösartige Updates durchkommen. Im Grunde ist es eine CLI-Version von MajorGeeks
    • Mit einem SHA-Check im Manifest allein lässt sich Manipulation nur schwer verhindern. Ich frage mich, wie die Signaturprüfung genau funktioniert
    • Trotzdem wird Winget stetig besser. Als zum Beispiel der offizielle Download-Link von ImageMagick defekt war, funktionierte der Download über Winget problemlos
    • Dank Paketmanagern konnte auch beim jüngsten Notepad++-Hijacking-Vorfall der Schaden reduziert werden. Wenn Entwickler selbst verteilen, müssen sie auf Infrastruktursicherheit wie PKI-Management und die Verteilung von Signaturschlüsseln achten
  • Es gibt Sorge, ob die über Winget installierten Versionen (v1.63, v2.19) sicher sind. Zur Prüfung werden das GitHub-Manifest und der Winstall-Link angesehen

  • Offenbar war dieselbe Gruppe beteiligt, die im letzten Monat FileZilla angegriffen hatte. Diesmal wurde keine gefälschte Domain verwendet, sondern die API-Schicht der offiziellen Website kompromittiert, sodass die legitime Seite bösartige Dateien auslieferte

  • Weitere technische Details sind im Beitrag von vx-underground zusammengefasst

  • Dieser Angriff war ein ausgefeilter Versuch, auf Utilities zu zielen, denen technisch versierte Nutzer vertrauen; die Hauptangriffsfläche war nicht die Binärdatei selbst, sondern die API-Schicht, die die Download-Links erzeugt