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

[heri]

Ich habe eine DLL programmiert welche ein Textdokument - mit einem Password verschlüsselt - speichern und wieder öffnen kann. Juhee, das funktioniert auch prima - sie macht sogar noch einiges mehr!

Doch heute Nacht kam mir mit schrecken plötzlich folgender Gedanke:
wie "offen" für Hacker ist meine Variable mit dem Passwort in einer DLL überhaupt?

Beispiel - Funktionen der DLL:

- Open(AFilename, APassword: WideString)
öffnet die Textdatei und schreibt das Password in eine private Variable (weil ich diese in der DLL sonst noch mehrmals benötige)

- Close
speichert die Textdatei durch das Passwort verschlüsselt wieder ab


Schön und gut - doch nun ist während dem Open und dem Close das Password in der Variablen doch für "jeden" ersichtlich?
da wird meine Verschlüsselung ja überflüssig?
Was denkt ihr dazu?

Vielen Dank für eure Hilfe

[Bernhard Geyer]

Wieso werden wohl auch aktuelle Sicherheitssysteme unter Windows geknackt: Weil man mit einem Debugger oft ran kommt.

Willst Du es sicherer muss sich deine Anwendung beenden wenn ein Debugger aktiv ist. Auch mußt du jeden Hook erkennen da ja aufgrund des DLL-Funktionsnamens diese Funktion wie auf dem Präsentierteller liegt. Hier wirst Du u.U. mittels Obfuscation/Verschleierung etwas verbesserung bekommen.

[chaosben]

Zufällig beschäftige ich mich grad mit DLL-Injection und Function-Intercepting (meist tagsüber, selten nachts ). Dabei bin ich zu folgendem Schluss gekommen: Wenn es einem "schlechten" Programm gelingt, die Rechte zu erlangen, eines anderen Prozesses Memory zu lesen (ReadProcessMemory, ...), ist Schluss mit lustig. Diese Rechte hat ein Administrator auf NT-Systemen automatisch.
Mit diesen Rechten kann man alle Variablen lesen, die eine Prozess benutzt. Idealerweise kann man auch allen anderen Speicher inklusive der Instructions (also den eigentlichen Code) lesen (und wenn man will auch schreiben). Das führt dazu, das man nachverfolgen kann, wie du zu deinem Passwort kommst.

Was sollte man daraus folgern? Eine gewisse Sicherheit gegen Attacken von Boon's geben folgende 2 Hinweise:
1. Man sollte die Rechtestruktur von Windows(NT) nutzen. (Wenn es um Prozesse geht, die nicht unter der eigenen UID laufen). Sie hat ihren Sinn.
2. Man sollte in regelmäßigen Absänden die Liste dergeladenen Module durchsehen und prüfen ob alle diese Module ihre Daseinsberechtigung haben (wenngleich man diese Informationen auch fälschen kann; aber das ist was für richtige Insider).

Man sollte aber darüber nachdenken, wie hoch die Wahrscheinlichkeit eines Angriffes ist. Ein Programm, das 100 Menschen nutzen verdient imho keinen Extra-Aufwand für Sicherheitsmechanismen von 100 Stunden.

[negaH]

Ich führe am besten einen Vergleich an:

Du sicherst dein Haus mit einem Vorhängeschloß und hängst den Schlüssel für das Schloß direkt daneben an einem Nagel. So wie dieser Schlüssel "an den Mann" gehört (mein Uffz der BW lässt grüßen), gehört dein Passwort in den Kopf des Anwenders, alles andere muß im Falle deines kryptographischen Verfahrens unsicher sein.

Am besten ist der Gedanke das deine Anwendung/DLL/EXE nur eine andere Form deines Sources darstellt. Dh. alles was du in deinem Source lesen kannst kann man auch direkt aus deiner Anwednung/EXE/DLL herauslesen. Wenn du in deinem Source dein hardcoded Passwort lesen kannst so kann man dies auch ohne Probleme aus der fertigen Anwendung herauslesen

Du musst also grundsätzlich dein Konzept des Datenschutzes überdenken. Aus meiner Sicht möchtest du Anwenderdaten per Verschlüsselung schützen. Also lass einfach den Anwender das Passwort selber auswählen und per Dialog fragst du es ab. Damit lösst du nicht nur dein eigentliches Problem sondern du erhöhst sogar die Sicherheit enorm. Denn jeder Anwender deiner Software schützt seine Daten mit eigenen Passwörtern. Dh. es gibt deinem "General-Schlüssel" nicht mehr. Die Frage die sich jetzt stellt ist ob dies deinem Konzept/Ziel entspricht.

Gruß Hagen

[SirThornberry]

du kannst auch per PHP-Script etc. die Verschlüsselung vornehmen, dann kommt keiner ran. Du müsstest dann die Rohdaten an das Scriptschicken und das Script schickt dann das verschlüsselte Ergebnis zurück. So sollte niemand an den verschlüsselungscode ran kommen.

[negaH]

Zitat:

1. Man sollte die Rechtestruktur von Windows(NT) nutzen. Sie hat ihren Sinn.
2. Man sollte in regelmäßigen Absänden die Liste dergeladenen Module durchsehen und prüfen ob alle diese Module ihre Daseinsberechtigung haben (wenngleich man diese Informationen auch fälschen kann; aber das ist was für richtige Insider).
3. Man sollte darüber nachdenken, wie hoch die Wahrscheinlichkeit eines Angriffes ist. Ein Programm, das 100 Menschen nutzen verdient imho keinen Extra-Aufwand für Sicherheitsmechanismen von 100 Stunden.

1.) bietet keinerlei Schutz. Der Angreifer hat definitiv die höchsten Privilegien auf seinem Rechner auf dem Deine Anwendung läuft. Diese Privilegien sind sogar überdurchschnittlich größer als ein bloßer Admin/SYSTEM Account. Mit Hilfe der entsprechenden Werkzeuge, wie SoftICE, SandBox'en und VM's hat der Angreifer die TOTALE Kontrolle. Ergo: Punkt 1.) ist irrelevant und hilft garnichts. Erst mit der Einführung von kryptographischer und einbruchsicherer Hardware in die Systeme (TCP, DRM, HDTV lassen grüßen) ändert sich das. Einfach weil der Angreifer, bzw. JEDER Benutzer solcher Hardware, keinen Vollzugriff mehr auf ihre eigenen Ssysteme haben.

2.) Das funktioniert ebenfalls nicht. Treiber wie LogiTech Mäuse, Keyboard Treiber, Grafik Treiber, DCOM, Protected Storage etc. pp. injezieren ihre DLLs permanent in die eigene Anwendung. Davon abgesehen kann ein Angreifer auf seinem System sehr wohl diese Treiber DLLs durch eigene DLLs oder durch die "Side by Side" Technik, austauschen. Dh. aus Sicht deiner Anwendung hast du keine Möglichkeit zu erkennen welche DLLs sich mit welchem Ziel in deine Anwendung injeziert hat. Ergo: Punkt 2.) ist ebenfalls untauglich.

3.) Man kann über die Wahrscheinlichkeit eines Angriffs viele Jahre lang sinnieren, analysieren und rumgrübeln. Man wird immer zu dem Schluß kommen das selbst die billigste Software mit den schlechtesten Features denoch ein Angriffziel eines Angreifers sein kann. Die Gründe warum ein Angreifer einen Angriff startet haben sehr oft rein garnichts mit Geld, Know How oä. zu tuen. Fazit: auch Punkt 3.) ist Zeitverschwendung.

Gruß Hagen

[negaH]

Zitat:

du kannst auch per PHP-Script etc. die Verschlüsselung vornehmen, dann kommt keiner ran. Du müsstest dann die Rohdaten an das Scriptschicken und das Script schickt dann das verschlüsselte Ergebnis zurück. So sollte niemand an den verschlüsselungscode ran kommen.

Ähm ??? Also falls das PHP auf deinem eigenem und einbruchsicher geschützten Server läuft könnte dies unter Umständen funktionieren. Alledings handelt man sich enorm viele Probleme für nichts damit ein.

- man muß eine sicherer Datenübertragung im INet sicherstellen
- man benötigt zu jeder Zeit eine INet Verbindung, ohne das Proxies, Rooter, Firewalls etc.pp. dazwischen funken
- man benötigt einen INet Server samt Software

So und wenn man dies alles hat muß man noch das Problem lösen das man ja mit einem General-Schlüssel der für alle Benutzer identisch ist, arbeiten möchte. Dh. selbst mit dem sicheren PHP, mit sicherer Kommunikation übers INet, mit einem sicheren Server, wird der Angreifer EINMALIG diesen General-Schlüssel legal abfragen, und kann dann JEDE Anwendungskopie ohne weitere Abfragen entschlüsseln. Dh. alleine die Benutzung eines General-Schlüssels für alle Benutzer ist unischer und tödlich. Das identische Problem tritt zb. bei den Serialnummern/Registrationsschlüsseln von Software-CDs auf. Auch hier ist der technische Aufwand JEDE dieser CD-ROMs individuell zu serialisieren enorm, und deshalb benutzt man bei solche CDs eben auch "General-Schlüssel" in Form von Schlüssel-Ableitungs-Funktionen == Registrations-Funktionen. Hat man diese Funktionen einmalig reverse-engieneered kann man sich seine eigenen Schlüssel erzeugen.

Gruß Hagen

[thetrue]

nja ist sehr leich ein hardcore(einprogrammierten) password zu finden
ich habe mich schon etwas mit cracken beschäftigt, und ich weis es
debugger starten und die PWs gehören dir

[hboy]

gibt es nicht die pgp en/decoder als commandline ?

[negaH]

Zitat:

gibt es nicht die pgp en/decoder als commandline ?

Was nützt dir dies ? Du möchtest von der symmetischen Kryptographie und die a-symmetrische Kryptrographie eines PGPs wechseln. Leider lösst das nicht das konzeptionelle Problem.

Der Anwender der Software oder die Software des Anwenders muß für diesen Anwender als erstes beim Setup einen eigenen a-symmetrischen Schlüssel erzeugen, zb. eben RSA Schlüssel. Der Anwender muß nun

1.) den rivaten Teil dieses Schlüssel per Passwort schützen und auf Platte/USB Stick öä. speichern
2.) dann muß der Anwender den öffentlichen Teil dieses Schlüssel zum Server übertragen/senden
3.) der Server benötigt nun die Möglichkeit die Authentizität, sprich die Zuordnung -> öffentl. Schlüssel zum berechtigten Benutzer, sicherzustellen.

Gerade Punkt 3.) ist aber das Problem. Man benötigt eine Dritte Partei, einen sogenannten Trust der die Authentizität sicherstellen kann. Ist dies NICHT möglich so kann ein Angreifer ohne Probleme sich als regulärer Benutzer ausgeben und der Server wird somit wiederum an das "Gerneral-Passwort" zu Verschlüsselung der Daten rankommen.

Effektiv hat man also nur die Komplexität des gesammten Prozessings erhöht aber rein garnichts an Sicherheit gewonnen. Denn ein einfaches Benutzergewähltes Passwort (wie oben schon beschrieben) wäre identisch sicher. Denn bei all den Verkomplizierungen muß der Anwender ja nun seinen privaten Schlüssel schützen und da er viel größer ist als ein im Kopf gespeichertes Passwort muß er diesen sogar noch extern irgendwo speichern. Satt diesem Umweg kann man ja dann gleich das identische Passwort benutzen.

Gruß Hagen