Binaries und Strings

[The_Invisible]

Es ist sicher vielen bekannt das man Strings in Binaries sehr leicht auslesen kann. Ich habe deswegen die Methode entwickelt sensible Strings encrypted zu speichern und mittels Passwort wieder zur Laufzeit zu entschlüsseln.

Dazu ist jedoch eine Passworteingabe nötig die ich nicht bei allen Programmen will (zb Binaries die von fremden Programmen aufgerufen werden). Das Problem ist dann ja wieder, das das Passwort wieder Plaintext im Binary stehen muss. Man könnte das Passwort zwar per Algo erzeugen und so Stück für Stück zusammensetzen, ist aber auch nicht SO das Wahre.

Wie macht Ihr das also das man zb nicht sofort auf die DB eines Mailservers mit tausenden Accounts kommt? ;D

mfg

[Senior Sanchez]

Es ist sicher vielen bekannt das man Strings in Binaries sehr leicht auslesen kann. Ich habe deswegen die Methode entwickelt sensible Strings encrypted zu speichern und mittels Passwort wieder zur Laufzeit zu entschlüsseln.

Dazu ist jedoch eine Passworteingabe nötig die ich nicht bei allen Programmen will (zb Binaries die von fremden Programmen aufgerufen werden). Das Problem ist dann ja wieder, das das Passwort wieder Plaintext im Binary stehen muss. Man könnte das Passwort zwar per Algo erzeugen und so Stück für Stück zusammensetzen, ist aber auch nicht SO das Wahre.

Wie macht Ihr das also das man zb nicht sofort auf die DB eines Mailservers mit tausenden Accounts kommt? ;D

mfg

Also wirklich habe ich das Problem jetzt nicht verstanden, aber von Passwörtern kann man doch einfach einen Hash-Wert (meinetwegen MD5) speichern. Bei Eingabe des Passworts bildet man den Hash und vergleicht eben ob die Werte gleich sind. Aus dem gespeicherten Hash-Wert kann man aber nicht das Passwort ableiten.

[The_Invisible]

Hm, ok, nochmal.

Es geht mir nicht darum einen Benutzer zu authentifizieren, ganz im Gegenteil sogar.

Ich habe ein Programm das auf eine DB zugreift, die Benutzerdaten sind im Quelltext als Strings hinterlegt. Nach dem Kompilieren sind die Strings im Binary noch immer normal lesbar -> PROBLEM.

Jetzt kann man halt diese Strings gleich encrypted im Quelltext reinschreiben und mittels Passworteingabe eines Users wieder entschlüsseln. Jetzt habe ich aber den Problemfall, dass eine Benutzereingabe nicht möglich ist, da zB das Programm automatisch von einem externen fremden Programm aufgerufen wird. Wenn man das Passwort bzw den Key wieder als String in den Quelltext schreibt, hat man quasi ja wieder das gleiche Problem -> Lösungsvorschläge erwünscht.

Wie schon gesagt: man könnte einen Algo basteln der das ganze einfach verschleiert und die Benutzerdaten Stück für Stück zusammenbaut.

Wenn keiner bessere Vorschläge hat muss ich es wohl so machen, besser als nichts...

mfg

[Gast]

Nach dem Kompilieren sind die Strings im Binary noch immer normal lesbar -> PROBLEM.
wenn das ein problem ist kannst du dein programm gleich vergessen. auch das verschlüsseln bringt keinen sicherheitsgewinn, dann liest man das passwort halt nach dem entschlüsseln aus dem speicher aus. und selbst wenn du dagegen auch noch irgendwas basteln willst, kann man einfach die datenbankverbindung abfangen und dort das übermittelte passwort auslesen.

kurz gesagt: das was du vorhast ist die mühe nicht wert.
wenn du ein programm samt passwort auslieferst, musst du dich damit abfinden, dass das passwort ausgelesen werden kann.

[Gast]

Man könnte es dem Angreifer nur schwieriger machen, indem man viele falsche Fährten legt … den ganzen Bereich um die verschlüsselten Passwörter herum mit Zufallszeug füllen und die Bestimmung der Stringadresse so umständlich wie möglich machen …

Ist das auch der Grund, warum Kopierschutzmechanismen so riesig sind (die StarForce-DLL bei Colin McRae DiRT z.B. > 20 MiB)?

[Marscel]

