Schlüsselzerstörung im Speicher

M

memberHB4711

0
Hallo,

Programme die kryptographische Schlüssel erzeugen/benutzen sind darauf bedacht diese danach auch wieder zu löschen, z.b. im Speicher (falls nur temporär erzeugt) mit Nullen zu überschreiben.

Wie kann ich das z.b. bei einem Windows Program überprüfen? Das nahe liegenste wäre den gesamten Speicher nach dem Schlüssel-String zu durchsuchen, aber das ist ja wohl nicht so einfach möglich wie es sich anhört, oder? Da gibt es doch mindestens Probleme wie: "Speicherseparierung" zwischen programmen, womit ich mit einem eigenen Program nicht den speicher des anderen auslesen kann. Oder die gesuchte Information könnte gerade ausgelagert sein und befindet sich im Moment garnicht im Speicher.

Ich weiss, die Frage passt eher zum Windows oder Programmierungs Forum, aber die Fragenursache liegt hier:)

Danke,
seb
 
Hallo,
wenn du Admin/Root-Rechte hast, stellt es eigentlich gar kein Problem dar (soweit ich weiß), den gesamten Hauptspeicher auszulesen (Probleme könnte es geben mit ein paar geschützen Speicherbereichen, evt. auch mit Speicher der vom Kernel reserviert wurde, da wissen aber andere bestimmt mehr)

So schwer ist es auch gar nicht, gab mal eine ähnliche Programmieraufgabe dazu: RAM test

Beim API hooking werden auch diverse Funktionen benutzt, um Speicher aus bestimmten Speicheradressen auszulesen.
Evt. hilft dies schon weiter.

Ein Problem wäre, den richtigen Schlüssel zu finden. Wenn du 500 MB (=500 Millionen Byte) RAM in Benutzung hast und eine 16 Byte Schlüssel suchst, entspricht dies etwa der Suche nach der Nadel im Heuhaufen.
Allerdings, wenn der Key zufällig gewählt ist, dann fällt dieser meistens schon deutlich auf. Musst also etwas haben, was Zufallsdaten von gewöhnlichen, nicht zufälligen Daten, unterscheiden kann
 
Ist das wirklich so einfach?
Ich meine naehmlich das es immer noch einen Unterschied zwischen einem Prozess und einem Benutzer gibt welcher auf den Speicher zugreifft.
Wenn ich mir z.b. ein Programm in C schreibe und damit den Ram durchlaufe,dann bricht das Programm irgendwann ab, und ich lasse das Programm dann schon als Root laufen.
Habe allerdings auch Stack-Protection angeschaltet.
mfg

sw33t
 
@Elderan: Befinde ich mich aber nicht wie gesagt in einem separaten Speicherbereich, in der mir nur vorgegaukelt wird dass ich den Speicher von z.b. 000000 bis FFFFFF durchlaufe, während ich mich in Wirklichkeit in einem eignen virtuellen Speicherbereich für mein program befinde?

Die Suche des Schlüssels gestaltet sich allerdings einfach (vorrausgesetzt obiges Problem ist gelöst), denn ich kann den generierten Schlüssel ja in Erfahrung bringen und dann nach Beendigung des Kryptotools nach dem bekannten Schlüssel suchen. Wie gesagt, es geht mir nur daram zu überprüfen dass die Schlüssellöschung tatsächlich vorgenommen wurde.

@sw33tlull4by: Die genannten Probleme würde ich auch erwarten, wobei Stack-Protection glaube ich nur bei einer "unnormalen" Schreiboperation auf dem Stackbereich aktiv wird.

Danke und Grüße,
seb
 
Hallo,
evt. gehts schon mit Windows Boardmitteln, es gibt scheinbar: \\Device\PhysicalMemory
Dieses sieht doch schonmal viel versprechend aus, oder hier ein anderer Thread wie man mit Windows Debuggin Tools an ein memory dump gelangt.

Ansonsten schau dir mal dieses Tut nochmal an: Windows API hooking

Um von fremden Prozessen Speicher auszulesen reicht doch nahezu schon:
HANDLE hproc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, ProcessId);

Und dann ReadProcessMemory() anwenden, wobei man ggf. vorher mit VirtualQuery() und VirtualProtect() die Rechte sich holen muss.

Der gleichen bzw. einer ähnlichen Technik bediehnt man sich auf bei DLL injections

Habs dies aber selber noch nie gemacht und mehr fehlt dort etwas die Erfahrung.


[Habs man in die Programmierabteilung verschoben, da dies eher etwas mit Programmierung zu tun hat]

Edit
Hier noch zwei intressante Links:
Playing with Windows /dev/(k)mem (Win2k)
Subverting Windows 2003 SP1 Kernel - Integrity Protection
 
am ehesten wäre imho die \\Device\Memory Lösung akzeptabel - denn alle Prozesse zu durchsuchen dürfte recht lange dauern (außerdem bekommt man auf einige Prozesse keinen zugriff, den Kernel wird man auch nicht durchsuchen können). Jedoch hat diese Lösung auch paar Nachteile - zum einen sollte es ab win2k3 nicht mehr so einfach möglich sein, vom Usermod aus auf den physikalischen Ram zuzugreifen, zum anderen - die Auslagerungsdatei bleibt auch noch übrig, zum dritten - das Programm würde dann Admin Rechte benötigen, was doch sehr unschön wäre. Und zum vierten - wer löscht den "Suchschlüssel" und stellt sicher, dass dieser gelöscht ist ? ;)

Daher würde ich versuchen, statt der Symptome eher die Ursachen anzugehen:
1. ich würde Defaultmäßig davon ausgehen, dass andere Programme den Key nicht abgreifen (sollte eigentlich nicht möglich sein, wenn die Programme nicht mit Adminrechten laufen (bitte selbst nachprüfen/nachrecherchieren)). Zumindest eine Grundsicherheit solltest Du schon voraussetzen.

2.Reserviere für den Schlüssel einen non-paged Speicherbereich.
(Reservierung mit VirtualAlloc und dann "locken"
http://msdn2.microsoft.com/en-us/library/aa366895(VS.85).aspx
Locks the specified region of the process's virtual address space into physical memory, ensuring that subsequent access to the region will not incur a page fault.
Zum Vergrößern anklicken....

Dieser wird dann nicht ausgelagert, so dass Du davon ausgehen kannst, dass es keine Swap- Kopie davon auf der Festplatte exisitert.
Falls Du selber danach suchen möchtst: Stichworte sind eher "non-paging" oder "nonpaged" Memory allocation.

3.Bleibt das Problem mit der GUI - und zwar existieren unabhängige Kopien der Usereingaben im Speicher, solange man "Standardguielemente" wie Editfelder oder Einlesefunktionen verwendet.

Hab ehrlich gesagt im moment keine Ahnung, ob es spezielle "Passworteinabefelder" gibt - ich weiß nur, dass man ein Standardeditfeld auf "ES_PASSWORD" setzen kann - ob das intern was bewirkt, bezweifele ich allerdings.
D.h dass Du dann Dir noch etwas überlegen müsstest - entweder wird die Eingabe noch gesaltet oder Du schreibst eine "sichere" Eingaberoutine (sowas wie "readkey" für GUI -> einen Tastendruck einlesen, auswerten, in den "sicheren" Speicherbereich kopieren, von dem Du weißt, dass dieser nicht ausgelagert wird) und lässt dann in der Ausgabe * anzeigen. Das ist etwas Aufwand, sollte aber gehen - vor allem bist Du da wohl nicht der erste (eventuell gibt es schon was vorgefertigtes). Alternativ könnte man auch eine Bildschirmtastatur anzeigen lassen.
 
Ich sehe schon ... Speichermanagement ist nicht trivial, und wenns dann noch um Sicherheiht geht ...

Werde mich mal in das Thema reinarbeiten. Der Einstieg ist dank euch schon etwas einfacher.

Auf deine Frage, wer nach einem Schlüssel sucht der zuvor gelöscht wurde: unabhängige Prüfer von Sicherheitsprogrammen:)

Ciao,
Seb
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben