Wir haben eine .NET 3.5-Anwendung mit registrierten Erweiterungen. Wie können wir es vor DLL-Hijacking-Angriffen schützen?
Wegen Legacy & amp; Design Probleme starke Benennung / Unterzeichnung ist keine Option jetzt
Zusätzliche Informationen, wenn Sie nicht wissen, was DLL Hijacking ist:
Ich war auf ein ähnliches Problem gestoßen. Ich hatte meine eigene Logik geschrieben, um die DLL zu verifizieren. Für mich habe ich nur diese DLL in LGPL Mode verwendet (ich kann die DLL nicht ändern), wollte aber sicherstellen, dass meine Anwendung die echte DLL verwendet (nicht die Hi-Jacked).
Einfache Lösung:
Bessere Lösung:
Wenn Sie ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle wie verisign haben, können Sie dieses Zertifikat anstelle des RSA-Schlüsselwertpaars verwenden.
Auf diese Weise stimmt der Hash nicht überein, selbst wenn jemand Ihre DLL durch eine geknackte DLL ersetzt. Ihre Anwendung wird den Hijacking-Versuch kennen.
Dieser Ansatz könnte besser sein, als dll nur einen starken Namen zu geben, da eine starke Namensüberprüfung möglicherweise durch Ausführen von
deaktiviert werden kann %Vor%Ich hoffe, das hilft Ihnen oder jemand, der verstehen möchte, wie digitale Signatur-Dinge intern funktionieren.
Sehen Sie sich diesen Thread an ... .it könnte Ihnen helfen und Ihnen Einsicht geben .... eine andere Sache, Sie können sicherlich EasyHook auschecken und die API createRemoteThread abfangen und finden aus, wenn die DLL eine der nicht autorisierten DLLs ist .... werfen Sie einen Blick auf diesen Thread erklärt, wie man gegen dll-Injektion blockiert
Können Sie die DLL nicht als Ressource verwenden und zur Laufzeit an die gewünschte Stelle schreiben? Dann laden Sie die DLL in die Assembly? Ich habe das einmal gemacht, weil wir als .exe verteilen wollten, aber ich denke, dass es auch dieses Problem lösen würde, nicht wahr?
Robert,
In Fairness gegenüber Jims Frage "Was für ein Design wäre das?". Indem Sie antworten, anstatt nur zu sagen "es ist was es ist", könnten Sie uns einen Einblick in die Einschränkungen geben, in die unsere Vorschläge / Lösungen fallen müssen.
Anders gesagt, ohne zu wissen, warum der Legacy-Code es verhindert, "den richtigen Weg" zu gehen, ist es schwierig, ideale Problemumgehungen für Ihr Problem bereitzustellen.
Sofern Ihre Architektur die von Vishalgiri vorgeschlagene MD5-Prüfsummen-Idee nicht verhindert, würde ich vorschlagen, diesen Rat zu befolgen. Wiederum ohne zu wissen, welche Anwendung (en) diese DLLs aufrufen und warum sie nicht signiert werden können, ist es schwer zu wissen, ob dies für Sie funktioniert.
Meine Idee ist vielleicht viel einfacher, aber können Sie Ihre Anwendung nicht so anpassen, dass sie die DLL von einem vordefinierten Ort lädt? ZB erlauben Sie es nur, vom BIN-Ordner Ihrer Hauptanwendung zu laden, und andernfalls - versuchen Sie es nie wieder?
Siehe diesen Link zum Laden von einem bestimmten Pfad: Ссылка
Dies ist möglicherweise schneller als das Schreiben des gesamten MD5-Prüfsummencodes. Auch wenn mir diese Idee gefällt.
Wenn Sie Ordner- / Datenzugriffsrechte haben, können Sie Code schreiben, um proaktiv zu gehen und an den gleichen Stellen zu suchen. Windows sucht nach Ihrer .DLL, bevor Sie Ihre eigene .DLL aufrufen (oder das gesamte Laufwerk durchsuchen), und Sie könnten rechnen eine CRC-Prüfung für Ihre legitime DLL oder andere Musterübereinstimmung, um Ihre legit.DLL auf lokalisierten, übereinstimmenden DLL-Dateien zu vergleichen und sicherzustellen, dass niemand sonst Sie entführt hat (eine Datei an einem Ort platziert, der vor Ihrem eigenen gesucht wird) Standort - oder sogar jeder Ort). Dies könnte eine Untersuchung der Methodik unter verschiedenen Windows-Versionen für die verschiedenen Suchreihenfolgen erfordern. Wenn Sie dann einen Hijacking-Versuch finden, können Sie etwas unternehmen, je nachdem, wie sicher Sie sind, dass jemand versucht, Ihre DLL zu entführen ... Benennen Sie die faker.DLL um, löschen Sie sie, benachrichtigen Sie den Benutzer, benachrichtigen Sie admin, don ' Rufen Sie Ihre DLL usw. auf.