Comment fonctionne WEP ?

C’est à grand renfort d’articles sur tout la toile qu’un nouveau POC (Proof Of Concept) vient annoncer que WEP est mort ! rien de bien nouveau en soit puisqu’on l’avait dejà tué depuis des années, mais cette fois la méthode est plus rapide, plus automatique et sans doute bientot à la portée de tous, ou presque.

Est-ce alarmant ? en soit, utiliser Wep est alarmant depuis bien longtemps, donc un peu plus un peu moins ? et si vous dormez sur vos deux oreiles malgré cela et bien continuez ! il n’y a pas de raisons ; le tout c’est d’en être concient, non ?

Qu’est ce que cette nouvelle methode de Bitau, Handley et Joshlack ? Elle repose en fait sur l’utilisation d’un utilitaire existant dans le protocole 802.11 (Wifi) : la fragmentation de trame ou plutot la défragmentation par l’AP. Le rôle de l’AP dans un réseau avec architecture est de recevoir les trames de tout le monde puis de les réémettre : ainsi si tout le monde capte l’AP, tout le monde peut communiquer, y compris si deux postes sont trop distants pour se joindre directement … L’AP etant un périphérique intelligent, lorsqu’il recoit des fragments de trames, il commence par les réunir en trame plus grosses avant de les réémettre. Alors comment cela nous aide-t-il a craquer une clef Wifi, c’est assez simple :
Avec le cryptage WEP, qui n’est autre qu’un simple XOR, il suffit de connaitre une chaine et son equivalent crypté pour connaitre la clef de cryptage, donc puisque nous captons des données cryptées, il nous faut connaitre leur equivalent non crypté pour connaitre la clef associée. Les protocoles de couches basse nous aident en celà : certaines trames LLC/SNAC, ARP ont des parties qui sont constantes et celles-ci sont identifiables par des tailles caractéristiques. En captant ces trames, nous avons des données cryptées et connaissons leur équivalent non crypté. Ainsi il est possible d’obtenir facilement quelques octets de la clef de cryptage (qui n’est cependant pas directment la clef partagée que l’utilisateur configure).
Cette étape accomplie, la nouvelle solution par fragmentation entre en jeu : les morceaux de clef que nous avons sont trop petits, la fragementation va nous permettre de les multiplier : il suffit de renvoyer plusieurs fois la trame reçue en l’indiquant fragmentée : connaissons la cryptée et son équivalent décryptée. L’AP va recevoir ces fragments, les décrypter et les assembler dans une nouvelle trame qu’il va crypter puis, enfin, réémettre cettre trame sur le réseau. Cette trame nous allons pouvoir l’écouter, nous connaissons sa version non cryptée puisqu’il s’agit de la concaténation du message precédent avec lui-même et l’AP vient de nous fournir sa version cryptée. Nous sommes donc à même, comme à l’étape 1 de connaitre la clef associée, mais cette fois nous n’avons plus 8 octets mais n*8 octets (avec n le nombre de framents).

En continuant ainsi il est possible d’obtenir une clef de cryptage valide suffisemment grande pour crypter n’importe quel paquet. Nous allons donc pouvoir emettre sur le réseau n’importe quel paquet, sans connaitre la clef partagée initiale mais simplement la suite issue du RC4. Cette facultée va nous permettre de générer du traffic valide vers le réseau et ainsi collecter un maximum de trames pour, par la suite, lancer une attaque sur ces informations et en déduire la clef partagée (type aircrack).
Cette methode, présentée ainsi est donc une solution plus rapide et encore imparable pour générer du traffic : le principe de defragmentation est à la base du protocole, il est difficile de le bloquer alors que bloquer les réémissions forcée d’une methode aireplay est assez courant. Par ailleurs, il permet de connaitre bcp plus de données de chaque chaînes cryptées (contrairement aux ARP habituels) et ainsi d’etre plus efficasse avec moins de trames.
Cette mehode reste totalement interdite à l’utilisation hors de son propre réseau privé puisqu’elle demande l’emission de données vers le réseau distant, ce qui implique une intrusion dans le dit système, Acte répréhensible par la lois.

