Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Zitat:
Zitat:
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. |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
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 |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
Und was für Module von der VCL und anderen Teilen, die du verwendets geladen werden, darauf hast du ja auch keinen Einfluß. |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
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. |
Re: Wie "offen" ist ein Password (String) im Arbei
@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 |
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
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:
|
Re: Wie "offen" ist ein Password (String) im Arbei
Zitat:
|
Re: Wie "offen" ist ein Password (String) im Arbei
Siehst du und ich will klarstellen das man nicht nur "scharz & weiß" sieht.
Zitat:
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 |
Re: Wie "offen" ist ein Password (String) im Arbei
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:50 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz