L'année 2008 est terminée.
Je ne vous ferai pas l'affront de vous en faire l'historique, cela a déjà été fait des dizaines de fois, et bien mieux que je ne l'aurais fait moi même

Restons simple donc, et permettez moi de m'associer à Benj0 afin de vous souhaiter à tous, une excellente année 2009 !

Je suis un peu en retard, mais mieux vaut tard que jamais.

La version 2.0 beta d'OllyDbg est disponible depuis le 23 Décembre 2008.
La version finale devrait donc être extrêmement similaire, à l'exception d'éventuels bogues corrigés.

Si Immunity Debugger séduit par la possibilité de scripter en python, et si IDA Pro reste la référence des desassembleurs, OllyDbg reste incontournable pour l'ingénierie inverse sous Win32.

Cerise sur l'opcode, OllyDbg qui est un produit d'excellente qualité, est totalement gratuit.

Après 3 mois d'absence, à priori pour cause de quelques problèmes d'hébergement, ARTeam revient... doucement.

Pour le moment, juste un forum a été mis en ligne ici.
Le reste devrait arriver plus tard et en attendant, vous pouvez toujours vous rendre sur le miroir.

Remplacer les precogs par des cameras, Pre-Crime par CCTV et John Anderton par la police locale.
Vous y êtes, CCTV nous fait un remake de Minority Report à la sauce Anglaise.

Cela pourrait être une farce mais, malheureusement, nous ne sommes pas le 1er Avril.
CCTV déploie son nouveau système qui devrait permettre, ni plus ni moins, que de prévoir les crimes. Bien voyons...
Grosso modo, le système serait capable de reconnaître les personnes sur les vidéos renvoyées par les nombreuses caméras déployées. La deuxième étape est alors d'analyser leur comportement.

Sachant qu'une personne qui se déplace lentement, s'arrête souvent ou reste dans le même secteur trop longtemps est considérée suspecte et peut être tenue d'expliquer son comportement à la police, on est en droit de s'attendre à une forte augmentation des contrôles d'identité dans la communauté des plus de 70 ans...

C'est débile, c'est très cher et ça fait ch*** les gens qui l'ont eux-mêmes financé en payant leurs taxes... Oui, c'est au UK.

Sur ce coup là, je ne suis pas en avance… Mais quelle idée de sortir un article en début d’un week-end de 4 jours ?

Je ne vais pas revenir sur les détails, l’article est très bien fait, et vous avez l’explication en français par Sid également.

Pour les conclusions, on peut dire ça : C’est pas encore la fin, mais ça sent pas bon. Donc, oubliez TKIP pour les déploiements Wi-Fi.

Néanmoins, je vais m’attarder un peu sur les contre-mesures. Les auteurs disent dans l’article :

« To prevent this attack, we suggest using a very short rekeying time, for example 120 seconds or less. In 120 seconds, the attacker can only decrypt parts of the ICV value at the end of a packet. Alternatively disabling the sending of MIC failure report frame frames on the clients would also prevent the attack. The best solution would be disabling TKIP and using a CCMP only network. »

Le deuxième point est le plus évident : désactiver TKIP et mettre en œuvre uniquement CCMP. Malheureusement, tous les clients sans fil en entreprise ne parlent pas encore AES-CCMP couramment. Donc, il va falloir trouver une solution… Le premier point va dans ce sens en proposant de diminuer le temps de rotation des clés de sessions.

Mouais, dans la théorie, c’est pas une mauvaise idée. Mais quelques problèmes à l’horizon : ajout de charge de traitement au point d’accès et le comportement des client sans fil va s’en retrouver modifié. C’est pas vraiment la meilleure solution. De plus qu'il faut faire attention aux conseils que l’ont peut trouver... Par exemple, le CERTA, dans son dernier bulletin d'actualité, dit : « Les points d’accès de type Aruba ("timer mkey-rotation-period") et Cisco ("broadcast-key change", "devshell dot1xUpdateBroadcastRekeyTimer") permettent par exemple de modifier ce paramètre. ». Pour la commande ArubaOS citée, elle ne concerne que les trames multicast. Ainsi, il est nécessaire d’utiliser également « timer ukey-rotation-period <nSeconds> » pour les unicast. Pour la commande Cisco, dans le Cisco Response to TKIP Encryption Weakness, il y est indiqué d’utiliser la commande « dot1x timeout reauth-period <nSeconds> » pour les bornes lourdes et « config wlan session-timeout <wlanID> <nSeconds> » pour une architecture en borne légère. Quoi qu’il en soit, avant de faire une modification sur votre architecture, valider avec votre intégrateur pour éviter que l’infrastructure sans fil s’écroule…

Personnellement, si la désactivation de TKIP est impossible, je pencherai pour une surveillance du réseau sans fil à l’aide de WIDS ou tout simplement les logs (parfois les SNMP Trap selon les éditeurs). En effet, l’attaque est bruyante et provoque des erreurs rares (MIC Failure).

On peut également noter que cette faille aura eu le mérite de faire comprendre que WPA, WPA2, TKIP et AES-CCMP se conjuguent à tous les temps : hé oui, WPA2/TKIP ça existe et WPA/AES-CCMP aussi. Autre point, maintenant tout le monde sait que RC4 est à AES ce que CCMP est à TKIP ! C’est beau le marketing : dans un des deux modes, on ne nomme pas l’algorithme de chiffrement, dans l’autre si C’est certain, suite aux déboires du WEP, mettre RC4 dans le nom du truc qui protège, ça donne pas confiance :D

M’enfin, pour ceux qui n'ont vraiment pas le choix, y'a toujours aussi la possibilité d'ajouter une couche VPN (ou alors tirer un câble).

C'est à peu près ce qu'a annoncé Gordon Brown suite aux multiples pertes de données sensibles / confidentielles survenues en Angleterre.
Quand le premier ministre explique que le gouvernement n'est pas capable de protéger les données qui lui sont confiées, on a beau dire, cela fait froid dans le dos.

Bon, reconnaître ses erreurs et en tirer des leçons, c'est bien.
Maintenant il serait peut être temps d'agir...

Belle boulette en tout cas du premier ministre britannique...

C'est un Dimanche pluvieux (un Dimanche à Londres quoi...), journée idéale pour faire un peu de reverse.
Toutefois, en bon geek de base, je commence par upgrader mon vieux kernel Linux 2.6.24 vers un pimpant 2.6.25.
L'opération se passe sans encombre, comme d'habitude.
On recompile les deux trois modules qui trainent et hop, on est prêt à lancer VMWare pour faire les fesses aux méchants malwares.

Bah oui mais non. Le module vmmon refuse de se charger.
Un rapide coup d'oeil à dmesg m'apprend que VMWare n'est pas content puisqu'il ne trouve pas le symbole "init_mm".
Heu... ouais c'est normal, il n'est plus exporté.
Aie. Que faire ?
Downgrader mon kernel ? Alors la, sûrement pas !

Apres quelques minutes de googlisation intense, me voila finalement en possession de la solution.
Donc, pour ceux qui auraient le même soucis, ajoutez la ligne suivante à votre .config:
CONFIG_UNUSED_SYMBOLS=y

Si vous utilisez l'interface curses pour configurer votre kernel (via make menuconfig), vous trouverez la petite case à cocher dans Kernel hacking sous le nom Enable unused/obsolete exported symbols.

Je n'ai pas pu résister à l'envie de partager cette photo, prise "à l'arrache".

Cela m'a fait penser aux fameux slogans des produits de sécurité IT.
- "Stop web threats before they reach you"
- "Maximum protection against all kinds of Internet threats"
- [...]

Moi je dis, autant être direct et clair dans son message, comme l'a été le propriétaire de ce véhicule

La DefCon est une conf. se tenant à Las Vegas, mais pas seulement.
C'est aussi un évènement mensuel prenant place au sein de la capitale Anglaise.

Ambiance très sympa et détendue, au premier étage d'un pub typique à proximité de Piccadilly Circus.

Des gens de profils très variés qui ont toutefois trois points communs:
- Ils aiment le hacking, dans son vrai sens
- Ils aiment la bière
- Ils aiment vraiment la bière

C'est donc avec maître Obi Wan KenLaFrite, craint par tout les réseaux du monde, que je me suis rendu au "4420", au premier étage du Glassblower pour voir les pirates de l'internet ! (et boire des bières...) :D

Au menu, quatre confs prometteuses :
- OpenVAS
- R2Z+CBI/O=BBUK (Race to Zero et du hack du clipboard Windows sur serveur VNC à grand coup de VBScript, glup!)
- Lockpicking
- GNURadio

Alors, déjà je ne vais pas vous raconter les confs, je n'ai pas le courage et vous n'aurez qu'à aller voir par vous même le mois prochain.
Par contre, il faut reconnaître que l'initiative est vraiment sympa. Bon esprit, tolérance, tout ça... agréable.

Si vous êtes de passage à Londres et souhaitez boire une (nan, sérieusement ce sera bien plus...) bière avec des gens cools et voir quelques confs sympa, n'hésitez pas, c'est ici.

Au UK, tout organisme qui se respecte doit perdre des données sensibles. C'est en tout cas l'impression que l'on peut avoir.
Nous nous souviendrons de l'HMRC, d'HSBC et la de la BBC et passerons même volontiers sur l'appareil photo du MI6 qui s'est retrouvé en vente sur eBay le mois dernier.

Allez hop, on gagne un point au stupidometre avec cette nouvelle perte de disque dur en provenance... du ministère de la défense (MoD) !
L'information relayée dans les medias parle des détails de 100000 personnes de l'armée de terre, marine et RAF, et 600000 potentielles recrues.
Le ministre des forces armées, Bob Ainsworth, nous rassure toutefois en disant que ce disque may, in the worst case, contain details relating to 1.7million individuals
Parfait, rien de grave donc

A la décharge du MoD, il n'ont pas perdu ce disque eux-mêmes.
C'est en effet un de leur prestataire (EDS, pour ne pas le citer), qui s'est chargé d'égarer le support numérique bourré de données confidentielles. Le MoD file sans broncher ses données confidentielles à ses prestas, on croit rêver !
Notre ami Bob Ainsworth a d'ailleurs précisé qu'il était très improbable que les données soient chiffrées.

Cet événement stupide n'est pas isolé au MoD. Le mois dernier, des disques durs, contenant les détails de 500000 employés de la RAF avaient déjà été "égares".
Le MoD avait même déclaré en Juillet, qu'en quatre ans, 658(!) ordinateurs portables auraient été volés, et 26 cartes mémoire contenant des données classifiées auraient disparues...

L'EEE PC d'Asus, tout le monde le connaît, mais peu de gens l'ont vu, faute de succès.
En tout cas, il est ultra-léger, vraiment peu encombrant et démarre en quelques secondes.
Cerise sur le chipset, il est livre pré-installe et depuis peu, pré-vérolé

Rien de bien méchant, juste un ver de type autorun. Mais si, vous savez, le genre de saloperie qui se recopie partout et balance des autorun.inf histoire d'être bien sur de pourrir la totalité du disque.

Encore plus drôle, Register Hardware, qui a récupéré un EEE PC pour l'occasion, s'est vu remettre une machine infectée par un password stealer... Décidément...

J'ai aussi adoré l'article sur Journal du Net qui est à mourir de rire.

C'est la partition D: du disque dur de la machine qui contient le virus recycled.exe en fichier caché. Le virus s'exécute quand l'utilisateur tente de lire la partition, et contamine ensuite l'espace C:.

On voit que le rédacteur est très à l'aise dans le domaine ... au moins autant que les gens responsables des masters chez Asus... (ouais je sais, c'est facile )

Voila, les résultats du challenge T2 sont en ligne depuis hier.
Et cocorico! C'est un Frenchy qui l'emporte

Le vainqueur, membre du Cert-Lexsi, se voit offrir une place à la conf T2, prenant place à Helsinki.

Congrats dude, you r0ck!

De mémoire, Cisco n’a jamais sorti autant d'« Advisories » d’un seul coup : 12 bulletins !

Vite fait, un "mega-extract" (la totale ici, comme d’habitude) :

• Cisco IOS Software Layer 2 Tunneling Protocol (L2TP) Denial of Service Vulnerability -> Successful exploitation of the vulnerability will result in a reload of the device. Repeated exploitation may result in an extended denial of service (DoS) condition.
• Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability -> Successful exploitation of the vulnerability may result in a reload of the device, linecards, or both, resulting in a DoS condition.
• Cisco IOS MPLS Forwarding Infrastructure Denial of Service Vulnerability -> Successful exploitation of this vulnerability may result in the reload of the device, leading to a DoS condition.
• Cisco IOS MPLS VPN May Leak Information -> This vulnerability may cause traffic to be improperly routed between MPLS VPNs, which may lead to a breach of confidentiality.
• Cisco uBR10012 Series Devices SNMP Vulnerability -> Successful exploitation of the vulnerability may allow an attacker to gain complete control of the device. "BIG UP" pour celle-ci avec un CVSS Score de 10
• Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities -> Successful exploitation of the vulnerabilities described in this advisory may result in a reload of the Cisco Unified Communications Manager process, which could result in the interruption of voice services.
• Cisco IOS IPS Denial of Service Vulnerability -> Successful exploitation of this vulnerability may cause a Cisco IOS device configured with the Cisco IOS IPS feature to crash or hang, resulting in a denial of service condition.
• Multiple Cisco IOS Session Initiation Protocol Denial of Service Vulnerabilities -> Successful exploitation of the vulnerabilities described in this document may result in a reload of the device. The issue could be repeatedly exploited to result in an extended Denial Of Service (DoS) condition.
• Cisco IOS NAT Skinny Call Control Protocol Vulnerability -> Successful exploitation of this vulnerability may cause the affected device to reload. Repeated exploitation will result in a denial of service (DoS) condition.
• Multiple Multicast Vulnerabilities in Cisco IOS Software -> Successful exploitation may cause a reload of the affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition.
• Cisco IOS Software Firewall Application Inspection Control Vulnerability -> Successful exploitation of the vulnerability may result in a reload of the affected device. Repeated exploitation attempts may result in a sustained denial of service attack.
• Vulnerability in Cisco IOS While Processing SSL Packet -> A successful exploit of this vulnerability may cause a crash of the affected device. Repeated exploitation may result in a sustained denial of service condition.

En gros, on a beauoup de reboot à la demande et de DoS, une potentielle fuite d’information (sur les routeurs MPLS quand même) et 1 powned.

Et demain matin, petite upgrade de Firefox au p’ti-dèj.

FileVault & Time Machine sont deux utilitaires inclus dans Mac OS X. Ils sont tous deux très utiles : le premier s’occupe en particulier de chiffrer le répertoire personnel de l’utilisateur de manière transparente, le deuxième permet de faire des sauvegardes incrémentales automatiques de manière transparente (ben ouais, c’est un Mac).
Programme intéressant…

FileVault permet de chiffrer son répertoire personnel (avec tous les fichiers qu’il contient, bien entendu).
A la mise en œuvre du service, FileVault remplace le répertoire personnel classique, par un alias pointant vers un fichier où les données contenues sont chiffrées/déchirées à la volée. Il prend tout ce qui était dans le répertoire personnel et le met dans une image disque appelée SparseBundle chiffrée en AES-256.
Attention, par défaut, lors de création du SparseBundle, les données originales ne sont pas effacées de manière sécurisée. Cependant, il suffit juste de demander gentiment à FileFault de le faire, et il le fera.
Dans le cas où il est trop tard, il est également possible de sécuriser cet espace libre de manière simple :
$ diskutil secureErase freespace Mode /dev/diskXsY , avec Mode = 1 -> 1 passe / 2 -> 7 passes / 3 -> 35 passes.
A l’initialisation, FileVault demande un « master password ». A quoi peut-il bien servir ? Imaginons que tu t’appelles Sarah, que tu mets le nom de l’endroit où tu as rencontré ton mari (Wasilla High) comme « master password » et que tu paumes ton MacBook. Ben là, un hacker en culotte courte aura accès à l’intégralité de ton méga SparseBundle en clair ! Plus sérieusement, ce « master password » permet de pouvoir déchiffrer l’image disque du répertoire personnel chiffrée en cas de perte du couple nom d’utilisateur et mot de passe lui étant associé.
D'un point de vue "comment ça se passe", c'est très simple : l’image disque chiffrée est montée quand l’utilisateur ouvre sa session, elle est démontée lorsque l’utilisateur quitte sa session.
FileVault chiffre les données en AES-256 avec une clé nommée Data Key. Cette clé est stockée (2 fois : chiffrée avec le mot de passe utilisateur et chiffrée avec le « master password ») dans les entêtes du SparseBundle.
Le format de SparseBundle permet à l’image disque d’avoir à peu près la taille des données qu’il contient (de manière dynamique). De plus, le SparseBundle est divisé en « bande » de bloc de données de 8 Mo. Ainsi, si un fichier est modifié, juste le ou les « bande(s) » de blocs utile(s) au stockage de ce fichier est(sont) à mettre à jour.

