wert "sicher" in der registry ablegen

[negaH]

Korrekt, es bleibt bei den Vorrausetzungen ja nichts anderes übrig !

Sicherheit kann entstehen durch definitiv sichere Algorithmen und deren Nutzung. Sie kann aber auch entstehen durch Anticracking Tricks. Diese Tricks sind zwar rechnerisch gesehen 0% Schutz, aber denoch halten sie praktisch gesehen viele Anfänger-Cracker ab. Das Problem bei diesen Tricks ist das sie nur maximal so gut sind wie der Programmierer der sie sich ausdenkt, und auf der Gegnerischen Seite arbeiten Gruppen von viel clevereren Crackern. Also hat ein normaler Profiprogrammierer eigentlich keine Chance von der Wissenbasis her.

Wenn also bestimmte Forderungen vom Kunden vorliegen, zB. das Passwort verschlüsselt zu speichern ohne das man den Passwort-Schlüssel jedesmal eingeben muß, dann muß man auch unsichere Verfahren vorschlagen und darf sie weil sie rechnerisch 0% unsicher sind nicht dem Kunden verschweigen. Davon hängt nämlich auch eine Aufwandsanalyse ab.

Meistens helfen aber ein paar Zahlenbeispiele die dem Kunden dann klarmachen um wievieles unsicher einer bloßer Anti-Cracking-Trick ist.

Meinesachtens arbeiten die effektivsten/ökonomischsten Anti-Cracking-Trick nach folgendem Schema:
- verstecke die Sicherheitsdaten an Orten wo sie nicht auffallen
- tarne diese Daten angepasst auf die häufigst vorkommenden Formate an diesem Ort
- bei Zugriff auf diese Daten gehe immer Umwege
- d.h. scann ALLE Daten am selben Ort wo die Sicherheitsdaten gespeichert wurden
- für alle gescannten Daten führe die gleichen Sicherheitsberechnungen durch, aber NUR für die tatsächlich entscheidenden Daten speichere deren Resultat.
- baue ca. 5 solcher Überprüfungen vollständige autark voneinander in die Anwendung ein
- gehe niemals den direkten Weg zum Ziel
- gehe diesen Weg immer nur sporadisch, z.b. alle 11 Tage o.ä.

Als Beispiel: eine Datei mit Daten soll versteckt werden. Wir entscheiden uns für den \Windows\System32 Ordner. Dort liegen hauptsächlich DLL's also muss unserer Datendatei eine DLL sein.
Bei Zugriff auf diese DLL scannen wir alle DLL's aus diesem Ordner. Für jede dieser DLL's lesen wir unserer Daten aus so als wäre sie eine gültige DLL-Datendatei von uns. Aber nur bei der richtigen Daten-DLL berücksichtigen wir das Resultat. Ein Cracker nutzt nun FileMon und protokolliert alle unserer Dateizugriffe. Pro DLL die unserer Anwendung aufruft sieht er ca. 10 Logeinträge, auf meinem Rechner sind in System32/ ca. 2.000 DLL's, er muß also 20.000 Logeinträge überprüfen auf eine verdächtige Aktion. Unsere Program benötigt zur Produktion eine solch großen Anzahl von Logs, nichtmal 10 Millisekunden.

In der Registry sieht es genauso aus. Speichere einen Gültig-erscheinenden Eintrag unter CLSID ab. Dieser Eintrag muß eine gültige CLSID Struktur aufweisen damit ein Automatischer Scanner diese CLSID nicht finden kann. 75% aller Schutzverfahren die ich analysiert habe bauten so auf die Registry sie nutzten ABER NIE die gültigen Strukturen. Somit flogen ihren versteckten Einträge sehr schnell auf. Z.b. CLSID-Schlüssel ohne Subkeys sind enorm verdächtig.
Nun gut beim Lesen unserer Informatonen scannen wir den Kompletten CLSID Registrybaum. Ich weiß nich aber 10.000 solcher CLSID's düften auf meinem System vorhanden sein. Wiederum 10 Logeinträge pro Zugriff in RegMon (Open,Seek,Close,Read,Subopen usw.). Sind also 100.000 Logeinträge die der Cracker analysieren muß und unser Program für ihn in maximal 50 Millisekunden erzeugt hat.

