Chaouki Bekrar (VUPEN Security) "Le plus mauvais élève est incontestablement l'organisation Linux Kernel"
Techniques de fuzzing, failles zéro-jour, pratiques des éditeurs en matière de publication de correctifs, besoin de réactivité et contraintes de mise à jour pour les entreprise : le regard d'un expert des failles de sécurité.
Relevez-vous des tendances dans l'évolution des failles depuis les deux dernières années ?
Le nombre total de vulnérabilités découvertes chaque année est relativement stable néanmoins la proportion des failles de type zero-day est en nette progression et le nombre de vulnérabilités des applications Web a doublé.
L'utilisation des techniques de fuzzing pour la recherche de vulnérabilités s'est considérablement développée aux cours des deux dernières années et a permis la découverte d'un grand nombre de failles dites coté-client, c'est à dire les navigateurs web et les applications de gestion et de traitement des fichiers.
Les applications en lien avec les navigateurs Web semblent souffrir de plus en plus de failles. Est-ce bien le cas ? Cela signifie-t-il qu'elles sont insuffisamment sécurisées ?
Les navigateurs Web sont depuis quelques années la cible privilégiée des chercheurs en sécurité et des hackers non pas parce qu'ils sont insuffisamment sécurisées mais plutôt parce qu'ils sont le vecteur d'attaque le plus simple à mettre en œuvre dans des attaques massives.
La faiblesse des contrôleurs ActiveX explique elle aussi, en partie, la recrudescence des attaques contre les navigateurs. Enfin, le perfectionnement des techniques d'exploitation de ce type de failles permet aujourd'hui le développement d'exploits pouvant fonctionner avec un même navigateur quelle que soit sa version ou sa langue.
"Les éditeurs ont amélioré leurs procédures de correction des vulnérabilités"
Les éditeurs ont-ils selon vous accru leur réactivité pour combler les failles de leurs logiciels ? Communiquent-ils suffisamment bien sur la criticité des failles dans leurs bulletins ? Il est reproché à Apple notamment de rester souvent trop vague.
Les éditeurs ont amélioré leurs procédures de correction des vulnérabilités, mais le temps nécessaire au développement et à la publication d'un correctif reste assez long : il faut compter plusieurs mois avant la correction d'une vulnérabilité rapportée à Microsoft ou à Mozilla, et dans certains cas le délai peut atteindre un à deux ans pour certaines vulnérabilités affectant des produits Oracle par exemple.
La majorité des éditeurs communiquent de manière transparente sur la criticité réelle des failles dans leurs bulletins car ils sont conscients que des sociétés de sécurité et de reverse engineering comme VUPEN Security vont décortiquer et analyser chaque vulnérabilité afin d'en déterminer la cause, les conséquences et l'exploitabilité réelle. Sous-évaluer la criticité d'une vulnérabilité pourrait, en plus de nuire à l'image de l'éditeur, nuire à la sécurité des utilisateurs qui n'auront pas été avertis du risque réel qu'ils encourent.
Il y a-t-il encore de mauvais élèves côté éditeurs ? Oracle est souvent pointé du doigt.
Oracle a revu il y a quelques mois ses bulletins de sécurité et a introduit une matrice de risque détaillant les différents aspects de chaque vulnérabilité - vecteur d'attaque, complexité et conséquences -, ce qui permet d'avoir une vision précise de la criticité des failles corrigées.
Le plus mauvais élève est incontestablement l'organisation Linux Kernel qui corrige les vulnérabilités du noyau Linux sans en indiquer la criticité ou les conséquences, et sans publier de bulletin dédié.
"L'utilisation de techniques virales pour des correctifs n'est pas adapté à un environnement d'entreprise"
Le projecteur est surtout dirigé sur la réactivité des éditeurs, mais les entreprises sont-elles assez promptes pour appliquer les correctifs ? A quoi sert-il aux éditeurs finalement d'être rapides compte tenu de la difficulté à déployer les correctifs ?
Il est vrai que certaines entreprises ont des procédures de déploiement des correctifs assez longues notamment à cause des nécessaires tests de compatibilité et de non-régression. D'autres entreprises et organisations sensibles font le choix d'appliquer les correctifs rapidement préférant prendre le risque de subir les conséquences d'une incompatibilité plutôt que de subir celles d'un incident de sécurité.
Les éditeurs doivent donc être réactifs pour permettre aux entreprises qui le souhaitent de procéder rapidement au déploiement des correctifs de sécurité.
Une rumeur a circulé récemment sur l'utilisation par Microsoft de techniques virales, comme les vers, pour déployer des correctifs plus facilement. Pourrait-ce être une piste à étudier ?
C'est une piste qui n'est pas réaliste. L'utilisation de techniques virales pour l'installation des correctifs signifieraient leur déploiement automatique et à distance sans le consentement préalable de l'utilisateur, ce qui n'est absolument pas adapté à un environnement d'entreprise.
Les simples différences de versions, de services packs et de langues entre les systèmes à corriger rendent déjà peu possible la mise en œuvre, à grande échelle, d'une telle technique.
Quels outils sinon pour un RSSI ou un DSI pour suivre les failles ?
Le suivi des failles doit s'organiser autour de deux axes : premièrement en amont du déploiement des correctifs, c'est-à-dire en répertoriant les différents composants physiques ou logiques du parc informatique de l'entreprise (systèmes d'exploitation, applications, serveurs, bases de données, et tous les logiciels et matériels) et en surveillant, au jour le jour, l'apparition de nouvelles vulnérabilités affectant un de ces composants.
C'est la vocation de notre solution VUPEN VNS (Vulnerability Notification Service) qui permet aux RSSI et DSI de recevoir, en fonction de leur environnement informatique, des bulletins décrivant les nouvelles failles découvertes ou corrigées.
Deuxièmement en aval, après le déploiement du correctif. Cette étape incontournable consiste à la fois à vérifier que le correctif soit bien appliqué mais aussi qu'il est réellement efficace et, pour ce faire, il est nécessaire pour chaque nouvelle vulnérabilité critique corrigée de simuler une attaque en utilisant des codes d'exploitation (exploits) professionnels, récents et de qualité, comme ceux que nous développons et fournissons dans le cadre de notre service VUPEN Exploits & PoCs.