La sécurité des BBox serait-elle bbancale ?

En 2008, un dénommé Kevin Devine avait réussi à retrouver l'algorithme de génération des clés WPA sur les routeurs Thomson Speedtouch, permettant ainsi de récupérer une liste de clés potentielles pour un routeur particulier.

Le 20 septembre dernier, un administrateur du site crack-wpa.fr a fait part d'une faille dans les BBox, également fabriquées par Thomson. Il apparait que les clés WPA par défaut font toutes 10 caractères, et sont dérivées du numéro de série de la box. Une légère adaptation de l'algorithme cité précédemment permet ainsi de retrouver la clé WPA par défaut !

L'outil, nommé BBkeys, ainsi que de plus amples explications sont disponibles ici.

Une fois de plus, cela montre qu'il faut toujours changer les mots de passes/clés par défaut, même si elles sont censées être "aléatoires".

c'est la rentrée dans le fort Apache

Et oui, la fondation Apache, pourtant réputée attachée à la sécurité et rigoureuse, à été infiltrée. Ils ont pris la peine (souvent douloureuse à annoncer) de faire toute la transparence sur l'incident pour que, disent ils, les autres apprennent aussi de leurs erreurs. Le déroulement de l'attaque est assez astucieux et je vous invite à lire l'article complet sur the register, pour les fainéants voici un résumé:

• L'attaque débute par la compromission du serveur apachecon.com. Surement par l'exploitation des quelques failles noyaux permettant de passer root localement et dont les patchs tout récents (7jours) n'avaient pas encore été appliqués. Surement, car ce n'est qu'une supposition, les logs ont été détruits.
• Une fois root, il aurait utilisé la clé SSH d'un compte de backup pour se connecter à people.apache.org
• Partie intéressante de l'attaque, le pirate n'ayant qu'un compte limité, a déposé des scripts CGI à la racine de certains site permettant d'ouvrir un shell, etc...
• Il n'a alors plus eu qu'a attendre la procédure de backup. cette dernière s'est chargée de copier les scripts sur les serveurs de prod, ce que lui ne pouvait pas faire... (oh le fourbe)
• Une fois sur les serveurs de prod, les scripts se sont retrouvés directement accessibles via le net.->pwned

L'attaquant a su profiter de la fenêtre entre la sortie du patch et son application. Apache reconnait deux erreurs ayant permis cette attaque: une clé SSH commune aux machines de backup et l'utilisation d'execCGI.

Bien sur les admins, ont de suite fait les changements nécessaires et ont même renforcé un peu plus, ainsi on note:
l'ajout d'OTP (mots de passe à usage unique) pour les sudo des comptes avec des privilèges, une gestion encore plus strictes des connexions autorisées entre les machines.

Ils ont de même pu rapidement tout remettre en place grâce à l'usage de redondance dans les services et de ZFS

En tout cas on saluera leur démarche de transparence qui permet non seulement de voir ce qu'on pu faire les attaquants,comment et avec quelles conséquences, mais surtout de voir aussi qu'ils n'ont pas eu accès à des information sensibles :) .
[Il faut savoir que la fondation pratique l'hétérogénéité des systèmes, ce qui limite les élévations de privilèges et la profondeur d'une attaque. Un attaquant est obligé d'avoir des exploits nécessaires pour passer de machine en machine et encore, à condition qu'ils existent. si les systèmes utilisés sont tous les mêmes, l'attaquant n'a qu'a avoir le bon exploits, il fonctionnera partout.]