Akamai face à Heartbleed : « nous avons eu un bug »

Akamai compte parmi les poids lourds du Web, supportant de 15 à 30 % du trafic en ligne, selon ses propres chiffres. Dès le 8 avril, le spécialiste de l’optimisation de l’acheminement Web indiquait avoir déployé un correctif sur ses systèmes, avant même que la vulnérabilité Heartbleed d’OpenSSL n’ait été rendue publique. Un correctif reversé à la communauté. Dans un billet de blog, Andy Ellis, RSSI d’Akamai assurait alors que les clés privés de ses clients étaient en sécurité, grâce au recours à un « schéma spécifique et sécurisé d’allocation de la mémoire, contrôlant quelles portions de mémoire peut utiliser chaque librairie, et plus spécifiquement contrôlant l’espace de stockage des clés SSL et d’autres secrets. » Et d’expliquer ne pas penser que des clés privées aient pu être dérobées en exploitant la vulnérabilité Heartbleed avant sa correction.

Las, le chercheur Willem Pinckaers a rapidement monté que le système dit sécurisé d’allocation de la mémoire ne remplissait pas alors toutes ses fonctions. Avec ironie, il souligne ainsi que « la sécurité, c’est difficile parce que l’on peut pas toujours affirmer que ce que l’on fait fonctionne. » Et dans le cas d’Akamai, ce n’était pas le cas.

Et Andy Ellis de faire son mea culpa dans un billet de blog. Qu’il résume lui-même : « pour faire court, nous avons eu un bug. » Pendant que ses équipes continuent d’enquêter et de chercher à corriger le tir, il indique qu’Akamai « a entamé le processus de changement de toutes les clés et certificats SSL de ses clients. » Certains changements seront rapides, mais d’autres seront plus lents en raison du besoin de validation supplémentaire par les autorités de certification.