@chaosben:
es ist eben nicht selten sondern eher der normale Vorgang. Und seit dem es die "side by side" Technik gibt gibt es auf
OS Ebene ein
API das es ermöglicht zb. die WinSock
DLL so zu laden das sie unbemerkbar durch eine Angreifer-WinSock-
DLL geladen wird. Dh. selbst wenn deine Anwendung WinSock lädt, und das auch gewünscht ist durch deine Anwendung, so kann ein Angreifer eine "Side by Side"
DLL für WinSock installieren die dann mit Hilfe des APis vollkommen transparent die originalen Funktionen der originalen WinSock
DLL ersetzt. Die Anwendung selber hat dabei keine Möglichkeit zu erkennen das es eine "Side by Side"
DLL ist. Somit stellt das
OS von Hause aus einen Weg zur Verfügung ganz regulär eigenen Code in andere Anwendungen zu injezieren. Also selbst wenn die eigene Anwendung WinSock absichtlich und STATISCH lädt. Und dann gibts noch die "Delayed Load" DLLs die erst zu einem Zeitpunkt nachgeladen werden. Bei sowas ist es denn wichtig das deine Anwendung auch korrekt zeitlich synchron die Überprüfung der geladenen DLLs durchführt, da sie ansonsten solche DLLs garnicht detektieren kann.
Ich erwähne dies (auch wenn es teil-
OT) ist nur aus einem Grunde: nämlich um fehlendes Wissen nachzuliefern das deutlich zeigt das deine 3 postulierten Taktiken wirkungslos sind.
Der Trend der "Treiber" Programmierer Funktionalitäten über injezierte DLLs zur Verfügung zu stellen wird dabei immer stärker. Dh. gabs sowas vor Jahren noch nicht so häufig so stelle ich heutzutage immer öfter fest das von den vielen DLLs in meinen Prozessen die meisten injezierte DLLs oder "side by side" geladene DLLs sind. Ein sehr hilfreiches Tool dafür ist der Dependency Walker. Alleine die fucking Treiber für die HP Drucker werden injeziert. Zwar nicht über Hooks dafür durch das
OS selber wenn man Drucker-APIs in der Anwendung aufruft. Deine Aussage zeigt also das du selber noch niemals sowas beobachtet hast.
Besteht noch die zweite große Frage: WIE und WANN will die eigene Anwendung erkennen welche DLLs im eigenen Prozess geladen wurden ? Hört sich trivial an ist es aber weiß Gott nicht. Denn der Weg über ToolHelp ist durch einen Angreifer so enorm leicht auszuhebeln (globale Hooks) das deine Anwendung garnicht die Chance hat eine Angreifer
DLL zu entdecken. Desweiteren besteht das Problem nicht nur zu verifizieren das eine spezielle
DLL tatsächlich geladen wurde sondern zu verifizieren ob diese
DLL noch das Original darstellt. Da helfen auch keine digitalen Signaturen da diese NUR und ausschließlich NUR auf dem Image der Festplatte arbeiten und NICHT auf dem Code der geladenen
DLL im Speicher !
Ergo: so bald es um DLLs geht kann sich eine Anwendung in nichts sicher sein. Und mal erhlich, wer hat von euch nicht schon mit SetWindowsHookEx() rumgespielt und seine eigene KeyBoard-Hook-
DLL gebastelt. Das ist wohl eines der offensten Geheimnisse und selbst für Visual Basic for Applications gibts Beispielcode im WEB.
Wir können aber gleich auf eine höhere Ebene wechseln, ins Kernel, dann Treiber und dann,
oh Gott finden wir raus das das komplette
OS nur rein virtuell in einer Sandbox, VM, in SoftICE oder auf einem Hardware Debugger läuft.
Ergo: das Passwort in der Anwendung zu speichern ist schlecht.
Ergo: ein Passwort als General-Schlüssel der für alle Anwendungskopien identisch ist ist eine unsichere Idee.
Ich empfehle das Passwort durch den Anwender eingeben zu lassen und damit auch Anwenderbezogen seine Daten zu verschlüsseln.
Klar ein kompromittiertes, unsicheres System wird mit keiner Lösung einen Schutz bieten. Ausnahme ist einbruchsichere Hardware. Alledings greift man so nur EIN Anwenderpasswort auf EINEM System an und nicht ALLE Anwender der gleichen Software in einem Rutsch und das auch noch OFFLINE.
Gruß Hagen