Les auteurs de cette methode, proposent une autre alternative à la simple collecte d’informations en vue de connaitre la clef partagée ; en effet, ils proposent d’utiliser cette methode, associée à d’autres pour forcer l’AP à router des paquets cryptés vers l’Internet : dans ce cas, le paquet emis en direction de l’Internet est décrypté par l’AP avant d’etre envoyé sur la ligne (logique on sort du WLAN). Le site distant est alors un site amis du pirate qui va ainsi recevoir les données décryptées issues du réseau WLAN dit “sécurisé” … pas mal ! Le principe en est assez simple, il s’agit de créer une entête IP a destination du serveur sur l’Internet, de l’indiquer fragmenter et de réémettre un paquet crypté que l’on souhaite faire décrypter en l’indiquant comme étant la suite du précédent. L’AP va alors decrypter les deux, concaténer le paquet “secret” à notre entete IP, constater qu’il s’agit d’une trame pour l’extérieur et la router décryptée. Reste que ce type d’attaque est plus facile à tracer qu’un wardriving sauvage, rendu rapide par la methode.

Quid de l’implémentation ? Les auteurs proposent quelques sources de leur POC, la mise en oeuvre demande un contrôle au niveau le plus bas des cartes Wifi, pour, entre autre, gérer les flags permettant la fragmentation au niveau logiciel. Ces possibilités ne sont pas offertes sure toutes les puces ou demandent des workaround un peu touchy .. bref, pour l’instant 2 chips sont supportés dont le PRISM2. Il y a de fortes chances pour que d’autres arrivent.
Point vraiment interressant, ce qu’ils ont mis en oeuvre est totalement automatisé, contrairement à ce qui existe sur aircrack. Les outils aircrack ne peuvent pas etre mis entre toutes les mains, elle doivent toujours être averties : ligne de commandes, options compliquées… Une solution entierement automatisée pourrait etendre la chose aux pirate boutoneux du dimanche …
Il n’en reste pas moins que ca ne marche et ne marchera sans doute jamais que sous Linux et autre BSD ;o)

Dell L400 et configuration ACPI

Autant sur une machine de bureau, l’acpi on vit bien sans, autant sur un portable on frole de danger si ca ne marche pas correctement ; à mettre en rapport avec mes remarques sur la suse 10 et 10.1 qui m’on values quelques arrets pour surchauffe ! Une solution qui semble bien fonctionner : couper l’acpi au démarrage (acpi=off) lors du prompt de sorte à laisser le bios se débrouiller…

Pour faire plus propre, il est toutefois possible de “débugger son acpi” : en fait, dans les distro classiques, on va avoir une configuration acpi générique : elle fontionne bien dans beaucoup de cas, mais pas toujours (un portable standard ca existe ?). Il est alors possible de mettre à jour l’acpi pour qu’il supporte correctement la machine… En voici la recette, appliquée sur mon L400.

  • Se procurer le fichier DSDT adapté au portable. (Tout est dans ce fichier de description de l’acpi !). Pour se faire, il faut télécharger le fichier sur cette adresse en précisant le constructeur et la marque.
  • Il faut ensuite compiler se fichier à l’aide de l’utilitaire fournit par Intel ici en choisissant la version source unix. Il faudra d’abord compiler le compilateur (nécessite bison et flex) en lançant make dans le répertoire compiler. Il faudra ensuite compiler la DSDT précedemment télécharger avec la commande suivante :
    iasl -tc dsdt.asl ce qui devrait générer un fichier de type dsdt.hex qui n’est d’autre en fait qu’un fichier de type “.h”
  • L’etape suivante consiste à recompiler son noyau pour ce celà soit pris en compte. Tout d’abord preparrons un noyau : make clean ; make mprpoper; make cloneconfig puis lancer la configuration via X make xconfig
  • La configuration de la nouvelle DSDT est, sur les noyaux 2.6.13 plus simple que ce qui est décrit sur les HOWTO classiques : dans la rubrique Power management options/acpi/ il faut cocher Include Custom DSDT puis double clicker sur Custom DSDT Table file to include et entrez le chemin complet jusqu’au fichier .hex.
  • Il reste à compiler le noyau :make
  • Enfin, il faut recopier le noyau ainsi obtenu dans le répertoire /boot. le noyau se trouve dans le répertoire /usr/src/linux/arch/i386/boot sous le nom de bzImage, il sera compié dans /boot sous le nom de vmlinuz-xxxx-version-xxx-acpi par exemple (voir le format de celui existant) et il faudra alors mettre à jour le lien symbolique de vmlinuz.
  • Pour terminer… on reboote

Bug demarrage Dell L400

Ouf, j’ai enfin la solution a un bug qui m’ennuyait depuis longtemps : au boot mon portable L400 de Dell m’offrait un superbe ecran noir avec curseur clignotant si je ne passais pas à chaque fois par le boot-menu … Un peu pénible ! Bien sûr, dans le Bios, impossible de changer l’ordre du démarrage une sombre vrai-fausse histoire de mode superviseur. En réalité, pour se sortir de cette histoire il suffit de falsher son BIOS pour une version plus récente. Pour ma part je suis passé du bios A3 au bios A9 disponible sur le site de Dell et il fonctionne à merveille maintenant.

VmWare player ou Xen ?

Avant d’utiliser cette technologie avec un objectif de rationnalisation de mes serveurs de dev (restons très modeste je parle de ce qui me sert à developper quelque site perso dont celui-ci), j’ai essayé deux produits me semblant être les principaux outils concernant ma cible d’implémentation à savoir Linux : vmware, outil payant mais disponible en version communautaire et xen, outil totalement ouvert.

J’ai donc commencé par vmware et de dois avoué que c’est à peut pret aussi simple qu’une installation de logiciel classique : installation du RPM qui va bien, lancement de l’executable en temps que root … la compilation des package, la signature de je ne sais trop quoi … tout est automatique. C’est beau c’est pro. nickel !
L’installation d’une VM est assez simple : vmware lance un vrai machine completement virtuelle, avec son bios, ses périphériques virtuel qui ne sont autre que les vrai périphériques physiques de la machine après association faite lors de la configuration de la VM. Bref, il suffit de mettre un cd d’install dans le lecteur, démarrer la VM en cliquant sur le bouton et zou, on boot la VM sur le CD et l’installation débute. Trop facile !!
Une fois installé, le petit package de drivers pour le système hôte se déploie en un clic et optimise grandement la performance des périphériques souris et clavier.
Avantage de vmware, simulant une machine physique, il supporte n’importe quel systeme fonctionnant sur la même plateforme (voir une autre plateforme dans des conditions plus pro). Du coup il est possible de s’en servir pour l’installation de windows XP sous linux lorsque l’on en a une utilisation très ponctuelle comme par exemple vérifier la compatibilité d’un site avec IE ou flasher un périphérique USB pour lequel on a qu’une version windows du soft (c’est du vecu). Parceque oui, le petit plus c’est la possibilité en un click de connecter un element USB sur la VM ! solution très interressante qui ouvre de nombreuses nouvelles possibilités en terme de support de périphérique sur une VM.
Bien sure, il faut aussi regarder les performance de cet environnent virtuel, et de ce point de vue là, dans un cadre d’utilisation simple c’est vraiment correct : pour vous dire j’ai fait tourner un XP sous Linux avec en tache de fond un calcul distributed.net + un calcul BOINC et franchement, l’utilisation etait acceptable, le tout sur une machine à environ 1.5Gz. Les problèmes de performance apparaissent vraiment avec le manque de mémoire : à savoir que le disque est simulé, il s’agit en réalité d’un fichier, lui-même écrit sur un file-système géré par linux et mappé sur un disque physique. Lorsque le système virtuel vient à manquer de mémoire physique, celui-ci se met à swapper dans un fichier, lui-même ecrit dans le fichier décrit ci-dessus … bref, l’empilement d’IO virtuelles et réelles que l’on rencontre alors finit vite par venir à bout de n’importe quoi … et vous amenè par exemple à fermer windows en plus de 2h … beau score ! POur une utilisation plus proffessionnelle ou resemblant moins à des tests je ne peux que conseiller l’utilisation de partitions physique plutot que logique pour les VM.

C’est ainsi que j’ai ensuite décidé de faire quelque essais avec Xen, d’autant que ma suse préférée offrait cette possibilitée. Pour la petite histoire, j’ai tout d’abord essayer ça dans une VM sous vmware (lol).
Le principe de Xen est un peu différent, il ne s’agit pas d’une application hébergée par un système hôte qui va faire tourner des VM, mais d’une couche basse, située en dessous du noyau hôte et qui va permettre le partage des ressources matérielles. Donc en gros, au boot, on demarre une sorte de noyau Xen (l’hyperviseur) qui lui-même va démarrer un noyau principal, le domaine0 depuis lequel on va pouvoir lancer les machines secondaires.
Le noyau est compilé spécifiquement pour Xen avec une architecture eponyme. Xen ne fournit pas une machine vituel, au même sens que vmware qui vous fournit une sorte de PC version logiciel, il fournit un service de partage des ressources matérielle à plusieurs systèmes ce qui est assez différent, surtout dans le sens où il n’est pas possible d’installer avec Xen n’importe quelle VM, mais seulement des noyaux type linux, openbsd & co. Pas de Windows ici bas. L’installation d’une VM ne se fait d’ailleurs pas de le même façon que celle d’un système classique : ici pas de boot depuis le cd pour l’install … on se débrouille pour installer l’OS dans un file système (logique ou physique) puis on boot sur ce file system. Un peu moins user-friendly, mais après tout, la création de VM est-ce vraiment une fonctionnalité grand publique ?
Les performances sont plutot au rendez-vous, j’utilise une VM comme serveur de DEV avec tomcat, mysql & co, les temps de réponse sont les même que sur mon serveur précédent dont la conf était certe un peu inférieur mais sans que ce soit sensible. Grosso modo, je concidère que le fait que ce soit une VM est transparent avec Xen, pour l’instant. A noter qu’il est possible de gérer la priorité entre les différentes VM, solution utile si l’on souhaite partager le même hardware pour des serveur de DEV et PROD par exemple.

