UPX - Wer hat aktuelle Erfahrungen damit?

[Back2Code]

Zitat:

Zitat von Lemmy (Beitrag 1235071)

Zitat:

Zitat von Back2Code (Beitrag 1235070)

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM

Super.. genau so stelle ich mir das vor. Sobald das Programm läuft und ich in Delphi was Debuggen will springt das Teil an und blockiert mir den Rechner, weil ich meine Entwicklungsumgebung in einer VM laufen habe. Aber gut - i.d.R. gibt es ausreichend Alternativen....

Grüße

Das war eher auf Debugger wie IDA & OllyDBG bezogen ...

[jaenicke]

Zitat:

Zitat von musicman56 (Beitrag 1235069)

Also speichert man das Passwort verschlüsselt.

Ich habe das einmal (neben weiteren Maßnahmen) so gemacht, dass ein Passwort oder ähnliches an sich nicht ausreicht. Der Client ruft ein Skript auf dem Server auf und bekommt von dort Bytecode, der zur Verschlüsselung der Anforderung dient. Dieser Bytecode wird von einem kleinen Interpreter ausgeführt und ist auch nur für die nächste Anfrage gültig.
Auf diese Weise müsste ein Angreifer sehr viel Aufwand betreiben. Da der Bytecode serverseitig dynamisch generiert wird, aber clientseitig ausgeführt wird, reicht es auch nicht aus einmalig herauszufinden was der macht. Man müsste den Interpreter nachbauen und dann noch herausfinden was dort wie an Daten hereinkommt und welche davon benötigt werden.

Das war ursprünglich nur eine kleine Übung. Und für mich reichte das aus, denn wer das knacken kann, der schafft es auch alles andere zu knacken.

[Lemmy]

Zitat:

Zitat von Back2Code (Beitrag 1235077)

Das war eher auf Debugger wie IDA & OllyDBG bezogen ...

das war mir schon klar :-) nur sollte man halt beachten, dass man mit jeder weitere Einschränkung ggf. Kunden ausschließt, die halt z.B. eine virtuelle Maschine nutzen, was aktuell immer mehr zunimmt. Und Debugger-Detection sollte dann halt nicht unbedingt ne Entwickler IDE zerschießen wenn man ein Produkt für Entwickler bereit stellt ;-)

[musicman56]

Zitat:

Zitat von Daniel (Beitrag 1235075)

Nun, wir sollten zur Ausgangsfrage zurück kommen. Es scheint mit UPX heute im Allgemeinen wohl eher keine Probleme mehr zu geben.

Den Eindruck habe ich auch, denn so richtig Stress gibt es (zumindest aktuell) wohl nicht mit UPX. Also könnte man das Thema eigentlich abhaken, wenn sich nicht noch jemand mit gravierenden neuen Erkenntnissen meldet.

Zitat:

Zitat von Daniel (Beitrag 1235075)

Welche Maßnahmen man zum Software-Schutz ergreifen kann, ist in der Tat spannend und ich bin just in diesem Moment an dieser Fragestellung in einem Projekt dran, aber das sollten wir - wenn überhaupt - separat besprechen.

Mich interessiert das Thema schon. Es gab hier (oder war es woanders, ich weiß und findes es nicht mehr) mal einen Thread der sich ausgiebig damit beschäftigt hat. Im Endeffekt läuft es wohl darauf hinaus, dass man das Debuggen so schwer wie möglich machen muss, weil nahezu alle anderen Möglichkeiten ins Leere laufen.

Als kleines Beispiel mal die Standardvorgehensweise, ein Passwort nicht inhaltlich, sondern dessen Hash zu speichern. Bei der Eingabe vergleicht man dann den Hash des Passwortes mit dem gespeicherten (womöglich verschlüsselten) Hash. Man glaubt, dass das sicher ist, weil der Hash nicht zurückberechnet werden kann. Einen Angreifer kümmert das gar nicht. Der biegt entweder die Funktion in der Echse um (dauert etwa 1 Minute und wird bei "lokal orientierten Cracks" gerne gemacht), oder nimmt einen Passwort-Pool von den meisten sagen wir mal 20 Millionen Passwörtern, generiert daraus die Hashes und schaut dann nach, welcher zum Hash passt. Das eigentliche Passwort braucht er dann gar nicht mehr. Dieser Mehraufwand wird dann praktiziert, wenn mehrere Leute in den Genuss des Zugangs kommen sollen.

Die Generierung von effektiven Schutzmechanismen nützt also nur was, wenn man genau weiß, wie Cracker/Hacker/Angreifer denken und arbeiten. Den schlimmsten Fehler den man machen kann ist glaube ich zu denken, dass man eine "sichere" Methode gefunden hat, Angreifer abzuwehren. Auch davon (oder darüber) könnte ich einige Lieder singen. Vor Jahren hatte ich z.B. mal sensible Daten in einer verschlüsselten Nexus-Datenbank gespeichert. Der Hersteller hat mir vorgerechnet, wieviel Jahre ein Angreifer über BruteForce brauchen würde, die Datenbank zu knacken. Ich glaubte mich in Sicherheit. Dann habe ich die Datenbank einem Bekannten aus England zur Überprüfung per E-Mail geschickt. Eine Viertelstunde später war die Datenbank geknackt. Die logische Erklärung warum das so schnell geht, und warum die Aussage des Herstellers nicht mal das Papier auf dem sie gedruckt war wert ist, hat mich auf den Boden der Tatsachen zurückgeholt.

Aber, das wäre dann jetzt wirklich ein eigenes Thema :thumb:

[himitsu]

Zitat:

Zitat von musicman56 (Beitrag 1235112)

oder nimmt einen Passwort-Pool von den meisten sagen wir mal 20 Millionen Passwörtern, generiert daraus die Hashes und schaut dann nach, welcher zum Hash passt. Das eigentliche Passwort braucht er dann gar nicht mehr. Dieser Mehraufwand wird dann praktiziert, wenn mehrere Leute in den Genuss des Zugangs kommen sollen.

Da gibt es schon (teilweise) vollständige "Rainbow Tables" für alle möglichen Hashs, wo z.B. zu praktisch jedem MD5-Hash schon ein passendes "Passwort" vorberechnet wurde.
Man braucht da also garnicht mehr selbst was berechnen, sondern sucht nur noch in einer Datenbank nach dem Hash und einem zugehörigen "Text", welchen man als Passwort nutzen kann.

[Lemmy]

Zitat:

Zitat von himitsu (Beitrag 1235117)

Da gibt es schon (teilweise) vollständige "Rainbow Tables" für alle möglichen Hashs, wo z.B. zu praktisch jedem MD5-Hash schon ein passendes "Passwort" vorberechnet wurde.
Man braucht da also garnicht mehr selbst was berechnen, sondern sucht nur noch in einer Datenbank nach dem Hash und einem zugehörigen "Text", welchen man als Passwort nutzen kann.

ich war die Tage auf der EKON - ein Teilnehmer war in der Session mit der Angewandten Kryptographie und der meinte bei einem Gespräch später, dass er seinen Hash-Algo selbst geschrieben hat, um damit die Problematik der Rainbow-Tables zu umgehen. Ich bezweifle aber irgend wie, dass ihm das was bringt, weil so gravierend unterschiedlich können die Berechnungsmethoden bzw. deren Ergebnisse doch nicht sein?!?

Bin dafür jetzt langsam ein eigenes Thema draus zu machen. Das hier finde ich viel zu interessant als an der Stelle jetzt aufzuhören...

Grüße

[Meflin]

Zitat:

Zitat von Lemmy (Beitrag 1235126)

ich war die Tage auf der EKON - ein Teilnehmer war in der Session mit der Angewandten Kryptographie und der meinte bei einem Gespräch später, dass er seinen Hash-Algo selbst geschrieben hat, um damit die Problematik der Rainbow-Tables zu umgehen. Ich bezweifle aber irgend wie, dass ihm das was bringt, weil so gravierend unterschiedlich können die Berechnungsmethoden bzw. deren Ergebnisse doch nicht sein?!?

Wenn Leute, die von Kryptographie wenig bis keine Ahnung haben (dazu zähle ich mich übrigens selbst auch) sich bemüßigt fühlen, irgendetwas selbst zusammen zu frickeln, kommt selten was sinnvolles dabei raus. Vor Rainbow-Tables "schützt" man sich mit Salting, und nicht, indem man eine eigene (höchstwahrscheinlich unter kryptographischen Gesichtspunkten völlig unzulängliche) Hashfunktion zusammenschustert.

Allgemein finde ich es ja sehr amüsant, was hier alles an Schutzmechanismen vorgeschlagen wurde, um ein FTP-Passwort zu schützen - wo es doch jedes 12-jährige Script-Kiddie in 2 Minuten schafft, selbiges einfach im Klartext aus einem Wireshark-Log auszulesen...

Es wird schon einen Grund geben, wieso immer mehr große Softwareanbieter stark in Richtung Software-as-a-Service umrüsten (siehe Adobe Creative Cloud oder Office 365). Alles, was auf dem Rechner des Kunden läuft, ist im Endeffekt einfach nicht zu schützen. Ich bin aber immer wieder erstaunt, wie viel Energie Entwickler trotzdem genau da rein investieren (anstatt die Zeit zum Beispiel dafür zu nutzen, das Produkt besser zu machen ;) ).

[Lemmy]

Zitat:

Zitat von Meflin (Beitrag 1235130)

Wenn Leute, die von Kryptographie wenig bis keine Ahnung haben (dazu zähle ich mich übrigens selbst auch) sich bemüßigt fühlen, irgendetwas selbst zusammen zu frickeln, kommt selten was sinnvolles dabei raus. Vor Rainbow-Tables "schützt" man sich mit Salting, und nicht, indem man eine eigene (höchstwahrscheinlich unter kryptographischen Gesichtspunkten völlig unzulängliche) Hashfunktion zusammenschustert.

Danke - war auch meine Meinung :-)

[jaenicke]

Zitat:

Zitat von Meflin (Beitrag 1235130)

Allgemein finde ich es ja sehr amüsant, was hier alles an Schutzmechanismen vorgeschlagen wurde, um ein FTP-Passwort zu schützen - wo es doch jedes 12-jährige Script-Kiddie in 2 Minuten schafft, selbiges einfach im Klartext aus einem Wireshark-Log auszulesen...

Wer für so etwas nicht FTPS nutzt hat einfach keine Ahnung. Dass es bei FTP ohne SSL sofort sichtbar ist, ist klar.

Aber mit einem entsprechenden Splitter kann man auch FTPS überlisten, nur nicht mehr so einfach.

Aber dass FTP nicht so der Bringer dabei ist, habe ich ja auch schon oben geschrieben.

[musicman56]

@Sebastian

Wenn ich nicht komplett daneben bin, dann reden wir von zwei voneinander gänzlich verschiedene Vorgängen. Du meinst die Verschlüsselung (den Transportweg oder die Transportart) der zu übertragenden Daten (was durchaus auch wichtig ist) aber vorher geht es doch erst mal darum, ob und wie der (Versuch) Verbindungsaufbau überhaupt zustande kommen darf. Ob das dann eine FTP-Verbindung, eine FTPS, HTTPS oder weiß der Geier was ist, das ist eine Designfrage, die mit dem Ressourcenschutz erst mal nichts zu tun hat, oder zumindest nicht in direktem Zusammenhang steht.

Macht man die Verbindung wie du über HTTP und Scripts, dann müssen beispielsweise die Scripts geschützt werden. Sind die nicht geschützt, nutzt die sicherste Verbindung nichts.

Insofern hat Meflin schon recht damit:

Zitat:

Zitat von Meflin (Beitrag 1235130)

Es wird schon einen Grund geben, wieso immer mehr große Softwareanbieter stark in Richtung Software-as-a-Service umrüsten (siehe Adobe Creative Cloud oder Office 365). Alles, was auf dem Rechner des Kunden läuft, ist im Endeffekt einfach nicht zu schützen. Ich bin aber immer wieder erstaunt, wie viel Energie Entwickler trotzdem genau da rein investieren (anstatt die Zeit zum Beispiel dafür zu nutzen, das Produkt besser zu machen ;) ).

Die Kunst besteht wohl auch darin, Zeit und Aufwand für den Schutz in ein gesundes Verhältnis zum Ergebnis zu bringen.