Passons à Time Machine maintenant. Il permet de faire des copies de tous les fichiers se trouvant dans le Mac. Ainsi, Time Machine permet de restaurer son Mac très facilement. Mais également de retrouver un fichier effacé ou l’état d’un fichier à l'instant -t. Il est bien évidemment possible d’exclure des répertoires des sauvegardes.
Time Machine ne chiffre rien, ce n’est pas son rôle. Apple préconise de mettre le disque servant à Time Machine dans un lieu physiquement sûr. En version disque réseau, penser à y limiter également les accès (ACL).
A la première utilisation de Time Machine, il copie tout le disque. Ca peut prendre un peu de temps… Après cette première opération, toutes les autres sauvegardes sont incrémentales.

Première interrogation : si j’efface un fichier ou un répertoire sur mon Mac, il restera à vie sur le volume de sauvegarde ?
Par défaut, oui (c’est un peu le but du truc). Néanmoins, dans l’interface de Time Machine, il vous est possible d’effacer le fichier ou le répertoire. Ils sont forts chez Apple.

Mais comment ça se passe pour le dossier personnel chiffré par FileVault ?
Ce dont je suis sûr, c’est que l’image SpareBundle chiffrée du répertoire personnel est bien sauvegardée, et qu’il n’est pas possible d’avoir accès élément par élément dans l’interface de Time Machine.
Pour avoir accès aux fichiers contenus dans l’image SparseBundle chiffrée, il est nécessaire de passer par Finder. Se rendre dans son volume Time Machine, puis dans le répertoire « Backups.backupdb », suivi du répertoire portant le nom de la machine (oui, un volume de sauvegarde peut servir à plusieurs machines). S’affiche alors dans le Finder un répertoire (date/heure) par sauvegarde faite par Time Machine. Choisir le répertoire correspondant à la date de la restauration désirée. Après, aller où se trouve le répertoire personnel (configuration standard : Macintosh HD > Utilisateurs > Nom de l’utilisateur). Ici se trouve l’image chiffrée du répertoire personnel (le SparseBundle) nommé « username.sparsebundle ». En double-cliquant sur ce fichier et en indiquant le nom d’utilisateur et le mot de passe correspondant, le répertoire personnel restauré est monté comme un volume, ce qui donne accès à la ressource désirée.
Bien, ça fait son boulot. C’est plus très « User Friendly », mais ça marche bien. Il est certain que d’implémenter l’accès à tout élément de son espace personnel chiffré ne doit pas être trivial à implémenter. Mais je pense que ça viendra.

Et voici le deuxième effet KissCool de la cohabitation FileVault / Time Machine.
Je l’ai dit en introduction, le but est que les deux services soient « transparents » pour l’utilisateur. En fonctionnement, on ne se rend compte ni de Time Machine qui fait ses sauvegardes, ni de travailler avec des documents se trouvant dans un environnement chiffré. Dans le cas d’application type « Direct-To-Disk » (musique, vidéo, photo), il est quand même préférable d’adapter ses zones de sauvegarde et de chiffrement. Mais bon, ça c’est normal.
Ce qui me gène vraiment arrive à la fermeture de session. Je ne pense pas que Time Machine fait une sauvegarde incrémentale de l'intérieur du SparseBundle, comme il le ferait pour le système de fichier normal. J’ai l’impression que Time Machine attend la fin de la session pour que le SparseBundle soit démonté pour en faire la sauvegarde. Le problème ? Si le Mac est sur un LAN en Gb, il y en a aucun. Cependant, si le Mac est un portable en Wi-Fi, ben il ne faut pas être trop pressé. Car même en 802.11n, 3 Go c’est long Ca oblige du coup a ne pas tout mettre dans son répertoire personnel.
Certains dirons que le type d’image disque utilisée (SparseBundle) est conçu pour justement être mis à jour plus facilement (histoire des bandes de 8 Mo). J’uis d’accord avec des données en clair, mais avec un chiffrement en mode chainé, je comprends pourquoi faut pousser l’image complète…

Je précise que Mac OS X permet à tout moment d'interrompre cette sauvegarde de fin de session. Ce qui autorise quand même de pouvoir partir de chez soi avec son MacBook Pro sans attendre qu’il finisse gentiment de faire sa sauvegarde. Merci la Pomme !

Le MISC de cette rentrée (n°39) est sorti vendredi dernier, avec une surprise page 76

Depuis quelques éditions vous pouvez le "feuilleter", et c’est ici !