• Skip Navigation

Blog von eddy14

Search for:

• Home
• About me
• Reverse Engineering
• Software
• Tutorials

Hackers

Eigentlich wollte ich (wie jedes Jahr) auf das heutige Opferfest eingehen. Aber statt eines Beitrages der negative Gefühle auslöst, möchte ich diesmal etwas gegenteiliges bewirken: Ich möchte mit euch einen Ausschnitt aus dem Buch “Hackers – Heroes of the computer revolution” teilen, den ich genial fand:

Hackers believe that essential lessons can be learned about the systems – about the world – from taking things apart, seeing how they work, and using this knowledge to create new and even more interesting things. They resent any person, physical barrier, or law that tries to keep them from doing this.

Na? Wer erkennt seine Handlungen da wieder?

Bin zwar noch nicht sehr weit im Buch, aber es ist definitiv lesenswert

Disgu(i)sting

Ja, ich lebe noch.

Der letzte Blogeintrag ist fast schon ein viertel Jahr her. Ich hatte leider während der Semesterferien absolut keine Zeit für meine Hobbys. Ich musste zwangsweise etwas Energie in mein Real-Life investieren, und wer will das schon, richtig? Mir hat irgendwie auch die Motivation gefehlt irgendein Verschlüsselungssystem zu erforschen.

Gehen wir einen Tage zurück: Ich hatte keinen Zugang zum Internet und so langsam sind mir die Bücher ausgegangen, und so musste ich mir anders behelfen. Klar, ich könnte rausgehen in die Natur (haha!), aber ich hatte noch in meiner VirtualBox eine Applikation die darauf gewartet hat analysiert zu werden. Also wurde ich rückfällig, und saß dann gestern Abend wieder vor dem Rechner, um etwas zu analysieren. Das heutige Target nennt sich “Disguise” (na, war der Titel von dem Blogpost nicht einfallsreich?).

Diesmal war es etwas anders. Dieses Programm setzt zwar wieder auf Security-by-obscurity, aber einen Unterschied zu meinen vorherigen Targets hat es: es ist nicht direkt gebrochen, allein wenn man den Schlüssel und den Algorithmus gefunden hat.

In diesem Fall musste ich (un?)glücklicherweise tatsächlich eine Kryptoanalyse durchführen. Es ist meine erste echte Kryptoanalyse von einem unbekannten Verfahren gewesen, und wie das Leben so spielt, war es garnicht so schwer. Ich bin quasi in das Thema hineingerutscht.

Nun, was ist denn dieses Disguise? Auf der Webseite heißt es:

I share with you, with Disguise, a SECURE dual-keys proprietary multi-stage encryption algorithm to protect your PRECIOUS DATA.

(die Hervorhebungen sind originalgetreu übernommen)

Na sieh sich das mal einer an. Klingt doch super! Wäre da nur nicht dieses kleine winzige Wort “proprietary”, gäbe es keinen Grund für mich dieses Programm zu analysieren. Denn sonst hätte ich gedacht, dass das Verfahren etwas wie AES ist. Aber so weiß ich, dass der Programmierer vermutlich einen eigenen Verschlüsselungsalgorithmus entworfen hat. Und wer schonmal einen Kryptoexperten erlebt hat, der euch förmlich anbettelt, niemals einen eigenen Verschlüsselungsalgorithmus zu entwerfen, der wird spätestens in diesem Blogeintrag erfahren wieso.

Mittlerweile scheint es mir so, als könne man schlechte Verschlüsselung bereits an der GUI des Programmes entlarven. Vielleicht erinnert sich noch jemand an das hier. Jedenfalls, ist dieses Programm genauso hässlich:

Ekelhaft. Na vielleicht tut es ja seine Arbeit gut. Nämlich: Daten sicher verschlüsseln (hey, ihr seid auf meinem Blog, was glaubt ihr?)

Vorerst machen wir eine Blackbox Analyse. Ich werde mir also vorerst nicht den Programmcode anschauen. Ich werde eine Datei einspielen, und mir das Resultat anschauen.

