Hat "Hacking" wirklich etwas mit Kreativität zu tun? Marc Ruef | 17.10.2010 Ja, ich weiss: Der Titel offenbart sich als offensichtliche Suggestivfrage. Und so ist es absehbar, dass ich nun behaupten werde, dass "Hacking" - jedenfalls im Rahmen einer kommerziellen Sicherheitsüberprüfung (http://www.scip.ch/?dienstleistungen.auditing) - eigentlich wenig mit Kreativität zu tun hat. Wie jeder Mensch behaupte natürlich auch ich von mir, dass ich kreativ bin. Doch Kreativität scheint mir eigentlich im genannten Zusammenhang der falsche Begriff zu sein. Ich bin lediglich gut darin den möglichen und existenten Variantenreichtum zu sehen und auszuschöpfen. Doch was heisst das? Am einfachsten lässt sich mein Standpunkt anhand einer Protokollanalyse und des damit einhergehenden Fuzzing illustrieren. Nehmen wir ein fiktives Produkt, welches wir im Rahmen einer Blackbox-Analyse (http://www.computec.ch/news.php?item.86) zu untersuchen haben. Durch das Mitlesen des Netzwerkverkehrs erkennen wir, dass zum System über TCP-Port 3031 die Anfrage "INITIATE CONFIGURATION config-20100912.xml restart=yes delay=30 message=*" verschickt wird. Und zwar immer dann, wenn wir auf das System eine neue Konfiguration hochladen. Es erscheint nun offensichtlich, dass es sich beim ersten Wort INITIATE um eine Anweisung handelt. Das zweite Wort CONFIGURATION definiert sodann den Wertebereich (die Konfigurationseinstellungen). Und mit config-20100912.xml wird wohl der interne Name der Konfigurationsdatei - die entspricht nämlich nicht der hochgeladenen Datei - vorgegeben sein. Zusätzlich werden mit restart, delay und message weitere Parameter aufbereitet. Ein Penetration Test dieses Kommunikationskanals auf der Ebene des Protokolls würde nun erfordern, mögliche Varianten und Abweichungen dieses legitimen Statements durchzusetzen. Anstelle von INITIATE soll DELETE oder DISABLE verwendet werden. Anstelle von config-20100912.xml soll der Zugriff auf /etc/passwd versucht werden. Und die Argumente können von "no" und -1 bis hin zu Versuchen einer Cross Site Scripting und SQL-Injection Attacke reichen. Der "Kreativität" sind keine Grenzen gesetzt. Theoretisch. Denn eigentlich besteht hier die Kreativität wirklich nur darin zu erkennen, was für Strukturen angewendet werden und wie sich diese modifizieren lassen. Jeder, der einmal ein eigenes Fuzzing-Framework programmiert hat weiss, dass dies schlussendlich ein trivialer Prozess von ineinander verschachtelten for-Schleifen ist. Geht es um die Analyse unerwarteter Eingaben, so sind wahrhaftig Maschinen die besseren Penetration Tester. Denn zur Durchführung von Fuzzing braucht es Ausdauer und Beharrlichkeit. Sind die Strukturen nämlich bekannt, geht es nur noch um das stupide Durchprobieren, wie man es von traditionellen Bruteforce-Attacken her kennt. Und individuelle Penetration Tests auf technischer Ebene - also Angriffe auf Nicht-Standard-Software zur Identifikation von 0-Day Schwachstellen - sind grösstenteils eben genau dies. Das Können eines Penetration Testers liegt also oftmals nicht in seiner Kreativität, sondern in seiner schnellen Auffassungsgabe und der Weitsicht, wenn es um Strukturen und Muster geht. Doch spätestens im Rahmen der Ausführung sind im Sinne von Wirtschaftlichkeit und Effizienz entsprechende Automatismen gefragt und damit der Analyst in einer späten Phase oftmals nur zum geistigen Architekten des Angriffs degradiert.