Das falscheste vom Falschen ist es zu versuchen SoftIce/RegMon/FileMon zu detektieren bzw. zu deaktivieren. So einen Schutz bauen nur Anfänger ein.


Gruß Hagen

[Chewie]

Mmh, das ist es eben. Unter und 100%iger Sicherheit verstehst du etwas anderes als ich, auch wenn wir (mehr oder minder) das gleiche meinen.

[negaH]

Nicht direkt, ich differenziere zwischen auf mathematischen Wahrscheinlichkeiten basierenden Algorithmen und Tricks.

Hat man aufgrund der Forderungen die Möglichkeit mathematisch sichere Verfahren zu nutzen so ist deren Sicherheit eben um rießige Dimensionen sicherer als jeder noch so clevere Trick. Die Sicherheit von solchen Tricks wird im Vergleich auf NULL reduziert.

Gruß Hagen

[Assarbad]

Seit NT 4 gibt es den Password-Stash von Windows und seit NT 5 ist er noch sicherer und einfacher zu bedienen. Dort liegen alle möglichen Paßworte inklusive des Maschinenpaßwortes und der Paßwörter von Services und COM-Servern die unter alternativen Credentials (nicht SYSTEM) laufen. Es ist also nicht sinnvoll eigene vermeintlich sicherere Methoden zu entwickeln. Was auch immer passiert, es läßt sich rauskriegen, ob ich es mit einem COM-Objekt zu tun habe, welches eine CLSID beim Registrieren in die Registry einträgt. Ist die nicht der Fall, würde ich als Cracker automatisch stutzig. Außerdem ist ja grade die Aktion, die den ungültigen (aber für uns relevanten) Key von den anderen Unterscheidet in einem Debugger sehr wohl auszumachen (wenn auch nicht so leicht mit RegMon). Also ich sehe da noch keine Vorteile und verlege mich lieber auf den bereits implementierten Teil der Crypto-API von Win. Ein anderer Schutz wäre das, was du uns letztens demonstriert hast - das war beeindruckend und IMO wirkungsvoll ...

[negaH]

@Asserbad, nur die Summe aller cleveren Mechanismen + mathem. bewiesen sichere Verfahren macht ein System gut. Ich persönlich meine das man das MS Ctypto API beherrschen sollte würde es aber nie für meine Aufgaben nutzen. 1.) gerade dieses Crypto API hat immer wieder gravierende Bugs, 2.) selbst MS kann keinen 100% Schutz bauen der nur auf Software bassiert, 3.) ich traue deren Implementationen nicht, 4.) würde jede Software den MS Passwort Schutz benutzten so wäre dieser Schutz ein enorm lohnendes Ziel für Hacker. Da dieses MS System auf reiner Software basiert und KEIN Passwort zur Verschlüsselung der Passwörter vom Benutzer abgefragt wird, muß es bewiesenermaßen immer knackbar sein.

Ich kann dir sagen was ich als Dateischutz benutze, es ist E4M ein Treiber der ein virtuelles Laufwaerk auf eine Datei mappt. Beim mounten dieses Laufwerkes wird immer das Passwort abgefragt und jede Lese/Schreibaktion in dieses virtuelle Drive wird online ver/entschlüsselt. Der Source war mal frei verfügbar und verifzierbar, und wurde als sicher eingestuft.
Desweiteren nutze ich meine eigene SmartCard (Chip karten) Software um meine Passwörter zu speichern. Wird 3 mal versucht mit einem falschen Key diese Passwörter zu lesen so blockiert sich die SmartCard selber (eg. Selbstzerstörung). Die Passwörter selber werden wenn möglich nie ausserhalb der SmartCard übertragen, sondern die SmartCard selber führt die Ver/Entschlüsselungen der Daten mit dem intern gespeicherten Passwort durch. Da nur ich das SmartCard API kenne, deren Funktionscode und deren PIN, ist es schwierig für eine Hacker selbst nur die Aufrufkonventionen in Erfahrung zu bringen. 3 mal ein solcher illegaler Versuch und die Karte sperrt.

Gruß Hagen

[negaH]

Zitat:

ob ich es mit einem COM-Objekt zu tun habe, welches eine CLSID beim Registrieren in die Registry einträgt. Ist die nicht der Fall, würde ich als Cracker automatisch stutzig

Richtig, deswegen betonte ich ja das dieser CLSID Eintrag möglichst die volle Funkionatlität eines COM Objectes simulieren sollte. Zudem habe ich erwähnt das die Überprüfung dieses CLSID Eintrags nicht per direktem Aufruf erfolgen sollte. Macht man das indirekt so hast du als Cracker ca. 10.0000 solcher CLSID's zu überprüfen denn das Program fragt alle CLSID's ab. Diese Abfrage sollte so gecodet werden das du als Cracker nicht die Möglichkeit hast herraus zu bekommen warum und nach was ich in den CLSID's suche ! Zudem sollte diese CLSID Suche nicht jedesmal zum Programmstart etc. durchgeführt werden, sondern nur periodisch alle par Tage. Somit würde ein Cracker viele Wochen lang mit großer Wahrscheinlichkeit den Schutz erstmal überhaupt nicht bemerken, denn er ist nicht mehr ständig aktiv.

Trotzdem, einmal aufgespürt, ist die Sicherheit = NULL im Vergleich zu richtig angewendeten kryptographischen Verfahren, eben genauso groß wie der Passwort Schutzt des OS.

Gruß Hagen

[raven_22]

Hallo !

Ich gebe zu, dass ich nicht alle Postings gelesen habe.
Aber es geht doch darum, Daten im System zu verstecken ?!
Ist es nicht möglich ein paar Daten in eine Systemdatei einzuschleusen.
In der Registry kann doch schließlich jeder rumspielen.
Oder verstecke doch diese Daten an einer zufälligen Stelle in deinem Programm.
Es soll wohl so eine Art Sharewareschutzmechanismus sein ?

Gruß raven 8)

[Assarbad]

Spätestens ab Windows 2000 wird dir da die SFC/WFP dazwischenfunken!

Außerdem ging es inzwischen darum etwas nur "so sicher wie möglich" zu machen, da wir übereingekommen waren, daß es kein "sicher" gibt. Nunja ... und Hagen versucht seinen Steganographie-Ansatz zu verteidigen, ich meinen Kryptographieansatz (wobei letzterer auf System-APIs basiert ... also bei Mißtrauen gegen MS/NSA etc sollte man ihn nicht verwenden).

[negaH]

Zitat:

Steganographie-Ansatz zu verteidigen, ich meinen Kryptographieansatz

Jay, jetzt ist da was falsch gelaufen. Am Anfang des Threads zeigte ich auf was der Prozentuale Unterschied zwischen einem solchen Steganographie-Ansatz zu einem Kryptograhischen sicheren Ansatz ist. Natürlich würde ich immer kryptographisch sicherer und mathematisch bewiesenermaßen sicherere System bevorzugen. Aber darauf lief die eingentliche Frage in diesem Thread eben nicht hinaus.
Es gings um's verstecken von Informationen so daß es ein Cracker schwerer hat.

Da der Passwortsafe im Windows ebenfalls die gespeicherten Passwörter mit einem im System gespeicherten Passwort + dem aktuellen Userpasswort verschlüsselt, ist selbst dieses API nicht mehr sicherer so bald sich der User eingeloggt hat. D.h. das Crypto-API wäre zwar technisch aufwendiger geschützt kann aber auf Grund dessen das ein geschütztes Passwort OHNE zusätzliche Passwortangabe auslesbar ist NICHT sicherer sein.

Passwörter gehören nur in die Birne oder in einbruchssichere Hardware. Die komplette Sicherheit eines Systems sollte nur auf diesem Passwort beruhen.

Gruß Hagen

[Assarbad]

Oki ;)

Also, raven, nicht auf mich hören ... was Hagen meint weiß natürlich er am besten *g* ... ich hab ihn dann falsch verstanden *g* (nicht das erste Mal, gelle Hagen ... "atomare Ops" ;))