UPX - Wer hat aktuelle Erfahrungen damit?

[musicman56]

Hallo,

wie das Thema schon sagt, wer arbeitet aktuell damit und welche Erfahrungen wurden "langfristig" damit gemacht? Ich bin etwas skeptisch, weil ich in der Vergangenheit AsProtect eingesetzt habe, und damit seit einem Jahr nur noch Probleme mit Virenscannern habe.

Es liegt sehr wahrscheinlich daran, dass im letzten Quartal 2012 und im ersten Quartal 2013 eine Menge neuer Viren/Trojaner und sonstige Schadsoftware produziert und mit AsProtect gepackt wurde. Somit fällt ein mit AsProtect gepacktes Programm bei den meisten Scannern erst mal unter Generalverdacht. Was natürlich über Ausnahmen geregelt werden kann, doch das ist für mich keine Option oder Lösung.

Aus diesem Grund interessiert mich UPX. Die Kompressionsrate ist gut und auch sonst habe ich beim Einsatz "auf meinem Rechner" noch keine Besonderheiten feststellen können.

[DeddyH]

Nach meiner Kenntnis stehen UPX-gepackte Kompilate bei vielen Virenscannern unter Generalverdacht (zumindest war das vor einigen Jahren so).

[Union]

Ich arbeite mit PECompact. Das kostet zwar in der Vollversion, ist aber sehr gut und flexibel. Und Probleme mit Virenscanner gab es auch noch nie, obwohl die Server meiner Kunden abgesichert sind wie ein Hochsicherheitstrakt.

[Namenloser]

Ich hatte mit UPX noch nie Probleme mit Virenscannern, auch vor Jahren nicht. Inzwischen kann sowieso jeder Virenscanner UPX entpacken, von daher glaube ich nicht, dass es noch einen großen Einfluss hat. Auf der anderen Seite ist UPX aber auch völlig unnötig und verlangsamt nur die Startzeit der Anwendung. Ob eine Exe 1mb oder 10mb groß ist, ist heutzutage doch wirklich egal. Und zum Verteilen kann man auch einfach ZIP-Archive benutzen.

[Union]

Bei mir ist es wichtig, da ich teilweise manuelle Push-Installationen über remote machen muß. Und wenn ich dann bei einem Update 1/2 Tag sparen kann und schneller bin - warum nicht.

[Back2Code]

UPX ist scheiße denn:

Why not use an EXE compressor?

Some have asked why I made StripReloc when there are EXE compression programs such as ASPack and UPX that will trim more bytes off of executables than StripReloc ever could.

The reason is there are downsides to using EXE compressors. Most notably:

Upon startup of a compressed EXE/DLL, all of the code is decompressed from the disk image into memory in one pass, which can cause disk thrashing if the system is low on memory and is forced to access the swap file. In contrast, with uncompressed EXE/DLLs, the OS allocates memory for code pages on demand (i.e. when they are executed).
Multiple instances of a compressed EXE/DLL create multiple instances of the code in memory. If you have a compressed EXE that contains 1 MB of code (before compression) and the user starts 5 instances of it, approximately 4 MB of memory is wasted. Likewise, if you have a DLL that is 1 MB and it is used by 5 running applications, approximately 4 MB of memory is wasted. With uncompressed EXE/DLLs, code is only stored in memory once and is shared between instances.
Some older virus scanners flag compressed EXE/DLLs as being virus-infected. (This is this reason I stopped compressing Inno Setup's EXEs.)
Update: In fairness, this was written several years ago. This very well may no longer be an issue today.

Das einzig wahre ist StripReloc...

http://www.jrsoftware.org/striprlc.php

[jaenicke]

Zitat:

Zitat von Union (Beitrag 1234945)

Bei mir ist es wichtig, da ich teilweise manuelle Push-Installationen über remote machen muß. Und wenn ich dann bei einem Update 1/2 Tag sparen kann und schneller bin - warum nicht.

Da die Komprimierung mit 7zip stärker ist, kannst du nicht schneller sein als wenn du die Exe damit komprimierst bevor du sie verschickst.

Sowohl mit ASPack als auch mit UPX haben insbesondere Antivir und AVG Probleme was die Fehlerkennung angeht. Norton bei mir privat zwar nicht, nutzen tue ich das dennoch nicht.

[Union]

Und wie packe ich das auf dem Zielsystem aus wenn dort kein ZIP drauf ist?

[Daniel]

Manchmal kommt es ja auch noch auf die User an - eine mit UPX gepackte Datei starten sie wie eine normale EXE.

Das größte Risiko sehe ich in Virenscanner - doch wenn sich diese mittlerweile an UPX angepasst haben sollten, dann leg' los. Der Hinweis auf den größeren Speicherverbrauch ist richtig - aber wird nur dann relevant, wenn Deine Anwendung entweder viel Speicher benötigt oder viele Instanzen gleichweit laufen. Ansonsten sind 4 MB RAM hin oder her heute doch weitgehend irrelevant.

Interessant noch die Frage, ob Deine Anwendung größere Ressourcen einbindet: Windows lädt nämlich nur die Teile einer EXE, die auch benötigt werden. Hast Du eine EXE, die aus 1 MB Code und 99 MB an Bitmaps besteht, dann lädt Windows erstmal nur das eine MB und den Rest nach Bedarf. Packst Du Deine Anwendung, nimmst Du Windows diese Möglichkeit und Deine Anwendung wird komplett in den Speicher geladen. In vielen Fällen mag das nicht auffallen, aber wissen sollte man es.

[EWeiss]

Ich hatte noch nie Probleme irgendwelcher art mit UPX und ich packe seit Jahren meine Dateien damit.
Meinen Mediaplayer von 14.8 auf 9.3 MB.

Zitat:

Packst Du Deine Anwendung, nimmst Du Windows diese Möglichkeit und Deine Anwendung wird komplett in den Speicher geladen. In vielen Fällen mag das nicht auffallen, aber wissen sollte man es.

Hatte aber bisher nicht wirklich irgendeinen Einfluss auf meine Anwendung selbst.

gruss

[Lemmy]

Zitat:

Zitat von Union (Beitrag 1234952)

Und wie packe ich das auf dem Zielsystem aus wenn dort kein ZIP drauf ist?

das ist jetzt nicht dein ernst? Ein eigener kleiner Entpacker mit der 7za.dll sollte für unter 1 MByte locker zu machen sein. der ist außerdem nur einmal zu übertragen, d.h. das fällt definitiv nicht ins Gewicht.

Zitat:

Zitat von Daniel (Beitrag 1234955)

In vielen Fällen mag das nicht auffallen, aber wissen sollte man es.

Danke für diese Info!

[Bernhard Geyer]

Wieso tut man sich in 2013 noch so ein Supportquelle an. Die paar MB die mehr auf HD verbraucht werden sind verglichen mit nur eine False-Positive durch einen Virenscanner zu vernachlässigen.

[Namenloser]

Zitat:

Zitat von Lemmy (Beitrag 1234957)

Zitat:

Zitat von Union (Beitrag 1234952)

Und wie packe ich das auf dem Zielsystem aus wenn dort kein ZIP drauf ist?

das ist jetzt nicht dein ernst? Ein eigener kleiner Entpacker mit der 7za.dll sollte für unter 1 MByte locker zu machen sein. der ist außerdem nur einmal zu übertragen, d.h. das fällt definitiv nicht ins Gewicht.

Wozu das Rad neu erfinden, es gibt bereits eine Kommandozeilenversion von 7zip. Darüber hinaus kann 7zip auch selbstentpackende Archive (also Exen) erstellen.

[Lemmy]

Zitat:

Zitat von Namenloser (Beitrag 1234963)

Wozu das Rad neu erfinden, es gibt bereits eine Kommandozeilenversion von 7zip. Darüber hinaus kann 7zip auch selbstentpackende Archive (also Exen) erstellen.

ist definitiv heute nicht mein Tag.. in meiner ersten Version (nicht zitierfähig) war das selbstextrahierende Teil noch drin....

cu

[musicman56]

Hallo zusammen,

zuerst mal, ich wollte keine Diskussion über das für und wider von Exe-Packern entfachen. Der Grund warum ich früher AsProtect eingesetzt habe, ist die Ressourcenverschlüsselung. Das Packen der Exe (also die kleinere Dateigröße) war also nicht das Hauptkriterium, sondern der Ressourcenschutz. Aber da scheint es neben AsProtect nicht viel Gutes zu geben. Die Kosten sind dabei für mich nebensächlich, solange es im dreistelligen Bereich bleibt.

Ich möchte mir nur ungern eine - so wie Bernhard treffend schreibt - zusätzliche Supportquelle schaffen. Und da war AsProtect nie ein auffälliges Thema.

Jetzt komme ich zwar vom eigentlichen Thema ab, aber wie schützt ihr denn eure Echsen vor "primitivem" Ressourcenklau? Mir ist schon klar, dass es keinen sicheren Schutz gibt, aber ein bischen was muss/sollte man doch tun.

Seit ich AsProtect nicht megr verwende habe ich irgendwie ein mulmiges Gefühl, obwohl ich natürlich in den exe'n gespeicherte wichtige Daten (z.B. Zugangsdaten zum Update-FTP-Server, Passwörter, Passworthashes usw.) verschlüsselt speichere.

[Furtbichler]

Zitat:

Zitat von musicman56 (Beitrag 1234966)

...wie schützt ihr denn eure Echsen vor "primitivem" Ressourcenklau?

Ganz einfach: Ich habe keine schützenswerten Ressourcen in der EXE. Icons sind frei oder so trivial, das man die ruhig kopieren kann und sonst ist da nix drin.

[Namenloser]

Exe-Packer helfen gegen Ressourcenklau sowieso nicht. Es ist ein leichtes, das entpackte Image aus dem RAM auszulesen (geht z.B. mit HxD). Bei Exe-Cryptern ist es ggf. anders, wenn diese extra darauf ausgelegt sind, sowas zu verhindern, aber da beschweren sich die Virenscanner dann meiner Meinung nach auch zu recht.

[Zacherl]

Zitat:

Zitat von musicman56 (Beitrag 1234966)

Seit ich AsProtect nicht megr verwende habe ich irgendwie ein mulmiges Gefühl, obwohl ich natürlich in den exe'n gespeicherte wichtige Daten (z.B. Zugangsdaten zum Update-FTP-Server, Passwörter, Passworthashes usw.) verschlüsselt speichere.

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases? :shock: Da hilft dir weder ASProtect oder noch schwereres Geschütz wie VMProtect. Ebenso unnütz ist die Verschlüsselung, da sich der Schlüssel ja wohl oder übel auch im Code befindet.

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1234940)

Nach meiner Kenntnis stehen UPX-gepackte Kompilate bei vielen Virenscannern unter Generalverdacht (zumindest war das vor einigen Jahren so).

Sollte eigentlich nicht so sein, denn fast alle Virenscanne kennen UPX und Co.
Die entpacken sich dann diese Dateien, genauso wie ZIPs und schauen sich dann auch noch den Inhalt an.

Was quasi unter Generalverdacht steht, daß sind anders gepackte Dateien, bzw. manipulierte UPX-Dateien, welche von dem "Standard"-UPX nicht entpackt werden können.

Zitat:

Zitat von Zacherl (Beitrag 1234969)

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases?

Wenn man den FTP-Zuganng entsprechend schützt, also z.B. mit ReadOnly-Zugriff, dann hat man zumindestens kein Sicherheitsleck in den Server reingebaut.

Wenn das Passwort aber davor schützen soll, daß "böse" sich nicht einfach so Dateien da rausholen dürfen (z.B. um regelmäßig an eine aktuelle Raubkopie des Programmes zu kommen), dann hilft das ebenfalls recht wenig.

[musicman56]

Zitat:

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases?

Dann sag doch mal bitte, wie man es richtig macht?

[jaenicke]

Wofür braucht man für ein Update einen FTP-Zugang? Da reicht schlicht HTTP, ggf. mit Skripten (so ist es bei uns). Die Prüfung kann man dann über das Skript machen, je nachdem was du wie schützen willst. (Den Dateizugriff?)

[musicman56]

Hallo,

HTTP ist offen wie ein Scheunentor. Es gibt Leute wie mich, die müssen mit Updates Geld verdienen.

[Daniel]

Zitat:

Zitat von musicman56 (Beitrag 1235002)

HTTP ist offen wie ein Scheunentor.

Das müsstest Du - wenn Du magst - vielleicht mal näher erläutern. HTTP(S) ist alleine für sich ja nur ein Vehikel - wie man die Daten verschlüsselt und auch server-seitig mit Requests umgeht, ist doch ein ganz anderes Thema.

Und im punto Sicherheit geben sich FTP und HTTP auf unterster Ebene nicht so furchbar viel. Eigentlich gar nichts - denn bei beiden kommt es darauf an, wie man sie nutzt.

[musicman56]

Hallo Daniel,

ich dachte hier auch weniger an das "Vehikel" - also den Transporteur - sondern an die Steuerung und Kontrolle der Zugangsberechtigungen. Derzeit verwende ich noch Filezilla (teilweise mit SSL/TLS), und da kann ich halt sehr schnell und flexibel agieren und auch reagieren, weil es mein eigener WEB-Server ist. Mit einfachen Mitteln auf der Serverseite steuern, wer was darf, Zugriff hat usw. Der Client muss nur die Zugangsdaten kennen, sonst nichts. Die Rechte vergebe ich auf dem Server, und das ist der Punkt. Und wenn ein Kunde ein neues Update gekauft und bezahlt hat, dann bekommt er in seinem Akkount eine kleine Änderung und das war's dann. Mit HTTP (und Scripts) würde das wesentlich umfangreicher, komplizierter und unsicherer. Sagt zumindest mein Sicherheitsexperte. Ich kenn mich da nicht so gut aus.

Auch mit der Protokollierung und dem Logging (wer hat wann/was runtergeladen) hab ich mit FTP eine Standard-Lösung die es mir erlaubt, die Logfiles automatisiert auszuwerten und Angriffe oder nicht autorisierte Login-Versuche schnell zu erkennen. Mit HTTP wesentlich aufwändiger.

Abgesehen davon ist meine derzeit noch praktizierte FTP-Lösung in Kürze schon Schnee von gestern. Ab 2014 laufen meine Updates über eine direkte Datenbank-Anbindung an meinen Web-Server. Dann brauche ich kein "Vehikel" mehr, dann läuft es direkt über eine mit Blowfish gesicherte und verschlüsselte TCP/IP-Verbindung. Der große Bruder muss nicht alles wissen. Aber das ist jetzt endgültog OT, oder?

[Luckie]

Welche Art von Ressourcen sollen denn geschützt werden? Wenn ich eine Grafik Ressource schützen will, darf ich sie auch nicht anzeigen und dann brauche ich sie auch nicht in das Kompilat packen.

[musicman56]

Hallo Michael,

da hat du natürlich recht, bei einer Grafik macht das keinen Sinn. Wir haben ja auch von sensibleren Daten wie z.B. dem FTP-Zugang für das Online-Update gesprochen. Bleiben wir mal bei diesem Beispiel. Das FTP-Passwort muss ja irgendwann mal zur Laufzeit zugewiesen werden. Das einfachste und dümmste wäre, es gleich im Klartext in der Komponente abzulegen.

Zitat:

Zitat von Zacherl (Beitrag 1234969)

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases? :shock: Da hilft dir weder ASProtect oder noch schwereres Geschütz wie VMProtect. Ebenso unnütz ist die Verschlüsselung, da sich der Schlüssel ja wohl oder übel auch im Code befindet.

