UPX - Wer hat aktuelle Erfahrungen damit?

[musicman56]

Zitat von Daniel:

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 von Daniel:

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

[himitsu]

Zitat von musicman56:

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 von himitsu:

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 von Lemmy:

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 von Meflin:

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

[musicman56]

Zitat von Meflin:

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...

Wireshark kannte ich noch gar nicht. Wieder was dazu gelernt. Vielen Dank für den Tipp!

Soeben vom Chip-Server runtergeladen und installiert. Erschreckend was man da so alles sieht

[jaenicke]

Zitat von Meflin:

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 von Meflin:

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.

[Assarbad]

Um das mal etwas von der AV-Seite zu beleuchten. Es gab in 2008 einen Workshop hier in Reykjavík zum Thema. Viele der AV-Hersteller sind unserer Einladung gefolgt und wir haben hier unweit der Uni das Thema von verschiedenen Seiten beleuchtet.

Es war schon damals Konsens, daß diverse Packer wie Themida unter Generalverdacht stehen. Es gab noch einige andere ähnlich trickreiche Packer (bzw. "Schutzprodukte") welche ebenfalls in diese Kategorie fielen. Wobei der Indikator dafür meist die Verbreitung innerhalb guter und schlechter Software ist. UPX stand damals zumindest nicht durch eine Mehrheit der AVs unter Generalverdacht.

Ansonsten einigte man sich darauf weiterzumachen wie bisher und eine einheitliche Lösung anzustreben (wobei das auch schon bei der Namensgebung einstmals angestrebt wurde). Die Entscheidung ob ein Packer unter Generalverdacht steht, ist dabei abhängig vom Hersteller.

Dennoch gab es im Nachhinein noch eine Entwicklung die derzeit doch etwas ins Stocken geraten ist. Bei der IEEE hat sich eine Arbeitsgruppe (bestehend aus diversen Mitgliedern der AV-Herstellergemeinschaft) unter dem Namen Taggant mit der Entwicklung eines Systems befaßt welches, nicht unähnlich zu AuthentiCode, eine Art Signatur in vom Packer gepackte Dateien einbetten soll um danach statt des Packers nur die Dateien welche mit dem Packer eines bestimmten Kunden gepackt wurden in die Erkennung zu nehmen. Dieses Projekt wurde unter anderem von Jeremy Collake, dem Autor des zuvor schon erwähnten kommerziellen PECompact, vorangetrieben.

Man kann sich vielleicht denken, daß dies im Hinblick auf FLOSS-Packer ala UPX ein paar Probleme bereitet und darf nicht zuviel davon erwarten. Auch denke ich, daß dies mehr oder minder nur ein Symptom bekämpft (mal abgesehen davon daß es natürlich unheimlich schwer ist in mit Themida und anderen Virtualisierung benutzenden Packern gepackten Dateien etwas zuverlässig zu erkennen), statt die Ursache.

Denn was wir (ich habe ja bekanntlich auch einige private Projekte) als Entwickler wollen ist ja, daß die Anzahl der Fehlalarme reduziert wird. Leider gibt es da einen sehr unglücklichen Mechanismus bei dem die AV-Hersteller (u.a. via VirusTotal und Testern) die Samples austauschen. Wenn also Firma A die Datei X in die Erkennung aufnimmt, passiert es oft, daß Firma B sich die Datei nicht mehr sorgfältig anschaut und mehr oder minder Firma A vertraut. Das setzt sich dann so fort und so verbreitet sich eine Erkennung (ob wirklich bösartig oder Fehlalarm ist egal) innerhalb der AV-Szene. Leider gibt es keinen Mechanismus allen AV-Herstellern mitzuteilen daß eine Datei harmlos ist, um eine nochmalige Überprüfung anzustossen. Genaugenommen ist es schwer dies schon bei einzelnen AV-Herstellern zu erreichen. Umgekehrt ist es manchmal aber auch schwer zu erreichen, daß AV-Hersteller eine bösartige Datei in die Erkennung aufnehmen, wie ich bei WinDirStat erleben mußte (siehe hier und hier).

Meine private Meinung ist, daß das gesamte System kaputt ist und verschiedene Hersteller (OS, AV und andere) versuchen mit verschiedenen Methoden das Problem zu flicken ... was in einem Flickenteppich resultiert.

Übrigens gibt es, wie uns zwei der Projektverantwortlichen bei VirusBulletin 2013 vor einem Monat in Berlin berichteten, auch ein Projekt (CMX-IEEE) welches versucht die Metadaten von sauberen Programmdateien direkt von den Herstellern einzusammeln. Auf meine Nachfrage hin wie man denn überprüfe wer Dateien einreichen dürfe denen dann irgendwie vertraut würde, hieß es, daß zum Anfang ohnehin nur große Hersteller ala Microsoft, Oracle, Google und so weiter im Programm beteiligt wären. Interessant ist dies insbesondere bei Microsoft welches ja auf beiden Seiten des Zaunes steht (AV-Hersteller und "normaler" Softwarehersteller).
Nach dem Vortrag hatte ich noch die Gelegenheit Mark Kennedy direkt zu fragen und der meinte auf meine Nachfrage hin, daß für FLOSS- und Software-Kleinhersteller keinerlei Lösung von diesem System zu erwarten sei (siehe hier).

Eine Anmerkung noch zum Thema Packen von DLLs (und Dateien die nicht *.dll heißen aber dennoch faktisch DLLs sind). Bitte laßt es. Es ist hochgradig unsinnig, auch wenn unsere Systeme heutzutage immer mehr RAM zur Verfügung haben.