Sysmon v11.0 von den Sysinternals-Tools freigegeben

[English]Microsoft-Mitarbeiter Mark Russinovich hat sein Sysinternals-Tool Sysmon zum 28. April 2020 in der Version 11.0 freigegeben. Hier ein paar Informationen dazu. Und auch mal wieder ein Blick, wie das Ganze sicherheitstechnisch ausschaut.


Anzeige

Die Sysinternals-Tools sind ja eine kleine Sammlung hilfreicher Tools für Windows (ab Windows 7), die Microsoft-Mitarbeiter Mark Russinovich kostenlos anbietet und von Zeit zu Zeit aktualisiert. Eine Übersicht über alle Tools findet sich auf der Sysinternals-Tool-Webseite.

Sysmon v11.0, das ist neu

Bei der Version 11.0 handelt es sich, laut changelog um ein größeres Update. Neu wurde die Überwachung und Protokollierung von Operationen zum Löschen von Dateien eingeführt. Ziel ist es, solche durch Malware oder Ransomware vorgenommene Operationen zumindest für eine spätere Analyse zu protokollieren.

In Version 11.0 gibt es zudem eine Option zur Deaktivierung der Reverse-DNS-Suche (Reverse DNS Lockup). Und leere Felder werden durch ein  ‘-‘ ersetzt, um einen WEF-Fehler (Windows Event Forwarding-Problem) zu umgehen.

Die neue Version behebt zudem ein Problem, das dazu führte, dass einige ProcessAccess-Ereignisse abgebrochen wurden. Weiterhin hasht die neue Version von Sysmon die Hauptdatenströme, die als in der Cloud gespeichert markiert sind, nicht mehr.

Wozu braucht man Sysmon?

Sysmon besitzt keine eigene Oberfläche wie Processmon, sondern es installiert sowohl einen Systemdienst als auch einen Gerätetreiber unter Windows. Die notwendigen Aufrufoptionen zur Installation sind auf der Sysmon-Seite ausführlich beschrieben.

Nach der Installation verbleiben Treiber und Dienste resistent auf dem System. Der Gerätetreiber erfasst dann die Systemaktivitäten, die durch den Dienst in der Ereignisanzeige protokolliert werden. Das umfasst detaillierte Informationen über das Erstellen von Prozessen und Netzwerkverbindungen sowie Änderungen der Dateierstellungszeiten von Dateisystemobjekten.

Administratoren können so im Nachhinein die Windows Ereignisanzeige verwenden, um die Einträge im Ereignisprotokoll anzusehen. Zudem ist eine Erfassung und Auswertung der Ereignisanzeige durch SIEM-Lösungen (Security information and event management) möglich. Das Ziel dabei: Durch anschließende Analyse bösartige oder anomale Aktivitäten erkennen und bei Angriffen verstehen, wie Eindringlinge und Malware im Netzwerk agieren.

Wo gibt es Details und den Download?


Anzeige

Die Sysinternals Tools stehen kostenlos auf dieser Webseite zum Download bereit. Auf der Sysmon-Seite gibt es das Tool zum Download. Dort findet sich auch eine umfangreiche Dokumentation, wie Sysmon installiert und deinstalliert werden kann. Zudem ist der Funktionsumfang beschrieben.

(Quelle: YouTube)

In obigem Video stellt Marc Russionvich die April 2020-Updates für die Sysinternals-Tools vor. Dort wird auch kurz auf Sysmon eingegangen.

Was man noch wissen sollte: DLL-Hijacking an Bord

So genial die Sysinternals-Tools auch sind, gibt es doch einen ‘großen Schuss Wermut zur Soße hinzu’. Um es mit Stefan Kanthak auszudrücken: Russinovich ist beratungsresistent und macht mit seinem Zeug kolossale Anfängerfehler.

Worum geht es genau?

Seit einiger Zeit habe ich mir angewöhnt, diverse Tools, die in Blogs und Webseiten angepriesen werden, über ein Testbett zu jagen. Ziel ist es, herauszufinden, ob diese Windows-Programme anfällig für DLL-Hijacking sind. Ich hatte es schon befürchtet und wurde bestätigt. Bereits beim Aufruf erschien eine lange Latte an Warndialogen – wie nachfolgend gezeigt.

Sysmon DLL-Hijacking alert

Das Programm ruft bei seinem Start eine Reihe benötigter DLLs auf, ohne sich um deren Pfad zu kümmern. Standardmäßig finden sich die benötigten DLLs im Windows-Unterordner system32 und sollten von dort geladen werden. Windows durchdurch aber, sofern der Programmierer das nicht berücksichtigt, erst den Ordner, aus dem das Programm gestartet wurde, auf DLLs mit dem entsprechenden Namen.

Das kommt natürlich beim einem Tool wie Sysmon besonders gut, müssen dessen Dienst und der Gerätetreiber doch mit Administratorberechtigungen unter Windows installiert werden. Eine Malware, die auf Verdacht DLL-Dateien gleichen Namens im Programmordner (hier der benutzte Download-Ordner) ablegt, erhielte so beim Laden der DLLs quasi im Huckepack administrative Berechtigungen.

Noch ein paar Hintergrundinformationen

Das Ganze ist jetzt kein Rocket-Science und in der weiten Welt da draußen gänzlich unbekannt. Bereits 2010 hat Microsoft das Security Advisory KB2269637 (Insecure Library Loading Could Allow Remote Code Execution) und das Advisory KB2533623 veröffentlicht, nachdem Sicherheitsforscher auf die potentielle Schwachstelle hingewiesen haben.

Und es gibt von Microsoft diesen Artikel mit Empfehlungen, wie Entwickler diese Schwachstelle in ihrem Code vermeiden. Dazu gehört, dass bei Verwendung von API-Funktionen wie LoadLibrary, LoadLibraryEx, CreateProcess oder ShellExecute schlicht ein voll qualifizierender Pfad (z.B. der Art %windir%/system32/) im DLL-Namen zu verwenden ist. Das erzwingt unter Windows, dass die Standardsuche zum Laden einer DLL deaktiviert und diese sauber aus dem gewünschten Ordner geladen wird.

Das stört den lieben Mark Russinovich kein bisschen, obwohl er von Stefan Kanthak – zumindest nach meinen Kenntnissen – mehrfach auf dieses Problem hingewiesen wurde. So etwas kann man nur unter dem Stichwort Ignoranz verorten, denn das Ganze ist beherrschbar. Ich hatte den Entwickler des von Malwarebytes angebotenen AdwCleaner auf die gleiche Schwachstelle aufmerksam gemacht. Binnen weniger Stunden lag mir eine korrigierte Fassung vor, die diese DLL-Hijacking-Schwachstelle nicht mehr aufwies (siehe AdwCleaner 8.0.4 schließt neue DLL-Hijacking-Schwachstelle). Geht also.

Das Testbett wird von Stefan Kanthak bereitgestellt, der sich mit solchen Sicherheitsthemen auseinander setzt. Man kann sich die Datei Forward.cab von seiner Webseite herunterladen und mit dem Windows-Explorer in einen Ordner (ich habe ihn Test genannt) entpacken. Zudem gibt es noch eine Sentinel.exe, die auch in diesen Ordner wandert.

Falls ein Virenscanner beim Besuch der Kanthak-Webseite anspringt: Er liefert auf seiner Webseite das Eicar-Testvirus in einem Data Block-Attribut aus, um zu testen, ob Browser diesen auswerten und in den Speicher zur Ausführung laden. Dann sollte ein Virenscanner anschlagen.

Im Anschluss kopiert man einfach das zu testende (portable) Programm in den mit den DLL-Dateien instrumentierten Ordner des Testbetts und führt die Anwendung aus. Gibt es keine der oben gezeigten Meldungen, hat die getestete Anwendung mit hoher Wahrscheinlichkeit keine DLL-Hijacking-Schwachstellen.

Schlagen die Module aber an, heißt es für mich ‘Finger weg von dem Zeugs, der Entwickler schlurt oder hat keine Ahnung’. Mein Problem: Auch bei Microsoft gibt es einen ‘großen Sack voll’ mit dieser Klientel, die teilweise nicht mal die Hinweise versteht und das aussitzt. So viel zur Mär, dass da High-Quality-Software her kommt und man aus Sicherheitsgründen immer auf die neueste Software aus Redmond setzen soll. Was dort inzwischen – speziell im Bereich plattformübergreifender Anwendungen oder Bibliotheken – sicherheitstechnisch verbrochen wird, lässt einen nur noch verzweifeln.

Ähnliche Artikel:
Die Nirsoft-Tools und die DLL-Hijacking-Schwachstellen
AdwCleaner 8.0.4 schließt neue DLL-Hijacking-Schwachstelle
Realtek schließt DLL-Hijacking-Schwachstelle in HD Audiotreiber-Paket
Teams: Erfolgreich, aber ein Sicherheits-GAU
Microsoft will Installer-Schwachstelle nicht schließen
Warnung: NVTrimmer-Tool für Nvidia-Treiberanpassung


Anzeige


Dieser Beitrag wurde unter Software, Update, Windows abgelegt und mit Sysinterals, Sysmon, Update verschlagwortet. Setze ein Lesezeichen auf den Permalink.

18 Antworten zu Sysmon v11.0 von den Sysinternals-Tools freigegeben


  1. Anzeige
  2. Guido sagt:

    Vielleicht sind Russinovich und Nir Sofer ja verwandt.

    Mit welchem Tool prüfst du auf dieses DLL Hijacking?

    • 1ST1 sagt:

      Stegt etwas weiter oben eingerückt kursiv:

      Das Testbett wird von Stefan Kanthak bereitgestellt, der sich mit solchen Sicherheitsthemen auseinander setzt. Man kann sich die Datei Forward.cab von seiner Webseite herunterladen und mit dem Windows-Explorer in einen Ordner (ich habe ihn Test genannt) entpacken. Zudem gibt es noch eine Sentinel.exe, die auch in diesen Ordner wandert.

  3. RD sagt:

    Ich habe eine Frage zur Sicherheit von Sysmon,

    Würde es evtl. reichen, wenn ich den Ordner in dem die Sysmon DLLs ligen, die Berechtigungen auf nur Administratoren ändere? Oder Sysmon im Windows Verzeichnis ablege in dem sowieso nur Administratoren Zugriff haben?

    Viele Grüße

    • 1ST1 sagt:

      dort ablegen: c:\program files\sysinternals

    • Günter Born sagt:

      Da Sysmon ja nur einmal installiert wird, reicht es, dass das System zu diesem Zeitpunkt sauber war. Das DLL-Hijacking-Thema zieht sich aber durch alle Tools durch. Ansonsten hat 1ST1 ja eine Lösung genannt.

      Ich könnte mir auch – hatte ich mal an anderer Stelle skizziert – auf einer separaten Partition ein Verzeichnis anlegen. Alle Dateisystemobjekte an diesem Ort bekommen die Berechtigung, dass jeder das Ausführungsrecht hat. Aber dem Verzeichnis und allen Objekten wird global das Schreibrecht entzogen und nur ein besonderes Benutzerkonto (sollte nicht das Administratorkonto sein) bekommt Schreibberechtigungen. Über dieses Konto könnten die Dateien dann aktualisiert werden, während Malware keine Schreibzugriffe bekommt. Wäre wohl ‘bombensicher’, aber wohl nur mit Aufwand handhabbar (speziell der Explorer ist da ja ein störrisches Vieh, da er Berechtigungen umsetzt, man müsste beim Kopieren mit einem separaten Dateimanager oder der Eingabeaufforderung arbeiten).

      Da es zu meinem heise-Artikel entsprechende Diskussionen gibt (da hatte ich das Thema DLL-Hijacking bewusst, auf Wunsch der Redaktion, nicht angesprochen, da die Redakteure in Feiertagsabwesenheit sind) eine ergänzende Antwort.

      Wir zäunen das Pferd vom falschen Ende auf. Ist wie beim Rohbau, wo Treppen und Balkone mit Brettern als Absturzsicherung versehen werden. Natürlich ist das ziemlich bescheuert, niemand käme auf die Idee, an der Balkonkante im 30. Stock zu balancieren – und alle gehen auf der Rohbautreppe an der Wand entlang – da stürzt niemand ab … wissen wir doch alle!

      Nur zu doof: 99% der Leute sind Kamikaze und balancieren am Abgrund – geht solange gut, bis etwas passiert. Daher haben Sicherheitsmaßnahmen und Good Practice am Bau (und unter Windows) schon ihren Sinn.

      Die Leute, die hier über Möglichkeiten der Absicherung diskutieren, dürften am wenigsten gefährdet sein. Wer sein System sauber hält, wird auch nicht durch DLL-Hijacking einfach so infiziert.

      Aber: Die täglich gelebte Praxis am Bau (ist bei mir 47 Jahre her) und bei Windows ist doch, dass die Meute am Abgrund jongliert. Schaue ich in meinen Download-Ordner, stecken da zig Dateien und Ordner. Wenn da mal eine System-DLL drunter geschmuggelt würde, fällt das nicht auf. Ähnliches gilt für den TEMP-Ordner. Es reicht ein Drive-by-Download einer entsprechenden System-DLL, schon ist die Falle aufgestellt.

      Gut, meine Wenigkeit und möglicherweise andere Leute kopieren die Downloads in einen frisch angelegten Ordner, löschen das Internet-Zonen-Bit, entpacken die Archive etc., um ganz am Ende die .exe zu starten. Besonders Vorsichtige schauen sich noch eine digitale Signatur an und vergleichen Hashes …

      Und jetzt schauen wir uns noch an, wie Otto-Normal-User agiert: Link mit Download anklicken und dann im Browser die Option zum Ausführen des Downloads wählen. -> Die .exe wird am Ort des Downloads ausgeführt, und schon hat es BAM gemacht.

      Zudem bin ich nicht Obermutti, der bei jedem Nutzer das Händchen führt. Ich weise auf die potentiellen Probleme hin – die kann man zur Kenntnis nehmen und reagieren oder ignorieren. Doof ist nur, wenn dann noch versucht wird (ist hier im Blog an anderer Stelle mehrfach versucht worden), das Problem klein zu diskutieren (a la, eine Malware könnte die .exe-Datei austauschen …). Muss vielleicht mal einen Blog-Beitrag verfassen, der erklärt, warum das Eine zwar möglich, aber weniger ein Problem, das Andere aber ein größeres Sicherheitsrisiko ist.

  4. Anzeige

  5. Alfred Neumann sagt:

    “Falls ein Virenscanner beim Besuch der Kanthak-Webseite anspringt”

    Hier wäre ein Link zur benannten Seite wünschenswert.

  6. Sherlock sagt:

    > So viel zur Mär, dass da High-Quality-Software her kommt

    Welcher Clown verbreitet solche Mär? Qualitativ hochwertige Software findet man nirgendwo auf dieser Welt. Möglich wäre es schon, müsste dann in etwa so aussehen:
    https://breakingdefense.com/2012/12/darpa-crash-program-seeks-to-reinvent-computers-for-better-secur/
    Sowas gibt’s aber im realen Leben weder für Privat noch für den Profi-Bereich. Alles nur mit heißer Nadel gestrickter Pfusch und Murks. Am schlimmsten gepfuscht wird im Bereich sogenannter “Sicherheitssoftware”. Übleren Pfusch findet man nirgendwo.

    • LocutusOfBorg sagt:

      Sehe ich das richtig, dass die dwmapi.dll in das gleiche Verzeichnis gelegt wurde? Gehe ich weiterhin richtig in der Annahme, dass diese von uxtheme.dll geladen wird?
      Wenn dem so ist, würde auch das Laden von Dlls vom Prozess aus mittel voll qualifiziertem Pfad nichts helfen, denn die Abhängigkeiten werden wie gewohnt aufgelöst.

      • Günter Born sagt:

        Ich bin nicht so tief in der API drin – aber von der Logik her postuliere ich mal, wird der Pfad immer von der Location des ladenden Moduls genommen. Rufe ich eine DLL von einer .exe aus einem beliebigen Ordner auf, sucht Windows im Ordner dieses rufenden Moduls nach den Abhängigkeiten. Ruft eine DLL eine andere auf, wird der Pfad auf deren Verzeichnis bezogen.

        Die Idee dahinter: Der Entwickler könnte eine eigene Version der DLL mit der Programmdatei ausliefern, um Probleme mit der in Windows beigefügten DLL zu umgehen. Genau dazu ist der default Suchpfad zum Laden von Dateien in Windows ja da.

        Gebe ich nun beim Aufruf der API-Funktion den vollqualifizierenden Pfad an, bezieht sich der auf das Windows-Verzeichnis mit den DLLs – so dass weitere DLLs auch von dort geladen werden.

        Ich mag mich aber irren und Microsoft hat das anders gelöst.

        • LocutusOfBorg sagt:

          Laut https://docs.microsoft.com/de-de/windows/win32/dlls/dynamic-link-library-search-order:

          “If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.”

          Nun lädt der Entwickler brav mittels voll qualifiziertem Pfad eine DLL (in diesem Fall uxtheme.dll). Diese wiederum hat eine statische Bindung an eine andere (dwmapi.dll). Beide liegen ausserhalb der Verantwortung des Entwicklers. Damit ist das ganze anfällig für solche Attacken. Das lässt sich aber nicht ausnahmslos mittels eines voll qualifiziertem Pfad lösen. Man muss auch noch andere Vorkehrungen treffen.

          • Sherlock sagt:

            Darüber könnte man sich in
            de.comp.os.ms-windows.misc
            ausgiebig unterhalten. Die Kommentarfunktion solcher Blogs erlaubt keine sinnvollen Diskussionen. Man bekommt auch nicht mit, zu welchem Kommentar irgendwo eine Antwort erfolgte.

          • Das Zitat ist UNVOLLSTÄNDIG, es (genauer: der GESAMTE Artikel) ignoriert das mit Windows 10 “Anniversary Update”, also vor VIER Jahren eingeführte DEPENDENTLOADFLAG

            Wie üblich hat sich Microsoft auch dabei NICHT mit Ruhm bekleckert: siehe https://skanthak.homepage.t-online.de/snafu.html

            JFTR: beachte vor allem das Wort IGNORANZ, sowohl bei Günter als auch mir: das ist eine besondere Eigenschaft VIELER Entwickler in Frickelbuden wie Microsoft!

      • Ist so, nur ist Deine Schlussfolgerung FALSCH!
        UXTHEME.dll lädt DWMAPI.dll per LoadLibrary(), hier liegt keine statische Abhängigkeit vor.
        Der Herr Russinovich täte gut daran, ENDLICH ‘mal die Dokumentation seiner eigenen Klitsche zu SetDefaultDllDirectories() lesen:
        https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-setdefaultdlldirectories

        Gilt ebenso für den Frickler der UXTHEME.dll

Schreibe einen Kommentar zu Guido Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.