Just Another Geek

Je viens de publier les slides de ma présentation aux JSSI du CELAR [archive] intitulée pompeusement Sécurité des systèmes VoIP : exemple d'un test blackbox [archive] (non j'ai pas trouvé plus court, enfin si, mais... ça faisait moins classe).

Je ne les publie que maintenant car j'hésitais à réutiliser ce support pour la caravane des conférences (Copyright news0ft [archive]), mais je me suis dit que j'étais trop jeune pour commencer à faire ça, c'est un cercle infernal après :)

Hier soir, lorsque j'ai vu l'advisory CVE-2006-5444 [archive] portant sur Asterisk [archive] et son implémentation Skinny, je me suis dit : chouette, je vais pouvoir utiliser scapy [archive] et mon implémentation Skinny toute prête [archive] pour écrire l'exploit (un integer overflow [archive] entrainant un heap overflow [archive]).

Oui, sauf qu'y a vraiment pas besoin : le bug (pré-authentification s'il vous plait! Excusez moi du peu) porte sur le premier champ du protocole (la longueur du message) dans le premier segment de données, bref rien de passionnant, et y a surtout pas besoin d'utiliser scapy pour faire ça :)

Toujours est-il que je remercie les développeurs Debian pour asterisk_safe qui permet de relançer le daemon lorsqu'il est mort. C'est une excellente solution pour les... attaquants puisque avec le noyau de Debian Sarge par défaut, il n'y a pas de randomization des adresses et la GNU Libc 2.3.2 n'a pas les "mesures de protection" qui permet d'utiliser un simple unlink(). Pour exploiter ça, c'est finger-in-the-noise si on cherche pas à faire compliquer.

Si j'ai le temps, je porterai l'exploit dans Metasploit 3... Mais faut d'abord que je fiabilise mon-mien-tout-crade-mais-qui-marchouille...

Note : Ça fait tout de même mal aux yeux que ce soit le tout premier traitement appliqué au message qui soit exploitable aussi facilement, ça laisse perplexe sur la sécurité du reste... À auditer donc.

Aujourd'hui, nous sommes un peu impuissants (surtout un certain F. R*nal par son grand age) face aux vulnérabilités clients : chaque semaine, une nouvelle faille sort dans Firefox, Thunderbird, Gaim, Skype, etc.
Tout le monde est potentiellement vulnérable (sisisi, même les gens sous Lynx) en cas d'attaque ciblée. Quelles sont les solutions ?

Mettre en oeuvre un système PaXé [archive] sur une machine orientée desktop est contraignant : tous les logiciels pas libres (comme le plugin flash propriétaire) vont commencer à segfaulter en permanence et on va finir par whitelister tous les binaires posant problème : on ne fait que déplacer le problème.
De plus, je ne suis même pas sûr que les vulnérabilités de Firefox seraient détectées (par exemple lorsque ça touche le moteur Javascript).

À défaut d'avoir une solution protégeant les applications, il faut essayer de minimiser l'impact d'une vulnérabilité. Ainsi, SELinux apporte une solution concrète et fiable : on applique à chaque application une politique de sécurité, on déclare ainsi toutes les actions que ce processus peut faire. L'exemple classique (limite bidon) sorti tout le temps est que Mozilla Firefox ne doit pas avoir accès à /bin/sh par exemple, je dis bidon car un attaquant déterminé pourra toujours s'en sortir en ajoutant une backdoor dans ~/.bashrc, cela marcherait car Firefox peut sauvegarder ses fichiers n'importe où!

Pourquoi ce n'est pas plus populaire que ça ? Car les distributions n'étaient pas très ouvertes à son entrée : il faut écrire les règles, gérer celles-ci lorsqu'on installe/supprime le logiciel, tester, etc.

Pour Debian, l'idée commence à germer dans la tête des développeurs qui aimeraient bien voir SELinux activé par défaut dans la future release de la distribution [archive]. C'est un très bonne nouvelle si ca marchait tout seul pour les paquets les plus populaires (navigateur et messagerie instantannée).

L'article How to Memorize 100 Passwords in 10 Seconds [archive] (via fr.misc.cryptologie [archive]) approche le problème de génération des mots de passe et la multiplication des logins/mots de passe différents.
La solution proposée par Jean-Philippe Aumasson est intéressante et doit ressembler à quelque chose comme ça (à vérifier dans les sources):

 
int passwords[maxpasswords][lenpassword]; /* avec lenpassword = lenpassword/4 */
int i, j;

srand(masterkey);

for (i=0; i < maxpassword; i++) {
  for (j=0 ; j < lenpassword ; j ++)
       passwords[i][j] = rand();

  srand(passwords[i][0]);
}

Ce tableau indexé correspond à n mots de passe disponibles. L'intérêt d'utiliser exclusivement rand() permet de ne pas compromettre p[n+1] ou p[n-1] si p[n] était découvert (car les passwords sont en ASCII, donc chaque octet généré est modulo la taille de l'alphabet). Notons que cela est vrai si et seulement si le PRG est considéré sûr et que la taille de l'alphabet est assez grande.

L'intérêt, face aux gestionnaires de keyring comme pwsafe [archive] ou revelation [archive], est que cet algorithme vous permet de ne pas avoir à vous balader avec votre keyring partout, vous avez juste besoin du programme, votre master key en tête... et d'une liste qui associe pr0nwild.com à l'index n de votre table de mot de passe.

Tout ça pour dire que je n'ai toujours pas trouvé un gestionnaire de mots de passe correct avec les fonctionnalités suivantes :

• Chiffrement standard (cad déchiffrable dans openssl) du keyring,
• Frontend graphique,
• Frontend console,
• Pas constamment cassé comme revelation dans Debian,
• Plus fonctionnel que pwsafe;

Update quelques heures plus tard : En fait, je ne sais pas ce qui est le mieux ; une taille d'alphabet grande ou petite ? Plus elle est grande, plus les caractères du password seront aléatoires, mais la difficulté de retrouver le mot de 32 bits à partir du modulo sera diminué... Enfin je me comprends...

SSTIC 2006 [archive] me voila [archive] !

Je me posais la question suivante : lorsqu'on télécharge une clef PGP depuis un serveur PGP (gpg --recv-key 0x9223052 par exemple), est-on sûr que c'est la clef 0x9223052 ?

Note pour les gens pressés que je parle du KeyID et pas de la personne possédant la clef.

La FAQ PGP [archive] indique qu'on est capable de forger des clefs pour une fingerprint donnée, ou un KeyID donné, ou un Userid donné mais pas pour tous ces composants à la fois.

On ne peut donc être sûr d'avoir télécharger la bonne clef que si le KeyID, la fingerprint et la taille correspondent (on doit donc les connaître avant de la télécharger) à ce qu'on s'attend. Il est également bien de vérifier que la clef est auto-signée par son propriétaire.

Je regardais les nouveautés de la prochaine release d'OpenBSD [archive] (la 3.8) et parmi les nouveautés d'OpenSSH (4.2), on trouve ça :

Adds a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server and eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.

C'est un sale temps pour les mass-rooters :p

Phénomène intéressant depuis quatre jours sur ma FreeBox : un scan du port 42 en TCP (utilisé par WINS). Jusqu'ici, rien de bien nouveau me direz vous, mais ce qui est amusant, c'est que les sources de scan ne sont que des adresses IP associées à mon DSLAM.

On sait que les nouveaux vers privilègient les machines voisines, mais là, ca semble très ciblé et les groupes comme SANS [archive] ne remarquent rien d'anormal.

/me va mettre un netcat+tcpdump de ce pas...

Update@19h05 : Après capture pcap, ca ressemble à un simple connect() scan. Toujours est-il que cela reste étrange...

Update 3 mois plus tard : C'est en réinstallant mon routeur que j'ai compris pourquoi, la configuration par défaut d'un abonné Freebox est d'avoir deux routes : l'une qui donne sur votreadresseippublique/24 et une route par défaut qui mène à la Freebox. Les vers/virus essayant ainsi de taper dans ce qu'il croit un réseau local, or cela est en fait tous vos voisins du DSLAM...

Je ne m'étais jamais rendu compte que le xlock ne servait strictement à rien chez moi : en effet, je n'utilise pas de Session Manager tel que gdm, wdm, xdm, etc. Je lance directement le mode graphique par la commande startx.

Le truc, c'est que lorsque, dans ta session X (non, ce n'est pas pornographique), tu lockes ton écran. Eh bien il suffit de taper les touches magiques Control-Alt-Backspace pour tuer le serveur X, de fait, tu killes en même temps xlock ce qui rend la main au shell qui a lancé startx. Moralité, xlock ne sert à rien (dans ce cas là).

Les solutions ?

• Utiliser un Session Manager
• Faire un alias : startx='\startx &; vlock'
• Bloquer la séquence Control-Alt-Backspace

L'installation de Sguil [archive] s'est largement simplifié depuis la dernière fois, il n'y a maintenant besoin que deux modules TCL [archive] (oui, le projet Sguil est en TCL/TK).

Sous Debian GNU/Linux, l'installation se résume alors à :

$ sudo apt-get install tclx8.4 itcl3 itk3 iwidgets4
$ cd ~/bin/
$ wget http://ovh.dl.sf.net/../sguil-client-0.5.3.tar.gz [archive]
$ tar zf client-0.5.3.tar.gz
$ ./sguil-0.5.3/client/sguil.tk &!

Mais ce n'est pas très user-friendly si votre écran fait 15" et que vous êtes limité en 1024*768, les développeurs m'ont alors indiqué de modifier l'agencement des fenêtres grâce à cela dans votre sguil.conf :

set RTPANE_PRIORITY(0) "1 2 3 4 5"

Et de commenter les lignes suivantes :

set RTPANE_PRIORITY(1) "3 4"
set RTPANE_PRIORITY(2) "5"

Merci de l'astuce !

J'avais envie de jouer avec le module Perl Net::DNS [archive] et avec le serveur DNS d'un ami un peu trop ouvert alors j'ai automatisé la technique (très simple) de DNS Cache Snooping documenté dans l'article de Luis Grangeia [archive].

Ce tout petit outils, snoopdns [archive], permet de savoir si un enregistrement DNS existe dans le cache d'un serveur DNS (si celui-ci est "ouvert").
Imaginez que vous êtes sur un réseau et que vous saviez que le serveur de production (tournant sous Debian bien entendu) utilise le serveur DNS ns0.boite.com.

Vous pouvez ainsi voir si un serveur est mis à jour après la découverte d'une faille en regardant si le cache DNS contient un enregistrement DNS pour security.debian.org.

Cet exemple est un peu foireux car le TTL pour security.debian.org est d'une heure donc la fourchette n'est pas très grande mais le principe est là.

Ca donnerait :

$ snoopdns ns0.boite.com security.debian.org
security.debian.org accessed 3310 seconds ago [91.94% of the original ttl (3600)]

On peut donc penser que le serveur a été mis à jour. C'est une hypothèse comme une autre hein...

moa@server:/home/moa% wget http://tinyproxy.sf.net/../tinyproxy-1.6.2.tar.gz [archive] \
                      tar zxf tinyproxy-1.6.2.tar.gz     && \
                      (cd tinyproxy-1.6.2/              && \
                          ./configure --prefix=/home/moa && \
                          make && make install)
moa@server:/home/moa% vi etc/tinyproxy.conf
moa@server:/home/moa% usr/sbin/tinyproxy

Puis

hmm@work:/home/hmm% ssh -L 8888:localhost:8888 -N moa@server

Réglage du navigateur pour utiliser http://localhost:8888/ comme proxy et c'est fait : toutes les sessions HTTP circuleront dans un tunnel SSH, adieu le sniffing sur le réseau local. C'est pas que j'ai pas confiance en mes collègues mais... j'ai pas confiance ;)

Ce patch [archive] (trouvé sur une des listes de Dshield [archive]) à appliquer sur OpenSSH [archive] permet de logguer les logins/mots de passe entrés lors de l'authentification.

Mais ce patch empeche toute tentative de login, alors je trouve son utilité discutable car il ne peut être utilisé ni en production (c'est une bonne chose), ni sur un honeypot (enfin, tout dépend de ce qu'on veut en faire). Ça sert a quoi alors ? :)

Y a plus qu'a patcher le patch pour faire ce qu'on veut...

WormRadar [archive], développé par Roger Thompson, est un projet qui a pour but d'écouter le trafic passant par une machine et de faire des statistiques sur les connexions entrantes en fonction des ports ciblés. Le résultat final est un graphique [archive] disponible sur le site du projet mis à jour toutes les trente minutes.

L'objectif principal est de détecter les nouveaux Worms, bots, ou tentative de piratage. WormRadar est un outil "distribué" dans le sens où tous les clients participant au projet envoient leurs résultat à un serveur principal qui traitera les données.

En effet, les paquets reçus par le client sont analysés pour détecter les patterns déjà connus. On peut alors distinguer deux catégories de "connexion" :

• Les données non reconnus par le moteur, représentée par l'item rouge dans le graphique. Les noms sur le graphique sont déterminés à partir du protocole (TCP ou UDP principalement), du numéro de port et de la chaîne "unk".
  Exemple : t1433unk pour le port 1433 en TCP
• Les paquets reconnus par l'analyseur, en vert. Cette catégorie comptablilise également les paquets vides.

Ce qui nous intéresse le plus sont les données inconnues car si on reçoit sur un même port un nombre important de connexions, on peut découvrir un nouveau Worm ou une nouvelle faille.

A l'heure actuelle, un peu plus de 1500 nodes participent au projet. Les données sont uploadées au serveur par mail et par UDP (avec exactement le même contenu que le mail sans l'enveloppe).

Les projets similaires ne manquent pas (Dshield [archive], ISC [archive]) et semblent beaucoup plus ouvert que WormRadar qui n'est disponible que sous forme binaire pour les systèmes Microsoft Windows (mais son auteur compterait porter l'application sous GNU/Linux).

C'est amusant de voir toutes les personnes qui croient avoir le scoop en or à chaque faille de sécurité. Par exemple, regardez tous les marketeux qui parlent au sujet de la Faille TCP/IP ! Ils sont tellement content qu'ils diffusent l'information sur toutes les mailing lists, ou forums. On leur dit que la technique est connue depuis 1996 ?

Ah si si si si, l'Internet va couler par les méchants n'hackers...

M'enfin...