Pourquoi utiliser des VM me direz-vous ? hors mis pour se trouver dans le situation hubuesque mais présente : lorsque je boot mon serveur de dev la séquence est la suivante :

  • Un bootloader sur disquette va chercher un booloader pxe sur un serveur tftp
  • Celui-ci charge un bootloder plus perfectionné qui permet de booter un noyau Xen (multi-kernel)
  • Ce dernier va ensuite chercher l’hyperviseur Xen
  • Qui boot le noyau du domaine principal présent sur NFS
  • Qui demarre enfin la VM, elle aussi présente sur un autre lien NFS

Pourquoi faire simple quand on peut faire compliqué ? et bien simplement pour détacher le matériel du logiciel !!! voila qui permet de se sortir en un clein d’oeil des problèmes de pannes, mais qui permet aussi de migrer de matériel sans avoir à faire de réinstallation fastidieuses.

Portes dérobées dans les BIOS

Les fabriquants de bios prévoient souvent des portes dérobées pour accéder aux bios alors que ceux-ci sont protégés par des mots de passe … bien utile pour s’eviter un démontage suivi de son clear CMOS …
En voici une liste :

Backdoor Passwords

Many BIOS manufacturers have provided backdoor passwords that can be used to access the BIOS setup in the event you have lost your password. These passwords are case sensitive, so you may wish to try a variety of combinations.

WARNING: Some BIOS configurations will lock you out of the system completely if you type in an incorrect password more than 3 times. Read your manufacturers documentation for the BIOS setting before you begin typing in passwords.

Award BIOS backdoor passwords:

ALFAROME	 	BIOSTAR	 	KDD	 	ZAAADA
ALLy	 	CONCAT	 	Lkwpeter	 	ZBAAACA
aLLy	 	CONDO	 	LKWPETER	 	ZJAAADC
aLLY	 	Condo	 	PINT	 	01322222
ALLY	 	d8on	 	pint	 	589589
aPAf	 	djonet	 	SER	 	589721
_award	 	HLT	 	SKY_FOX	 	595595
AWARD_SW	 	J64	 	SYXZ	 	598598
AWARD?SW	 	J256	 	syxz	 	 
AWARD SW	 	J262	 	shift + syxz	 	 
AWARD PW	 	j332	 	TTPTHA	 	 
AWKWARD	 	j322	 	 	 	 
awkward 	 	 	 	 	 	

AMI BIOS Backdoor Passwords:

AMI	 	BIOS	 	PASSWORD	 	HEWITT RAND
AMI?SW	 	AMI_SW	 	LKWPETER	 	CONDO

Phoenix BIOS Backdoor Passwords:

phoenix	 	PHOENIX	 	CMOS	 	BIOS

Misc. Common Passwords

ALFAROME	 	BIOSTAR	 	biostar	 	biosstar
CMOS	 	cmos	 	LKWPETER	 	lkwpeter
setup	 	SETUP	 	Syxz	 	Wodj

Other BIOS Passwords by Manufacturer
Manufacturer      	Password

VOBIS & IBM	merlin
Dell	        Dell
Biostar	        Biostar
Compaq	        Compaq
Enox	        xo11nE
Epox	        central
Freetech	Posterie
IWill	        iwill
Jetway	        spooml
Packard Bell	bell9
QDI	        QDI
Siemens	        SKY_FOX
TMC	        BIGO
Toshiba	        Toshiba

Toshiba BIOS

Most Toshiba laptops and some desktop systems will bypass the BIOS password if the left shift key is held down during boot

IBM Aptiva BIOS

Press both mouse buttons repeatedly during the boot

Demarrage d’un noyau Xen en réseau via PXE

Un article précédent décrit brièvement comment booter une machine sur le réseau en utilisant PXE. Je me suis donc amusé à booter, cette fois ci, non pas un noyau classique mais un moyau Xen. De prime abord cela pourrait sembler être semblable mais il n’en est rien !

L’utilisation de Xen demande de booter un premier noyau “gen.gz” qui va lui-même, par la suite, booter un second noyau compilé spécifiquement. L’utilisation de pxelinux.0 comme bootloader n’est donc plus possible dans un tel cas. Voici donc la procédure à suivre :

  • Il faut tout d’abord créer un noyau compatible Xen et acceptant un boot depuis le reseau, pour celà, je vous renvoie à l’article précédent qui indiques les options que celui-ci doit supporter. Ce noyau devra en outre être compilé pour une cible de type XEN.
  • Il faut ensuite récupérer un bootloader adapté, celui-ci se trouve dans le package Syslinux (il est possible qu’il ne soit pas livré avec votre distribution, il suffit alors de le télécharger sur le net). Le bootloader en question est mboot.c32 ; il se trouve dans syslinux/com32/modules. Ce fichier sera placé dans le répertoire tftpboot sur serveur.
  • La configuration de PXE se fait dans le fichier dhcp.conf, exactement comme nous l’avions fait précédemment. Rien ne change.
  • Dans le fichier de démarrage (tftpboot/pxelinux.cfg/mac-adress ) nous allons trouver la configuration suivantes :
    default linux
    label linux
      kernel mboot.c32
      append xen.gz dom0_mem=192000 --- vmlinuz_xen root=/dev/nfs devfs=mount ip=::::::dhcp nfsroot=10.0.0.20:/share/homeXen initrd=initrd_xen
    prompt   1
    timeout  10
    • Le noyau qui sera booté en premier est le fameux mboot.c32
    • Celui-ci va lancer la couche basse de XEN (xen.gz) qui est à récupérer dans le package de XEN
    • Le premier noyau va être configuré avec 192Mo de mémoire
    • Il va ensuite lancer le noyau linux compilé pour XEN : vmliuz_xen
    • Le boot se fera depuis le réseau, la configuration etant obtenue par dhcp
  • Le noyau ainsi démarré va encore poser un problème : lorsque XEN demarre en mode bridge, il tombe l’interface réseau, ce qui bien sure lors d’un boot NFS plante la suite du démarrage. Une des solution est l’utilisation du mode rootage plutot que bridge. Il faut modifier le fichier /etc/xen/xend-config.sxp :
    • Mettre en commentaire les deux lignes de confugration du bridge :(network-script network-bridge) et (vif-script vif-bridge)
    • Décommenter les lignes du mode routage : (network-script network-route) (vif-script vif-route)

    Pour ceux qui comme moi tiendraient vraiment à utiliser une configuration de type bridge, je n’ai rien trouvé de mieux que d’utiliser une seconde carte réseau sur la machine …

Utilisation d’un fichier comme SWAP avec Linux

Sur un pc sans disque (mais aussi parfois sur une machine virtuelle), il n’est par définition pas possible de créer une partition dédiée au swap, dans ce cas, il est possible d’utiliser un fichier en temps que swap.
La création consiste en les étapes suivantes :

  • Créer un fichier de swap : dd if=/dev/zero of=/swapfile bs=1024 count=xxx avec xxx = taille en Ko du swap
  • Créer en temps que swap : mkswap /swapfile
  • Il faut ensuite associer ce fichier à un périphérique : losetup /dev/loop0 /swapfile
  • Puis activer ce swap : swapon /dev/loop0

Créer un disquette de boot permettant de faire un demarrage PXE sans ROM réseau

Dans un précédent article, j’ai indiqué comment booter depuis un PC diskless en utilisant la fonction boot-pxe de la carte réseau. Toutefois sur un pc un peu ancien il est rare de trouver une carte supprotant le pxe… Dans ce cas, il y a une solution simple : créer une disquette de boot minimaliste avec les driver PXE pour ensuite demarrer sur le réseau. (je retrouve ainsi enfin une utilité à mon lecteur de disquette !! génial !)

La démarche est assez simple d’autant que tout est automatiser : il faut créer une disquette de boot sur le site suivant : http://rom-o-matic.net/5.4.2/

  • Choisir la carte réseau dans la liste
  • Choisir le format de sortie : Floppy bootable ROM image (.zdsk)
  • Choisir customize ROM Option et choisir :
    • USE_STATIC_BOOT_INFO en indiquant toute la configuration (je ne sais pour quelle raison, les infos dhcp ne sont pas reçu sur le client dans ma config)
    • PXELOADER_KEEP_ALL
  • Sélectionner le bouton “Get ROM”
  • ecrire le fichier sur une disquette : cat eb-5.4.2-driver.zdsk > /dev/fd0
  • configurer le serveur pxe comme indiqué dans le précédent article
  • booter !

Et voila … une machine sans disque dur qui boote sur le réseaux avec une carte réseau ne supportant pas PXE ;o)