Hi,

ich schreibe in unserer Firma an einer Software welche nun demnächst auch an Kunden verteilt werden soll.
Intern nutzen wir sie schon eine ganze weile und sie läuft sicher und stabil, allerdings gibt es in dieser Software ein Rechte-Management, also nicht jeder Benutzer darf alles machen.

Da wir nun die Software auch an Kunden verteilen wäre es wichtig das es weitest gehend sicher ist das die Berechtigungen nicht umgangen werden können. Im Prinzip ist es das, wir würden nur auch gern versuchen es jemandem der es drauf anlegt nicht all zu einfach zu machen.

Das wovor wir uns da denke ich sorgen machen müssten wären irgendwelche Exploits die ausgenutzt werden, oder?
Ich persönlich habe allerdings absolut keine Ahnung davon wie das ganze Funktioniert - daher auch keine Ahnung wie ich es anstelle das ich im Code die Möglichkeit für Exploits so gut wie möglich verhindere..

Wäre super wenn mir da jemand ein wenig auf die Sprünge helfen kann und erklärt wie diese Exploits funktionieren.
Gern auch per PN wenn das ganze nicht hier öffentlich breit getreten werden soll

Aya~

Also ich bin kein Experte darin. Aber die Grundgedanken sind einfach (in absteigender Intensität):

• Disassemblierung des Programms und Veränderung der relevanten Abschnitte
  
• Wenn Lizenz-Keys da sind: Aufspüren der Veränderungen und Einfügen von eigenen Material
  
• Wenn eine Netzwerkübertragung genutzt wird: Mitsniffen und Analyisieren
  
• Ganz trivial: Fehleingaben provozieren (aber das sollte ja schon abgefangen werden)

Regan hat folgendes geschrieben :

Ganz trivial: Fehleingaben provozieren (aber das sollte ja schon abgefangen werden)

Ich bin auch kein Experte, aber den letzten Punkt sehe ich als Hauptpunkt bei "Exploits" an, und den finde ich auch nicht trivial. Wenn durch Benutzeingaben (kann ja auch binärer Kram sein) und mangelnde Prüfung Speicherbereiche überschrieben werden, Rücksprungadressen gefälscht werden etc., dann kann da eine Menge passieren. Der Trick ist dabei das Finden der "richtigen" pöhsen Daten - die müssen ja so strukturiert sein, dass das Programm nicht einfach abstürzt, sondern das macht, was der Angreifer will (z.B. Admin-Rechte bekommen).

Das Cracken von Software ist imho etwas anderes - das lässt sich ja bekannterweise nicht verhindern.

Genau, mir geht es eher um die Geschichte wie Gausi sie beschreibt.

Gegen Cracken ist man recht machtlos natürlich, bzw damit kenne ich mich genug aus um zu wissen was sinn macht und was nicht

Aber ich verstehe nicht mal ansatzweise wie man durch Absichtliche-Falscheingabe in z.B. einem Edit Feld etwas erreichen kann. Wenn die User-Eingabe direkt in einen SQL Query packt - ja.. aber sonst?

Ari~

Gelöscht

Das mit dem Plaintext gilt natürlich auch für das Programm und die gespeicherten Daten an sich:
Das Passwort darf aus dem gespeicherten Passwort auf keine Art und Weise wieder entschlüsselt werden können. Sprich es darf nur ein Hash gespeichert werden, am besten gesalzen.

Zum Vergleich hasht man das zu prüfende Passwort und salzt es dabei mit dem gleichen Wert wie das Originalpasswort.

Leider sieht man immer wieder, dass Programme das Originalpasswort entschlüsseln und die Passwörter selbst vergleichen. Das lässt sich natürlich verhältnismäßig leicht knacken, da dann das Originalpasswort irgendwo im Speicher stehen muss und zudem irgendwo eine Entschlüsselungsroutine existiert, die man nur im Assemblercode identifizieren muss.

Also die einzigste Lösung für das Problem ist meiner Meinung nach relativ einfach wenn man das von Anfang an so konzipiert. Das ganze hat natürlich auch Nachteile.
Ich meine damit Logik des Programms auf einen Server zu verschieben und dort kommt der Anwender/Angreifer grundsätzlich (i.d.R.) nicht dran.

Mir fällt außerdem noch eine andere Option ein, wobei das auch nicht ganz trivial wäre.
Und zwar könnte man doch die Module die höhere Rechte benötigen verschlüsselt ausliefern. Den Schlüssel dazu bekommt man nach erfolgreicher Authentifizierung vom Server zurück geschickt(Auf die Kommunikation an sich gehe ich jetzt nicht weiter ein). Abgesehen von der Sicherheit der Verschlüsselung gibt es dann für den Angreifer eigentlich keine Möglichkeit mehr auf dem Client-System deine Restriktionen zu umgehen. Also ich weis nicht ob das Prinzip so irgendwo schon verwendet wird aber das war die beste Idee die ich hatte. Wenn es dazu Bedenken gibt würde mich das auch interessieren.

Je nach Anwendung gibt es natürlich noch mehr Möglichkeiten..