Labs: Schwachstellen finden mittels Fuzzing
am Donnerstag, 2. August 2012
von Marc Ruef | G+
Bei Fuzzing handelt es sich um eine Technik im Bereich des Software-Testing. Dabei werden in semi-automatisierter oder automatisierter Weise Eingaben getätigt, um mittels fehlerhafter Zugriffe unerwartete Reaktionen zu provozieren.
Die Geburt des Begriffs wird Barton Miller zugeschrieben, der 1988 an der University of Winsconsin eine entsprechende Arbeit mit dem Titel Operating System Utility Program Reliability – The Fuzz Generator durchgeführt hat. Doch schon 1983 wurde für den Macintosh durch Steve Capps eine Applikation namens The Monkey entwickelt, mit der entsprechendes Fuzz Testing in der Software MacPaint umgesetzt werden konnten.
Fuzzing ist damit eigentlich eine relativ alte Technik, die aber erst ab ca. 2005 den zaghaften Durchbruch in der IT-Security Branche geschafft hat. Heutzutage gilt es als fester Bestandteil systematischer Sicherheitsüberprüfungen.
Ein System erwartet immer irgendwelche Eingaben. Diese haben eine bestimmte Struktur. Zum Beispiel erwartet in einem Formular das Feld Postleitzahl für Schweizer Adressen stets vier Ziffern der folgenden Form (als regulärer Ausdruck):
([0-9]{4}) = { 0000, 0001, ..., 9999 }
Beim Fuzzing werden nun Eingaben getätigt, die gezielt diese Anforderungen verletzen. In diesem Beispiel bieten sich an:
| Test | Beispiel |
|---|---|
| kürzer als 4 Zeichen | 111_ |
| länger als 4 Zeichen | 1234567890(...) |
| Buchstaben | 123A |
| Sonderzeichen | 123* |
| Minuswerte | -123 |
| konstruierte Werte | 1+23 (wird nach Berechnung als 24 gehandelt) |
| leere Eingabe | ____ |
| nicht abgeschlossene Eingaben | (gibts in diesem Beispiel nicht) |
| reservierten Mustern | HTML-Anweisungen, SQL-Abfragen, ... |
| alternative Codierungen | UTF-8, Unicode, ... |
Dadurch soll ein Verhalten provoziert werden, auf das das Zielsystem nicht ausgelegt ist. Wenn zum Beispiel die PLZ eingegeben und das Formular abgeschickt wurde, dann soll direkt die Ortschaft aus einer Datenbank geholt und dargestellt werden. Doch was wird geholt, wenn 123* eingegeben wird? Mögliche Resultate, denen eine generische Kritikalität beigemessen wird, sind:
| Sicherheitstechnisch Positiv | |
|---|---|
| passed | allgemeine Fehlermeldung (bevorzugte Lösung) |
| low | es passiert gar nichts (vom Betrieb her aber unerwünscht) |
| Sicherheitstechnisch Negativ | |
| medium | technische Fehlermeldung (z.B. Informationen zur internen Verarbeitung) |
| medium | erster Treffer wird geladen |
| medium | letzter Treffer wird geladen |
| medium | “zufälliger” Treffer wird geladen (z.B. je nach Sortierung) |
| high | alle Treffer werden geladen (erweiterte Zugriffsrechte) |
| high | auf geschützte Daten zugreifen (erweiterte Zugriffsrechte) |
| high | geschützte Funktionen benutzen (z.B. Code ausführen) |
| high | Datenverarbeitung blockieren (Denial of Service) |
In einer guten Sicherheitsüberprüfung wird mit intelligentem Fuzzing gearbeitet. Dies erfordert aber viel Verständnis für die eingesetzten Technologien. Das simple Abstützen auf irgendwelche Vulnerability Scanner gewährleistet nicht, dass derlei Tests mitberücksichtigt werden. Gerade wenn individuelle Software-Lösungen zum Tragen kommen, muss ein zielgerichtetes Fuzzing angestrebt werden.
(442 Wörter)
Links:
Tags: HTML, Buch, Denial of Service, Dienstleistung, Fuzzing
- Letzte Beiträge
- Sicherheitsverantwortlichkeiten und Risikosteuerung
- Computer Forensik – Ein Überblick
- Vortrag zu Security Testing an SGRP Veranstaltung
- Staatstrojaner – Kritik am neuen Bundesgesetz
- Overview of Microsoft’s security toolkit EMET
- Blog Digest April 2013
- Wie statisch sollten Sicherheitsrichtlinien sein?
- Timing für effiziente unentdeckte Portscans
- Interpreting a Logfile with Grok
- Spamhaus DDoS mit DNS Amplification
- Archiv