Auf meine Frage hierzu, wie man es sonst machen sollte/kann, kam leider bisher noch nichts. Wir sind uns einig, dass es keinen Schutz gibt, der nicht zu knacken ist. Es geht letztendlich nur darum, dem Angreifer das Leben ein bischen schwerer zu machen und nicht gleich das komplette Menü auf einem silbernen Tablett zu servieren. Man nimmt dem armen Hund ja sonst sein Erfolgserlebnis. :stupid:

Also speichert man das Passwort verschlüsselt. Der Schlüssel für die Verschlüsselung ist natürlich auch irgendwo gespeichert. Und vielleicht noch ein Hash zur Kontrolle. Und vielleicht noch die Exe mit UPX komprimiert, oder mit AsProtect, oder was und wie auch immer, irgendwann landet das Passwort im Klartext in der Indie-Komponente (wenn man mal im einfachsten Fall von den Indie's ausgeht).

Mit jedem popeligen Debugger also kein großes Problem. Nichts verhindert eben....nur ein bischen schwerer gemacht. Womit wir vielleicht wieder ein bischen beim Sinn und Unsinn von UPX wären.

[Back2Code]

Zitat:

Zitat von musicman56 (Beitrag 1235069)

Hallo Michael,

da hat du natürlich recht, bei einer Grafik macht das keinen Sinn. Wir haben ja auch von sensibleren Daten wie z.B. dem FTP-Zugang für das Online-Update gesprochen. Bleiben wir mal bei diesem Beispiel. Das FTP-Passwort muss ja irgendwann mal zur Laufzeit zugewiesen werden. Das einfachste und dümmste wäre, es gleich im Klartext in der Komponente abzulegen.

Zitat:

Zitat von Zacherl (Beitrag 1234969)

Du hardcodest nicht wirklich Passwörter oder FTP Zugangsdaten in deinen Releases? :shock: Da hilft dir weder ASProtect oder noch schwereres Geschütz wie VMProtect. Ebenso unnütz ist die Verschlüsselung, da sich der Schlüssel ja wohl oder übel auch im Code befindet.

Auf meine Frage hierzu, wie man es sonst machen sollte/kann, kam leider bisher noch nichts. Wir sind uns einig, dass es keinen Schutz gibt, der nicht zu knacken ist. Es geht letztendlich nur darum, dem Angreifer das Leben ein bischen schwerer zu machen und nicht gleich das komplette Menü auf einem silbernen Tablett zu servieren. Man nimmt dem armen Hund ja sonst sein Erfolgserlebnis. :stupid:

Also speichert man das Passwort verschlüsselt. Der Schlüssel für die Verschlüsselung ist natürlich auch irgendwo gespeichert. Und vielleicht noch ein Hash zur Kontrolle. Und vielleicht noch die Exe mit UPX komprimiert, oder mit AsProtect, oder was und wie auch immer, irgendwann landet das Passwort im Klartext in der Indie-Komponente (wenn man mal im einfachsten Fall von den Indie's ausgeht).

Mit jedem popeligen Debugger also kein großes Problem. Nichts verhindert eben....nur ein bischen schwerer gemacht. Womit wir vielleicht wieder ein bischen beim Sinn und Unsinn von UPX wären.

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM
- Anti Sniff
- MD5 Checksum Überprüfung
- Strings im Quelltext (Fehlermeldungen / Pfade etc verschlüsseln)

[Lemmy]

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

[musicman56]

Zitat:

Zitat von Back2Code (Beitrag 1235070)

Gibt noch weitaus mehr Maßnahmen zum Schutz.

- Anti Debugger Routinen
- Anti VM
- Anti Sniff
- MD5 Checksum Überprüfung
- Strings im Quelltext (Fehlermeldungen / Pfade etc verschlüsseln)

Absolut richtig, aber wie du schon sagst, es sind nur "Maßnahmen", also kein echter Schutz, weil es den nicht gibt :cyclops:

[Daniel]

Nun, wir sollten zur Ausgangsfrage zurück kommen. Es scheint mit UPX heute im Allgemeinen wohl eher keine Probleme mehr zu geben.
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.

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