Zero Day Threat est un terme désignant des vulnérabilités de développement qui n'ont pas encore été découvertes. Ces vulnérabilités peuvent être exploitées par des cybercriminels, ce qui affectera en fin de compte la réputation de l'entreprise. Les développeurs sont confrontés à la tâche de minimiser le nombre de défauts dans le code qui pourraient provoquer une telle vulnérabilité. L'un des outils permettant d'identifier les failles de sécurité est l'analyseur de code statique PVS-Studio pour C, C ++, C #, Java.
Menace Zero Day
La menace Zero-day est un terme qui identifie les lacunes et les vulnérabilités autorisées par les développeurs, mais qui n'ont pas encore été découvertes. Jusqu'à ce que la vulnérabilité soit corrigée, elle peut être utilisée pour accéder aux réseaux, contrôler à distance un ordinateur, manipuler des données, etc. Ce nom du terme est bien établi du fait que les développeurs n'ont pas un jour pour réparer le défaut, puisque personne ne le sait encore. En temps voulu, de grandes sociétés et des logiciels tels
qu'Adobe ,
Windows , le
navigateur Tor et bien d'autres ont souffert de telles vulnérabilités.
Certaines organisations ont eu de la chance, leur vulnérabilité a été découverte par des personnes qui n'allaient pas l'utiliser et elles ont simplement fourni des informations sur le problème. Par exemple, c'était avec
MacOS . Ou il y a eu une mise à jour qui, en plus de nouvelles fonctionnalités, a également corrigé accidentellement la menace du jour zéro.
Cependant, il y a eu d'autres situations. Par exemple, Google Chrome a dû à un moment donné corriger une
vulnérabilité qui permettait à un attaquant d'exécuter à distance du code arbitraire sur l'appareil d'une victime.
Le problème avec cette menace est qu'il est impossible de se défendre à 100%, car il est difficile de se défendre contre ce que vous ne savez pas encore. Cependant, il existe des moyens de réduire la probabilité d'une telle menace dans votre projet, et nous en discuterons plus tard, mais pour commencer avec un peu de théorie.
Analyse statique
L'analyse de code statique est le processus de vérification du code de programme par l'analyseur sans démarrer le programme lui-même. L'analyse statique peut être considérée comme un processus automatisé de révision de code. Dans certains cas, l'efficacité de l'analyse statique est supérieure à la révision de code, mais elle ne peut pas être considérée comme une alternative complète à la révision de code par plusieurs programmeurs. Ci-dessous, j'ai essayé de décrire brièvement les avantages et les inconvénients de la révision du code et de l'analyse statique du code les uns par rapport aux autres.
CVE et CWE
Common Vulnerabilities and Exposures (CVE) est une base de données d'erreurs logicielles pouvant être utilisée par les cybercriminels. CVE a été créé pour rationaliser les défauts logiciels connus. La plupart des outils de sécurité de l'information utilisaient leurs propres bases de données et noms, et afin d'éliminer ce chaos et d'ajouter la compatibilité avec divers outils, MITRE en 1999 a créé CVE. Cependant, CVE n'était pas suffisant pour évaluer la sécurité du code. Cela nécessite quelque chose de plus précis, avec une description détaillée des problèmes et moins grossier qu'elle. Par conséquent, la base d'énumération commune des faiblesses (CWE) a été créée pour répondre à ces exigences. Si l'erreur est sur la liste CWE, il est probable qu'elle conduira à une vulnérabilité qui pourrait être exploitée par l'attaquant et entrer dans la liste CVE. Pour plus de clarté, vous pouvez consulter le diagramme d'Euler ci-dessous.
Certains analyseurs statiques peuvent indiquer au développeur que, par exemple, le projet utilise la bibliothèque dans laquelle se trouve la vulnérabilité. Cela vous permet de choisir une version plus récente de la bibliothèque dans laquelle la vulnérabilité a déjà été corrigée et de réduire la probabilité de problèmes avec des menaces provenant du code de quelqu'un d'autre.
Avec l'avènement du développement des listes CVE et CWE, de nombreux outils de sécurité de l'information ont pris en charge leur support, y compris les analyseurs statiques. Ces analyseurs peuvent être considérés comme une solution SAST. SAST (Static Application Security Testing) permet aux développeurs de trouver des vulnérabilités dans le code source de l'application dès les premiers stades du cycle de vie du développement logiciel.
L'utilisation de SAST dans le développement est une autre option pour minimiser la probabilité d'une menace zéro jour. L'analyseur, classant ses erreurs selon le CWE, peut dire où se cache une vulnérabilité possible. Et en corrigeant ces erreurs, le développeur rend son application plus fiable et réduit la probabilité d'une menace de 0 jour.
Il existe différents outils pour les tests de sécurité statiques. Pour démontrer les capacités de gestion des vulnérabilités, arrêtons-nous sur l'outil
PVS-Studio . Les avertissements de cet analyseur peuvent être classés comme CWE. Regardons quelques exemples.
Avertissement PVS-Studio:
CWE-561 : code mort (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
Ce code a fait par inadvertance une faute de frappe. Dans deux conditions
if , la même variable est vérifiée. A en juger par l'exception générée, dans la deuxième condition, la variable
outputPath doit être vérifiée. Par conséquent, une partie du code est inaccessible.
De telles erreurs semblent inoffensives à première vue. Cependant, cette impression peut être très trompeuse. Considérons une erreur très simple et à première vue inoffensive liée à la duplication de l'opérateur
goto .
À un moment donné, cette erreur a provoqué une vulnérabilité dans le système d'exploitation iOS.
CVE-2014-1266 Description de la vulnérabilité: fonction SSLVerifySignedServerKeyExchange dans libsecurity_ssl / lib / sslKeyExchange.c dans la fonction de transport sécurisé du composant Data Security d'Apple iOS 6.x avant 6.1.6 et 7.x avant 7.0.6, Apple TV 6.x avant 6.0.2, et Apple OS X 10.9.x avant 10.9.2 ne vérifie pas la signature dans un message TLS Server Key Exchange, ce qui permet aux attaquants man-in-the-middle d'usurper les serveurs SSL en utilisant un arbitraire clé privée pour l'étape de signature ou en omettant l'étape de signature.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
En raison du double
goto , une situation avec du code inaccessible se produit également. Quelles que soient les conditions, la deuxième instruction goto sera exécutée dans les instructions
if . Cela conduit au fait que la vérification de la signature n'a pas lieu. La fonction renvoie 0, ce qui signifie que tout va bien avec la signature, puis le programme reçoit la clé du serveur, même s'il y a un problème avec la signature. Cette clé est nécessaire pour crypter les données pendant la transmission.
Les conséquences d'une erreur aussi simple sont très graves. Par conséquent, cela n'a aucun sens de dire à quel point telle ou telle erreur est classée comme CWE. Il suffit de le corriger, ce qui rend le code plus sûr.
Soit dit en passant, l'erreur décrite pourrait facilement être détectée par l'analyseur PVS-Studio. Il donnerait immédiatement deux avertissements CWE:
Regardons un autre exemple. En 2012, on a découvert le problème de sécurité dans MySQL, dans lequel un attaquant pouvait entrer dans la base de données MySQL. Je vais fournir un extrait de code qui a servi de raison à cela.
CVE-2012-2122 Description : sql / password.c dans Oracle MySQL 5.1.x avant 5.1.63, 5.5.x avant 5.5.24 et 5.6.x avant 5.6.6, et MariaDB 5.1.x avant 5.1.62, 5.2.x avant 5.2.12, 5.3.x avant 5.3.6 et 5.5.x avant 5.5.23, lors de l'exécution dans certains environnements avec certaines implémentations de la fonction memcmp, permet aux attaquants distants de contourner l'authentification en s'authentifiant à plusieurs reprises avec le même mot de passe incorrect, qui finit par entraîner une comparaison de jetons en raison d'une valeur de retour mal vérifiée.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
Le type de retour de la fonction
memcmp est int , et le type de retour de la fonction
check_scramble est my_bool , en fait,
char . Par conséquent, un
int est converti en un caractère, dans lequel les bits de poids fort sont ignorés. Cela a conduit au fait que dans environ 1 cas sur 256, il était possible de se connecter avec n'importe quel mot de passe, en connaissant le nom d'utilisateur.
Encore une fois, cette erreur CWE pourrait être neutralisée et empêchée de se transformer en CVE même au stade de l'écriture du code. Par exemple, l'analyseur statique PVS-Studio génère l'avertissement suivant:
CWE-197 (
V642 ): Erreur de troncature numérique.
Dans la continuité de cette rubrique, je propose de lire l'article «
Comment PVS-Studio peut-il aider à rechercher des vulnérabilités? ».
Conclusion
Vulnérabilités 0 jours - une chose contre laquelle il n'y a aucune protection garantie. Mais la probabilité de leur apparition peut être considérablement réduite. Pour cela, des solutions SAST spécialisées telles que PVS-Studio peuvent être utilisées. Si votre projet détecte des erreurs pouvant être classées comme CWE, vous devez y prêter attention et les corriger. Bien que seule une petite quantité de CWE remplisse la liste CVE en éliminant les erreurs CWE, vous protégez votre application de nombreuses menaces potentielles.
Liens annexes
- Téléchargez et essayez PVS-Studio
- Technologies utilisées dans l'analyseur de code PVS-Studio pour rechercher des erreurs et des vulnérabilités potentielles
- Classification des avertissements PVS-Studio selon l'énumération commune des faiblesses (CWE)
- Classification d'avertissement PVS-Studio selon la norme de codage SEI CERT
Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien vers la traduction: Ekaterina Nikiforova.
PVS-Studio Static Analyzer comme outil de protection contre les vulnérabilités Zero-Day .