Ich habe also testweise eine Datei verschlüsseln wollen. Und in dem Moment hatte mich das Programm nach zwei Daten gefragt. Es wollte von mir zwei so genannte “Signaturen” haben. Im Prinzip meint der damit nur ein Passwort. Ich sollte also zwei Passwörter eingeben. Allerdings durften diese nicht länger als 8 Zeichen sein. 8 Bytes? Das sind nur 64 Bit für einen Schlüssel. Allerdings will er zwei mal 8 Bytes. Wer weiß, was er mit diesen Passwörtern genau tut ?!

Ich werde im Laufe dieses Blogeintrages folgenden Plaintext als Eingabedatei “god.txt” verwenden (damit hier einige nicht rumheulen: es ist tatsächlich die erste txt Datei auf meinem Rechner, die mir unter die Finger kam; es hat keine weitere Bedeutung):

Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?

Nach der Verschlüsselung hatte ich eine Datei “goddis.txt”, mit dem Inhalt:

Na das sieht doch ziemlich verschlüsselt aus. Was mir als erstes aufgefallen ist: die Ausgabedatei ist um 33 Bytes größer als das Original. Was hat der Algo da bloß getan? Beim Versuch andere Dateien zu verschlüsseln, ist jedesmal die Ausgabedatei um 33 Bytes größer.

Ich mache jetzt etwas ganz simples. Ich werde die Ausgabe Datei goddis.txt mal nach der statistischen Häufigkeit der Bytes untersuchen. Da bietet mir mein Hexeditor HxD eine passende Funktionalität. Die Ausgabe sieht so aus:

Es gibt da nicht viel zu sehen. Man erkennt bloß, dass einige Bytes garnicht vorkommen, wohingegen die letzten Bytes (0xF4 bis 0xF7) verglichen mit den anderen Bytes, ziemlich oft in der verschlüsselten Datei auftauchen. 0xF7 taucht sogar ganze 17 mal auf (das sind 6,32% der ganzen Datei).

Schauen wir uns das Resultat der Verschlüsselung von standardisierten Verschlüsselungsalgorithmen an. Hier in dem Fall ist es AES:

Die statistische Verteilung der Bytes sieht schon ziemlich zufällig aus. Das Byte 0×35 kommt hier am häufigsten vor, mit genau 6 Auftritten (das sind 2,49% der Datei). Zum Vergleich schauen wir uns noch eine rein zufällige generierte Datei an:

Es gibt in diesem Fall mehrere Bytes die das Maximum darstellen. Sie tauchen genau 4 mal auf, und machen damit 1,66% der Datei aus.

Verglichen damit steht Disguise sehr doof da. Es gibt einem das Gefühl, dass die Ausgabe nicht wirklich durchgewürfelt ist; und vielleicht haben wir sogar eine Möglichkeit, den Algorithmus zu brechen.

Genug Blackbox Analyse. Wir öffnen das Programm mit unserem Lieblingsdisassembler/debugger und schauen uns an, was das Programm tut. Da ich in diesem Beitrag mehr auf die Analyse des Verfahrens eingehen möchte, und nicht schon wieder auf das Reverse Engineering (dazu schaut ihr lieber hier nach), werde ich kurz beschreiben was ich alles über den Algorithmus herausgefunden habe:

Es gibt eine erste Runde die ich “Phase 1″ getauft habe. In dieser Phase wird ein “Pseudo”-Ciphertext generiert, der einfach wieder zurück zum Ursprungszustand versetzt werden kann. Danach folgt die Phase 2, wo dann die zweite Signatur angewendet wird, um es zu verschlüsseln. Und dann haben wir unsere verschlüsselte Datei.

Ein etwas tieferer Einblick: Zuerst wird aus der Signatur 1 (hier der Einfachheit zur Liebe: “sign123″) etwas generiert, was ich sig1c nenne. Dabei wird folgendermaßen vorgegangen: Wir lesen das aktuelle Byte aus (hier “s” = 0×73). Dieser wird reversed zu 0×37. Nun führt man eine OR-Verknüpfung mit dem Wert 0×08 durch (= 0x3F) und negiert anschließend das Ganze (= 0xC0). Das macht man mit allen Bytes der Signatur. Alles hinter der Signatur ist 0×00. Diese pseudo-Verschlüsselung wird genau 31 mal angewandt. Nun wird ein 0×00 Byte angeschlossen und dahinter wird ein konstanter Wert “03″ hinzugefügt. Das sind insgesamt 33 Bytes, welcher der Verschlüsselten Datei vorne angehangen werden (das erklärt schonmal dieses Mysterium!).

Aber mooooment. Ich sagte gerade, dass hinter dem sign123 nur noch 0×00 Bytes folgen. Wenn man genau dieses Verfahren auf 0×00 anwendet, dann kommt stets 0xF7 heraus. Das könnte eventuell die statistische Häufigkeit der 0xF7 in der Ausgabe Datei erklären.

Das erzeugte sig1c sieht nun so aus: C0 61 81 11 E4 D4 C4 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 F7 00 03

Das ist der Header, der jeder verschlüsselten Datei hinzugefügt wird (wobei die ersten 7 Bytes variieren, aufgrund der ersten Signatur; der Rest ist stets gleich!).

Der eine oder andere fragt sich nun: Wieso ist die Signatur nur 7 Bytes lang, obwohl das Programm 8 Zeichen haben will? Ich weiß nicht ob das so gewollt ist, aber das Programm liest nur 7 Bytes, und reserviert das 8te für das 0×00 Byte, um den String abzuschließen. Obwohl das total überflüssig ist. Wie wir nachher sehen werden, hat dieser kleine “Bug” mir Tür und Tor geöffnet.

Dieses sig1c-Verfahren wird auf die ganze Plaintext-Datei angewandt. Nun haben wir diesen Pseudo-Ciphertext, der wieder zurück zum Urprungszustand versetzt werden kann (es ist reversible/umkehrbar).

Auf diesen Zustand wird nun die Phase 2 angewandt. Dieser geht wie folgt:

Die Datei wird in 8-Byte Schritten eingelesen. Nun wird mit jedem Byte dessen mit dem aktuellen Byte der zweiten Signatur XOR verknüpft. (Bedenke: das letzte Byte der zweiten Signatur ist auch 0×00! Einfachheitshalber ist meine zweite Signatur “ABCDEFG”).

Beispiel von oben: Das erste Byte war 0xC0. Dieser wird mit 0×41 (“A”) geXORed. Es ergibt 0×81. Das Ergebnis des ersten Durchlaufes ist: 81 23 C2 55 A1 92 83 F7.

Nach jedem Durchlauf der 8 Byte, wird ein “shuffle” durchgeführt. Die Signatur2 wird verwürfelt. Allerdings hat sich der Programmierer hier sehr dumm angestellt (aber er hat anscheinend Ideen in die richtige Richtung gehabt!): Die Verwürfelung der Signatur ist nicht ständig das selbe. Es gibt 5 verschiedene Funktionen. Ein Counter wird jeweils modulo 5 geteilt, und jenachdem wird die jeweilige Funktion aufgerufen. Der Counter wird anfangs auf das 4te Byte des sig1c gesetzt (hier: 0×11 = 17).

17 modulo 5 ergibt 2. Es wird also die zweite Funktion zum shufflen der Signatur aufgerufen. Diese Funktion sieht in C so aus:

unsigned char op_value = signature2[3];
int i;
for(i = 0; i < 8; i++)
{
signature2[i] = signature2[i] ^ op_value;
}

es wird das 4te Byte der Signatur ausgelesen, und für die nachfolgenden Operationen verwendet. Nun wird jeder Wert der Signatur mit diesem Wert geXORed.

Das heißt quasi: Unsere aktuelle Signatur2 ist 41 42 43 44 45 46 47 00. Das dick markierte ist unser op_value. Zuerst XORed er also 0×41 mit 0×44. Dann 0×42 mit 0×44 usw. Irgendwann ist er aber bei sich selbst, er XORed also 0×44 mit 0×44. Wie jeder wissen sollte, ergibt das zwangsläufig immer 0×00. Das ist sehr fatal, wenn dieser Wert später in der Verschlüsselung Verwendung finden soll! Nach dem Shuffle haben wir eine Signatur2 die wie folgt aussieht: 05 06 07 00 01 02 03 44

Beachte: das letzte Byte ist 0×44, da hier 0×00 mit 0×44 geXORed wurde.

Nun, das ist der ganze Algorithmus. Nun machen wir uns daran, den Algorithmus anzugreiffen!

Wenn wir genau nachdenken, dann baut die Verschlüsselung darauf auf, dass der Pseudo-Ciphertext jeweils mit der zweiten Signatur XOR-verknüpft wird. Allerdings haben wir gerade gesehen, dass die zweite Signatur zwangsweise irgendwo eine 0×00 enthält. Irgendein Wert mit 0×00 geXORed ergibt wieder den Wert. Es passiert also nichts. Das heißt im Klartext: Ein Byte wird in dem Ursprungsformat bleiben, und nicht verändert.

Wenn ich mir jetzt in der fertig verschlüsselten Datei goddis.txt den nächsten 8-Byte Block anschaue, sehe ich das hier:

F2 F1 F0 F7 F6 F5 F4 B3

Wir erinnern uns, der Header bestand im zweiten Block nur aus 0xF7. Hier eine kleine bildliche Erläuterung:

Und da es ein XOR Verfahren ist, könnten die Pfeile auch eine Spitze auf beide Seiten haben. Denn ich kann auch Rückwärts von 81 durch XORen mit 0×41 wieder 0xC0 erhalten.

Ich sehe hier, dass beim XORen des zweiten Blockes, ein Fehler entsteht. Und zwar bleibt der 0xF7 bestehen, wie bereits erwähnt. Wenn wir nun die Ausgabe-Bytes (also F2 F1 F0 F7 F6 F5 F4 B3) wiederum mit 0xF7 alle XORen, haben wir die aktuelle Signatur2 (nämlich 05 06 07 00 01 02 03 44) errechnet. Aufgrund des 0×00 Byte-Bugs am Ende der Signatur, haben wir hier 0×44 (“D”) am Ende hängen. Wir wissen also, mit welchem Wert die Signatur geshuffled wurde. Wenn wir also alle signatur Bytes wieder mit 0×44 XORen, erhalten wir “ABCDEFG”. Tada!

Wir haben den zweiten Signatur-Key errechnet, dank der unzähligen Bugs im Algorithmus. Das hier vorgestellte Verfahren würde wohl in die Kategorie “Known Plaintext” fallen (beispielsweise wurde WEP dadurch gebrochen). Da wir in diesem Fall wissen, wie der Plaintext (hier eher Pseudo-Ciphertext) im Header aussieht (nämlich fast nur 0xF7er Bytes), können wir in jedem Fall den zweiten Signatur Key errechnen. Zur verdeutlichung:

Und mit diesem Key können wir nun sig1 entschlüsseln.

Wir haben allerdings ein Problem. Beim shufflen wird nicht immer XOR verwendet. Wir erinnern uns: es gibt 5 verschiedene Funktionen, um die Signatur zu shufflen. Eine davon verwendet ein “AND” zum verknüpfen, ein anderer ein “OR”.

Nehmen wir an, es wurde ein OR verwendet. Ich schaue mir diese shuffle Funktion an. Und als Operator wird das letzte Byte der Signatur verwendet. Allerdings ist das letzte Byte ja immer 0×00! D.h., beim shufflen werden alle Bytes der signatur mit 0×00 geORed. Das Resultat: es verändert sich nichts an der Signatur! Der nachfolgende 0xF7er Block wird mit der Original Signatur verschlüsselt. Wir XORen also wieder den Ciphertext mit 0xF7, und erhalten unsere original Signatur2. Das ist wieder ein trivialer Bug!

Anders sieht es aus, wenn “AND” zum shufflen benutzt wurde. Die passende Funktion dazu benutzt das 5te Byte der Signatur zum shufflen. Dieser könnte alles mögliche sein (alle printable ASCII Zeichen). Doch nicht verzagen, eddy fragen!

Bei einem AND können wir also nicht mit einer so einfachen Möglichkeit die Signatur2 errechnen. Aber wir können die aktuelle geshufflete Signatur für den 0xF7er Block errechnen, indem wir wieder diesen Ciphertext mit 0xF7 XORen. Und mit diesem Key rechnen wir ganz normal weiter.

Man sieht zwar noch meine Debug-Ausgaben, aber ich denke es ist ersichtlich, dass dieses Programm eine verschlüsselte Datei brechen kann, ohne zusätzliche Informationen, nur allein die verschlüsselte Datei! Wie toll ist das bitte? Hier der C-Quelltext (Bitte bitte entschuldigt den dreckigen Code! Es ist sehr schwer zu coden, und nebenbei die Analyse zu betreiben): disdis.c (hab jetzt absolut keine Lust die ganzen Debug Informationen zu entfernen…).

In diesem Blogpost liest man viele verschiedene Werte, und ich bin mir sicher, dass die meisten dem nicht folgen konnten und einfach nur verwirrt waren. Ich werde versuchen dazu ein paar Bilder mehr zu basteln (eventuell sogar eine Flash Animation?).

Wie auch immer; ich bin froh, denn: Der Verschlüsselungsalgorithmus ist gebrochen!

HaxoGreen 2010

Vor einigen Wochen hatte ich ein paar Freunde, die ich aus dem Internet kenne, mal im Real-Life getroffen. Und wir hatten auch zusammen etwas gehackt. Es hatte wahnsinnig Spaß gemacht, die Leute zu treffen, die man sonst nur im IM antrifft. Und lustigerweise reden diese Personen genauso wie im IRC, mit all den Abkürzungen, und ab und an hört man sogar Leetspeak. Ich nenne diese Leute “die Illuminaten”, weil sie alles unter ihre Kontrolle reißen können. Ich war beeindruckt zu erfahren, hinter wie vielen Hacking-Aktionen diese Leute standen, von denen ich in den letzten Jahren gehört hatte. Und niemand weiß weder wer sie sind, noch dass sie dahinter gesteckt haben. Genug über die leetesten h4x0rs die ich bisher kennen gelernt habe. Nun etwas anderes:

Ich bin vor ein paar Stunden von einem Hacker Camp zurück gekehrt: dem HaxoGreen in Luxemburg. Dort habe ich mit den oben genannten Personen 5 Tage verbracht. Hat ziemlich viel Spaß gemacht (mal abgesehen davon dass es schwierig für mich war, dort was essbares zu finden). Ich war noch nie bei irgendeiner Veranstaltung, wo es zahlreiche Hacker gibt. Und wie nicht anders zu erwarten war, hat mich kabel mit seinen Social Engineering Skills überzeugt, einen Talk zu halten. There you go: http://events.hackerspace.lu/camp/2010/schedule/events/30.en.html. In dem Vortrag ging es um das eigentliche Thema hier auf dem Blog (neben den zahlreichen Emo-Beiträgen): Security through Obscurity. Eine kleine Einführung in Reverse Engineering. Und als Beispiel dann meine Vorgehensweise um OTRKEY zu analysieren. Es war nunmal der aufwendigste, welches nicht in 5 Minuten erklärt ist (sonst hätte ich lieber SFT erklärt).

Zu meinem Talk gibt es keine Aufnahmen die ihr euch ansehen könnt (sorry!). Man hat mir gesagt, dass mein Vortrag ganz okay war. Meine Behauptung, dass ich irgendeinen peinlichen Fehler mache, hat sich zum Glück als leere Behauptung herausgestellt

Aber was mich eigentlich am meisten freut: Ich habe nun eine eigene Top-Level-Domain!

www.41yd.de

Für alle die den Namen nicht verstehen: Es ist “eddy14″ rückwärts (reversed! Wenn ihr versteht …)

Nun denn. Ihr solltet von nun an diese Domain benutzen Ich kuschel mich jetzt in mein warmes Bettlein. Viel besser als ein Zelt *froh ist*

Löcher im Sieb

Lange ist es her, dass ich mich mit PHP Scripten beschäftigt habe. Aber gestern hatte ich Grund dazu.

Wenn ich nicht gerade dabei bin für die Prüfungen zu lernen, oder mich mit logischen Fehlschlüssen beschäftige, bin ich seit gestern zusätzlich am Reversen von Zend Optimizer. Ich will wissen, wie der Schutz (unter anderem die Verschlüsselung) funktioniert. (Anmerkung: Der Schutz von Zend Guard bewirkt, dass man die PHP Dateien nicht mehr einfach einsehen kann, da diese durch ein unbekanntes Verfahren geschützt, verschlüsselt und komprimiert sind. Der Zend Optimizer kann diese verkrüppelten Dateien ausführen). Zum Analysieren der Software brauchte ich eine Beispieldatei, welches mit Zend Guard geschützt ist. Ich nahm Schulfilter Plus. Obwohl ich eigentlich den Zend Optimizer selbst analysieren wollte, und nicht die Beispiel Datei, zog etwas merkwürdiges meine Aufmerksamkeit auf sich. Wenn ich Schulfilter Plus im Browser ausführte, erreichte mich eine Fehlermeldung:

Call to undefined function: mcrypt_get_iv_size()

Anscheinend hatte dieses Stück Software eine Anwendung für Verschlüsselung gefunden. Ist das nicht toll? Diese, eigentlich ungewollte, Entdeckung bescherte mir ein paar Stunden Spaß. Dem wäre nicht so, wenn die PHP Datei lesbaren Code beinhaltet hätte; da wäre alles sofort ersichtlich. Der Zend Guard machte es spannend!

Die Fehlermeldung tauchte nur auf, weil ich mcrypt nicht installiert hatte. (Normalerweise installiert man Schulfilter Plus mit einer .iso Datei, welches Apache, PHP, libmcrypt und alles drum und dran mitinstalliert. Die Installation ist in der VM immer abgestürzt, deswegen habe ich die PHP Dateien in eine bestehende Apache Installation kopiert. Und da hat nunmal mcrypt gefehlt! Welch ein Glück.)

Mcrypt ist einigen PHP Entwicklern bekannt: es bietet uns einfache Schnittstellen um gängige Verschlüsselungsalgorithmen (u.a. DES, AES, Blowfish,…) anzuwenden. Normalerweise hätte ich mir gedacht: Wow, da legt jemand sehr großen Wert auf Datensicherheit! Und ich hätte mich gefreut. Aber kurz zuvor hatte mir Lemming von einem sehr peinlichen Bug in der Schulfilter Plus Software erzählt, sodass ich nun bereit war alles mögliche von den Entwicklern zu erwarten. Wofür wurde hier die Verschlüsselung verwendet? Um die tatsächliche Wirkung zu entfalten, nämlich Daten sicher aufzubewahren, oder doch nur, um gewisse Daten und Vorgehensweisen zu verbergen/verschleiern?

Und da ich dieses Posting verfasse, könnt ihr euch denken, dass es letzteres war. Ich habe mir kurz nach diesen Gedanken mcrypt installiert. Für Windows ist es eine einfache DLL Datei. Diese exportiert alle benötigten Funktionen, damit der PHP Interpreter sie nutzen kann.

Nun könnte ich theoretisch folgendes machen: Da libmcrypt selbst open-source ist, könnte ich mir den Code besorgen, vor jeden Aufruf einer Funktion ein printf machen, neu compilen, und mir ausgeben lassen welche Funktion mit welchen Argumenten aufgerufen wird. Nun lass ich die Schulfilter Software laufen; so hätte ich eine nette Ausgabe, und wüsste, welcher Key verwendet wird, welcher Algorithmus etc. (das gleiche kann ich theoretisch auch mit dem PHP-Interpreter machen, um Zend Guard zu umgehen, dazu aber irgendwann in einem späteren Posting mehr).

Aber ich wollte es mir nicht so einfach machen. Ich hatte Lust auf Assembler. Also blieb ich weiterhin in meinem Debugger OllyDbg.

Ich lud mir php-cgi.exe in den Debugger, und führte es aus, bis alle wichtigen Bibliotheken geladen waren. Nun wechselte ich die Ansicht auf mcrypt, und ließ mir die angebotenen Funktionen ausgeben:

Wie man sieht, habe ich schnell ein paar Breakpoints gesetzt. Das wichtigste hier ist mcrypt_enc_get_iv_size. Dort müsste ich ja anhalten wenn ich die Software ausführe (denn aus der Fehlermeldung kann ich darauf schließen, dass diese Funktion aufgerufen wird).

Allerdings gibt es noch andere sehr schöne Funktionsnamen wie z.b. mcrypt_set_key. Diese Funktion wird sehr wahrscheinlich aufgerufen, wenn das Passwort für Ver-/Entschlüsselung gesetzt werden soll. Wenn ich nur einmal auf dieser Funktion breake, müsste ich die Möglichkeit haben die Parameter einzusehen. Dann bräuchte ich nur noch den Namen des Algorithmus um die Verschlüsselung nachzubauen.

Ich trace ein bisschen im Code rum; da ich Zend Optimizer noch nicht genug analysiert habe, ist das alles schwer nachzuvollziehen. Aber irgendwann sehe ich dann folgendes im Stack:

0012F834   01858FA0  ASCII “rijndael-128″
0012F838   00000000
0012F83C   0182A228  ASCII “ecb”

Na das sieht doch sehr nach Rijndael aus, im ECB modus. Also gehe ich zurück zu den exportierten Funktionen, und setze überall breakpoints, die was mit Rijndael zu tun haben:

Nun sollte ich immer benachrichtigt werden, wenn die Software etwas mit diesen Funktionen anstellt. Und das tut sie wirklich: “Breakpoint at libmcryp.rijndael_128_LTX__mcrypt_set_key”. Irgendwo müssen die Parameter für diese Funktion rumliegen, und ich bin optimistisch dass es der Key sein wird! Tada:

Ausgeschrieben: “fhslJefRe12jadf45HSDd54kad4fk2dA“. Das ist der Schlüssel für die Verschlüsselung. Es gilt noch herauszufinden, ob es immer der selbe ist (davon kann man sich überzeugen indem man die Daten von verschiedenen Ausführungen, und Installationen von Schulfilter Plus in den Debugger schmeisst). Um es vorweg zu nehmen: ja, es ist immer der selbe Schlüssel.

Irgendwann komme ich in die decrypt Prozedur, und sehe, wie Daten entschlüsselt werden. Live! Das ist ein sehr schöner Augenblick <3

Ich weiß also nun, dass Rijndael-128 verwendet wird, mit dem oben genannten Schlüssel. Nun muss ich gucken, für welche verschlüsselten Daten es überhaupt gebraucht wird. Ich suche in der Ordnerstruktur der Software nach irgendwelchen Dateien die verschlüsselt aussehen. Und tatsächlich: Im Unterordner “xml” befindet sich eine Datei mit dem Namen “systemusers.xml”. Der Name ist vielversprechend.

Haben die Entwickler etwa alle User-Daten in dieser Datei gespeichert? Das wäre sehr gefährlich, denn die XML Dateien sind für jedermann zugänglich! (Wieso zum Teufel programmiert irgendjemand so etwas? Ich könnte ausrasten). Nur die (wie wir noch sehen werden: unsichere) Anwendung von Verschlüsselung hält uns davon ab, die Daten einzusehen.

Ich schreibe eine kleines Python Script, welches das Verschlüsselungsverfahren anwendet, um die Daten zu entschlüsseln: Und tatsächlich, ich sehe am Ende die XML Datei. Erschreckender Fund darin:

<user xml:id=”user1″ role=”role1″ added_by=”cockpit”>
<name>tfkadmin</name>
<password>263aa25bd34cc2fbe24b70ba46e41fe0</password>
<dn/>
</user>

Es sind die Login Daten für den Administrator. Das Passwort ist einfaches MD5. Und sowas kann jeder von jedem Server runterladen, welches diese Software einsetzt? Mir ist es schleierhaft, wieso die Entwickler sowas tun. Entweder sie wissen es nicht besser, oder sie halten sich einen eigenen Zugang offen (böse Vorwürfe meinerseits!). Vieles in der Software ist auf diese Weise (mit dem gleichen festen Schlüssel) verschlüsselt. Auch die Backup-Datei (Nebenbei angemerkt: Die Backup-Datei ist eigentlich nur eine PHP Datei, mit verschlüsselten Strings. Sehr schlampig…). Die ganze Sicherheit geht zugrunde, wenn jemand diesen privaten Schlüssel der Entwickler hat (der Schlüssel wird jedem Kunden in der Software mitgeliefert!). Die gehen echt ein großes Risiko ein. Das sind echte Kerle mit Eiern in der Hose, sage ich euch!

Ich hoffe es wird so langsam jedem klar, dass eine Tarnung (wie durch den Zend Guard) nicht sehr viel bringt, wenn man vor dem Erforscher des Systems etwas verheimlichen will. Ich gehe sogar soweit zu behaupten, dass die unsichere Programmierarbeit bekannt war; ich denke, dass mit dieser Verschleierung versucht wurde, sich einen eigenen Zugang offen zu halten. Ich denke nicht, dass die Leute versucht haben ihr geistiges Eigentum zu schützen. Jeder der den Code einsehen könnte, würde es strikt ablehnen, so ein Scheunentor auf seinem Server zu installieren. Wieviele gravierende Bugs und Geheimnisse findet man erst, wenn man die Scripte einsehen könnte?

In der oben genannten systemusers.xml ist ein weiterer User aufgelistet. Der Benutzername ist “tfksupport” und das Passwort ist anscheinend nur den Entwicklern bekannt. Dieser User ist auch auf invisible gesetzt, sodass man ihn (sogar als Administrator) nicht verwalten kann. Auch wenn dieser User in dem Handbuch Erwähnung findet, und es tatsächlich für den Support zu sein scheint, macht das einen stutzig. Man will doch trotzdem die volle Kontrolle über die Maschine haben!

Der Vorteil eines PHP Codes ist es ja, dass es auf einem (entfernten) Server läuft. So lange man also den Server nicht hacked (durch eine Sicherheitslücke etc.), hätte man theoretisch keine Möglichkeit, irgendwelche Daten zu kopieren, manipulieren etc. Aber die Entwickler haben sich echt komisch angestellt; sie stellen die Daten frei zugänglich ins Netz, und versuchen den Inhalt zu verschleiern, anstatt einfach den Zugriff zu den Daten zu verweigern. (Siehe: Security through Obscurity)

(20:36:48) eddy14: das ist echt so lächerlich von denen, sowas verstecken zu wollen
(20:37:07) lemming: evtl arbeiten die mit otr zusammen ^^
(20:37:12) eddy14: haha

Wie gefährlich so eine Burka für Software ist, sieht man an dieser Äußerung: “Nachdem in Bayern bereits 1500 von 5500 Schulen mit dem Jugendschutzpaket der TIME for kids Foundation einen wirksamen Schulfilter einsetzen, soll nun Bayern zum Musterland für Kinder- und Jugendschutz im Internet werden.”. Schützt die Kinder, aber bitte richtig!

Anfangs wollte ich die Entwickler über diesen Missstand informieren, bevor ich diesen Beitrag veröffentliche. Aber ich denke, diese Leute haben sehr fahrlässig gehandelt. Sehr viele Schulen verwenden diese Software. With great power comes great responsibility.

Ich bin verliebt

Seit Tagen fühle ich mich großartig. Wenn ich morgens aufwache, und die Augen öffne, fange ich sanft an zu lächeln. Ich fühle mich toll. Oft liege ich einfach nur da, und lächle die Wand an.

Kurz darauf setze ich schöne Musik auf, die mich noch glücklicher macht. Ich stehe auf und fange an wilde Bewegungen mit meinem Armen zu machen. Ich spiele Luftgitarre; oder ein anderes Instrument das gerade auf die Musik passt. Es fühlt sich großartig an. Das Leben fühlt sich großartig an.

Ich bin verliebt.

Und auch wenn ich euch jetzt in die irre geleitet habe; es geht hier um keine Frau. Ich habe mich in die Wissenschaft verliebt. Ich liebe Darwin, ich liebe Einstein, ich liebe Newton, ich liebe Feynman, ich liebe Dawkins.

Es erfüllt mich plötzlich mit solch einer großen Freude, mir einfach nur die Welt anzuschauen und darüber nachzudenken, wie genial es ist, dass mich überall Atome umgeben. Ich schaue mir die unzähligen Tiere an und ich bin fasziniert von der Tatsache, dass sich alle entwickelt haben. Nachts schaue ich mir die Sterne an, und mir gefällt der Gedanke, dass ich mit wissenschaftlichen Methoden hier aus der Erde, aus meinem Kopf heraus, verstehen könnte, wie das alles funktioniert. Mit Stift und Papier.

Die Welt ist so wunderschön, wenn man annimmt, dass es keine Magie gibt, keine Wunder, keine göttlichen Eingriffe.

Meine Gedanken fühlen sich gerade wirklich frei an. Ich habe so ein großes Verlangen danach, das Universum zu verstehen. Die Innereien des Computers zu erforschen war anscheinend nur die Einstiegsdroge.

Ich gehe nun schlafen, es ist schon wieder fast 6 Uhr morgens.

Für alle die von diesem neuen Beitrag enttäuscht sind: ich finde aktuell leider keine Zeit für Reverse Engineering. Ah, und da ich noch nie ein Video hier auf dem Blog eingebunden habe, tu ich das mal, passend zu diesem Beitrag: