Histoire du bug : tout savoir sur les bugs et les vulnérabilités des logiciels

Comment sont détectées les vulnérabilités logicielles ?

La plupart des bugs logiciels sont découverts par des chercheurs en sécurité que nous surnommons affectueusement « chasseurs de primes ». Les primes aux bugs sont des programmes gérés par des éditeurs de logiciels (et des sociétés de sécurité externes) qui offrent souvent des récompenses en espèces à des chercheurs sur les menaces et à des pirates informatiques éthiques qui découvrent et signalent des bugs que les éditeurs peuvent reproduire, pour finalement fournir un « correctif », souvent sous la forme d’un patch ou d’instructions de modification de configuration.

Les bugs peuvent également être découverts par des pirates informatiques peu éthiques ou des acteurs malveillants ayant des objectifs moins honorables. Et lorsque ces derniers découvrent des vulnérabilités, contrairement à nos amis chasseurs de primes, ces mauvais acteurs ne les signalent pas aux éditeurs, ni à qui que ce soit d’ailleurs. Ils les utilisent à des fins malveillantes.

Le Known Exploited Vulnerabilities Catalog (catalogue des vulnérabilités connues et exploitées) répertorie les vulnérabilités identifiées et exploitées lorsqu’elles sont connues à des fins malveillantes, souvent à la suite d’une enquête sur une infraction ou une série d’infractions.

Parmi les motivations les moins honorables en matière de piratage, citons :^[1]

• Les gains financiers : cela comprend les ransomwares, le vol direct des victimes, la vente de données sur le Dark Web, etc.
• Les messages politiques : l’« hacktiviste » cherche à perturber les sites Web, les systèmes, etc. pour soutenir une idéologie spécifique.
• La vengeance : employés mécontents, clients insatisfaits ou autres personnes qui causent des dommages pour assouvir une vengeance personnelle.
• La renommée : des hackers en quête de reconnaissance.
• Le vol de la propriété intellectuelle :  la motivation du vol de la propriété intellectuelle est particulièrement dangereuse pour les entreprises et autres organisations, car cette catégorie tend à inclure des attaques soutenues par des États ou des entreprises, qui visent tous les domaines, des plans d’armement aux brevets de produits. Les pirates informatiques sponsorisés par des États disposent souvent d’un temps et d’un financement illimités pour trouver un moyen de pirater leur cible.

Mitre dresse une liste exhaustive des groupes de menace. Les groupes de menaces persistantes avancées (APT) ^[2], tels que DeputyDog (APT17), Buckeye (APT3) et le terrifiant Double Dragon (APT41)^[3], sont des exemples de ces acteurs étatiques.

Gartner a également fait part de ses préoccupations en matière de sécurité en déclarant : « Il est impossible pour une organisation, quel que soit son niveau de maturité en matière de sécurité, d’atteindre un niveau à zéro vulnérabilité dans son environnement »[^[4]

Anecdote à propos des bugs :

De nombreux éditeurs de logiciels exigent un accord de confidentialité (NDA) pour la participation à des programmes de primes aux bugs afin d’empêcher la divulgation prématurée des vulnérabilités et de décourager les mauvais acteurs d’exploiter les vulnérabilités avant que les clients aient la possibilité de récupérer, de tester et d’appliquer les correctifs^[5].

Comment les éditeurs réagissent aux bugs

Savez-vous ce que les éditeurs sont tenus de faire lorsque des bugs sont découverts dans leurs logiciels ? En général, rien. Pourquoi ? Parce que l’accord d’utilisationt^[6] que les détenteurs de licences signent les protège généralement via des clauses de non-responsabilité en matière de garanties et de recours. Cela n’empêche pourtant pas les éditeurs d’agir. Pour cela, de manière générale :

• Ils examinent les bugs soumis
• Ils les reproduisent (en suivant les instructions du chasseur de primes)
• Ils valident le bug, identifient les produits concernés et acceptent les mesures pour corriger le bug
• Ils développent un correctif
• Ils intègrent le nouveau correctif à leurs packages de mise à jour tels que les mises à jour critiques des correctifs Oracle (CPU) ou SAP Security Patch Day

Ce processus peut prendre du temps, de quelques semaines à plusieurs années.

Anecdote à propos des bugs :

Le NIST suit la soumission de nouvelles vulnérabilités dans une base de données nationale sur les vulnérabilités (NVD). En 2023, plus de 29 000 failles de sécurité ont été enregistrées en tant que vulnérabilités et expositions communes (CVE) et 2024 est en passe de dépasser 2023^[7].

Comment sont identifiées les vulnérabilités et les expositions communes (CVE) ?

Il est utile de nommer les bugs logiciels (il s’agit en réalité de numéros). Heureusement, les autorités de numérotation CVE, notamment les chercheurs et les éditeurs de logiciels^[8] attribuent des identifiants CVE à partir de blocs de numéros réservés pré-attribués fournis par le NIST.^[9] Ils attribuent un enregistrement CVE par vulnérabilité soumise afin que les experts en cybersécurité puissent suivre et signaler les correctifs et les mesures d’atténuation pour les logiciels.

Remarque : la date de création du CVE correspond à la date à laquelle le numéro a été attribué pour la première fois à un éditeur, ce qui peut être très différent de la date à laquelle la vulnérabilité a été découverte^[10].

Anecdote à propos des bugs :

Par définition, les listes CVE reposent sur un principe de volontariat et sont incomplètes, car les éditeurs n’ont aucune obligation de signaler les bugs dans les logiciels nouveaux ou anciens^[11]. En outre, bien que le MITRE et le NIST fournissent des lignes directrices et des normes pour les soumissions CVE par souci de cohérence, les éditeurs ne sont pas obligés de les respecter.

Élaborer une réponse en matière de sécurité et de gestion des risques (SRM)

Si vous réagissez à la découverte d’un nouveau bug logiciel : « Génial ! Encore un bug ! Et encore un correctif ! », vous n’êtes pas seul.

Cependant, ce bug ou cette vulnérabilité est probablement présent dans le logiciel depuis qu’il a été écrit pour la première fois par le développeur (à moins qu’il n’ait été introduit par un correctif) et comme les acteurs malveillants peuvent rapidement exploiter un bug, il est judicieux de disposer d’un plan de riposte contre les bugs.

L’application de correctifs par l’éditeur est une défense courante, mais laborieuse, avec les exemples d’étapes suivants :

• Choisir des correctifs parmi les mises à jour correctifs critiques (CPU) Oracle ou le Security Patch Day de SAP
• Regrouper les correctifs et les tester sur un serveur hors production
• Confirmer qu’ils n’affectent pas les données critiques telles que des bilans comptables ou des dossiers médicaux.
• Planifier les temps d’arrêt et mettre les systèmes de production hors ligne pour appliquer les correctifs
• Répéter l’intégralité du processus si l’éditeur publie de nouveaux correctifs en réponse aux commentaires des utilisateurs à propos des correctifs d’origine

Anecdote à propos des bugs :

Le temps moyen d’exploitation des bugs dans la nature n’était que de 4 jours en 2024^[12], contre plus de 74 jours en 2014.^[13]

Aborder les correctifs de sécurité

Bien qu’il soit courant de se tenir informé sur les correctifs de sécurité des éditeurs pour atténuer les vulnérabilités^[14], il n’est pas rare que les entreprises aient du mal à appliquer des correctifs^[15] car cela peut nécessiter :

• Des ressources IT extrêmement qualifiées^[16] et une planification, des tests et des temps d’arrêt du système très longs^[17]
• De longues attentes (des mois, voire des années) pour que les vulnérabilités des logiciels soient détectées et que les correctifs soient fournis, testés et installés^[18]
• Des mises à jour logicielles potentiellement coûteuses et à faible retour sur investissement pour continuer à recevoir les nouveaux correctifs de sécurité de l’éditeur sur les versions logicielles qui ne reçoivent plus de mises à jour de sécurité de l’éditeur^[19]

Une stratégie basée uniquement sur l’application de correctifs se heurte aux difficultés suivantes :

• Atténuer rapidement tous les risques liés à la cybersécurité^[20]
• Prendre en compte des configurations système ou des données uniques^[21]
• Les correctifs des éditeurs ne sont pas spécifiquement conçus pour protéger le code personnalisé développé par un client ou pour tenir compte de l’environnement et de l’architecture particulière d’un client
• Le développement et l’application des mises à jour de sécurité des éditeurs peuvent prendre beaucoup de temps, ce qui retarde la protection contre les menaces connues

De plus, un temps d’arrêt considérable est nécessaire pour appliquer les correctifs des systèmes et les mettre à jour. Cela peut provoquer des frictions entre les équipes de sécurité qui tentent de déployer toutes les tactiques disponibles pour réduire les risques et les équipes d’exploitation IT chargées du temps de fonctionnement et de la continuité des activités^[22].

Anecdote à propos des bugs :

Aucune solution unique ne peut garantir que vous pourrez trouver et corriger toutes les vulnérabilités..^[23]

Comment Rimini Protect™ corrige les vulnérabilités logicielles

De nombreux systèmes logiciels d’entreprise sont au cœur des activités de leurs clients depuis des décennies et ont désormais dépassé la date de fin du support fourni par les éditeurs, ce qui signifie que peu ou pas de nouveaux correctifs de sécurité sont disponibles pour ces systèmes. De plus, les correctifs de sécurité ne sont généralement pas disponibles lorsqu’un client quitte le support de l’éditeur.

Rimini Street permet une approche axée sur l’entreprise et les données pour prioriser l’atténuation des risques. Nous nous concentrons sur l’amélioration des postures de sécurité et la réduction de l’exposition au risque de sécurité sans appliquer les correctifs de sécurité fournis par l’éditeur ou modifier le code de l’éditeur.

En raison de la disponibilité limitée des correctifs de sécurité, de nombreuses organisations ont déjà mis en place d’autres stratégies de défense pour protéger leurs logiciels. Les solutions Rimini Protect sont adaptées à l’écosystème d’un client afin de compléter et d’améliorer leurs stratégies de sécurité existantes pour les protéger contre  les menaces et les vulnérabilités connues (découvertes) et inconnues (non découvertes).

En savoir plus sur Rimini Protect

Réponses aux questions fréquentes sur les vulnérabilités des logiciels

Quelle est la différence entre une faiblesse et une vulnérabilité logicielle ?

Les faiblesses sont des conditions logicielles ou matérielles qui peuvent conduire à une vulnérabilité. Mitre tient à jour une liste de faiblesses connue sous le nom de Common Weakness Enumerations (CWE). Une vulnérabilité est un « bug » ou une erreur qui peut être directement utilisée pour exploiter (accéder) un système. Le NIST tient à jour une base de données nationale des vulnérabilités connue sous le nom de Common Vulnerability Enumerations (CVE).

Quels sont les exemples de vulnérabilités logicielles ?
Considérez les vulnérabilités comme un moyen de tirer parti du contexte (faiblesse) pour exploiter un système. Dans CWE-787, il existe une liste non exhaustive des nombreuses manières dont cette faiblesse a été utilisée pour exploiter les systèmes. Parmi les vulnérabilités logicielles, citons la corruption de la mémoire (CVE-2021-28664), la possibilité de « s’échapper » d’un environnement de test ou sandbox (CVE-2020-0041), etc.

Quels sont les exemples de faiblesses logicielles ?
Il faut voir les faiblesses logicielles comme le contexte de la situation. Par exemple, CWE-787 s’intitule « Out-of-bounds Write » (écriture hors limites), c’est-à-dire l’écriture de données avant ou après la zone de mémoire à laquelle le programme est censé accéder. Permettre l’écriture de données dans des zones inattendues de la mémoire peut entraîner des résultats imprévisibles et constitue une faiblesse.

Quelle est la différence entre les logiciels malveillants et les vulnérabilités logicielles ?
Un logiciel malveillant est un programme qui peut être installé via un exploit destiné à compromettre la « confidentialité, l’intégrité ou la disponibilité des données, des applications ou du système d’exploitation de la victime ». Les vulnérabilités logicielles sont des « bugs » qui peuvent être utilisés pour exploiter un système.

Qu’est-ce qu’un exploit ?
Un exploit est un « mauvais acteur » qui utilise un programme ou un morceau de code pour tirer parti d’une faille de sécurité. La CISA tient une liste des vulnérabilités exploitées connues, appelée catalogue KEV.

Quels sont les exemples d’exploits ?
Voici quelques exemples d’exploits :

• Une personne ou une organisation utilisant les méthodes décrites dans CVE-2021-28664 pour écrire du code qui pourrait corrompre la base de données d’une entreprise.
• Une personne ou une entreprise utilisant les méthodes décrites dans CVE-2020-0041 pour écrire du code permettant un accès non autorisé aux fichiers d’un ordinateur afin de voler des informations sur les clients ou des secrets commerciaux.

Pourquoi les CWE sont-elles importantes ?
L’atténuation de la faiblesse générale peut généralement rendre inefficaces toutes les CVE mentionnées dans une CWE. Cela permet également de se protéger contre les vulnérabilités futures qui reposent sur la même faiblesse (protection proactive). C’est bien plus efficace que d’essayer de corriger chaque vulnérabilité une par une.