Dans le monde de la sécurité informatique, il existe trois types de failles : L’exploit connu de tous, généralement rapidement corrigé par un patch. L’exploit de type 0-day, très peu de gens en ont connaissance — qui sera peut-être corrigé un jour — Et enfin les vulnérabilités dues a la conception d’un système/protocole et qui ne pourrons pas être, c’est le cas de par exemple du protocole de routage BGP (sur lequel j’ai fait un billet précédemment) ou encore de l’ « Address Resolution Protocol » aka ARP. Et tout bon sysadmin se doit de les connaitre pour savoir où et comment surveiller son réseau et se prémunir de ces attaques qui ne pardonnent pas.
Ce protocole et les attaques qu’il permet sur un LAN sont plutôt bien connus. Néanmoins, les conséquences de ces attaques sont rarement appréhendées à leur juste mesure. La technique que nous allons voir ici se nomme ARP Spoofing (ou ARP Cache poisoning). C’est une technique de spoofing très efficace bien que facilement détectable et – comme je le disais plus haut, parfaitement incurable, car lié directement a sa conception. . Nous étudierons trois possibilités de sont utilisation : Denial of Service, Man in the middle et MAC Flooding. Mais tout d’abord, commençons par une piqûre de rappel.

MAJ 6 Mai 2009: Correction de quelques fautes.

• 1. Modèle OSI
• 2. L’adresse MAC
• 3. Le protocole ARP
• 4. L’ARP Spoofing
• 5. Faiblesses
• 5.1 Denial of Service
• 5.2 Man in the middle
• 5.3 MAC Flooding
• 6. Solutions
• 6.1 Pour les petits réseaux
• 6.2 Pour les grands réseaux
• 6.3 Pour tous le monde

1. Modèle OSI

