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
lundi 3 août 2009
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
Inscription à :
Articles (Atom)