Fuzzing - Informatik

Transcription

1
Faath Michael, Schäffler Florian - Fuzzing
Fuzzing – Was kann im Netz angewandtes Fuzzing erreichen?
Was ist Fuzzing?
Fuzzing ist eine Software-Testing
Testing-Technik,
Technik, welche eine automatische Suche nach Fehlern ermöglicht.
Viele in den letzten Jahren entdeckte
entdeck Fehler sind mithilfe dieser
ser Technik zutage gekommen.
Dafür werden zufällige bzw. semi-zufällige
semi zufällige Daten genutzt, um z.B. ein Programm zum Absturz zu
bringen. Mit semi- oder auch halbzufälligen Daten ist folgendes gemeint:
"good enough
ugh so it'll look like valid data, bad enough so it might break stuff"
Quelle: 22c3: Fuzzing Fuzzing - Breaking software in an automated fashion (2006),
http://events.ccc.de/congress/2006/Fahrplan/events/1758.en.html
Fuzzing ist eine Blackbox-Testing
Testing-Technik,
nik, dies bedeutet, es wird ohne zusätzliche Informationen wie
z.B. den Quellcode eines Programmes oder die Konfiguration, getestet. Man konzentriert sich auf die
fertige Anwendung.
Was bringt Fuzzing?
Primär kann Fuzzing dazu genutzt werden, seine eigenen
eigenen Programme auf Fehler zu überprüfen. Aber
auch das lahmlegen von fremden Programmen und Diensten ist eine Anwendungsmöglichkeit. Durch
genauere Analyse der gefundenen Fehlfunktionen kann es auch möglich werden, Code
einzuschleusen.
Ein kurzer geschichtlicher
icher Abriss
Fuzzing wurde von Professor Barton Miller zusammen mit Studenten an der Universität von
Winsconsin-Madison
Madison im Jahre 1989 entwickelt. Sie testeten verschiedene UNIX-Programme,
UNIX Programme, indem
sie automatisiert zufällige Parameter übergaben. Ein Drittel aller getesteten Programme stürzten
dabei ab.
Was kann man alles Fuzzen?
Weit verbreitet ist die Meinung, man könne nur HTTP fuzzen. Doch ist dies schlicht und ergreifend
falsch, es können so gut wie alle Dinge gefuzzed werden, die in irgendeiner Art Eingaben erwarten.
Sei es durch Argumente, Umgebungsvariablen, die Standardeingabe
Standardein
(stdin) etc.
Hier eine kleine Auflistung, was gefuzzed werden kann:
•
•
•
•
Netzwerkprotokolle / Netzwerkanwendungen
Argumente, Umgebungsvariablen, stdin, file-descriptors
file
APIS (syscalls, library calls)
Dateien
Es lassen sich also neben Webanwendungen auch
auch Netzwerkprotokolle aber auch lokale Programme
mithilfe der Konsole oder über von Ihnen geöffnete Dateien fuzzen.
Fuzzer-Typen
Prinzipiell kann man zwischen zwei Arten von Fuzzern unterscheiden:
•
•
Solche die speziell für einen Zweck, also ein Protokoll oder eine Anwendung, geschrieben
wurden
Fuzzing-Frameworks,
Frameworks, welche Funktionen zum Bau eines eigenen Fuzzers beinhalten
2
Wie funktioniert Fuzzing?
Es werden zufällige Daten (z.B. an eine Anwendung) gesendet, hier gibt es zwei Möglichkeiten, wie
bereits erwähnt:
1. Es werden völlig zufällige Daten gesendet
So ist es möglich, eine Vielzahl von Fehlern aufzudecken. Jedoch braucht man dafür viel Zeit,
da der komplette Raum von möglichen Eingaben durchgegangen wird. Dies kann im Prinzip
unendlich lange gemacht werden, so dass man Glück benötigt, frühzeitig einen Treffer zu
landen.
2. Vorherige Analyse der möglichen Eingabe-Daten
Eingabe
Man begrenzt den Eingaberaum, indem man sich z.B. die Anwendung oder das Protokoll
genauer anschaut. Viele Anwendungen/Protokolle filtern direkt Eingaben, welche nicht in ein
bestimmtes Schema
hema passen. Bei dieser Methode werden also zufällig generierte Daten in ein
bestimmtes Schema eingebettet, so dass diese das Programm annimmt. Hierbei können
jedoch Fehler übersehen werden, da wir nicht alle Möglichkeiten durchgehen.
Außerdem unterscheidet
et man in 3 Methoden, mit welchen Fuzzing betrieben werden kann:
1. Manuelles Fuzzen
Jede Eingabe wird manuell generiert und abgesendet, dadurch hat der Benutzer die
größtmögliche Kontrolle und kann alle Reaktionen selbst analysieren. Diese Methode ist sehr
gründlich, erfordert jedoch viel Zeit und Kenntnisse von der Materie.
2. Automatisches Fuzzen
Der Fuzzer generiert hier im Gegensatz zum manuellen Fuzzen die Eingaben selbst und
sendet diese auch selbstständig an das Programm. Danach muss er analysieren, ob sich die
zu testende Anwendung weiterhin normal verhält. Stellt er eine Abweichung fest, wird die
Abarbeitung beendet und dem Benutzer das Ergebnis mitgeteilt. Mit dieser Methode lassen
sich große Mengen an Eingaben ausprobieren, jedoch können Fehler übersehen
übers
werden, falls
der Fuzzer diese nicht richtig erkennt und einfach weiter arbeitet.
3. Halbautomatisches Fuzzen
Dies stellt einen Mittelweg zwischen dem manuellen und dem automatischen Fuzzen dar. Die
Eingaben werden automatisch generiert, die Auswertung übernimmt jedoch der Benutzer. So
werden beide Vorteile der ersten Methoden vereint, die Kontrolle bleibt beim Benutzer und
es kann schneller gearbeitet werden. Die Geschwindigkeit eines automatischen Fuzzers kann
aber bei weitem nicht erreicht werden.
Wann ist das Ziel erreicht?
Ein Fuzzer hat sein Ziel erreicht, wenn das Programm z.B. hängen bleibt, komplett crasht (also sich
ungeplant beendet), der Zielrechner einen Reboot ausführt oder eine übermäßige Speichernutzung
festgestellt werden kann. Dann kann der Fehler genauer analysiert werden, ggf. kann so auch Code in
das Hostsystem eingeschleust werden.
3
PROTOS (http://www.ee.oulu.fi/research/ouspg/protos):
PROTOS ist kein Programm im eigentlichen Sinne, sondern viel mehr eine ganze Sammlung von
Programmen
ammen die unter dem Namen PROTOS zusammengefasst und entwickelt werden. Entwickelt
wird diese Anwendung an der finnischen Universität Oulu vom Computer Engineering Laboratory seit
1999. Dieses Projekt wird seit Beginn von mehreren Unternehmen unterstütz. 1999
1999 waren diese
Unterstützung 90.000 Euro und 2001 schon 140.000 Euro.
Das PROTOS Projekt ist in einzelne Test-Suites
Test Suites unterteilt, welche jeweils für verschiedene Protokolle
und Anwendungen zuständig sind. Was diese Test-Suites
Test Suites von anderen Fuzzern unterscheidet
unters
ist
nicht nur die Funktionsweise, sondern auch dass allesamt in Java geschrieben sind, weil viele andere
Fuzzer entweder in Skript-Sprachen
Sprachen oder C geschrieben sind. Des Weiteren ist der Quelltext frei
erhältlich und von den einzelnen Test-Suite
Test
Seiten
iten herunterladbar. Zu diesen Test-Suites
Test
gehören
c04-wap-wsp-request, c05-wap-wmlc,
wmlc, c05-http-reply,
c05
c06-ldapv3, c06-snmpv1,
snmpv1, c07-sip,
c07
c07-h2250v4,
c09-isakmp, c09-dns und c10-archive.
archive.
Jeder Fehler der bei Tests mit einer Test-Suite
Test
aus PROTOS auftritt kann
n theoretisch mindestens als
Denial of Services ausgebaut werden. Diese Denial of Services können natürlich auch auf gleiche
Funktionen abzielen und somit die gleiche Ursache haben. Es handelt sich also nicht nur um
unterschiedliche Fehlerquellen. In mehreren
mehreren Fällen ist auch ein Buffer Overflow Exploit möglich.
Einblick c05-http-reply:
Die Ausführung des Fuzzers verhält sich ziemlich einfach. Ohne vorherige Konfiguration muss nur die
Java-Anwendung
Anwendung aufgerufen werden um den Fuzzer zu starten. Dies geschieht mit
java -jar c05-http-reply-r1.jar
Es wird nun ein kleiner Webserver auf Port 8000 gestartet, welcher HTTP-Anfragen
HTTP Anfragen beantwortet, die
aus wirklichen HTTP-Daten
Daten und zufällig generierten Daten bestehen. Es wird speziell darauf geachtet,
dass kritische Informationen
ormationen miteinander verknüpft werden, da somit Fehler wahrscheinlicher
werden. Obwohl die Entwicklung des co5-http-reply
co5
reply schon vor einigen Jahren beendet wurde, wird
es noch immer eingesetzt um Browser zu testen.
Einblick c06-snmpv1:
reply verhält es sich auch mit dieser Test-Suite
Test Suite bezüglich der Einfachheit. Um
Ähnlich wie c05-http-reply
ein SNMP-fähiges
fähiges Gerät zu testen muss man sich nur entscheiden, ob Requests oder Traps fuzzen
möchte. Um beispielsweise Requests zu fuzzen wird einfach die Test-Suite
Test
c06-snmp
snmpv1 gestartet
werden. Dies geschieht mittels
java -jar c06-snmpv1-req-app.jar
app.jar -host <HOSTNAME>
Nun werden halbzulässige Pakete an gesetzten Hostnamen geschickt, welche darauf abzielen zu
testen wo in der jeweiligen SNMP-Implementierung
SNMP
sich Schwachstellen
len befinden. Diese Test-Suite
Test
dürfte wohl die bekannteste aus dem PROTOS Paket darstellen, da es mit Hilfe dieses Fuzzer
gelungen ist schwerwiegende Fehler im SMNPv1 nachzuweisen. Es wurde zum Beispiel eine
Möglichkeit entdeckt jedes Gerät, welches SNMPv1
SNMPv1 abstürzen zu lassen und bei manchen
Implementierungen sogar Code einzuschleusen. Obwohl diese Schwachstelle schon seit geraumer
Zeit bekannt ist wird bei vielen Geräten noch immer SNMPv1 benutzt, obwohl SNMPv3 unter
Anderem auch dieses strukturelle Problem
Probl
behebt.
Einblick c07-sip-r2:
Wie der Name schon sagt handelt es sich hier um die Test-Suite
Test Suite welche versucht das SIP Protokoll für
VoIP zu fuzzen. Als Ansatz-Punkt
Punkt wird hier die INVITE-Funktion,
INVITE Funktion, welche beim Aufbau einer SIPSIP
Verbindung benutzt wird, verwendet.
verwendet. Es werden immer wieder abgeänderte INVITE-Nachrichten
INVITE
an
4
den Server verschickt. Genauso wie bei der Veröffentlichung der snmpv1 Test-Suite
Test Suite hatte diese
Anwendung auch verheerende Auswirkungen. Es konnte unter Anderem gezeigt werden, dass ein
Großteil der Systeme durch die gefuzzten INVITE-Anfragen
INVITE Anfragen abstürzte und somit Ansatzpunkt für
Sicherheitslöcher ermöglichte. Im weiteren Verlauf wurden, ausgehend von diesen Ergebnissen,
mehrere Proof-of-Concept
Concept Buffer Overflow Exploits oder Denial of Services-Explo
Service Exploits entwickelt.
Durch PROTOS gefundene Schwachstellen in folgender Software:
• Cisco IP Phone Model 7940/7960 running SIP images prior to 4.2
• Cisco Routers running Cisco IOS 12.2T and 12.2 'X' trains
• Cisco PIX Firewall running software versions with SIP support, beginning with version 5.2(1)
• Ingate Firewall < 3.1.3
• All versions of SIP Express Router up to 0.8.9
• Mediatrix VoIP Access Devices and Gateways firmware < SIPv2.4
• Mozilla Firefox IBM SecureWay V3.2.1 running under Solaris and Windows 2000
• Lotus Domino
mino R5 Servers (Enterprise, Application, and Mail), prior to 5.0.7a
• Microsoft Exchange 5.5 prior to Q303448 and Exchange 2000 prior to Q303450
• Network Associates PGP Keyserver 7.0, prior to Hotfix 2
• Oracle Internet Directory, versions 2.1.1.x and 3.0.1
• OpenLDAP,
enLDAP, 1.x prior to 1.2.12 and 2.x prior to 2.0.8
• ...
Mengleme (http://freshmeat.net/projects/mangleme) :
Bei mengleme handelt es sich um einen reinen HTTP-Fuzzer,
HTTP Fuzzer, welcher in der Programmiersprache C
geschrieben ist. Auf Grund dessen, dass mengleme so effektiv
effektiv arbeitet ist es mittels dieses Fuzzer
gelungen jeden der bekannten und viele kleinere weniger bekannte Browser zum Absturz zu bringen.
Funktionsweise Mengleme:
Es wird mittels eines CGI-Skripts
Skripts eine Seite aus mehreren zufällig zusammengestellten HTML-Tags,
H
Extremwerte innerhalb dieser HTML-Tags
HTML Tags und zusätzlichen variierenden Informationen erstellt. Diese
Seite wird nun immer wieder von einem Browser aufgerufen. Sollte nun der Browser beim Aufrufen
dieser mittels CGI generierten Webseite abstürzen, so
so war der Fuzzer erfolgreich. Um später eine
Suche nach der Ursache für den Absturz zu machen ist es vernünftig die generierten Seiten auf dem
Server zu speichern, bevor sie an den Browser geschickt werden.
HTMLer („ it finds IE bugs after roughly 2.5 -> 3 hours“)
Dies ist eine Portierung von C in Python mit kleineren Modifikationen. Somit bleibt die
Funktionsweise ähnlich verglichen mit der mengleme, außer dass nun keine CGI sonder einen Python
generierte Seite aufgerufen wird.
Mittels dieses Fuzzer wurde
de 2004 der IFrame Bug beim Microsoft Internet Explorer entdeckt. Diese
Schwachstelle machte sich der Bofra-Wurm
Bofra Wurm zu nutze. Die Konsequenz war, dass Microsoft rund ein
Monat nachdem der IFrame Bug entdeckt wurde 5 Tage vor einem Patching Tuesday ein Fix für
dieses Problem herausbrachte.
Durch mengleme/HTMLer gefundene Schwachstellen in folgender Software:
• Microsoft Internet Explorer: u.A. IFrame Bug
• Netscape Navigator / Mozilla Firefox
• Links
• Lynx
• Opera
• Safari
• …
5
Fuzzing Tools und Frameworks
Tools für Webbrowser
Axman
Active X
COMbust
Common Object Model
CSS-Die
Stylesheet-Unterstützung
DOM-Hanoi
Data Object Model
Hamachi
DHTML-Code
jsparsefuzz
JavaScript
MangleMe
HTML-Tags
Tools für Betriebssysteme
ISIC
IP-Stacks
Sfuzz
Unix-Sockets
Stress2
FreeBSD-Kernel
Sysfuzz
syscall()-Funktionen
Tools für Netzwerkdienste
DHCPfuzz
DHCP-Clients
FTPStress
FTP-Server
Fuzzball2
TCP/IP-Header
IRCfuzz
IRC-Clients
Protos
Tool-Sammlung
Sammlung für SIP, SNMP, DNS und andere
SSHredder
Sammlung mutierter SSH-Pakete
Sonstige Tools
Mangle
mutiert Datei-Header
Bugger
mutiert Daten im Speicher laufender Programme
CFG9000
intelligente Mutation unbekannter Eingabedaten
Frameworks
Autodafe
Netzwerkprotokolle, mit Laufzeitanalyse
Bed
Netzwerkprotokolle, Sprache: Perl
Peach
universell einsetzbar, Sprache: Python
Smudge
Netzwerkprotokolle
Spike
Netzwerkprotokolle, Sprache: C
Spikefile
Dateiformate, Sprache: C
Quelle: http://www.heise.de/security/Schwachstellensuche-mit-Fuzzing--/artikel/100167/3
http://www.heise.de/security/Schwachstellensuche
6
Quellen:
•
Heise: Schwachstellensuche mit Fuzzing,
http://www.heise.de/security/Schwachstellensuche
http://www.heise.de/security/Schwachstellensuche-mit-Fuzzing--/artikel/100167/
/artikel/100167/
•
Heise: Die Axt im Walde
http://www.heise.de/security/Die
http://www.heise.de/security/Die-Axt-im-Walde--/artikel/76512
•
22c3 - Ilja van Sprundel: Fuzzing - Breaking software in an automated fashion
http://events.ccc.de/congress/2005/fahrplan/events/537.de.html
•
23c3 - Dan Kaminsky: Black Ops 2006 Viz Edition - Pixel Fuzzing and the Bioinformatic
Bindiff
cc.de/23c3_m4v_1713.html
http://chaosradio.ccc.de/23c3_m4v_1713.html
•
23c3 - Gadi Evron: Fuzzing in the corporate world
http://chaosradio.ccc.de/23c3_m4v_1758.html
•
Ziegler, Paul S. (2007): Fuzzing – Teil 1 und 2, Bonn: Hakin9 – Hard Core Security Magazine
•
Miller, Barton P.: Fuzz Testing of Application
Applic
Reliability
http://pages.cs.wisc.edu/~bart/fuzz/

Fuzzing - Informatik

Transcription

Similar documents

Vorlesung „Barrierefreies Webdesign“