Equifax a publié aujourd’hui une annonce sur son site web avec plus d’informations concernant ce qu’il croit être la source de cette faille de sécurité massive.
Pour Equifax, il existe deux raisons majeures à cette fuite de données :
Nous savons que les cybercriminels ont exploité une vulnérabilité visant les applications des sites web aux États-Unis.
Cela n’est pas vraiment surprenant : l’étude DBIR menée par Verizon a montré à maintes reprises que les applications web étaient des cibles privilégiées vis-à-vis de cyberattaques, et de loin. Les cibles sont nombreuses, leur sécurité est généralement faible, et l’étude a montré que l’écart entre vulnérabilité/patch était plus important pour les applications web que pour la plupart des autres types d’applications. Nous vous en dirons davantage sur cet écart plus loin dans cet article.
La vulnérabilité était Apache Struts CVE-2017-5638.
Cette vulnérabilité Struts (à ne pas confondre avec le plus récent retour d’Apache Struts) était un vilain bug d’exécution de code à distance côté serveur, révélé au public en mars dernier. Paul Ducklin, de Naked Security, a analysé en profondeur le fonctionnement de ce bug dans son article, mais le point le plus important est le suivant :
Sans se connecter, sans chercher la page originale du formulaire web en premier lieu, et sans même avoir des données de formulaire à télécharger, un cybercriminel peut activer ce bug simplement en visitant la page web répertoriée dans le champ d’action de l’un de vos formulaires web.
Si vous utilisez Struts 2, à un endroit au sein de votre réseau, et que vous n’avez toujours pas appliqué le dernier correctif, vous devriez vraiment le faire, car cette vulnérabilité est facile à exploiter par quiconque désirant tout simplement essayer.
Il est possible que les serveurs vulnérables Equifax n’aient pas été délibérément ciblés, mais simplement pris dans un large filet tendu par des cybercriminels qui cherchaient simplement des serveurs Apache non patchés à attaquer. Pourtant, étant donné que cette vulnérabilité était connue depuis mars dernier, et que la faille de sécurité Equifax datait quant à elle du mois de mai, il s’agit d’un délai de plus de deux mois durant lequel un serveur vulnérable a été à la merci des cybercriminels.
La faille de sécurité Equifax est, malheureusement, un excellent exemple de cybercriminels profitant du délai fatal entre la découverte d’une vulnérabilité et la remédiation apportée à cette dernière. Divers chercheurs ont examiné le délai moyen pris par les entreprises pour patcher une vulnérabilité, et le résultat oscille entre 60 et 150 jours, selon la source citée par l’étude.
Cela signifie que les cybercriminels qui profitent des vulnérabilités ont tendance à avoir le temps de leur côté, et ils agissent généralement dans les 40 à 60 jours. Donc, dans de nombreux cas, ces derniers ont une marge de manœuvre d’environ deux mois avant qu’une vulnérabilité qu’ils veulent utiliser soit corrigée. Dans le cas d’Equifax, il semble que cette fameuse marge de manœuvre ait été suffisante pour que les cybercriminels commentent l’un des plus grands vols de données de l’histoire !
La sagesse la plus élémentaire, lorsque l’annonce d’une telle faille de sécurité fait le tour du monde, est de la corriger le plus rapidement possible. D’ailleurs ce conseil n’est pas un scoop pour la plupart des experts en informatique.
Dans un monde idéal, les correctifs seront testés et ensuite déployés dans leurs versions débuguées, au moment jugé opportun grâce à des ressources suffisantes. Le patch n’interagira avec aucun processus, et la vulnérabilité disparaîtra, aussi simplement que cela ! Mais la réalité est toujours plus compliquée bien sûr: les correctifs ne sont pas déployés aussi rapidement qu’ils le devraient, car la liste des patchs à développer est déjà assez longue !
Et parfois, corriger une vulnérabilité de sécurité peut rencontrer toutes sortes de problèmes imprévus dans les systèmes de production qui peuvent nécessiter de stopper le déploiement du patch (un autre scénario catastrophe !), et ce même si le patch a été testé avant son déploiement, ce qui n’est pas toujours le cas d’ailleurs. Dans le cas de Struts, étant donné qu’il s’agit d’une vulnérabilité côté serveur, il est possible que la mise en œuvre des correctifs impliquent que des systèmes majeurs soient déconnectés pour déployer les patchs, ce qui peut se révéler être un vrai cauchemar politique et logistique.
Quand un bug spécifique fait les gros titres, comme Heartbleed, le patch pour cette faille de sécurité devrait devenir une priorité absolue avec les projecteurs braqués sur elle (surtout à partir d’un exec de niveau C très préoccupant). Et souvent, des bugs moins médiatisés mais tout aussi dangereux sont ajoutés à la file d’attente, et il apparaît alors la notion d’acceptation des risques et celle d’espoir : quelles sont les chances pour que ces bugs atteignent mes systèmes pendant le délai nécessaire pour mettre en place les correctifs ?
En fin de compte, c’est un pari avec les données des clients, et lorsque le pari est perdu, ce sont les clients qui en souffrent le plus !
Billet inspiré de Equifax felled by a months-old Apache Struts vulnerability, sur Sophos nakedsecurity.