Wie macht Ihr das also das man zb nicht sofort auf die DB eines Mailservers mit tausenden Accounts kommt? ;D

Web-Service dazwischenpacken?

Ich weiß nicht, welche Relevanz dein Programm hat, im simplesten Fall kann man UPX nutzen, aber mit geringfügiger Ahnung lässt sich das auch schon aushebeln.

[Trap]

Ich versteh das konkrete Problem immer noch nicht. Was verteilst du an wen und was willst du vor wem schützen?

[Gast]

Web-Service dazwischenpacken?


Das nützt auch nichts, wenn die Authentifizierung Userbezogen sein soll, denn dann muss man sich ja wieder beim Webservice authentifizieren. Gut, man könnte dann über den Rechnernamen gehen, aber ohne Kerberos oder Ntlm ist hier auch überhaupt keine Garantie der Echtheit des Senders gewährleistet.

Wenn der Ursprungposter z.B. Windows verwendest und seine DB Windowsauthentifizierung (Kerberos, Ntlm) kann, dann sollte er auf jeden Fall Windowsauthentifizierung verwenden (oder etwas äquivalentes auf einem anderen OS).

[Marscel]

Das nützt auch nichts, wenn die Authentifizierung Userbezogen sein soll

Soll es laut 2. Posting doch aber gar nicht. So wie ich das Problem verstanden habe, ist sein Problem etwas der Sorte:

string password = "geheim";
sql_connection csql = sql_connect(..., password, ...);

Sein Programm nutzt also die SQL-API zum Arbeiten.

Wenn man nun OllyDbg oder vergleichbares laufen lässt, steht irgendwo der String "geheim". Das ist, neben User, Host und DB, der Kram, der im Programm hardcoded steht. Jemand, der sich die Mühe macht und das rausfischt, kann nun mit einem Clienten seiner Wahl nach belieben auf der Datenbank rumstöbern.

Entweder: einen DB-Account einrichten, der auf die einzig nötigen Tabellen ein SELECT-Recht hat - und sonst gar nichts darf.
Oder: Einen Webservice dazwischen tun, der nichts mit dem Passwort zu tun hat, und nicht mehr als Frage -> Antwort oder eben das, was The_Invisible vorhat, kann.

[Gnafoo]

Du könntest das Passwort per DPAPI verschlüsselt in einer Konfigurationsdatei des Users ablegen. Dann kommt man (zumindest in der Theorie) nur dran, wenn man das Windows-Login des entsprechenden Users kennt, bzw. am entsprechenden Rechner bereits eingeloggt ist.

Die Frage ist aber tatsächlich, ob dir das wirklich einen Sicherheitsvorteil verschafft. Der entsprechende User kann so theoretisch immer noch an das Passwort kommen (was sich nicht verhindern lässt, schließlich muss irgendwann ein Login stattfinden) und wenn man sich den Datenaustausch mit der Datenbank ansieht, kann man das Passwort auch herauslesen, sofern die Verbindung nicht extra gesichert ist.

Vielleicht könntest du etwas konkretisieren, wer genau zugreifen darf, wer nicht und wo du genau einen Angriff vermeiden willst. Das du die EXE-Datei schützen willst impliziert, dass du diese entweder öffentlich zugänglich machen willst, oder dass du dem User nicht vertraust. Im ersten Fall ist die DPAPI vielleicht eine Lösung (nach einmaliger Eingabe des Passwortes durch den User z. B.). Im zweiten Fall hast du sowieso ein Problem. Da ist ein zwischengeschalteter Web-Service oder so vielleicht wirklich nicht schlecht, weil dieser besser einschränken kann, was der User in der Datenbank tun darf.

[The_Invisible]

Soll es laut 2. Posting doch aber gar nicht. So wie ich das Problem verstanden habe, ist sein Problem etwas der Sorte:

string password = "geheim";
sql_connection csql = sql_connect(..., password, ...);

Sein Programm nutzt also die SQL-API zum Arbeiten.

Wenn man nun OllyDbg oder vergleichbares laufen lässt, steht irgendwo der String "geheim". Das ist, neben User, Host und DB, der Kram, der im Programm hardcoded steht. Jemand, der sich die Mühe macht und das rausfischt, kann nun mit einem Clienten seiner Wahl nach belieben auf der Datenbank rumstöbern.


Korrekt ;)