L’OSI (Open Systems Interconnection) est un modèle de communications entre machines proposé par l’ISO (Organisation internationale de normalisation). Il décrit les fonctionnalités nécessaires à la communication et l’organisation de ces fonctions.
Dans sa forme la plus simple, il divise le réseau en sept couches que nous ne détaillerons pas ici. La numérotation des couches commence par le bas, c’est à dire par le matériel (matériel en bas, logiciel d’application en haut. Nous nous intéressons uniquement à certaines couches dites basses :

• La couche physique (niveau 1) : La couche physique est chargée de la transmission effective des signaux électriques ou optiques entre les interlocuteurs (100BASE-TX, ADSL, Firewire, USB, RS-232…).
• la couche liaison (niveau 2) est le lien entre la carte réseau et la couche réseau (Ethernet, Token ring, WiFi, PPPoE)
• la couche réseau (niveau 3) gère l’adressage logique et le routage (IPv4, IPv6, ICMP).

Exemples :

- Un hub est un matériel de niveau 1 : il permet de relier plusieurs machines à une même branche du réseau. Il se contente de faire circuler les signaux dans les deux sens, sans traitement.
- Un routeur est un matériel de niveau 3, c’est-à-dire qu’il intervient aux niveaux 1 à 3. C’est le dispositif de base des réseaux. Il lit l’adresse IP des paquets qu’il reçoit et les re-expédie où il faut depuis les données contenues dans sa table de routage et son cache ARP. Cette dernière est mise à jour régulièrement, en fonction des données que le routeur reçoit des routeurs et des ordinateurs voisins.

2. L’adresse MAC

L’adresse MAC (Media Access Control) est un identifiant physique constitué de 6 octets, elle est attribuée par le constructeur de l’équipement et « hard codé » sur la carte (il est possible de la changer, mais ce n’est pas le but de cet article.) Elle consiste en six nombres hexadécimaux séparés par des « – » ou des « : », il existe potentiellement 248 (environ 281 000 milliards) d’adresses MAC possible, il est donc quasiment impossible de se retrouver avec un doublon sur le réseau. Notez que l’adresse de broadcast est: FF:FF:FF:FF:FF:FF, les données seront envoyées à l’ensemble du réseau local.
Nota : L’IEEE a donné des préfixes de 24 bits sur les 48 bits aux fabricants, c’est l ‘OUI (organizationally unique identifier). Ce qui permet facilement d’identifier une carte de destination, ex :

00-00-0C(hex) Pour Cisco ou encore 00-00-7D(hex) pour Sun – (clin d’œil a touff’.. si tu me lis ;)

Vous pouvez y avoir accès, sous Linux avec la commande ifconfig :

En savoir plus : http://www.iana.org/assignments/ieee-802-numbers

3. Le Protocole ARP

Ce protocole est vraiment très simple : Il sert à mettre en corrélation l’adresse IP avec l’adresse MAC pour savoir qui sont les machines sur le réseau et donc savoir ou router les paquets. Ce protocole est totalement séparé de TCP/IP puisqu’il n’opère qu’entre les niveaux 2 et 3 de la couche réseau. Nous pourrions le comparer aux DNS sauf qu’au lieu de convertir les noms de domaines en IP, il convertit les IPs en Adresse MAC.
Les équipements réseaux communiquent en échangeant des trames Ethernet (dans le cas d’un réseau Ethernet bien sûr) au niveau de la couche liaison de données, toute machine connectée a un réseau possède un cache ARP de toutes les adresses IP/MAC rencontrés, ce qui permet de ne pas encombrer les réseaux en renouvelant les requêtes pour communiquer avec les machines contactées précédemment.

Il comprend quatre messages de base :

Aller plus loin : http://tools.ietf.org/html/rfc826

4. L’ARP Spoofing

Bien, assez de tous ces rappels ennuyeux, passons aux choses amusantes : la vulnérabilité de ce protocole. Pour améliorer le temps de réponse et limiter l’utilisation du réseau la plupart des systèmes mettent a jour leur cache ARP a chaque fois qu’ils reçoivent une réponse, même s’ils ne l’on pas demandé : ce qui veut dire qu’un « pirate » envoyant un message ARP a l’ordinateur B disant « l’ordinateur C a mon Adresse MAC » recevra ensuite tous les messages qui devraient normalement être délivrés a cet ordinateur C.
petite mise en situation :

(J’ai simplifié les adresses MAC pour une meilleure lisibilité)
A. Le serveur, 00:00:00:00:00:01 – 192.168.0.10
B. Un utilisateur, 00:00:00:00:00:02 – 192.168.0.20
C. Le pirate, 00:00:00:00:00:03 – 192.168.0.30

C annonce à B “192.168.0.10” est a l’adresse MAC: 00:00:00:00:00:03.
C annonce à A “192.168.0.20” est a l’adresse MAC: 00:00:00:00:00:03.

Comment ? avec des solutions comme ARPSpoof ou Némésis, très simplement :

Maintenant toutes les communications de l’utilisateur vers le serveur (ou inversement) seront routées vers le pirate… qui pourra par exemple récupérer les login/mot de passe.

5. Faiblesses

Comme je viens de le dire, il n’y a aucun système d’authentification. ARP est basé sur la confiance : il considère tous les messages reçus comme authentiques, qu’il provienne de la machine légitime ou pas et il n’intègre aucun moyen de vérification. Je pense que les concepteurs de ces protocoles ont sûrement simplifié les communications pour que les réseaux fonctionnent de manière optimale, les débits étaient très peu élevés à cette époque et un système d’authentification aurait été beaucoup plus lourd.
La possibilité d’associer n’importe quelle adresse IP avec une @MAC permet à un pirate plusieurs vecteurs d’attaques, je vais maintenant en détailler 3 : Denial of Service, Man in the Middle et MAC Flooding.

5.1 Denial of Service (DoS)

Comme nous l’avons vu précédemment, un pirate peut facilement associer une adresse IP a une fausse adresse MAC. Par exemple, un pirate peut envoyer une réponse ARP associant l’adresse de vôtre routeur avec une adresse MAC qui n’existe pas. Votre ordinateur pense donc connaître réellement la passerelle par défaut, mais en fait ils envoient leurs paquets a une destination qui n’existe pas. Le pirate vous a isolé du réseau.
Nous pourrions tout aussi bien projeter – sur un réseau plus grand – une attaque de type DDoS (Distributed Denial of Service) en signalant a toutes les machines qu’une seule adresse MAC correspond a toutes les adresses IP. Ce qui risque de submerger la machine sous des requêtes en tout genre. (Voir aussi MAC Flooding).

5.2 Man in the Middle

Une autre utilisation intéressante de cette faille est de rester dans l’ombre et d’ « écouter » le trafic (sniffing) pour récupérer des informations comme les logins et mot de passe… ce qui est particulièrement dévastateur, car le pirate peut rapidement avoir accès a des informations qui lui permettront de s’infiltrer plus profond dans vôtre réseau.
Mise en œuvre : Dans le cadre d’un ARP Poisoning simple, les machines n’arrivent plus a joindre leur destinataire légitime, l’attaque est donc très facilement repérable. Mais le pirate peut facilement mettre en place ce qu’on appelle l’IP Forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward), celles-ci enverront donc leurs trames Ethernet à la machine pirate tout en croyant communiquer avec la cible, et ce de façon transparente pour les switches. De son côté, la machine pirate stocke le trafic et le renvoie à la vraie machine en forgeant des trames Ethernet comportant la vraie adresse MAC (indépendamment de l’adresse IP) pour cela il suffit en fait d’envoyer régulièrement des paquets ARPReply en broadcast, contenant l’adresse IP cible (mettons, un serveur) et la fausse adresse MAC. Cela a pour effet de modifier les tables dynamiques de toutes les machines du réseau. Ce qui permet à la machine du pirate d’écouter toutes les informations qui transitent par son ordinateur et il peu – facilement – avoir accès a vos mots de passe non chiffrés (entre autres).

