Wie "offen" ist ein Password (String) im Arbeitsspeicher

[chaosben]

Zitat von negaH:

Treiber wie LogiTech Mäuse, Keyboard Treiber, Grafik Treiber, DCOM, Protected Storage etc. pp. injezieren ihre DLLs permanent in die eigene Anwendung.

Wer hat denn was von Treibern, Mäusen oder anderem Getier gesagt? Es geht hier um die eigene Anwendung.

Zitat von negaH:

Dh. aus Sicht deiner Anwendung hast du keine Möglichkeit zu erkennen welche DLLs sich mit welchem Ziel in deine Anwendung injeziert hat.

Falsch, denn ich weiß, welche Module ich geladen habe. Alle anderen sind falsch an der Stelle.

Zitat von negaH:

Ergo: Punkt 2.) ist ebenfalls untauglich.

Ergo: Auch dieser Teil deiner Aussage ist falsch.

Und btw: Selbst wenn man fachlich kompetent ist, muss man nicht reden als ob man der Schöpfer der Welt ist. Manchmal hilft es auch, einen Moment länger über die Meinung eines Anderen nach zu denken.

[Neotracer64]

Zitat:

Falsch, denn ich weiß, welche Module ich geladen habe. Alle anderen sind falsch an der Stelle.

Wieso? Hagen hat doch gesagt, dass "Treiber wie LogiTech Mäuse, Keyboard Treiber, Grafik Treiber, DCOM, Protected Storage..." ihre DLLs in DEINE Anwendung injezieren. Und DAS ist definitiv gewollt, damit zum Beispiel bei der Logitech-Maus auch der Extra-Knopf in deinem Programm funktioniert. Wie unterscheidest du, die vom User gewollten DLLs von den des Angreifers?

[chaosben]

Zum einen denke, ich das das sehr selten ist. Hast du schon mal sowas gesehen?
Zum anderen kann ich dafür einen Schalter einbauen, mit dem der Nutzer wählen kann:
- Secure Mode: alle ungewollten Module rausschmeißen (also auch Logitech und Konsorten)
- Unsecure Mode: nicht empfohlen, aber wenn der Nutzer es so will

[himitsu]

Zitat von chaosben:

Falsch, denn ich weiß, welche Module ich geladen habe. Alle anderen sind falsch an der Stelle.

Du weißt aber nicht welche Module wirklich geladen werden ... die "Maus-DLL hab ich auch schon lange entdeckt und heute Früh sind mir noch mehr aufgefallen, die nicht direkt von meinem Programm geladen werden ... wenn ich richtig gezählt hatte waren das 3, oder 4, welche kurz nach dem Programmstart plötzlich aufgetaucht sind.
Und was für Module von der VCL und anderen Teilen, die du verwendets geladen werden, darauf hast du ja auch keinen Einfluß.

[chaosben]

Zitat von himitsu:

Und was für Module von der VCL und anderen Teilen, die du verwendets geladen werden, darauf hast du ja auch keinen Einfluß.

Das nicht, aber ich kann nachsehen, was von mir (oder der VCL) ist und alles andere ist ungewollt.

Aber ehe wir uns hier total in OT verrennen: Ich wollte mit meinem ersten Post genau eine Sache sagen(auch wenn sie scheinbar nicht so rübergekommen ist): Es gibt imho keine(0, nil, null ) Sicherheit für ein Passwort im RAM.
Und das ist wohl die Frage, um die es hier geht.

[negaH]

@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

[Vjay]

Zitat von chaosben:

Wer hat denn was von Treibern, Mäusen oder anderem Getier gesagt? Es geht hier um die eigene Anwendung.
Falsch, denn ich weiß, welche Module ich geladen habe. Alle anderen sind falsch an der Stelle.
Ergo: Auch dieser Teil deiner Aussage ist falsch.

Also zuallererst würde ich prinizpiell einfach mal unterstellen, dass Hagen sich damit auskennt.
Und da ich selber über genügend Kenntnisse verfüge, kann ich mir dessen sogar sicher sein.

Man braucht übrigens nicht einmal eine DLL verwenden, openProcess und createRemoteThread tuen es auch. Und zu dem Vorschlag, eines Securemodus, der sich nur mit bestimmten DLLs aktivieren lässt... Erstens: siehe Hagens Thread und zweitens: Wie findest du denn heraus was geladen ist? Ein komplettes Speicherabbild vergleichen? Und sagen wir rein theoretisch, du würdest es schaffen, so vertausche man ein true und false in deinem Programm und es denkt der Securemodus ist aktiv... Rest siehe Hagens thread.

Zitat von chaosben:

Und btw: Selbst wenn man fachlich kompetent ist, muss man nicht reden als ob man der Schöpfer der Welt ist. Manchmal hilft es auch, einen Moment länger über die Meinung eines Anderen nach zu denken.

Dazu sage ich jetzt mal nichts...

[chaosben]

Zitat von chaosben:

Ich wollte mit meinem ersten Post genau eine Sache sagen(auch wenn sie scheinbar nicht so rübergekommen ist): Es gibt imho keine(0, nil, null ) Sicherheit für ein Passwort im RAM.

[negaH]

Siehst du und ich will klarstellen das man nicht nur "scharz & weiß" sieht.

Zitat:

ch wollte mit meinem ersten Post genau eine Sache sagen(auch wenn sie scheinbar nicht so rübergekommen ist): Es gibt imho keine(0, nil, null ) Sicherheit für ein Passwort im RAM.

denn auch diese Aussage ist absolutistisch. Mit der Entwicklung neuer Hardware stimmt diese Aussage eben auch nicht mehr. Zur Zeit vollzieht sich nämlich im HW Sektor ein Trend der durchgängigen "Digitalisierung" und Integration der Kryptographie. Das sind solche Sachen wie Änderungen an Datenprotokollen, die Verwendung schneller serieller Datenübertragungen wie SPDIF, DVI und Speicherbausteien.
Dh. überall gibt es Entwicklung die Kryptographie direkt in die HW integrieren.

- DVI, HD-TV, SPDIF Datenübertragungen mit Entschlüsselung im Endgerät
- Sachen wie TCP im Betriebssystemen wie Palladium, Linux
- Hardware wie Secure Digital Speichermedien, Compact Flash Karten, xD Pixture Cards, Sony Memory Stick
- Datenübertragungsstandards wie Bluetooth, ZigBee, WLAN
- IDE ATA/ATAPI-7 Standard mit Hardwareverschlüsselungen direkt in der Festplatte (ein großes Ärgernis bei originalen xBox HDs)
- serieller SRAM Speicher für Grafikkarten und PCs die ihre Daten ebenfalls live verschlüsseln
- selbst Druckerpatronen nutzen kryptographische Protokolle heutzutage

Es gibt also fast in jedem Sektor Bestrebungen Kryptographie direkt in HW zu integrieren nachdem die komplette Datenübertragung/haltung digitalisert ist. Die nötigen Schlüssel liegen dabei NICHT in den Händen des Besitzers der gespeicherten Daten sondern bei den Herstellern von HW und SW und TrustCentern.

Es gibt also auch schon Speicherchips die zwar ausgelesen werden können, aber das was man da ausließt ist live verschlüsselt worden und kann nur innerhalb einer entsprechenden CPU mit Krypto-Co-Prozessor real verwertet werden.
Die Aussage das ein Passwort im RAM absolut unsicher und ungeschützt wäre ist also ebenfalls nicht mehr "ganz" richtig. Vielleicht noch heute aber nicht mehr in 4-5 Jahren.

Technologisch und auch vom Know How her gesehen wissen die heutigen Experten sehr genau was sie wie entwickeln müssen damit unsere Hardware in Zukunft vor UNS als Benutzer ABSOLUT sicher wird. Das kann vorteilhaft für uns als Anwender sein weil ein entsprechendes OS dann wirklich sicher vor Viren/Trojanern etc.pp. sein könnte. ABER! eher nehme ich an das solche "Features" nur zum Zwecke der Profitmaximierung benutzt werden, sprich zur Kontrolle unserer Daten oder unseres Verhaltens.

Aus dieser Sicht könnte man ja eigentlich froh sein das unsere heutige Technik so "unsicher" ist, da wir damit auch noch die absolute Kontrolle über unsere private HW haben. Denn eines steht fest: die Entwicklung und Vermarktung solcher krypto-gebundener-Hardware wird von Experten die wissen was sie tuen forciert. Dh. die Hoffnung das es intelligente Hacker in Zukunft gibt die dann immernoch überall einbrechen können (was ich schon heute für ein Gerücht halte) ist absolut falsch. Sollte in Zukunft jeder Schritt der Herstellung von Informationen/Daten, zur Vermarktung, über deren Speicherung und Datenübertragung bis hin zum Abspielen auf dem digitalem HD-TV Fernseher digitalisiert, kryptographisch geschützt und authentifiziert worden sein, so wird es mit den schon heute bekannten mathematischen Verfahren KEINERLEI effiziente Möglichkeit mehr geben ein solches System zu knacken.

Bestes Beispiel sind die bedauernswerten Benutzer der xBox die ihre persönlichen Daten auf Platte speicherten und später beim Einbau dieser HD in andere Rechner keinen Zugriff mehr auf diese, IHRE Daten haben.

Also gibt es Möglichkeiten ein Passwort sicher auf einem Rechner zu speichern, das Problem dabei ist es dieses Passwort sicher in der eigenen Anwendung zu speichern und zum Anwender zu transportieren. Das geht bisher noch nicht sicher. Wenn man also heute feststellen muß das ein Passwort in einer EXE absolut unsicher ist so liegt das nur daran das es noch keine durchgängige "Kryptographisierung" der Daten vom Hersteller einer Software bis hin zum Endkunden-Gerät existiert. Aber das wird kommen. Man kann also heute über die Protected Storage und dem Cryptographic Service Provider im Windows sehr wohl Daten sicher im Speicher ablegen. Das Problem ist nur wie man diese Daten über die eigene Anwendung dahin tranportiert. Falls diese Daten durch die Anwendung dynamisch erzeugt wurden so ist dies kein Problem. Ein Passwort hardcoded in der EXE gespeichert ist damit aber immer noch nicht sicher.

Gruß Hagen

[chaosben]

Ach Hagen ... das wir 2 uns immer in die Wolle bekommen ist komisch. (Vielleicht sind unsere Charaktäre zu unterschiedlich: du mit deinem gegen mich mit keinem )

Natürlich hast du Recht. Theoretisch besteht die Möglichkeit auf einem PC ein Passwort im RAM sicher abzulegen.
Aber versteh bitte auch mich. Wenn hier jemand fragt, ob sein Passwort im RAM sicher ist, dann gehe ich davon aus, das wir hier von Windows(darüber könnte man sich nocht streiten, aber muss man ja nicht) und aktuell gängiger Hardware reden. Und wie wir schon festgestellt haben, gibt es auf einem solchen System keine Sicherheit dafür, das ein Passwort nicht erschnüffelt werden kann. Warum sollte ich also eine andere Antwort als diese geben? Nur weil es theoretisch möglich wäre, wenn man spezielle HW nutzen würde?
Ich denke, der Thread-Ersteller wollte eine präzise Antwort, die er beim nächsten Programmieren nutzen kann. Und eine solche wollte ich ihm geben.