Das Programm ist eigentlich ganz trivial. Es läuft auf einem Linux Server quasi als Addon für den Maildienst und überprüft welche Services dem Benutzer zur Verfügung stehen.

Der DB-User kann in den entsprechenden Tabellen sowieso nur selects absetzen, plaintext Passwörter gibt es keine, insofern würde ja nicht gleich die Hölle zufrieren wenn wer die Daten hätte. Es geht mir aber ums Prinzip, ich habe Angst das die Binaries irgendwo mal rumschwirren könnten (geht bei uns schnell) und quasi jeder DAU die DB-Zugangsdaten bekommen könnte.

Hoffe das wäre jetzt geklärt.

mfg

[Marscel]

Hoffe das wäre jetzt geklärt.

In dem Fall wäre ein Webservice die beste und noch freie Möglichkeit in meinen Augen, das zu verhindern. Festkompilierte Zugangsdaten sind ja auch nicht gerade das flexibelste.

Kannst du beim Start von anderen Programmen aus nicht einen Paramter in der Pipe setzen, sodass in dem Fall die Datenabfrage nicht über die DB-API erfolgt, sondern dausicher über z.B. Text oder XML? Dann ist eigentlich nur ein Host und ein Anfrage Query nötig.

In so einem Fall hoffe ich, dass du eine gute Data-Model-Struktur hast. ;)

[Monger]

Benutzerdaten die in den Quellcode kompiliert sind, sind immer böse - egal wie. Die Authentifizierung sollte letztendlich immer vom Benutzer kommen, und sollte daher bis ans Frontend durchgereicht werden.

Wer dann noch den Stresslevel ein bißchen reduzieren will, so dass das Passwort nur dann abgefragt werden muss wenn es sich geändert hat, nutzt halt solche Technologien wie Cryptostore o.ä.

Was du versuchst, ist im Prinzip ein Versuch genau das zu imitieren. Das ist aber eben alles andere als trivial - wirklich brauchbare Sicherheitsmechanismen kann wohl kein Normalsterblicher implementieren. Das sollte man Profis überlassen.

[Gast]

Es geht mir aber ums Prinzip, ich habe Angst das die Binaries irgendwo mal rumschwirren könnten (geht bei uns schnell) und quasi jeder DAU die DB-Zugangsdaten bekommen könnte.


Sehe ich anders. Also erst mal kann garantiert nicht jeder DAU irgendwelche Binaries dissamblieren. Bei Zwischencode kann man einen Obfuskator verwenden. Aber selbst ohne kann das auch nicht jeder DAU analysieren.

Sprich, du musst dir wenn um Leute Gedanken machen, die Ahnung von der Materie haben. Und dann musst du dir sowieso ganz andere Gedanken machen.

Wie gesagt, unter Windows würde ich IMMER Windows Authentifizierung verwenden, egal ob die Anwendung nur unter einem Account läuft oder jeder einzelne Nutzer authentifiziert werden soll.
Unter Linux gibt es sicherlich äquivalente Technologien.

[The_Invisible]

hm, gut, weiß noch immer noch nicht so recht was ich machen soll.

webservice wäre zwar ein guter ansatz, ist aber ein zusätzlicher overhead gegenüber nativen db abfragen. am anfang sind zwar nur 1500 user oben, aber das könnte sich schnell verzehnfachen oder sogar mehr.

bzw
wenn man die binary mit zb nano öffnet sieht man sofort die textstellen, da braucht man nix großartig dissamblieren.

mfg

[Trap]

Wenn die Gefahr besteht, dass das Programm einfach von irgendwem kopiert wird, darf man die Nutzerdaten halt nicht im Programm speichern, sondern muss sie von irgendwo holen/gegeben bekommen.

Konkreter kann man da keine Ratschläge geben mit dem was du geschrieben hast.

[Gast]

bzw
wenn man die binary mit zb nano öffnet sieht man sofort die textstellen, da braucht man nix großartig dissamblieren.


Dann verschlüssel sie eben und speichere sie z.B. im Base64 Format als eingebettete Resource im Binary. Dann sieht man es nicht sofort.

Oder: Lass das Programm unter einem bestimmten Account laufen und speichere den String irgendwohin (z.B. Registry), wo nur der Account Rechte zum Zugriff hat.

Oder: Wie mehrfach erwähnt, verwende sowas wie Kerberos. Dann brauchst du gar kein Passwort oder irgend einen String