• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

DevSecOps in der Praxis

10. Dezember 2019
Aral Yaman
0
Azure, Azure DevOps, DevOps, DevSecOps, OWASP, Security, Testen, testing

Agile Softwareentwicklung hat sich längst zum Standard für viele Firmen etabliert. Softwareentwicklung und der IT-Betrieb arbeiten enger zusammen, Stichwort DevOps!
Was aber in der «DevOps-Bewegung» meist nicht oder nur sporadisch berücksichtigt wurde, ist das Thema Security.
Mit DevSecOps will man das Thema Security näher an den Entwicklungsprozess bringen, angefangen beim Ermitteln von Sicherheitsanforderungen in der Anforderungsanalyse, über automatische Sicherheitsüberprüfungen im CI/CD Prozess, bis hin zur Überwachung der laufenden Anwendung. In all diesen Bereiche, in denen die Sicherheit eine Rolle spielt, kommt DevSecOps zum Zug.

READ MORE

Sicherheitslücken finden mit WinAFL

10. November 2016
Aral Yaman
0
AFL, Application Security, automated testing, CVE-2016-7212, Fuzzing, Microsoft, MS16-130, Secuirty, security testing, Software Security, testing, WinAFL, windows

Beim Sicherheitsupdate für Microsoft Windows vom November 2016 (MS16-130, CVE-2016-7212) wurde eine kritische Sicherheitslücke behoben, welche ich gemeldet hatte (siehe Danksagung von Microsoft).

In diesem Artikel möchte ich das Vorgehen und das Tool vorstellen, mit dem die Sicherheitslücke gefunden werden konnte.

Fuzzing und AFL
Wie aus meinem früheren Artikel ersichtlich ist, bin ich ein grosser Fuzzing Enthusiast und konnte diese Sicherheitslücke von Microsoft Windows sowie auch andere Sicherheitsrelevante Softwarefehler bei anderen Firmen (CVE-2011-2989, Mozilla Advisory 2016-53) mit dieser Strategie finden.
Fuzzing ist eine alte und bewährte Strategie, Software auf Fehler zu überprüfen. Dabei werden massenhaft Eingabedaten erzeugt und manipuliert, um dann schlussendlich zu überprüfen, wie sich die Software verhält. Es gibt viele Fuzzingtools und Frameworks  (siehe Peach Fuzzer, Sulley, Radamsa), welche verschieden Techniken verwenden, Fehler in der Software zu finden.
Ein Beispiel für eine Fuzzingtechnik ist, dass das Fuzzingtool relativ „dumm“ ist und die Eingabedaten einfach nur mittels „Bit flipping“ manipuliert werden, um diese als Eingabedaten für die zu testende Software zu verwenden (siehe Fuzz testing techniques).
Seit 2014 hat sich das Fuzzingtool American fuzzy loop (kurz AFL) vor allem im Open-Source Bereich durchgesetzt und zahlreiche Sicherheitslücken und Softwarefehler gefunden. Das Besondere an diesem Tool ist, dass durch Instrumentierung von der zu testenden Software die Codepfade beobachtet werden, die durch die Eingabedaten genutzt werden. AFL verwendet dann diese Informationen, um selber weitere Eingabedaten zu erzeugen, welche verschiedene Codepfade abdecken. Wie dieses Experiment zeigt, konnte mit dieser Technik  aus einer simplen Datei mit dem Inhalt “hello”, mit der Zeit gültige Bilddaten erzeugt werden.

WinAFL
Das Fuzzingtool AFL ist nur für Linux und Unix Betriebssysteme ausgelegt. Glücklicherweise erschien Mitte diesen Jahres WinAFL, das ein Fork von AFL und für das Windows Betriebssystem ausgelegt ist.
WinAFL verwendet, im Unterschied zu AFL, einen etwas anderen Ansatz für die Instrumentalisierung. Bei AFL wird die Instrumentalisierung statisch beim kompilieren zum Programmcode hinzugefügt. Bei WinAFL wird die Instrumentalisierung dynamisch mittels DynamoRIO erreicht und kann auch bei Software verwendet werden, bei denen nur die ausführbare Binärdatei verfügbar ist (also wenn kein Programmcode vorhanden ist).

WinAFL in Action
Der Programmcode für WinAFL sowie die vorkompilierte Versionen von WinAFL in 32- und 64 Bit sind komplett auf github verfügbar.
Nach dem Klonen vom WinAFL Repository und der Installation von DynamoRIO,  kann es auch schon gleich losgehen mit dem Fuzzing.
Eine Bespielapplikation ist auch dabei, welche hier für die Demonstration verwendet wird.
Der Programmcode von der Bespielapplikation (test.exe) ist ziemlich einfach und soll die Basis-Funktion von WinAFL aufzeigen:
wenn in einem Textfile das Wort „test“ enthalten ist, soll ein Programmabsturz verursacht werden, der dann erkannt werden soll.
Für diese Demo verwende ich die 32Bit Version.

Das Testprogramm (test.exe) und das Fuzzingtool (afl-fuzz.exe) sind im Ordner Bin32 zu finden.
Bevor aber angefangen werden kann, muss die Funktion, die das WinAFL Fuzzingtool aufrufen soll, als Konsolen-Parameter in Form von einem Offset (target_offset) mitgegeben werden, den man am besten mit dem WinDbg Tool von Microsoft herausfinden kann.

Nachdem WinDbg gestartet wurde, kann die Bespielapplikation (test.exe) mit dem WinDbg Tool geöffnet werden:

afl01
In diesem Beispiel möchten wir einfach die „main“ – Methode mittels WinAFL überprüfen.
Dazu muss folgender WinDbg – Befehl eingegeben werden:
x test!main

afl02
Der Offset kann ermittelt werden, indem der Wert von B (Anfangsadresse von test.exe) vom Hex-Wert von A (Adresse von main-funktion) abgezogen wird:

afl03
target_offset = A – B = 0x01241010 – 0x01240000 = 0x1010

Achtung! Dieser Offset kann auf einem anderem Computersystem unterschiedlich sein und muss daher individuell ermittelt werden.

Als nächstes stellen wir sicher, dass die Beispielapplikation fehlerfrei ausgeführt werden kann.
Dazu erstellen wir ein Textfile mit einem beliebigen Inhalt und rufen test.exe mit diesem Textfile als zusätzlichem Parameter auf:

afl04afl05
Um einen Crash bei der Beispielapplikation zu verursachen muss als Input das Wort „test“ im Textfile vorhanden sein. Dazu ändern wir den vorherigen Inhalt von „noser“ auf „test“ und führen die Beispielapplikation erneut auf:

afl06afl07
Wie man sieht konnten wir den Crash erfolgreich auslösen.

Als nächsten Schritt kann nun überprüft werden, ob mit DynamoRIO die Instrumentalisierung und der ermittelte target_offset funktionieren.
Dazu ändern wir unsere Textdatei wieder so um, dass die Beispielapplikation nicht abstürzt („test“ auf „noser“) und rufen unsere Beispielabblikation wie folgt auf:

c:\DynamoRIO-Windows-6.2.0-2\bin32\drrun.exe -c winafl.dll -debug -target_module test.exe -target_offset 0x1010 -fuzz_iterations 5 -nargs 2 — test.exe test.txt

afl08

Nachdem auch das geklappt hat sind wir nun bereit unsere Bespielapplikation mit dem WinAFL Fuzzingtool zu testen.

Dazu muss unsere Beispielapplikation wie folgt aufgerufen werden:

C:\winafl\bin32>afl-fuzz.exe -i in -o out -D c:\DynamoRIO-Windows-6.2.0-2\bin32 -t 20000 —
-coverage_module test.exe -fuzz_iterations 1000 -target_module test.exe -target_offset 0x1010 -nargs 2 — test.exe @@

afl09
Nach einigen Durchläufen wird WinAFL verschiede Programmpfade finden und sogar der Crash konnte relativ schnell gefunden werden.

Sicherheitslücken finden mit WinAFL
Wenn wir das File anschauen im out/crashes Ordner, dann werden wir ein File mit dem Inhalt „test“ finden, welches die Ursache vom Crash ist:

afl11
Fazit
Mit WinAFL konnten schon erfolgreich sicherheistrelevante Software-Fehler gefunden werden. Darum kann der Einsatz von WinAFL,  um Software auf Softwarefehler zu untersuchen, durchaus eine Variante sein.
Ein Beispiel, wie so eine Teststrategie aussehen könnte, ist bei SQLite zu finden, welche Fuzz Testing mit AFL standartmässig in ihrer Teststrategie integriert haben. Dies könnte sicher auch für Software auf Windows Systemen mit WinAFL adaptiert werden.

Happy Fuzzing!

12

Tag Cloud

.NET android Angular AngularJs Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded Führung gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie UX Visual Studio WebAPI windows WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Akzente setzen mit der Android Splash Screen API unter .NET MAUI
  • Do You have Your Personal Space?
  • Automated provisioning with ARM Templates
  • Asynchrone Beobachtungen und Versprechungen in Angular
  • Simplify Your Automated Tests With Fluent Syntax

Last Comments

  • Hans Reinsch bei Der Safety-Plan: Die wichtigsten Antworten mit Checkliste
  • George H. Barbehenn bei Modeling Optocouplers with Spice
  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie