[English]Die Nirsoft-Tools sind wohl vielen Windows-Nutzern ein Begriff. Was weniger bekannt ist: Die Tools kommen mit bösen DLL-Hijacking-Schwachstellen daher und sollten daher eher gemieden werden.
Anzeige
Das Thema dümpelt hier schon einige Zeit und ich habe es immer wieder aufgeschoben. Denn einerseits versprechen die Nirsoft-Tools Unterstützung bei diversen Windows-Problemen. Und ich muss den Entwickler nicht ohne Not in die Pfanne hauen. Andererseits gibt es in den Tools gravierende DLL-Hijacking-Schwachstellen, und der Entwickler interessiert sich einen feuchten Dreck dafür. Daher sollte jeder Nutzer wissen, auf was er sich einlässt.
Was sind die Nirsoft-Tools?
Bei den Nirsoft-Tools handelt es sich um eine Sammlung von hilfreichen Windows-Programmen für verschiedene Aufgaben, die kostenlos zur Verfügung stehen. Hinter den Tools steckt der Entwickler Nir Sofer, der sich als 'erfahrener Entwickler mit umfassenden Kenntnissen in C++, .NET Framework, Windows API und Reverse Engineering von undokumentierten Binärformaten und Verschlüsselungsalgorithmen' bezeichnet. Die Tools lassen sich auf der Webseite nirsoft.net abrufen. Ich selbst habe gelegentlich das eine oder andere Programm aus der Tool-Sammlung genutzt. Alle Tools sind als portable Programme ausgeführt und brauchen nicht installiert zu werden.
Die DLL-Hijacking-Schwachstellen
Es war Ende Januar 2020, als ich bei den Kollegen von deskmodder.de auf den Artikel AdvancedRun 1.15 jetzt auch mit Kontextmenü-Eintrag stieß. Das ist ein Tool von Nirsoft, mit dem man andere Programme mit erweiterten Rechten (Administrator, System etc.) starten kann. Eigentlich eine tolle Sache, und da die Tools kostenlos sind, war der Gedanke da, das Ganze im Blog vorzustellen.
Anzeige
Impuls zum Sicherheitstest für das Tool
Aus einem plötzlichen Impuls heraus entschloss ich mich aber, das heruntergeladene Tool über mein Testbett zur Aufdeckung von Schwachstellen laufen zu lassen. Denn ein Tool, welches Administratorberechtigungen beim Aufruf weitergibt, sollte möglichst keine DLL-Hijacking-Schwachstellen aufweisen.
Das Ganze endete recht ernüchternd. Bei Advanced Run habe ich bereits beim Aufruf sofort zig Warnungen (siehe obige Abbildung) kassiert, weil das Tool versucht, Dlls wie dwmapi.dll, uxtheme.dll, version.dll etc. aus dem eigenen Verzeichnis nachzuladen. Aber auch beim Versuch, ein anderes Programm wie z.B. Regedit.exe über die Schaltfläche Run mit erhöhten Rechten auszuführen, löst die oben gezeigten Warndialoge aus (wobei ich nicht geprüft habe, ob die aufgerufenen Module die Berechtigungen erben – die UAC-Abfrage kommt zu einem späteren Zeitpunkt).
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 in einen Ordner 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.
Später kopiert man die zu testende Software in den Ordner des Testbetts und führt diese aus. Gibt es Alarme wie in obigem Screenshot gezeigt, liegt eine DLL-Hijacking-Schwachstelle vor.
Problem ist: Es gibt eine Schwachstelle, die bei 'guter Programmierpraxis' verpönt ist. Die sollte fix behoben werden, das geht. Ich habe hier im Blog ja bereits vor mehreren Tools mit solchen Schwachstellen gewarnt, meist nützt das nichts oder ich fange mir geharnischte Kommentare ein, wieso ich so etwas publiziere und ich könne es ja besser machen. Aber es gibt auch die Positiv-Beispiele für solche Fälle (siehe unten).
Warum DLL-Hijacking kritisch ist
Das beobachtete Verhalten bedeutet, dass alle von Advanced Run nachgeladenen DLL-Dateien ebenfalls als Prozess mit administrativen Berechtigungen ausgeführt werden. Der Nutzer gewährt den aufgerufenen Prozessen ja explizit diese Berechtigungen.
Normalerweise geht das gut, da Windows die erwarteten DLL-Dateien im Ordner des Programms nicht findet und dann in den Windows-Ordnern sucht und dort auch die benötigte DLL findet. Das Problem: Ist eine solche Schwachstelle bekannt, könnte eine Malware das ausnutzen.
Es reicht, wenn die Malware im betreffenden Ordner DLLs mit den erwarteten Namen ablegt. Um nicht aufzufallen, könnte die Malware sich bei einem Zugriff auf den Ordner mit den Tools (meist wird das der Ordner Downloads sein) per Ereignis informieren lassen. Dann wäre noch Zeit, die DLLs in das Verzeichnis zu kopieren. Der Benutzer erteilt dem Programm nichtsahnend erhöhte Berechtigungen und im Huckepack werden die Malware-DLLs per DLL-Hijacking-Schwachstelle mit den erhöhten Rechten ausgeführt. Advanced Run ist quasi eine ideale Tarnkappe für Malware, die dann erhöhte Berechtigungen erlangen könnte.
Microsoft hat beispielsweise den Supportbeitrag KB2533623 in Form eines Security Advisory veröffentlicht (letztmalig im Januar 2020 aktualisiert), in dem auf diese Gefahr hingewiesen wird. Für ältere Windows-Versionen gab es sogar ein Update, damit Entwickler die Ausnutzung der DLL-Hijacking-Schwachstelle verhindern können. Ein weiteres Security Advisory KB2269637 geht ebenfalls auf diese Schwachstelle ein.
Ernüchternde Erfahrungen mit dem Entwickler
Ich habe mir dann einige weitere Nirsoft-Tools von der Webseite des Entwicklers heruntergeladen und ebenfalls über das Testbett laufen lassen. Es gab das gleiche Ergebnis, die haben alle eine DLL-Hijacking-Schwachstelle. Dabei haben Entwickler die Möglichkeit, vorzugeben, aus welchen Pfaden bzw. Ordnern die System-DLLs nachzuladen sind. Wenn Sofer Nir ein erfahrener Entwickler ist, sollte es ein leichtes sein, das zu korrigieren.
Im Dezember 2019 hatte ich die Entwickler des AdwCleaner von Malwarebytes über eine solche DLL-Hijacking-Schwachstelle informiert. Die haben sofort reagiert und einige Tage eine fehlerbereinigte Version freigegeben (siehe die Blog-Beiträge AdwCleaner 8.0.1 schließt DLL-Hijacking-Schwachstelle). Im April ist denen erneut ein Malheur passiert, was nach einem Hinweis von mir zeitnah behoben wurde (siehe AdwCleaner 8.0.4 schließt neue DLL-Hijacking-Schwachstelle).
Also habe ich Sofer Nir im Januar 2020 direkt über sein Kontaktformular kontaktiert und auf das Problem angesprochen. Mit verbunden war die Bitte, da zu reagieren und ggf. Rückmeldung zu geben, weil ich einen Artikel veröffentlichen möchte. Gleichzeitig habe ich die Veröffentlichung des Artikels zurückgestellt. Die Hoffnung war, dass es ähnlich wie beim AdwCleaner läuft.
Alleine, es blieb bei der Hoffnung, denn Sofer Nir reagierte nicht auf meine Anfragen. Da ich mit Stefan Kanthak im regelmäßigen Austausch stehe, habe ich bei ihm diesbezüglich Ende März 2020 explizit nachgefragt. Hier die Korrespondenz samt der Rückmeldung von Stefan Kanthak:
> PS: Hattest Du in der Vergangenheit mit Sofer Nir von Nirsoft Kontakt?
> Die Nirsoft-Tools leiden ja durch die Bank an DLL-Hijacking-
> Schwachstellen. Ich hatte ihm eine Mail geschickt, aber nie eine
> Antwort bekommen (obwohl er die Mail abgerufen hat). Bin nur
> noch nicht dazu gekommen, da was dazu zu schreiben.Ich habe ihm MEHRFACH Mails zu seinen ANFAENGERFEHLERN geschickt, aber der Typ ist *** taub und stumm: KEINE Reaktion!
Bestätigt also mein Bild. Ich hatte den Artikel schon wieder aus dem Fokus verloren, bis ich wieder durch die Kommentare zum Artikel Defender stufte fälschlich Winaero Tweaker als Hacker-Tool ein erinnert wurde. Auch wenn es in den Kommentaren darum ging, dass die Nirsoft-Tools vom Defender bemängelt werden, war das der Trigger, den Beitrag endlich zu veröffentlichen.
Ich tue mich zwar schwer, kostenfreie Tools 'in die Pfanne zu hauen'. Wenn sich deren Schöpfer aber der Thematik DLL-Hijacking verweigert, sollten zumindest Nutzer der Tools wissen, auf welch wackeliges Brett sie sich begeben. Die Information ist daher jetzt draußen, also zieht eure Schlüsse draus.
PS: In der Antike war es zur gängig, den Boten der schlechten Nachrichten zu köpfen. Führte aber nicht dazu, dass die schlechten Nachrichten damit aus der Welt waren. Nur als Vorgriff auf Kommentare 'ist ja nicht so schlimm' oder wie auch immer. Hier werde ich aus den oben skizzierten Gründen weder NirSoft-Tools im Blog vorstellen noch weiter einsetzen.
Anzeige
Hatte jetzt das erste mal von dieser Tool-Sammlung gehört.
Und kenne auch keinen, der die mal "erwähnt" hätte. Können also kein so wirklicher Verlust sein, wenn man sie nicht einsetzt. Und Freeware in der Richtung gibt es auch genug. Sollte also nicht so schwer sein, eine Alternative zu finden.
Die Nirsoft-Tools sind schon sehr bekannt, Shellexview z.B….
Es ist zwar meist nicht schwer, Alternativen zu finden, dummerweise haben die dann oft aber die gleichen Schwachstellen, also doch schwer! Softwareentwickler scheinen allgemein völlig unfähig zu sein, wenn es um den Sicherheitsaspekt geht. Und schon das nackte Windows ohne installierte Software produziert schon Sentinel-Warnungen! Darüber hinaus sind ALLE portablen Tools eh dicke Sicherheitslücken…
Nirsoft, ein Begriff? Und ob, alleine die Password tools …
Schade, und merci Günter für das Augen öffnen.
Seit Linux und BSD allerdings Sofer frei ;-)
Danke für den Beitrag! Ich kenne diese Tools zwar dem Namen nach – und auf einigen Computer-Seiten werden diese zum Download angeboten – aber ich habe sie nie benötigt oder benutzt. Wenn Windows, egal welche Version, nicht mit "hilfreichen" Tools und Schlangenöl zugemüllt ist, lauft es einwandfrei und bedarf keiner Tools.
Und lasse Dich nicht von Kommentaren abschrecken, es ist DEIN Blog und DEINE Meinung und/oder Erfahrung.
Sicher ist es möglich durch DLL Hijacking ein System zu Infizieren.
Allerdings ist diese Schachstelle eher zu Vernachlässigen und der Normale Anwender hat doch nicht wirklich etwas zu Befürchen.
Ein eventueller Angriff setzt dazu ersteinmal vorraus, das eine Schadsoftware auf dem Rechner den genauen Pfad dieser Tools kennt um dann dort die DLL's auszutauschen.
Und um ersteinmal dorthin zu kommen ist der Computer sowieso schon mit Schadsoftware Infiziert und ein DLL Hijack macht dann keinen sinn mehr.
Dann durchdenke einfach dein Szenario nochmals ;-).
PS: Ein normaler Anwender, der keine Administratorrechte besitzt, wird die Nirsoft-Tools nicht einsetzen. Der Rest der Argumentation läuft auf das Treppengeländerbeispiel beim Rohbau aus meiner nachfolgenden Erwiederung hinaus. Wenn ein Risiko bekannt ist, gilt es das zu beseitigen.
bei der betrachteten software handelt es sich um portable software, d.h. sie wird in der regel in einem verzeichnis ausgefuehrt, in dem JEDES beliebige programm schreibzugriff hat. ist dll-hijacking dann wirklich noch die hauptbedrohung? wer sich ernstlich um dll-hijacking bekuemmert, der sollte IMHO grundsaetzlich nicht auf portable anwendungen setzen – erst recht nicht, wenn die anwendung adminrechte anfordert.
Auch Normalanwender Installieren sich solche Programme, da sie z.b. bei Chip oder irgendwo lesen,
das man sich damit sein Windows "Verbessern" kann.
Und dabei spielt es keine Rolle, ob erfahrener User oder Anfänger.
Wenn eine anderes programm die Schreibrechte besitzt, um DLL dateien eines anderen Programmes zu ersetzen,
hat es auch die Möglichkeit sich anderweitig unter Windows zu verbreiten.
d.h. wenn der Austausch der DLL's schon möglich ist, ist der Hijack Angriff das geringste Übel.
Sicher sollten solche Lücken geschlossen werden, aber das ist nebensächlich, denn diese lücke ist unwichtig wenn andere Einfallstore offen stehen.
Und wenn z.b. diese Hijacking angriffe Verhindert werden, dann nistet sich die schadsoftware welche Sowieso schon vorhanden ist eben als Browser oder sonstiges programm ein.
Frage eines Normalverbrauchers: "…d.h. wenn der Austausch der DLL's schon möglich ist, ist der Hijack Angriff das geringste Übel…"
Ist die Übernahme des PCs nicht eine Folge des Austauschs der DLLs?
Um entsprechende DLL's der Software auszutauschen, muss eine entsprechende Schadsoftware schon auf dem PC sein.
Somit ist das System schon kompromittiert.
Und wenn diese Software unbemerkt DLL'S austauscht, braucht es keine Admin rechte um andere Dateien entsprechend zu manipulieren.
z.b. Browser oder andere vom Benutzer verwendeten Programme.
Also ist der DLL Hijack überflüssig, und nur ein unnötiger schritt.
Und somit ist die übernahme des PCs ist nicht die Folge des DLL austauscht.
Der PC muss vorher schon Schadsoftware laufen haben.
Nur nicht mit Admin rechten.
AUTSCH: Kleinkinder, die nicht mal ihren Namen schreiben können, plappern ahnungslos und merkbefreit hanebüchenen Unsinn!
ES WERDEN KEINE DLLS AUSGETAUSCHT!
Die wohlbekannten Pfade, in denen Otto Normalmissbraucher solchen (portablen) Schrott ausführt, lauten %USERPROFILE%\Downloads und %TEMP%
"Bei Advanced Run habe ich bereits beim Aufruf sofort zig Warnungen (siehe obige Abbildung) kassiert, weil das Tool versucht, Dlls wie dwmapi.dll, uxtheme.dll, version.dll etc. aus dem eigenen Verzeichnis nachzuladen."
Das verstehe ich nicht, soeben AdvancedRun v1.20 heruntergeladen und entpackt.
Da sind drei Dateien drin, AdvancedRun.chm, AdvancedRun.exe und readme.txt.
Keine DLL-Dateien drin. Nach dem Start von Advanced Run wird AdvancedRun.cfg angelegt und sonst nichts.
Dein Gedankenfehler: Es ist uninteressant, was das Tool Advance Run macht, sondern nur das, was es an DLLs verwendet. Die DLLs, die es benötigt, liegen normalerweise in den Windows-Verzeichnissen – und ein erfahrener Programmierer stellt sicher, dass das Programm beim Laden auch dort sucht.
Die Scharlatane unter den Entwicklern (um es mit Stefan Kanthak auszudrücken) kümmert dies nicht. Die treffen keine Vorkehrungen, so dass der Aufruf 'lade mal DLL xyz' durch Windows frei umgesetzt werden kann. Ergo wird erst mal im Verzeichnis nachgeschaut, aus dem das Programm geladen wurde.
Kopiert eine Malware dann eine entsprechende Datei mit diesem Namen in diesen Ordner, wird diese statt der Windows DLL geladen und läuft mit den Rechten, die das betreffende Modul vom Benutzer bekommen hat. Im dümmsten Fall liegt also eine Remote Execution-Schwachstelle (RCE) vor.
Und das Argument des Vorposters, ist Unsinn. Ein Schadprogramm könnte im Browser mit niedrigster Vertrauensstufe laufen. Gelingt es der Malware, eine DLL in das Zielverzeichnis zu kopieren, hat der Angreifer gewonnen. Denn die Malware-DLL bekommt die Rechte, die der Nutzer der aufrufenden Anwendung mitgeben kann.
Die Argumentation: Ja, mir ist klar, dass an die Treppe ein Geländer als Absturzsicherung gehört, aber die Leute sollen halt aufpassen, ist genau so unzulässig wie die Argumentation 'diese Schwachstelle ist eher zu vernachlässigen und der normale Anwender hat doch nicht wirklich etwas zu befürchten'. Am Rohbau schreibt die Baubehörde/ Berufsgenossenschaft/ Unfallverordnung vor, dass gefährliche Stellen entsprechend zu sichern oder der Zugang zu sperren sind. Und im Softwareumfeld gilt: Ist bekannt, dass es eine Schwachstelle gibt, ist diese zu beseitigen – oder die Software darf nicht mehr eingesetzt werden.
Alles klar, ist schade dass der Entwickler da nicht nachbessert.
Benutze die Tools von Nir Sofer seit Jahren, jedoch nur bei Bedarf. Werde daher in Zukunft das benötigte Tool herunterladen, entpacken, ausführen und dann wieder löschen. Für meine Bedürfnisse reicht das an Sicherheit.
Die Tools werden häufig aktualisiert, so alle paar Wochen.
Da wird also ständig dran gearbeitet und dann kann man auch erwarten, dass sich um Schwachstellen gekümmert wird. So nützlich die Tools auch sind, wenn die Verantwortlichen nichts auf Sicherheit geben, dann kann ich ihnen auch nicht mehr vertrauen. Und dass man für sie auch noch im AV-Programm Ausnahmen erstellen soll, wie von Hersteller empfohlen, hinterlässt ein Geschmäckle.
Da ich die Tools eh kaum benutze, fällt mir die Trennung nicht schwer.
Es war halt praktisch, so viele Tools in einem Archiv zu haben, falls man mal eins davon brauchte.
Über den Nir Launcher kann man auch andere Toolsammlungen starten, wie Sysinternals, was auch praktisch ist.
"Und dass man für sie auch noch im AV-Programm Ausnahmen erstellen soll, wie von Hersteller empfohlen, hinterlässt ein Geschmäckle."
Hinterlässt es nicht, das liegt an der Funktion einiger der Tools. Ein Programm das im Browser gespeicherte Passwörter ausliest wird von diversen AV-Programmen als bösartig angesehen.
Potentiell unsichere Anwendung trifft es eher. Bösartig ist zu viel des Guten.
Auch ich habe eine Frage, zumal ich vor kurzem auch einen Kommentar zu
https://www.borncity.com/blog/2020/04/11/defender-stufte-flschlich-winaero-tweaker-als-hacker-tool-ein/
abgegeben habe.
Szenario:
# Ich lad mir das Programm von Nirsoft für die Passwörter im Outlook, ggf. schalte ich dabei den MS Defender aus, wenn er das herunterladen blockiert.
# Ich deaktiviere den Internetanschluss (Stecker ziehen) und schalten MS Defender aus.
# Ich starte das Programm und habe mein Ergebnis. Ich speichere das Ergebnis sinnvoll ab.
# Ich lösche das Programm vom System und aktiviere MS Defender
# Ich fahre den PC herunter und stecke den IT-Anschluss wieder.
# Ich starte den PC neu und überprüfe die Aktivierung des AV-Programms auf Echtzeitschutz.
# Ich lasse den MS Defender durchlaufen. Ggf. lasse ich andere AV-Programm durchlaufen.
Ich denke das ist doch o.k.?
Viele Grüße
Ich nenn sowas Paranoia …
toll, bezieht sich das jetzt auf das nicht archivieren (weil mit kurzem Zugriff des Kennworts auf Papier es auch nach Stunden nicht gelingt?) des Kennworts der diversen E-mail -Adressen?
Ich denke nicht.
Der Angriff über DLL-Hijacking-Schwachstellen ist nur so lange möglich, bis das Schadprogramm auf dem PC vorhanden ist und auch bedient wird.
Alles andere würde die These in die Welt setzen, dass jedes Programm, jede Installationsroutine auf dem PC ein Virus bedeutet, den es zu bekämpfen gilt. Dem ist jedoch nicht so. Wäre es so, so wäre jeder PC infiziert (die smarte Dinger sowieso).
Je mehr ich darüber nachdenke, das ist völlig unlogisch. Das würde bedeuten, dass Schädlinge schon auf dem PC sind und nur darauf warten erweckt zu werden. Auch Nichtschädlinge würde dann zu Schädlingen mutieren, um dann über DLL-Hijacking ihren Angriff zu starten. Die wissen aber gar nicht wen sie anzugreifen haben, weil sie dafür nicht programmiert sind. Der Schläfer der nicht aufzuwecken ist (frei nach Orwell).
Ich verstehe es nicht.
Bitte Fakten, Fakten, Fakten.
@Gerold,
na ja, ich habe es jetzt noch mal gelesen. Man wird schon etwas meschugge. :)
Paranoia? Vielleicht oder auch nicht. Im ZDF kam gerade Edgar Wallace (8 Folgen) .
Ich habe es dann versucht unten dann noch einmal mit der Treppe zu formulieren.
Wenn Du dem Download vertraust und dieser keine Benutzerkontensteuerung auslöst, hält sich die Bedrohung in Grenzen. Nur sind die Randbedingungen halt schon doof: Du müsstest vor dem Start die Hashes des Downloads auswerten, um sicherzugehen, dass das Programm auch von Nirsoft stammt. Du müsstest postulieren, dass Nirsoft nicht gehackt wurde und Malware ausliefert. Und Du müsstest sicherstellen, dass keine Schadsoftware aktuell mit normalen Benutzerrechten läuft. Und dann wird das Ganze halt schwierig – wie mit der erwähnten Treppe im Rohbau, wo das Geländer fehlt. Es geht tausend Mal gut – und dann stürzt einer auf der ungesicherten Treppe tödlich ab …
Ich habe das vor paar Jahren gemacht, als ich hier im Blog auf Nirsoft hingewiesen wurde. Es hat alles geklappt. Die Bedrohung hielt sich nicht nur in Grenzen, sie war auch so nicht entstanden.
Das Thema ist sicherlich kompliziert, aber manchmal gibt es Bedrohungsszenarien.
Es gibt im IT-Bereich solche Bedrohungsszenarien, wo man sich tatsächlich fragt, warum man die Hersteller und Entwickler von PC nicht anklagt und einsperrt. Sowas soll es ja in religiösen Kreisen durchaus geben. Das meine ich auch so.
Es fehlt manchmal die Differenzierbarkeit.
Zur Treppe: Es gibt da einen Witz. Ich sage es mal anders:
In den Keller führt eine Treppe von der Kellertür. Im Keller ist es dunkel. Der Lichtschalter ist so la la. Was passiert, wenn wenn man den Lichtschalter betätigt? Was passiert wenn man Licht hat und das Licht auf der Treppe ausgeht und ein Windzug die Kellertür zuhaut? Ich kenne solche Keller.
Wenn ich dem Download direkt auf der NirSoft-Webseite nicht vertrauen kann (abgesehen von dieser DLL-Geschichte), wie kann ich dann x-beliebigen anderen Hobbyprojekten mit eigener Webseite vertrauen, z.B. dem für mich essentiellen Shark-007-Codec-Pack? Oder abermillionen Installern auf Github? Ist am Ende das Windows 10 Powertoy auf Github auch gefälscht?
Wenn es soweit kommt, können wir alle einpacken. Hier steht noch ein Atari TT (eigentlich nicht nur einer…) mit dem nötigsten an Textverarbeitung, Tabellenkalkulation, Grafikbearbeitung (vozugsweise Schwarzweiß, mit Truecolor ist der Rechner überfordert) und Desktop-Publishing. Reine HTML-Seiten und Javascripte könnte man damit auch noch erstellen, aber damit surfen eher unmöglich, da die moderne HTTPS-Verschlüsselung den Seitenaufbau zu sehr verzögert und die Webbrowser erstmal für TLS 1.1/1.2 ertüchtigt werden müssten.
Vertrauen wird jemandem entgegengebracht, der die Belange seiner Kunden/Anwender/Nutzer ernst und sich dafür Zeit nimmt und sie nach seinen Möglichkeiten unterstützt. Kleine Projekte können zwar nicht so viel tun, wie große Konzerne, aber alleine schon, dass man zuhört und antwortet, schafft Vertrauen. Jemand, der seine Nutzer ignoriert, hat kein Vertrauen verdient, egal wie mächtig er ist.
Ein Forum oder Blog kann schon reichen, um mit Nutzern zu kommunizieren. Das gibt es bei kleinen Projekten fast immer, während große Anbieter es möglichst schwer machen können. Auf Seiten großer Anbieter meint man manchmal, dass sie den Kontakt versuchen möglichst zu behindern, weil sie oft arrogant sind und negatives lieber verschweigen. Auf Facebook und Twitter will man auch nicht gerne mit Problemen hausieren gehen. Ein Forum ist familiärer und da kommen schon eher Probleme zur Sprache und werden oft auch gleich dort ohne großem Tamtam bereinigt.
Ich hatte vor Jahren schon auf verschiedene Lücken in den Tools aufmerksam gemacht darunter auch DLL-Hijecking, der Dev scheint aber echt resistent gegen Hilfestellung und oder Tipps und Hinweise zu sein.
Daher stehen sowohl Tools als auch die Webseite auf der schwarzen Liste.
Nichts davon wird eingesetzt und wenn es entdeckt wird durch automatisierte Routinen im gesamten Netzwerk gelöscht und oder blockiert.
Das ist aber eine komische Verlinkung von @user. Da ist wohl ein Fehler passiert.
Günter, ich danke Dir für den sehr informativen Artikel. Diese Art eines Angriffes hatte ich tatsächlich nicht auf dem Schirm, aber ja, Du hast recht.
Wäre es unter Umständen ein gangbarer Weg, die Tools zu installieren, zu verfolgen welche Dateien aufgerufen werden und für die dll's jeweils einen Symlink in den Installationsordner zur Version des Betriebssystems zu setzen?
Ansonsten muß ich wohl eine (weitere) Sandbox bauen, um diese Werkzeuge weiterhin einzusetzen…
Früher eine Erlösung/ein Weg aus der DLL-Hell, einfach die passende/benötigte DLL-Datei ins Programm Verzeichnis kopieren, heute bubu-böses DLL-Hijacking, ich sag nur VBRUN300, allein davon musste man ab einem bestimmten Programm Pool mindestens drei unterschiedliche Versionen bereithalten. Das ist alles so historisch gewachsen, nichts geschieht ohne Grund 🤪
Was ist mit dem Tipp,den Netzwerkordner mit den Nirsoft-Tools als Netzlaufwerk in Windows einzubinden um so stets über das Netzwerk die aktuelle Version der Tools zu starten? Dann wird das betreffende Tool doch jedes mal frisch in ein temporäres Verzeichnis geladen, von dort gestartet und nach Beenden idealer Weise gelöscht, wobei man letzterem ja nachhelfen kann (temp. Dateien beim Herunterfahren autom. löschen.
Freundliche Grüße
P.B.
Warum der ganze Krampf. Lege einen Ordner für die Tools an, vergebe Ausführungsrechte für alle Nutzer, begrenze aber die Schreibrechte auf einen Administrator. Fertig.
Na wenn die Lösung des Problems ja so einfach ist… Bei mir liegen die NirSoft-Tools unter c:\program files\nirsoft\, so als hätte ich sie mit einer setup.exe installiert, und es gibt eine Verknüpfung auf den Launcher in einer Schnellstartleiste. Also mal eben die DLLs dort droppen ist ohne UAC auszulösen nicht.
Genauso verfahre ich übrigens auch mit den Sysinternals-Tools. Die haben zwar (wahrscheinlich) keine DLL-Hijacking-Lücken, wären aber potentiell auf der Ebene der EXE-Dateien einfach infizierbar, so wie es früher diverse Viren gemacht haben, sich einfach ins Binary einzuklinken, anzuhängen, etc.
Man könnte aber auch eine Batch anbieten, welche die benötigtren DLLs aus dem Windows-Ordner herüber kopiert, und auf diesen DLLs Schreibrechte entziehen, dann würde es einem Schädling nicht gelingen, sich da einzunisten… Oder könnte man DLLs unter den gefährlichen Namen anferigen, welche die Originale aus dem Windows-Ordner nachladen und an die NirSoft-Tools "durchreichen"?
Aber ansonsten richtig, dass dieses Problem offengelegt wird, wenn das jetzt noch von anderen IT-Nachrichten-Seiten aufgegriffen wird, reagiert NirSoft vielleicht doch mal. Für Deutschland wäre insbesondere wichtig, dass Winfuture.de darüber berichtet, denn diese schreiben regelmäßig über diese Tools, wenn es ein Update gibt.
Als nächstes wünsche ich mir einen Artikel über Portable Apps, der den Leuten erklärt, was da für Gefahren lauern, wenn der Benutzer Schreibrechte auf den Programmordner hat… Das ist nämlich die viel verbreitetere Unsitte! Gerade die Leute von portablen Mailclients und Browsern denken, sie wären besonders schlau und sicher unterwegs!
AUTSCH!
Der von dem blutigen Anfänger Mark Russinovich verbrochene Schrott hat selbstverständlich diese Schwachstellen auch.
Ältere Versionen von ihm waren NOCH übler: die 32-bittigen Programme haben auf 64-bittigem Windows die 64-bittigen Programme nach %TEMP%, teilweise sogar %SystemRoot%\TEMP\ extrahiert und dann dort ausgeführt.
Siehe dazu u.a. https://seclists.org/fulldisclosure/2020/Apr/12
Otto Normalmissbraucher lädt sich solche "Tools for fools" mit (s)einem Browser herunter, in den dort voreingestellten "Downloads"-Ordner, wo auch alle anderen (inklusive der "drive-by") Downloads stehen, und führt das Zeux dann dort aus.
Wie geschrieben, bei mir liegen die in Program Files, da schreibt niemand irgendwelche DLLs ohne UAC auszulösen.
Hallo,
zuerst einmal sei gesagt, dass ich selbst in der IT bin, wenn auch nicht so tief im Thema wie es hier behandelt wird. Aber die Themen stimmen mich bedenklich. Wenn auch nicht sicherheitstechnisch.
Ist es nicht schon fast Verleumdung und "Hatespeech", was hier von euch (Born und Kanthak) betrieben wird?
Dass Software immer wieder Fehler hat, ist klar.
Auch wenn es in diesem Fall kritischer ist.
Aber ein Mark Russinovich sollte international bekannt und renommiert sein (wäre er sonst da wo er jetzt ist?) und diesen als "blutigen Anfänger" zu denunzieren, finde ich gewagt.
Die c´t beruft sich oft auf Tools von diesem. Was sagen die anderen Redakteure? Für dieses aus-meiner-Sicht-kein-Käseblatt schreibt ja auch Herr Born. Was sagt ein Jürgen Schmidt? Oder anderes Fachpersonal, das dort tätig ist? Weil wenn man das hier liest, kann man entnehmen, dass man die ganze Sysinternals-Palette meiden soll.
Jedenfalls verunsichert es mich, wenn beide Personen hier schon beinahe Kraftworte verwenden und die Programm-Autoren denunzieren. Auch die Art, wie auf Kommentare reagiert wird, scheint eher "hitzköpfig" als ruhig, fachlich und besonnen. Das lässt mich eher an deren Authentizität und Fachwissen zweifeln, als an Sysinternals, Microsoft und u.a. auch Nirsoft
Vielleicht gibt es (u.a. banale) Gründe, wieso auf die Nachrichten nicht reagiert wurde.
Vielleicht gibt es bessere Wege, auf diese Problematik hinzuweisen, es zu eruieren und zu prüfen. Sachlich und ohne Unterstellung und ohne zu diskreditieren.
Ps.: Ja, ich gehe davon aus, dass hier Gegenwind kommen kann. Aber ich bin gespannt, in welcher Weise :)
Nichts für ungut!
Zu: 'Dass Software immer wieder Fehler hat, ist klar. Auch wenn es in diesem Fall kritischer ist.'
Nochmals zum Mitschreiben: Das ist kein Fehler (aka Bug), sondern Stümperei!
Zu: 'Aber ein Mark Russinovich sollte international bekannt und renommiert sein (wäre er sonst da wo er jetzt ist?) und diesen als "blutigen Anfänger" zu denunzieren, finde ich gewagt.'
Schlage bitte mal die Bedeutung des Wortes 'denunzieren' nach – und nenne mir die 'niederen Beweggründe' …
Ansonsten: Umso schlimmer, wenn ein Russinovich so etwas verbricht! Solange er noch alleine gesegelt ist, hätte man es noch als 'kann ja mal passieren' entschuldigen können. Er fungiert heute als Microsoft-Mitarbeiter, die Firma, die Advisories zu diesem Problem heraus gibt. Und wenn er ein Tool wie Sysmon zur Unterstützung von SIEM-Agenten (wird zum Erkennen und Analysieren von Sicherheitsvorfällen genutzt) schreibt, muss ich postulieren, dass er zumindest die Sicherheits-Advisories aus dem eigenen Hause kennen sollte. Wie es aktuell gehandhabt wird, 'schmerzt mich nur noch' (vorsichtig ausgedrückt).
Zu: 'Die c´t beruft sich oft auf Tools von diesem. Was sagen die anderen Redakteure? Für dieses aus-meiner-Sicht-kein-Käseblatt schreibt ja auch Herr Born. Was sagt ein Jürgen Schmidt? Oder anderes Fachpersonal, das dort tätig ist? Weil wenn man das hier liest, kann man entnehmen, dass man die ganze Sysinternals-Palette meiden soll.'
Ist die c't relevant für das, was ich hier im Blog schreibe? Antwort: NEIN! Soll nicht borniert sein – bloggen funktioniert nicht mit der Einstellung 'schaue erst einmal, was der und jener für Meinung hat'.
Hat heise die Sysinternals- oder Nirsoft-Tools auf das Thema DLL-Hijacking überprüft? Genau weiß ich es nicht – aber eine Suche im Newsticker nach dem Stichwort liefert mir z.B. Null Treffer … Postulat: Von denen hat noch keiner drüber nachgedacht oder getestet – oh …
Jeder Nutzer kann natürlich abweichende Meinungen haben und so handeln, wie er meint, dass es für ihn richtig ist (ich benenne Sachverhalte, und dass ich auch mal spitzer formuliere, gehört dazu). Aber ich werde mir nicht die Schere im Kopf 'was sagt die c't dazu' geben – andernfalls wäre es an der Zeit, die Blogs hier zu schließen.
Nebenbemerkung 1: Gelegentlich muss ich die heise-Redaktion bildlich gesprochen 'zum Jagen tragen', und wenn das nicht klappt, kriegt Golem schon mal das Thema. Ist auch so (für mich) in Ordnung – heise ist unabhängig – genau so, wie meine Wenigkeit als Blogger. Ansonsten ist es schon eine coole Erfahrung für mich, beide Seiten als Autor kennen zu lernen: Hier im Blog knackig formulierte Posts, die nicht selten weltweit eine Erstmeldung darstellen. Und dann die Anfrage von heise, ob ich was zu schreiben kann – erscheint u.U. 3 Tage später und extrem geschliffen – aber sachlich und ausgewogen, manchmal noch vom Redakteur ergänzt. Beide Welten haben ihre Vorteile – und die heise-Redakteure haben schon verdammt viel Fachwissen. Ohne mir jetzt auf die Schulter klopfen zu wollen – ich schätze, da gibt es eine gegenseitige Befruchtung. Aber wenn ich jetzt 'heise-Stil' hier im Blog pflegen müsste, würde ich sofort den Stecker ziehen.
Nebenbemerkung 2: Vor dem 1. Mai gab es von der heise-Redaktion die Anfrage, ob ich was zu den Sysinternals-Tools / Sysmon-Geschichte schreiben kann. Es gab den Vorschlag von mir, das Thema DLL Hijacking mit zu thematisieren. Die Redakteurin, die aus dem Sicherheitsbereich kommt, war sofort interessiert. Aber es gab Vorbehalte in der Redaktion, das Thema 'nicht ausdiskutiert' vor dem Feiertag/langen Wochenende als Schnellschuss rauszuhauen – und das war auch gut so und in Ordnung. Wie das ausgeht, ist offen.
Nebenbemerkung 3: Gestehen wir auch der heise-Redaktion zu, dass die ihre Redaktionsthemen selbst festlegen darf – und es ist auch klar, dass ein Redakteur nicht immer die Brisanz eines Themas erkennt (da ist immer das Risiko 'wenn ich was falschem aufsitze' im Hinterkopf – so mein Eindruck), oder Diskussionsbedarf. Ist mitunter mein Vorteil als Blogger, wenn dann plötzlich eine Mail in meinem Posteingang landet und jemand schreibt 'da habe ich heise schon vor einem Jahr drauf hingewiesen, mehrfach' (letztes Mal war das in Zusammenhang mit einem Sicherheitsleck im medizin. Bereich der Fall). Oft landen dann ergänzende Details bei mir, die ich aufbereiten kann.
Unter dem Strich: heise ist schon gut mit c't und News-Ticker – aber da wird auch vieles geschliffen (sehe ich, wenn ich einen Rohtext in die Redaktion hinein gebe und der dann als fertiger Text erscheint – wobei es ja, die Freiheit habe ich mir bei heise ausbedungen, die Informationen hier im Blog – oft knackiger und umfangreicher formuliert – gibt). Beides hat seine Vorteile – dass heise weiterhin nachfragt, ob ich zu diesem oder jenem Thema schreibe – und so mancher Redakteur fleißig hier mitliest und auch Themen selbst aufgreift, zeigt, dass ich nicht alles falsch mache.
Nebenbemerkung 4: Ich tausche mich hinter den Kulissen mit US-Bloggern aus. Rückmeldung von voriger Woche aus der Bleeping Computer-Redaktion zum Thema: 'Thanks. Sadly as you have started to learn, most vendors do not treat DLL hijacking seriously, including Google.' Die haben wohl aufgesteckt … bei dem Thema.
Zu: 'Vielleicht gibt es (u.a. banale) Gründe, wieso auf die Nachrichten nicht reagiert wurde.'
Ob es banale Gründe gibt, weiß ich nicht. Was ich aber weiß: Da wird landauf/landab auf diversen Webseiten und in Blogs jedes neue eingefärbte Icon in höchsten Tönen gelobt und die Meute jubelt mit. Die Nutzer werden darauf konditioniert, nur jede aus dem Support heraus gefallene Software-Version wegen der doch so argen Sicherheitheitslücken, die da existieren, für die nächste Generation zu dumpen. Monatlich hüpfen Millionen Leute in eine Update-Orgie, in der Hoffnung, dass deren Zeugs im Anschluss sicher ist und noch funktioniert.
Und dann schaust Du mal 'unter der Decke nach' und findest Sicherheitslücken, von denen Microsoft in Advisories sagt, dass man sie unbedingt vermeiden solle. Aber das wird auf den Webseiten der angebotenen Tools nicht mal thematisiert? Das Mindeste wäre doch, wenn man schon gute Gründe hat, gegen die Advisories zu verstoßen, ein paar Handlungsanweisungen, was man beachten sollte, zu veröffentlichen.
Klar, wir können Schönsprech pflegen, bis zum Grab. Zumindest hier im Blog ist der Sachverhalt thematisiert, und ich nehme auch kein Blatt vor den Mund. Wenn was sachlich falsch von mir dargestellt ist, wird das korrigiert. Wer den Artikel gelesen hat, kann reagieren – es gibt von den Diskutanten sogar konkrete Vorschläge, wie man das Problem umgehen kann (Stichwort: Ablegen in einem normalerweise für Nutzer schreibgeschützten Ordner). Damit sind die Leute, die den Beitrag gelesen haben, schon mal ein großes Stück weiter als der Rest der Welt.
Wenn das dich 'an deren Authentizität und Fachwissen zweifeln, als an Sysinternals, Microsoft und u.a. auch Nirsoft' zweifeln lässt – bitte, ich kann damit leben. Soll auch kein Gegenwind sein, jeder ist da souverän, und deine Sichtweise auch in Ordnung. Die Informationen liegen auf dem Tisch. Anschließend handelt jeder, wie er zu meinen glaubt.
PS: Ich habe am WE nochmals kurz wegen des Themas DLL-Hijacking recherchiert. Es gibt Trojaner und Malware, die DLL-Hijacking wohl nutzen, um erhöhte Systemrechte zu erlangen. Spätestens, wenn ein Netzwerk wegen einer solchen Geschichte von Schadsoftware befallen wird, weil der Administrator ein solches Tool mit erhöhten Rechten gestartet hat, dürfte Schluss mit lustig sein.
PPS: Ich könnte mir das Leben natürlich einfach machen – und nur über die Updates der Tools jubeln. So ein Beitrag ist in einigen Minuten hingerotzt und bringt Traffic. Stattdessen investiere ich Zeit, und tippe mir die Finger wund, um das Thema aufzubereiten. Und am Ende des Tages darf ich mich mit den Argumenten herum schlagen, warum nicht sein kann, was nicht sein darf. Verstehe einer die Welt. Und damit bin ich aus diesem Diskussion-Thread raus. Denn wir haben jetzt Sonntag, 23:39 und ich wollte eigentlich noch ein paar Blog-Beiträge für Montag raushauen, statt gefühlt unproduktiv auf Kommentare zu antworten und Hintergrundinfos zu geben, was aber am eigentlichen Sachverhalt DLL-Hijacking-Schwachstelle wenig ändern.
hoppela,
kaum gibts ein eher kleines "moomendemal" fühlt sich Herr Born (warum eig.) wohl auf die Füßleins getreten und reagiert imho etwas laut und mit erstaunlicher Textwüstenei. Auffällig, unsouverän. Nerv getroffen.
Wohl Fan von Kanthak, kann man ja machen (find den ja eher aufgeblasen), aber dann vlt. etwas leiser?
Und die Anregung, doch auch mal die beteffenden Jungs bei der c't zu befragen ist jetzt so falsch eig. auch nicht.
aber jeder, wie er mag…
Einfach setzen … zumindest, wenn der Text von mir nicht gelesen/verstanden wurde – meine kurzen 2 Cents.
Denunzieren – aus "meist" niederen Beweggründen. Laut Wikipedia zumindest inklusive. Laut Duden sind diese niederen Beweggründe gar nicht angeführt.
Meiner Ansicht nach ist die Bewertung "blutiger Anfänger" eine Denunzation.
Aber ich bin weder Germanist, noch Jurist, noch Herr Knigge oder Herr Duden.
Wir leben – im Gegensatz zu vor vielen Jahrhunderten – in einer Zeit, wo nicht das Problem besteht, sich Infos und Wissen zu beschaffen. Sondern im Gegenteil – es kommt ein zuviel an Information und Informationsquellen.
Ergo: Man muss sich entscheiden, was man glaubt und wo man sich informieren soll.
Wenn man – so wie ich es tun möchte – grundsätzlich davon ausgehen will, dass das, was man liest, der Wahrheit entspricht, so merkt man ständig, dass es Widersprüche gibt. Also muss man auch mal mit Misstrauen an Infos heran gehen. Ich habe mich entschieden, vor allem an "emotional" verfasste Texte und wo andere Personen in gewisser Weise abgewertet werden, eher weniger zu glauben.
Und wenn man nun weder Zeit noch Wille hat, sich in das Thema einzufinden, so muss man fremden Worten Glauben schenken. Ich bin in der IT, aber aus persönlichen Gründen nicht die Möglichkeit, so tief in das Thema einzutauchen.
Ist das Problem verständlich? Wem soll man glauben?
Der Kommentar war an sich gut und gut verständlich für mich :)
Ich stimme vielem dazu zu und will kein weiteres Fass aufmachen.
Das war einfach aus meiner Sicht, wie solche Texte / Kommentare bei mir ankommen und vielleicht auch bei anderen…?
Wenn nicht – ich habe ein wenig daraus gelernt und gehe wieder meinen Verpflichtungen nach.
Korrekt!
Dummerweise fehlt dieser WICHTIGE (Sicherheits-)Hinweis, der vor allem auch für Installationsprogramme (IGITT!) gilt, auf fast allen Download-Seiten.
Siehe dazu den Link unter meinem Namen!
Otto Normalmissbraucher ist sich der Risiken beim Ausführen irgendwelcher dahergelaufener/unbekannter Programme in seinem "Downloads"- oder TEMP-Ordner NICHT bewusst.
Und ignorante ahnungslose Frickler wie Nir Sofer denken nicht an bzw. für ihre "Kunden".
Das einzige Programm was ich davon Privat einsetze ist BlueScreenView. Auch das braucht Administrative Berechtigungen. Das liegt aber daran das der Ordner auf dem es zugreift halt nur mit solchen berechtigen genutzt werden darf.
AV Software hat aber in letzter Zeit auch den drang Software die 10 Jahre oder älter ist mittlerweile als Böse einzustufen. Weshalb der Uniblue Registry booster nun x Jahre nach der letzten Nutzung unter Windows XP plötzlich Böse ist kann mir nur Kaspersky erklären.
Das die Datei die auf der Externen Festplatte liegt von Schadsoftware befallen ist kann ausgeschlossen werden. Auch eine vor 10 Jahren gebrannte CD mit der Software führt beim Prüfen mit der aktuellen Kaspersky Version zum gleichen Ergebnis.
Hallo zusammen,
darf ich mal ganz nebenbei Fragen, welche Tools Ihr für die Schwachstellen-Erkennung verwendet. Für ein paar Tipps wäre ich sehr dankbar!
Bezüglich der DLL-Hijacking-Sachen einfach nochmal den Artikel lesen. Steht alles drin.
Nein, dort steht zu wenig drin!
Der Link unter meinem Namen führt zur Beschreibung.
Sicherheit schön und gut, aber: Ich sehe hier das Problem nicht!
Du hast ein Tool das liegt in einem Ordner in dem jeder schreiben darf.
Du gibst dem Tool Admin rechte, ein mal geht das gut.
Du gibst dem Tool Admin rechte, aber irgend eine Malware hat die exe modifiziert oder ersetzt, und BAM Malware ist jetzt Admin.
An der stelle hat man kein DLL Hijacking gebraucht.
Also was lernen wir daraus Exe's mit Admin rechten aus für jeden Hintz und Kuntz beschreibbaren Ordnern ausführen ist schon mal ein ganz riskantes Vorhaben.
Was schert mich das die Malware hier anstelle des beschriebenen Angriffes auch DLL Hijacking hätte benutzen können? Kommt doch am ende auf's genau gleiche raus.
Mein reden schon vor Tagen.
Es wird von Experten ein riesen Fass aufgemacht über Gefahr durch DLL Hijacking, und fehlerhafte prüfung der Software.
Dabei Interessiert es niemanden, ob entsprechende Schadsoftware sowieso schon auf dem Rechner war/ ist.
Aber Hauptsache auf dem DLL Hijacking rumreiten.
Was bringt es nachts die Rolläden zu schliessen, die Fenster zu Vernageln und mit Alarmkontakten zu versehen,
wenn der Einbrecher vorher schon vom Bewohner ins Haus gelassen wurde.
Ich hatte nicht auf den Kommentar von Trax geantwortet, weil das schon thematisiert war. Denkt schlicht nochmals über euren Standpunkt nicht. Vielleicht nehme ich mir mal die Zeit, die Sachlage noch mehr zu verdeutlichen.
Es ist schon eine andere Qualität, einen TEMP- oder Download-Ordner mit zig Dateien per Drive-by mit schadhaften DLLs zu bestücken und auf einen DLL-Aufruf irgend eines Tools zu warten, als gezielt eine .exe von irgend einem Tool auszutauschen.
Aber es sind eure Rechner – und es ist nicht mein Problem, wenn Malware auf dies Art zuschlägt. Ist wie mit dem Metzger und den Kälbern, notfalls Eddy Stäuber fragen ;-).
@Günter
Du hast ja sicher recht mit der Gefährlichkeit dieses Angriffes.
Aber du vergisst oder Ignorierst nachwievor einen ganz großen Aspekt.
Wer oder was Tauscht oder Kopiert diese DLL's aus.
Selbst durch ein Drive-By MUSS zwangsläufig ein EXE /Script oder sonstiges Programm Ausgeführt werden,
damit irgendwelche Dateien Kopiert werden können.
d.h. um Dateien aus dem Temp Ordner in das Entsprechende Verzeichniss Kopiert zu werden, muss ein Programm dies Veranlassen.
Somit muss ein Schadprogramm schon auf dem Rechner Laufen.
Es gibt mehr als genügend wege um einen Rechner dann weiter zu Infizieren, und der DLL Hijack ist dabei ein unnötiger schritt.
Da die schadsoftware vielleicht mit Userrechten läuft, was aber schon reicht um z.b. Dateien zu Verschlüssel (Erpresser Software)
>> NirsoftTools als Netzlaufwerk
>Warum der ganze Krampf.
Einfach so. Man setzt die Tools ja eher selten ein und hat so immer die aktuelle Version verfügbar. Das war im Prinzip der Grundgedanke dabei. Sicherheitsaspekte spielten dabei keine Rolle.
Ist natürlich mit Kanonen auf Spatzen geschossen, so selten wie man solche Tools überhaupt braucht.
Freundliche Grüße
P.B.
Danke für den Artikel! Wenn auch schade zu hören. Die Tools schönen interessant, aber zu schön, um wahr zu sein.
Und danke dass Sie die Aussagen in ein verständliches Deutsch übersetzen. Ich finde toll, wenn auch die gute Arbeit von Menschen mit Defiziten so etwas Öffentlichkeit bekommen.
Kann mir jemand das Program von Stefan Kanthak noch erklären?
Ich entpacke die Datei "FORWARD.CAB" nach "Testbett". Darin gibt es dann 2 Verzeichnisse "7" und "XP". Die Datei" SENTINEL.exe" kommt auch in das Verz. "Testbett". Dann ein Testprogramm dort rein. Z.Bsp. nirsoft "FolderChangesView.exe"
Wenn ich dann "FolderChangesView.exe" starte passiert nix ausser dass das Programm startet.
Da ist irgend etwas schief gelaufen bei dir. Mein Testbett hat in einem Ordner einen Sack an DLLs und das war es. Wenn ich FolderChangesView.exe aufrufe, kommt hier ein Tannenbaum an Warndialogen.
Ich finde Deinen Kommentar nett indem Du mitteilst daß etwas schief gelaufen ist. Das weiß Volker sicherlich auch, sonst hätte er nicht um Hilfe gebeten. Anstatt zu beschreiben wie man das "Testbett" richtig zum laufen bekommt.
Ich habe selbes Problem wie Volker. Und was bei mir schief gelaufen ist weiß ich nicht. Ich hab´s so gemacht wie Du es beschrieben hattest.
Nachtrag. Ich habe das "Testbett" nun zum laufen gebracht.
Bei mir war die Lösung, man muß die zu testende Datei in den Download Ordner im Benutzerprofil rein kopieren. Dann funktioniert es.
Bei mir kommen die runter geladenen Dateien in einen Ordner auf einer anderen Partition, also außerhalb der Systempartition, das war der Grund warum das Testbett bei mir in meinem üblichen Download Ordner nicht funktionierte.
Danke für den sehr wertvollen Hinweis bezüglich Nirsoft und besonders bezüglich des Testbett´s.
In meinem Text war beschrieben, wie das Testbett zu erstellen ist – einfach nochmals lesen.
1. Einen Ordner Test anlegen.
2. Die Dateien des Testbetts von Kanthak aus der .cab-Datei in den Ordner Test kopieren.
3. Die zu testende Datei in den Ordner Test zu kopieren.
Habe das x-Mal in den letzten Monaten gemacht, ohne Probleme. Mehr muss ich nun wirklich nicht liefern – sorry.
Zwei Ergänzungen zur Verwendung von Testbett:
1. Kapiert:
Die "FORWARD.CAB" enthält zwei Unterverzeichnisse "7" und "XP"
Das auszuführende Program muss direkt nach "7" und nicht eine Ebene höher.
Dann funktioniert es.
2. Wichtiger:
Auf seiner website:
https://skanthak.homepage.t-online.de/sentinel.html
gibt es eine Anleitung:
"Manual offline installation"
mit Installation durch die "SENTINEL.INF".
Das hatte ich damals auch gemacht.
Hierbei wird das Skript systemweit integriert.
(Hinweis: Hat bei mir mir aber auch nicht richtig funktioniert, da ich mit einem Standard-User-Account arbeite und das Script beim Starten mit Adminrechte ins Dateien ins AdminUser Download-Verz. schreibt).
Heute wollte einen VPN-Client (Shrewsoft) starten,
ging aber nicht, die Dienste starteten nicht (Timeout Meldung).
Dann überlegt was sich seither geändert hat, und auf Testbett gestoßen.
Die Dateien manuell aus den diversen Windows-Verzeichnissen gelöscht,
(Es gibt keine Deinstallations-Routine)
Shrewsoft startet wieder!
Holzauge sei wachsam.
vg
Volker
Danke für die Hinweise!
Die habe ich mir zu Herzen genommen und mir schnell mal einen Ausweg aus dem DLL-Hijacking-Dilemma gebaut.
Hier mein Beispiel "WifiInfoView":
1. Mit Admin-Rechten Ordner C:\Program Files\WifiInfoView\NirSoft angelegt.
2. Dorthin mit Admin-Rechten WifiInfoView.chm, WifiInfoView.exe und WifiInfoView_lng.ini kopiert
3. Mit Admin-Rechten 1. Start von WifiInfoView.exe ausführen.
4. Ordner C:\ProgramData\NirSoft angelegt
5. Dorthin WifiInfoView.cfg verschoben und oui.txt runtergeladen.
6. Symbolische Links erzeugt von WifiInfoView.cfg und oui.txt im Ordner C:\Program Files\WifiInfoView\NirSoft
Nun kann kein (Schad-)Programm mehr ohne Adminrechte eine DLL in den Programmordner schreiben.
Ist da noch ein Denkfehler? Dann bitte im um sachdienliche Hinweise.
Gruß
Andreas
Interessanter Beitrag. Ich gehe mal davon aus dass NirSoft keine Änderungen vermeldet hat, sonst hätte sich der Blogautor ja sicher geregt.
Falls jemand hier vorbeikommt, und die Antwort kennt: Was sind denn die sichere(re)n Alternativen zu den einzelnen NirSoft Produkten? Sind ja immerhin so an die hundert Stück, gibts da eine Alternativen-Liste?