5.3 MAC Flooding

Le MAC Flooding est un ARP Cache poisoning visant les routeurs et les switches. Certains matériels réseaux actifs – lorsqu’ils sont surchargés – basculent dans un mode moins gourmand en ressources, pour sauvegarder leurs liens : ils deviennent de simples hubs et donc broadcastent tout le trafic réseau sur tous leurs ports (et donc tous les ordinateurs qui y sont connectés. (Et en floodant la table ARP d’un switch avec énormément de données on peut facilement le surcharger..) ce qui permet ensuite au pirate d’écouter facilement tout ce qui transite sur le réseau.

6. Solutions

Certaines solutions que je vous propose ci-dessous sont simples, mais n’hésitez pas à les mettre en place – car si vous vous pensez à l’abri c’est là que vous êtes le plus vulnérable. Notez tout de même que l’ «ARP Poisoning» ne peut être utilisé qu’en local. Il doit contrôler une machine sur votre réseau, ce qui veut dire que le pirate aurait déjà accès à ce réseau… Parce que cette faille est inhérente au protocole requis par TCP/IP vous ne pourrez le patcher, cependant il existe des solutions pour le surveiller/détecter.

6.1 Pour les petits réseaux

Si vous êtes administrateur d’un petit réseau, vous avez plusieurs méthodes imparables pour vous prémunir de ces attaques : Utiliser des Adresses IP fixes / Tables ARP statiques. (arp –s pour définir les @MAC/IP de tous vos périphériques) ils ne changeront donc jamais, quels que soient les messages reçus. Si vous avez mis en place un contrôleur de domaine, il est possible de définir un script de démarrage dans lequel vous spécifieriez ces adresses.
Gardez tout de même a l’esprit que maintenir une liste de ces adresses est possible seulement si vous possédez un petit réseau. S’il devait s’agrandir vous seriez rapidement submergé par le temps demandé a maintenir cette liste, car il vous faudrait ajouter chaque machine a ce script avant qu’elle ne puisse dialoguer avec les autres (quid de la taille du fichier script ?).

6.2 Pour les grands réseaux

Si vous êtes administrateur d’un réseau informatique assez étendu vous devriez être équipé de switch qui propose des options « port security » (par exemple Cisco) cette option permet de définir une seule adresse MAC par ports et qui – si cette adresse change – verrouille le port. Cela permet de limiter la plupart des attaques ARP comme le Man-in-the-middle.

6.3 Pour tous le monde

La meilleure protection contre l’ARP Poisoning est la surveillance de votre réseau, en effet, avec les outils appropriés, cette attaque ne peut pas passer inaperçue. Par exemple, il existe un outil nommé ARPwatch qui permet – en autres – d’envoyer une alerte quand messages ARP anormaux apparaissent (j’écrirais un billet sur l’envoi d’alertes par SMS via des API bientôt).

Je vais vous expliquer, ici comment « patcher » votre Wii pour pouvoir y installer des programmes tiers et pouvoir jouer à des jeux gravés (sauvegardes…).

Mise à jour du tutoriel le: Samedi 28 avril 09′

Une modification du système votre Wii peut, potentiellement, l’endommager. Je décline toutes responsabilités si le fait d’essayer cette méthode causait des problèmes à votre console. De plus, vous n’avez le droit de copier un logiciel ou jeux que si vous possédez l’original (création d’une copie de sauvegarde). Par le non-respect de ce texte et des lois qui en résultent (disponibles dessous) vous vous rendez coupable de violation du code de la propriété intellectuelle. Crashdump.fr ne peut être tenu responsable des utilisations illicites (actes de piratage) exercé par l’un de ses lecteurs.

DIRECTIVE EUROPEENE 91/250 DU 10-05-1991:
- Article 5 (extrait) Une personne ayant le droit d’utiliser le programme d’ordinateur ne peut être empêchée par contrat d’en faire une copie de sauvegarde dans la mesure où celle-ci est nécessaire pour cette utilisation.
- Liste des textes relatifs aux copies de sauvegarde (cette liste n’est pas exhaustive et les cas de jurisprudence n’y sont pas évoqués) : A122-4, 122-5, 122-6, 122-6-1, 122-6-2, 122-7, 131-3, R335-1 , R335-2 du code de la propriété intellectuelle. Directive Européenne 91/250 du 10/05/91 et 92/100 du 19/11/92.

Retrouvez toutes les photos du Hack ici

- Une Wii,
- Le jeu « Zelda: Twilight Princess » (Version wii uniquement),
- Une carte SD (attention aux cartes SD de plus de 2Go/SDHC.. elles peuvent poser problème),
- Un moyen de lire/ecrire sur votre carte SD via un ordinateur,
- Une manette gamecube,
- Une connexion internet sur votre Wii,
- Le pack de logiciels (disponible ci-dessous).

Trois packs sont disponibles ici, pour trois situations différentes. En effet, suivant le firmware de votre Wii la procédure change un petit peu !
MAJ: Nouvelle version des packs (v2), mise à jour: du Twilight Hack et du Homebrew channel. Les anciens packs sont toujours disponibles au cas où…
Pour une Wii v3.2E: WiiPatchPack3.2Ev2.zip – (Pack v1 disponible ici)
Pour une Wii v3.3E: WiiPatchPack3.3Ev2.zip – (Pack v1 disponible ici)
Pour une Wii v3.4E: WiiPatchPack3.4Ev2.zip – (Pack v1 disponible ici)

Si votre Wii utilise un firmware antérieur au 3.x faites une mise à jours en 3.4 avant de commencer. (Si vous faites cette mise à jours en ligne, attention à l’évolution des firmwares Nintendo.. il n’est pas dit que nous puissions toujours exploiter les mêmes bugs sur un hypothétique Firmware > 3.5.)

- Homebrew Channel 10.1,
- Channel File Manager 2.0 beta 2,
- cIOS Rev7,
- cIOS Uninstaller,
- Backup Creator,
- cIOS Downgrader,
- ImgBurn,
- Chaine Backup Launcher 0.3 Gamma Autoboot,
- Starfall,
- Sauvegarde Twlight Hack.

Tout d’abord, il faut savoir quel firmware est installé sur votre wii:

• A partir du menu de lancement, cliquer sur « wii », puis « parametres wii »,
• En haut a droite, vous verrez la version du firmware installé (3.3 E, 3.2 E …),
• Selon la version, dezippez le contenu du pack correspondant sur votre carte SD.

• Mettez votre carte SD dans votre Wii,
• Allumez votre wii puis allez dans : « (Wii) » (En bas à gauche) –> « Gestion des données » –> « Données de sauvegarde » –> « Carte SD » –> Copiez la sauvegarde « Twilight Hack » (eur, jap, usa, selon la provenance de votre console),
  

• Insérez le jeu « Zelda : Twilight Princess » dans votre Wii et lancez le par la chaîne disque,
  

• Après avoir appuyez sur « A+B » choisissez la sauvegarde nommée « Twilight Hack« ,
  

• Une fois dans le jeu , reculez de quelques pas, ou allez parler à la personne en face de vous,
  

• Votre écran devient noir avec plusieurs phrases en blanche,
  

• suivez les instructions ;
  

• votre Wii redémarre et vous avez une nouvelle chaine sur votre menu Wii qui se nomme  »the homebrew channel« ,
  

• La chaîne est désormais installée.
  

• Lancez la chaîne « the homebrew channel«  (La chaîne va chercher une mise à jour, n’hésitez pas à l’appliquer),
  

• Lancez « Wad Manager v1.3« ,
  

• installez « IOS16-64-v257-prod.wad » avec la touche « +« ,
  

• Revenez à la chaîne « the homebrew channel« , lancez « Wad Manager IOS 16 » et installez « CIOS Fix »,
  

• Revenez à la chaîne « the homebrew channel« , lancez « Cios-Downgrader » pour downgrader votre Wii en 3.2E (le E est très important, il signifie Européen),
  

• Revenez à la chaîne  »the homebrew channel » et enfin, lancez « IOS Downgrader V1« .

• Lancez la chaîne « the homebrew channel« , lançez « cIOS Rev7« ,
  

• Choisissez « wad installation » (ou « network » pour avoir la dernière mise à jours, si vous êtes connecté en wifi), suivez les indications, en sachant que le bouton 1 de la wiimote correspond à « accept », le 2 à « cancel »,
  

• Sélectionnez le firmware 3.2E et installez le (la liste continue vers le bas, il suffit de descendre…),
  

• Une fois terminée , revenez sur la chaîne the homebrew channel, lancez « Channel File Manager 2.0 beta 2« ,
  

• Suivez les instructions et installez le fichier « [Chaîne] Backup Launcher 0.3 Gamma Autoboot« ,
  

• Vous avez désormais une nouvelle chaîne sur votre menu Wii , celle-ci permet de lancer les backups sur votre Wii, vous pouvez relancer la « channel file manager » pour installer toutes les applications wad dont vous aurez besoin (ex: dans le pack, il y a un lecteur audio/video, « Mplayer »).

(Optionnelle , uniquement pour les Wii en 3.2E , empêche les mises à jours automatique de Nintendo)

• Allez dans la chaîne « the homebrew channel », lancez « Starfall »,
  

• appuyez simultanément sur « B+1″ et pas « B+2″ (C’est une erreur de programmeur),
  
  
• Un nouveau menu apparait, sélectionnez les 3 dernières options et appuyez sur avec « A » avec chacune d’elle pour que ça affiche « Install »,
  
  
• Une fois que les 3 dernières options ont été appliquées , appuyez sur « 2″,
  
  
• Éteignez votre Wii, Branchez votre manette Gamecube,
  
  
• Allumez votre Wii en maintenant appuyer le bouton « Y » de la manette, Un écran noir s’affiche indiquant « 3.2E »,
  
  
• L’installation de la protection contre le brick de votre Wii est terminée.

Utilisez la fonction ‘graver l’image’ de votre logiciel préfère (pas de problème avec imgburn ou nero). Lancez la gravure a la vitesse la plus basse possible, et uniquement sur des DVD -R2. Comment jouer à mes backups ?
- Lancez la chaîne « Backup Channel »,
- Faîtes « Demarrer ».

- Utilisez les packs disponibles ici, ils sont cohérent, si vous en utilisez d’autres je ne pourrais sûrement pas vous aider.
- Vérifiez que vôtre carte SD est bien formatée en FAT32 (voir FAT16).
- Si vôtre carte SD fait plus de 2Go ou qu’elle est SDHC, cela peu poser des problèmes.. essayez avec une autre.

- Mettez votre carte SD dans votre Wii,
- Lancez la chaîne « the homebrew channel »,
- Lancez « Channel File Manager 2.0 beta 2″,
- Suivez les instructions pour désinstaller le fichier « [Chaine] Backup Launcher 0.3 Gamma Autoboot ».
- Revenez à la chaîne « the homebrew channel »,
- Lancez « cIOS Uninstaller »,
- Revenez au menu Wii,
- Allez dans : « (Wii) » [En bas à gauche] –> « Gestion des données » –> « Données de sauvegarde » –> « Wii » –> Supprimez la sauvegarde ‘Twilight Hack’,
- Allez dans : « (Wii) » [En bas à gauche] –> « Gestion des données » –> « Chaînes » –> Supprimez la chaîne « the homebrew channel »,
- Faites un formatage de votre Wii,
- Votre wii est comme neuve.

- Mettez la carte SD dans votre Wii,
- Éteignez votre Wii,
- Branchez votre manette Gamecube,
- Allumez votre wii en maintenant le bouton « Y » appuyé,
- Lancez la sauvegarde « Twilight Hack »,
- Parlez à la personne en face de vous,
- Suivez les instructions,
- Downgradez ou Upgradez votre console en la version désiré mais en version « E »,
- Votre Wii est désormais réparée.

Le BGP (Border gateway protocol) est un protocole d’échange de route utilisée – entre autres – sur Internet. Son objectif est d’échanger des réseaux avec les routeurs voisins pour établir des tables de routage dynamiques : Les routeurs s’échangent des informations sur les réseaux qu’ils connaissent et sur le moyen de les atteindre.

Pour communiquer avec une autre machine, le système suis la table de routage. (On peut l’afficher sur quasiment tous les Unix avec « netstat -rn », avec « route -n » sur Linux ou encore « route -n show » sur NetBSD. Prenons un exemple :

Imaginons un routeur ayant la table de routage suivante :

Et dont les paquets doivent être envoyés à la destination de 192.168.20.37 : Ils seront envoyés tout d’abord à 192.168.20.254 qui les fera suivre. Faisons un traceroute pour le vérifier:

On voit bien dans cet exemple la manière dont les paquets arrivent à destination. Seulement ici nous sommes dans le cadre d’un petit réseau, imaginez la même chose à la hauteur d’un réseau comme internet…

La plupart des connexions vers Internet à partir d’une résidence ou au bureau sont réalisées par un routing statique, c’est-à-dire qu’il n’existe qu’une seule route, celle vers votre FAI (Fournisseur d’accès a Internet). Mais après cela, Internet est un maillage de réseaux. Cela signifie que plusieurs chemins existent entre deux réseaux d’extrémité. Et ceux-ci ne sont pas tous équivalents…

En se servant du protocole de routing BGP et à condition de disposer de deux connexions ou plus vers Internet, on peut décider de façon dynamique d’envoyer un certain type de traffic par une connexion et un autre type de trafic par une autre connexion. En effet, imaginez votre connexion à crashdump.fr circulant dans cette univers cruel et barbare qu’est Internet. Vous préférerez peut être qu’ils transitent par tel AS, car l’admin est un pote ou que vous avez négocié un tarif avantageux. Vous refuserez peut-être qu’ils transitent par un autre AS, car vos flux sont incompatibles avec la législation en vigueur dans le pays ou pour toute autre considération politique (nldr: Chine), économique ou de sécurité que l’on peut imaginer. Dans ce cas, vous aurez besoin de définir une politique de routage sur Internet. BGP sert a cela.

Le 24 février 2008, YouTube a été indisponible pendant deux heures environs. Ce n’était pas une panne, mais le résultat d’une action (délibérée ?) en provenance du Pakistan. Le gouvernement (du Pakistan) a annoncé ce jour là, un blocage de YouTube. Pakistan Telecom à donc exécuté l’ordre. Ce qui est rigolo (ou pas..) c’est que par incompétence ou bien par volonté de tester, ils ont réussi à couper YouTube sur l’ensemble de la planète.

La technique est très banale (ou du moins, connue) et des tas de gens l’ont déjà exploité. On appelle ça l’IP hijacking (détournement d’adresse) et ça consiste à annoncer une route plus spécifique, pour les adresses IP de la victime comme je vous l’ai expliqué plus haut, grâce au BGP. Oui, très peu d’entre eux limitent ce qu’on peut annoncer. N’importe quel routeur BGP de l’Internet peut tout à coup se mettre à dire « Envoyez tous les paquets IP à destination de x.x.x.0/24 – vers moi ». Cette annonce aura même la priorité sur celle du propriétaire légitime, car elle est plus spécifique (la longueur du préfixe est de 24 bits, contre par exemple 22 pour l’annonce légitime. Ici vous me dites : « Il n’y a qu’à authentifier le pair BGP en face ! ». Non, cela ne sert à rien puisque ça ne garantit pas qu’il aura, lui-même, authentifié ses propres pairs.

Ce problème est connu et ce depuis longtemps et devrait, logiquement, susciter plus d’inquiétudes pour la sécurité et la stabilité de l’Internet. Ce n’est pas facile à résoudre, le problème n’étant pas technique mais politique et organisationnel. Ce ne sont donc pas les solutions techniques qui manquent (Ex : Secure BGP, soBGP). Rien ne sert d’installer une alarme ultra sophistiquée sur votre voiture si vous prêtez les clés a tout le monde.

Alex Pilosov et Anton Kapela ont dit, lors du DefCon 16 (2008):

- Everyone … has assumed until now that you have to break something for a hijack to be useful.
- But what we showed here is that you don’t have to break anything. And if nothing breaks, who notices?

Entendez par là :

- Tout le monde est d’accord sur le fait que, jusqu’à présent, vous étiez obligé de casser quelque chose pour faire un détournement d’adresse efficace. (Et donc faire du « bruit »).
- Mais ce que nous avons montré ici est différent : Si rien n’est cassé, qui le remarquera ?

Le type d’attaque qu’ils ont démontré est d’un type nouveau, car elle permet d’écouter les flux d’autrui sans être propriétaire du réseau normalement emprunté et surtout sans être repérable !
Pourquoi rien n’a été fait avant ? Deux raisons : Personne n’avais jamais démontré qu’il était possible de faire ce que ces deux jeunes pirates on fait ce jour-là. L’autre, pire encore : l’argent. Comme je vous l’ai expliqué tout à l’heure, en théorie le problème est bien connu des gouvernements et des agences de sécurité gouvernementales, mais cela coûterait très cher – en temps et en argent – de mettre en place une solution plus sûre… du moins pour le moment !

On pourrait même penser que la situation n’évolue pas, car elle pourrait permettre aux agences comme la NSA (Big B, Echellon) ou les équivalents d’autres pays, d’écouter le trafic mondial très facilement… Pire, là où un hacker avec peu de moyens ne pourrait pas traiter toutes ces informations, un pays devrait être moins limité.

Ces lignes ont été retirée parce qu’elle produisait des erreurs avec certains outils (Utilisation d’une donnée non initialisée dans la plupart des projets liés a OpenSSL). Mais la suppression de des lignes en question à eu des effets collatéraux sur OpenSSL PRNG. En fait au lieux de mélanger différentes variables aléatoire pour la génération initiale, la seule variable « aléatoire » qui a été utilisée étais le PID du générateur -et quand on sais que le nombre maximal par défaut sous linux est de 32,768- le résultat est que PRNG utilise une très petite fourchette de valeurs initiales.

Impact:

Toutes les clés SSL et SSH générées sur des systèmes basé sur Debian (Ubuntu, Debina, Mint…) entre Septembre 2006 et le 13 Mai 2008 sont affectée par la vulnérabilité. Dans le cas des clé SSL, tout les certificats doivent être révoqué et a nouveau généré. Tous les administrateurs système doivent auditer leurs clés pour être sur qu’ils ne sont pas touché par la vulnérabilité ! D’ailleurs tout les outils liés de près ou de loin a OpenSSL PRNG peut être vulnérable, attention.

Tout flux d’un serveur SSH qui utilise une clé générée par un système vulnérable peut être sujet a une interception (man in the middle) sans que l’administrateur ne se rende compte de rien. Je vous rassure, les projets Debian et Ubuntu on développé des outils pour identifier les clé vulnérables, vous trouverez plus d’information a leurs propos en fin de page.

Q: Combien de temps cela prendrais de générer toutes les clés touchées ?
A: Avec 31 Xeon @ 2.33Ghz. Cela prend deux heures pour les clés DSA 1024-bit et RSA 2048-bit pour x86. Les clés RSA 4096-bit sont générés en 6 heures. En ce qui concerne les clés RSA 8192-bit cela prendrais environs 100 heures.

Q: Combien de temps cela prendrait il de cracker un SSH avec ces clés ?
A: Tout dépend de la vitesse du réseau et de la configuration du serveur SSH. Il devrait être possible d’essayer toutes les clés (32,767 DSA 1024 et RSA 2048) en quelques heures. Attentions aux scripts tels que Fail2Ban (anti-bruteforce).. etc.

Q: J’utilise une clé RSA 16384 bit, suis-je vulnérable ?
A: Oui, c’est juste une question de temps (processeur et réseau). Pour le RSA 8192 bit, cela prend environ 3100 heures pour générer toutes les clés. J’imagine que pour le 16384 bit, nous serions dans les 100,000 heures (en temps CPU). Mais gardez en tête que la « fourchette » réele est bien plus mince, basée sur PID du processus qui a servit a générer le tout. Donc, inutile de générer toutes les clé pour en couvrir la majorité ! (La plupart de ces clés sont dans les premiers 3,000 PID)..

http://www.debian.org/security/key-rollover/
http://wiki.debian.org/SSLkeys

Un tutoriel de mise a jour du kernel par dedibox: http://documentation.dedibox.fr/doku.php?id=distrib:kernel&s=noyau

La faille a été corrigé par les équipes de sécurité de la plupart des distributions.
Aussi peut être pensez vous comme moi qu’un simple (pour debian)

Pourrais vous mettre à l’abri… Malheureusement chez dédibox il est optimisé pour C7, donc spécifique. Pas de panique ça reste assez simple a corriger quand même.

La manipulation pour corriger la faille est décrite ici:

Je l’ai testé sur une testing:

Si vous avez installé votre dédibox avant le 28 Mai 2006 (ou si vous possedez une version raid), cette partie ne vous concerne pas !
Sinon, distributions Ubuntu-Server, Ubuntu Dedibox et Debian Sarge comportent un bug dans le comportement de grub-install. On va donc patcher grub.

On cherche sur quelle partition est “/” (pour savoir sur quel disque on boot):

Ce qui devrait vous retourner quelque chose du genre:

C’est ce sda1 qui nous intéresse.. c’est le disque sur lequel boot votre machine !

On va donc lancer le script téléchargé précédemment, avec comme paramètre sda1 (dans notre cas, sinon remplacez par la bonne valeur):

Le script va modifier le fichier: /boot/grub/menu.lst pour y entrer les bonnes valeurs. Si un problème survient par la suite, le script créé une sauvegarde de ce fichier ici: /boot/grub/menu.lst.bak

Mise a jour du Kernel

On le télécharge:

Puis on l’installe :

On met a jour grub:

Tout va bien il a trouvé notre noyau.. donc on reboot:

Prennez un café… puis on vérifie:

Ipv6 Activé ?

Il faut impérativement penser que l’IPV6 est activé et qu’il faut mettre les règles adoc pour filtrer un minimum.
Personnellement, j e n’utilise pas « encore » ipv6 donc j’ai entré ces règles dans mon script iptables/ip6tables :

C’est bon, je peut donc aller me recoucher, en paix. ;)

Voici un exemple d’utilisation :

… voila qui est plutôt grave, mettez donc a jour vos kernel:

De plus, on pourrais imaginer une utilisation de cet exploit via des scripts cgi, php,.. Mal programmé – En exploitant une faille include – Et la je vous laisse imaginer le drame !

Un petit conseil donc: Mettez votre système à jour régulièrement !