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".
mercredi 23 septembre 2009
dimanche 6 septembre 2009
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'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.]
- 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.]
jeudi 13 août 2009
Oh, peine, Office !
La suite Microsoft Office sera-t-elle interdite aux states ? Un juge Texan a prononcé sa sentence mardi dernier, lors d'une affaire de violation de brevet. La société canadienne i4i accuse ainsi la firme de Redmond (Microsoft quoi) de violer un brevet qu'elle a déposé en 1998, relatif aux formats XML.
Sachant que Word 2003 et 2007 (et 2010) se basent sur les formats .docx qui reposent sur du XML, le juge a fixé à 290 millions de dollars les dommages et intérêts.
Face à cette interdiction un peu gênante, Microsoft compte bien faire appel : preuves à l'appui, ils estiment n'avoir violé aucun brevet, et qualifient même d'invalide celui revendiqué par i4i.
En fin de compte, Office n'est pas la seule suite à se baser sur des formats XML, à ma connaissance toutes autres les suites existantes le sont : OpenOffice et ses dérivés et ancêtres, KOffice, etc. Que va-t-il donc se passer pour tous ces logiciels libres ou non, dont les développeurs n'ont surement pas les moyens de payer de telles indemnités ?
Est-ce la fin du monde des suites bureautiques ?
[Source]
Sachant que Word 2003 et 2007 (et 2010) se basent sur les formats .docx qui reposent sur du XML, le juge a fixé à 290 millions de dollars les dommages et intérêts.
Face à cette interdiction un peu gênante, Microsoft compte bien faire appel : preuves à l'appui, ils estiment n'avoir violé aucun brevet, et qualifient même d'invalide celui revendiqué par i4i.
En fin de compte, Office n'est pas la seule suite à se baser sur des formats XML, à ma connaissance toutes autres les suites existantes le sont : OpenOffice et ses dérivés et ancêtres, KOffice, etc. Que va-t-il donc se passer pour tous ces logiciels libres ou non, dont les développeurs n'ont surement pas les moyens de payer de telles indemnités ?
Est-ce la fin du monde des suites bureautiques ?
[Source]
Apple ferme les yeux...
... surement pour se protéger des éclats de verre que peuvent projeter certains iPhones. L'actu se retrouve partout dans les medias, mais en tant qu'experts en sécurité, on rigole bien en voyant ça. Après des failles logicielles, les produits vendus par Apple sont victimes de surchauffes ou d'(ex|im)plosions, comme c'est le cas récemment pour deux iPhones.
Il y a donc manifestement une vulnérabilité sur les écrans de ces téléphones : peut-être à cause d'une surchauffe due à une housse (ou pas), les écrans peuvent se fissurer, voire projeter des éclats de verre. Là encore, Apple semble démentir et incriminer des chocs dus aux utilisateurs... qui de leur côté affirment que leur joujou explose sans qu'on ait fait tomber de pommes dessus.
Des cas de dysfonctionnement ont été recensés de nombreuses fois, souvent à cause de batteries au lithium défectueuses. Des rappels massifs ont déjà été faits il y a quelques années, mais l'histoire continue encore et encore...
Avis aux possesseurs, il vaut mieux surveiller votre téléphone, et s'il commence à faire des bruits bizarres, n'hésitez pas à le lancer sur votre boss. Après tout, l'iPhone est peut-être voué à devenir la prochaine arme des Corses ou d'Al-Qaïda ?
[Source]
Il y a donc manifestement une vulnérabilité sur les écrans de ces téléphones : peut-être à cause d'une surchauffe due à une housse (ou pas), les écrans peuvent se fissurer, voire projeter des éclats de verre. Là encore, Apple semble démentir et incriminer des chocs dus aux utilisateurs... qui de leur côté affirment que leur joujou explose sans qu'on ait fait tomber de pommes dessus.
Des cas de dysfonctionnement ont été recensés de nombreuses fois, souvent à cause de batteries au lithium défectueuses. Des rappels massifs ont déjà été faits il y a quelques années, mais l'histoire continue encore et encore...
Avis aux possesseurs, il vaut mieux surveiller votre téléphone, et s'il commence à faire des bruits bizarres, n'hésitez pas à le lancer sur votre boss. Après tout, l'iPhone est peut-être voué à devenir la prochaine arme des Corses ou d'Al-Qaïda ?
[Source]
lundi 10 août 2009
british fail
Désolé pour le retard, mais une info qui vaut le coup d'être relayée sur ce blog.
La nouvelle carte d'identité britannique, qui avait déjà fait parler d'elle pour les sommes colossales qu'elle avait engloutie pour rien. En effet, sa réalisation a couté tellement d'argent que les autorités britannique avaient exclu le développement de lecteurs spécifiques pour la carte. Juste une puce sans lecteur, ça s'annonçait déjà bien. Les choses ont avancé et les voilà avec une carte d'identité complètement altérable en 12minutes!!11
prévoir 5milliard pour équiper les gens d'une carte hackable si c'est pas de l'epic fail ca o_O.
avec en bonus la mauvaise foi du home office :) (lisez l'article en anglais)
La nouvelle carte d'identité britannique, qui avait déjà fait parler d'elle pour les sommes colossales qu'elle avait engloutie pour rien. En effet, sa réalisation a couté tellement d'argent que les autorités britannique avaient exclu le développement de lecteurs spécifiques pour la carte. Juste une puce sans lecteur, ça s'annonçait déjà bien. Les choses ont avancé et les voilà avec une carte d'identité complètement altérable en 12minutes!!11
prévoir 5milliard pour équiper les gens d'une carte hackable si c'est pas de l'epic fail ca o_O.
avec en bonus la mauvaise foi du home office :) (lisez l'article en anglais)
It had seen “no evidence” that personal data was accessible or changeable, and the card had "excellent" security, the Home Office said.bref vous trouverez à présent différents articles un peu partout, mais si vous avez la flemme de chercher, en voici un (en francais en plus :) ca faisait longtemps) et un en anglais un peu plus "direct".
mercredi 5 août 2009
Quand l'écureuil part en cahuète...
Une bonne nouvelle pour les gens qui utilisent le webmail squirrelMail. Eh oui en plein dans le mille, c'est le cas de notre école donc vous aussi!
Le serveur du projet s'était un peu fait rentrer dedans mi-juin(ou peut être bien avant même) par des gens tout plein de bonnes intentions :). Après avoir constaté les dégâts, les administrateurs ont innocemment expliqué que "C'est bon, les gens ont pas fait ça pour toucher au code". Ouf! on l'a échappé belle.
Nous voici donc début août et là qu'est ce qu'on apprend? que trois plug-ins ont été modifiés lors de cette attaque. Lesquels me direz vous et l'intérêt?
Les nouveaux modules sont bien entendu dispos avec des hashs pour vérifier leur intégrité. En attendant, vu l'assiduité aux mises à jour de l'école je ne pense pas qu'on ai à s'inquiéter de quoique ce soit ^^.
le site de squirrelMail, l'article
Le serveur du projet s'était un peu fait rentrer dedans mi-juin(ou peut être bien avant même) par des gens tout plein de bonnes intentions :). Après avoir constaté les dégâts, les administrateurs ont innocemment expliqué que "C'est bon, les gens ont pas fait ça pour toucher au code". Ouf! on l'a échappé belle.
Nous voici donc début août et là qu'est ce qu'on apprend? que trois plug-ins ont été modifiés lors de cette attaque. Lesquels me direz vous et l'intérêt?
- sasql-3.2.0
- multilogin-2.4-1.2.9
- change_pass-3.0-1.4.0
The new versions steal passwords, among other things, and send them to an offsite server.Bref toute les versions mises à jour depuis personne-sait-trop-quand n'étaient ni plus ni moins que des collecteurs de mot de passes.
Les nouveaux modules sont bien entendu dispos avec des hashs pour vérifier leur intégrité. En attendant, vu l'assiduité aux mises à jour de l'école je ne pense pas qu'on ai à s'inquiéter de quoique ce soit ^^.
le site de squirrelMail, l'article
mardi 4 août 2009
cloud computing: trop dans les nuages?
Je vais aujourd'hui m'attarder sur une présentation d'Alex Stamos au blackhat 2009 concernant le cloud computing. Pas de réelle vulnérabilité ou d'exploit fantastique mais des considérations sur la sécurité qui valent la réflexion:
Il semblerait que la génération de nombres aléatoires, un problème réglé depuis des années, en redevienne un.
En effet, pour petit rappel, l'ordinateur utilise les périphériques bas niveau pour collecter des données aléatoires. Il se sert ensuite de ce "réservoir" pour obtenir des nombres "vraiment" aléatoires (donc quasiment non prédictibles). Mais le cloud computing serait en train de changer la donne:
Là ou un pc utilise les mouvements de la souris et les touches du claviers pour collecter de l'aléatoire, un serveur ne possède rien de cela. Il peut toutefois utiliser les mouvements du disque dur comme source d'aléa. Mais qu'en est il d'un serveur virtualisé? N'ayant pas accès aux matériels physiques, il ne lui reste que la mesure du temps exacte depuis sa mise en route, ce qui est bien peu et pas assez pour générer des nombres robustes.
Bien sur plus le temps passe et plus les ressources d'éléments aléatoires sont importantes. Mais Alex Stamos s'intéresse aux machines générées à la volée pour une tache particulière. Ces dernières sont éphémère et d'après lui n'ont pas le temps d'atteindre des seuils raisonnables de ressources aléatoire.
Il imagine ainsi un scénario où l'attaquant se crée une machine sur un serveur. Le peu d'entropie l'aidera grandement dans la prédiction des nombres aléatoires et réduira ainsi considérablement le temps de crackage du chiffrement des autres machines virtualisé.
Ce n'est bien sur à l'heure actuelle que de l'extrapolation, mais loin d'être une chimère ce fait mérite d'y porter attention. Juste en petit exemple du défaut d'entropie des systèmes virtualisés je vous cite un commentaire du dernier article:
ca laisse songeur n'est ce pas...
Les deux articles (bien plus complets et abordant pour le second d'autres problèmes que l'aléa) sur cette conférence: ici et là
Il semblerait que la génération de nombres aléatoires, un problème réglé depuis des années, en redevienne un.
En effet, pour petit rappel, l'ordinateur utilise les périphériques bas niveau pour collecter des données aléatoires. Il se sert ensuite de ce "réservoir" pour obtenir des nombres "vraiment" aléatoires (donc quasiment non prédictibles). Mais le cloud computing serait en train de changer la donne:
Là ou un pc utilise les mouvements de la souris et les touches du claviers pour collecter de l'aléatoire, un serveur ne possède rien de cela. Il peut toutefois utiliser les mouvements du disque dur comme source d'aléa. Mais qu'en est il d'un serveur virtualisé? N'ayant pas accès aux matériels physiques, il ne lui reste que la mesure du temps exacte depuis sa mise en route, ce qui est bien peu et pas assez pour générer des nombres robustes.
Bien sur plus le temps passe et plus les ressources d'éléments aléatoires sont importantes. Mais Alex Stamos s'intéresse aux machines générées à la volée pour une tache particulière. Ces dernières sont éphémère et d'après lui n'ont pas le temps d'atteindre des seuils raisonnables de ressources aléatoire.
Il imagine ainsi un scénario où l'attaquant se crée une machine sur un serveur. Le peu d'entropie l'aidera grandement dans la prédiction des nombres aléatoires et réduira ainsi considérablement le temps de crackage du chiffrement des autres machines virtualisé.
Ce n'est bien sur à l'heure actuelle que de l'extrapolation, mais loin d'être une chimère ce fait mérite d'y porter attention. Juste en petit exemple du défaut d'entropie des systèmes virtualisés je vous cite un commentaire du dernier article:
The same problem (lack of randomness) may also affect IP sequence number generation for virtual machines. A quick nmap scan of a Fedora Core 10 system running as a VM ends with:
TCP Sequence Prediction: Difficulty=0 (Trivial joke)
but the same host running Fedora Core 11 natively gives:
TCP Sequence Prediction: Class=random positive increments
Difficulty=939462 (Good luck!)
Cheers,
Dave
ca laisse songeur n'est ce pas...
Les deux articles (bien plus complets et abordant pour le second d'autres problèmes que l'aléa) sur cette conférence: ici et là
Inscription à :
Articles (Atom)