Vers une certification … utile

Contexte

Avec les nouvelles CSPN très symboliques délivrées ces derniers mois, il apparaît clairement que la certification sécurité de produits logiciels est une activité politico-marketing, dont l'efficacité réelle a largement été battue en brèche lors de la conférence SSTIC 2013.

Les questions fondamentales qui se posent alors sont les suivantes : est-il possible d'améliorer la sécurité des logiciels commerciaux ? D'aider à la sélection des meilleurs, lorsque ni Darwin, ni la main invisible du marché n'y arrivent ? Et si oui, par quel miracle ?

La sûreté logicielle est un domaine curieux. La majorité des problèmes avaient été résolus il y a 30 ans. La quête de la perfection a produit les langages formels, la preuve de programme, ainsi que des certifications fiables - comme la DO-178 en aéronautique. L'ANSSI semble d'ailleurs redécouvrir aujourd'hui que les systèmes critiques sont programmés en ADA. L'industrie informatique était alors à son apogée. On entrait dans les salles machines en blouse blanche, et les informaticiens étaient promis à de brillantes carrières dans leurs entreprises respectives. Bref, le paradis originel.

Puis tout a basculé avec l'informatique personnelle. En quelques années, tout le monde est devenu informaticien. Les systèmes MS-DOS, puis Windows 3.1, sont devenus des références pour le grand public, habituant les utilisateurs à tolérer les bogues et les redémarrages intempestifs. La science informatique est devenue une commodité dont la valeur ajoutée a été remise en cause, jusqu'à être complètement niée, ouvrant la voie à l'externalisation puis à la "cloudification", voire au BYOD, qui sont les négations suprêmes de toute forme d'informatique interne.

Ce billet ne va donc pas essayer de résoudre un problème qui n'existait pas avant d'avoir été inventé. Il va juste pointer les défauts du processus de certification actuel, en proposant (une fois n'est pas coutume) des solutions concrètes.

Point de vue de l'éditeur

Pour l'éditeur, l'équation est simple : une CSPN coûte environ 30k€ et permet de mettre le logo "ANSSI" sur toutes ses plaquettes commerciales.

Même si le produit n'a aucune qualité, deux ou trois itérations sur la cible de certification permettront d'obtenir le précieux label sur un périmètre tellement contraint que l'échec est impossible. Rappelons que Windows NT4 est certifié "C2" (soit EAL4) sur un système qui n'a pas de lecteur de disquette, de lecteur de CD-ROM, ni de carte réseau.

Au pire le produit est une bouse innommable qui échoue même à remplir les fonctions de sécurité élémentaires pour lesquelles il a été conçu. Il n'obtiendra donc (probablement) pas la certification, mais personne n'en saura jamais rien.

Point de vue de l'auditeur

Pour l'auditeur, l'équation est plus compliquée, car elle fait intervenir son "éthique" (une notion si difficile à définir) …

La première réaction d'un auditeur qui découvre une faille peut être de la garder sous le coude. Car cela lui permettra de "réussir" tous ses pentests futurs dans le même environnement. Et après tout, No More Free Bugs.

Supposons maintenant que l'auditeur décide de remonter les failles de sécurité. C'est une obligation pour les sociétés certifiées PASSI (certification qui va être un échec, mais ceci est une autre histoire ).

La communication avec le vendeur est la suivante : "Votre produit souffre d'un Cross-Site Scripting (XSS). Voici une preuve de concept en Python permettant de reproduire la faille."

Et là, tout est possible …

• Réponse A : "C'est quoi Python ?"

Décision : vendez la faille au plus offrant. Vous allez perdre du temps avec cet éditeur, au pire il va vous menacer.

• Réponse B : "Ok c'est corrigé."

Décision : ditchez le produit ("poubellisez" n'ayant pas encore été validé par l'Académie Française). L'éditeur a probablement utilisé un hack sordide pour corriger la ligne de code qui pose problème, afin de passer le test. La faille sera réintroduite dans la prochaine version du produit.

• Réponse C : "Ok merci. Qu'est-ce que vous recommandez comme librairie de filtrage ? Est-ce que OWASP ESAPI est efficace contre cette attaque ?"

Décision : gardez le produit. Il y aura probablement d'autres failles, mais l'éditeur connaît son métier.

• Réponse D : "désolé l'outil d'analyse statique que nous utilisons en intégration continue avait détecté le problème, mais le développeur a fermé le ticket sans corriger. Il sera durement châtié."

Décision : appelez moi. Vous êtes probablement en communication avec des entités extraterrestres chargées d'asservir les humains par la technologie.

La clé du problème

Le fond du problème, c'est que les audits de sécurité ne servent à rien. D'ailleurs en ce qui me concerne, j'ai arrêté le pentest. Désormais les tâcherons de l'informatique (souvent appelés "chef de projet Java" ), frappés de cyber-superstition savamment entretenue par les technomanciens et autres cyber-charlatans, déposent leurs enfants accouchés dans la douleur (certains projets informatiques prennent largement plus de 9 mois) devant l'antre de la Sybille. Je questionne la pureté de leur cœur, et prononce (parfois) la sentence fatidique: "il vivra".

Mais quel est le secret de la clairvoyance ? Comment auditer un logiciel par des méthodes plus proches de la thérapie analytique que du reverse engineering ?

L'édition logicielle c'est la vie: tous les projets naissent égaux, mais certains sont plus égaux que d'autres. Car un CMS peut être né en Erlang, ou en PHP. Et born in PHP, born dead.

Pour juger de la qualité d'un produit, il est inutile de se focaliser sur les failles d'implémentation. Certes je ne nie pas l'élégance d'une exploitation de faille particulièrement ardue, mais les bonnes questions à se poser sont d'abord les suivantes :

• Quelle est l'origine du projet ? S'agit-il du travail d'un stagiaire hâtivement rebaptisé "produit" ? Quel est l'historique de l'entreprise ?
• Quels sont les choix technologiques opérés ? Sont-ils subis (ex. PHP c'est gratuit, Java tout le monde connait) ou choisis ?
• Quels sont l'environnement et les méthodes de développement mises en œuvre ? Quelles sont les options de compilation utilisées ?
• Quelle est la liste du code tierce partie et/ou Open Source intégré au produit ? L'éditeur est-il seulement capable d'en fournir la liste ?
• Y a-t-il une équipe sécurité côté vendeur ? Y a-t-il eu des bulletins de sécurité publiés ? La liste des alertes de sécurité est-elle claire et facilement accessible ?

Mes plus grand succès en pentest ne sont pas d'avoir réussi à pénétrer un OpenVMS depuis un accès FTP anonyme, ou d'avoir analysé un firmware inconnu over the night dans une chambre d'hôtel. Mes plus grands succès sur le long terme sont d'avoir réussi à convaincre un éditeur d'effectuer une montée de version sur Visual Studio, ou d'appliquer le template SiteLock sur un contrôle ActiveX. Car indépendamment des failles d'implémentation qui restent à découvrir, cela démontre une maturité de l'éditeur sur le sujet, et procure des bénéfices beaucoup plus larges que la correction d'une faille unitaire.

A contrario, j'ai du mal à imaginer comment on peut certifier sans réserve un produit qui expose d'emblée une interface Web en PHP à des utilisateurs non authentifiés. Rien que la lecture du changelog PHP donne une idée du nombre de failles qui affecteront la version "certifiée" d'un tel produit. Sans parler des mécanismes "annexes" tels que la mise à jour, la vérification de licence, le reporting ou l'administration distante – presque toujours exclus du périmètre – et pourtant risques majeurs pesant sur la sécurité du système.

Pour avoir une certification qui fonctionne, il faut juger l'esprit d'un produit plus que son implémentation.

Des propositions concrètes

Maintenant que tous les biais du système ont été identifiés, voici des propositions concrètes qui permettraient de rendre la certification plus efficace à mon sens.

Mettre la pression sur les éditeurs

Le choix d'entrer en CSPN doit être une décision lourde de conséquences. L'une des mesures "phare", toujours réclamée, mais jamais obtenue, serait de publier la liste des produits "recalés" (assortie des motifs). Sous cette hypothèse, aucun éditeur ne s'amuserait à soumettre un produit dans lequel il n'a qu'une confiance limitée.

L'un des problèmes de fond est la valeur de la CSPN dans le temps. Certes un produit peut être conforme à un instant T selon l'avis d'un expert X, mais l'état de l'art évolue et tous les logiciels ont (et auront) des bogues. Comment faire en sorte que le travail réalisé sur une CSPN donnée puisse encore signifier quelque chose 6 mois après ? Un produit certifié CSPN il y a 10 ans, à base de DES et MD5, figurerait-il encore en bonne place sur le site de l'ANSSI ? (Notons que c'est le cas pour certains produits certifiés Critères Communs qui ne sont pourtant plus du tout à l'état de l'art).

La valeur d'une évaluation s'effrite avec le temps. Dans un autre domaine, CVSS définit un facteur "temporel" sur la criticité des failles. Voici quelques idées pour transposer le concept à la CSPN :

• Borner dans le temps la validité d'une évaluation, par exemple à 3 ans. Au-delà, le produit devrait passer par une phase de re-certification, ou bien perdre son "tampon".
• Obliger les éditeurs à commercialiser la version certifiée pendant toute la durée de validité du certificat, avec support technique et maintien en condition de sécurité (MCS). Après tout, on oblige bien les boulangers à fabriquer un quota de baguettes au prix réglementé.

Car la plupart des produits figurant sur le site de l'ANSSI ne sont tout simplement plus disponibles dans la version certifiée ; il existe même parfois plusieurs versions majeures d'écart. Ce qui conduit à des incompréhensions entre l'auditeur (qui découvre que la version qu'il audite est une passoire) et l'administration (qui confirme que la version "tamponnée" était bien meilleure).

Au final, comme il faut bien annoncer au client que la sécurité de son réseau est affaiblie par l'utilisation d'un produit CSPN, alors que n'importe quel produit standard de l'industrie aurait fait l'affaire, c'est un coup fatal qui est porté à tout le processus de création de confiance.

• Suspendre ou révoquer la certification en cas de faille identifiée a posteriori, ou d'évolution majeure du produit (ex. montée de version obligatoire pour les clients).

(Accessoirement, on peut déplorer le fait que les versions auditées ne soient pas archivées par l'ANSSI dans une démarche d'investigation a posteriori, pouvant éventuellement conduire à la révocation d'un certificat.)

• Publier le rapport d'audit technique complet. Ceci permettrait à chacun de se faire une idée ce qui a été réellement testé, ce qui a été laissé de côté, ainsi que les choix d'implémentation de l'éditeur.

Car personnellement, savoir si la couche cryptographique repose sur OpenSSL ou sur GnuTLS me donne une bonne idée sur la sécurité future d'un produit. Plus qu'un "avis d'expert : le produit est conforme à la cible de sécurité" en tous cas …

• Ne pas accepter les certifications en "boite noire".

Il faut arrêter de se retrancher derrière la propriété intellectuelle et autres arguments juridiques, donc fallacieux : tout ça c'est du pipo pour les attaquants. Tous les consultants en sécurité sérieux pratiquent le reverse engineering, y compris dans des pays où la législation applicable est pourtant contraignante. Quant aux attaquants, ils vont plus loin et n'hésitent pas à pirater les éditeurs s'ils ont besoin d'accéder au code source.

Toute évaluation doit être effectuée par démontage total du matériel et du logiciel, facilité par l'éditeur si besoin. Bienvenue dans la "vraie vie".

(Note : je ne sais pas comment se passe réellement le processus de certification, mais on a parfois l'impression que le test a été réalisé en pure boite noire. exec.php FTW !)

Personne ne lit les cibles de sécurité

C'est un fait : personne ne lit les cibles de sécurité. Heureusement d'ailleurs, car on y trouve des énormités du style "notre produit protège le système, mais seulement s'il n'est pas compromis". Seriously.

Il est totalement indispensable pour la crédibilité de la CSPN que les cibles de sécurité n'aient pas besoin d'être lues par les utilisateurs. Que le produit soit "raisonnablement sûr" dans le cas d'usage le plus courant (principe de moindre surprise), pas dans une configuration obscure potentiellement non supportée par l'éditeur.

Les cibles de sécurité ne devraient pas être rédigées par les éditeurs, mais par les utilisateurs. Pour aller plus loin, on pourrait même imaginer que les certifications ne puissent pas être réalisées à la demande d'un éditeur, mais nécessairement d'un client final (qui peut être l'ANSSI elle-même) …

De l'importance de l'écosystème

Un produit logiciel n'existe pas ex nihilo. Il vient avec tout un écosystème : matériel, système d'exploitation, mises à jour, télémaintenance, etc. Or les failles les plus triviales (ou les plus efficaces) à exploiter sont parfois à chercher dans les catégories suivantes :

• Mises à jour : le produit supporte-t-il les mises à jour automatiques ? Sont-elles actives par défaut et/ou obligatoires ? Sont-elles sécurisées (ex. signature) ? Le serveur de mise à jour est-il chez OVH ? Le retour à une version antérieure (downgrade) notoirement boguée est-il possible ?
• Télémaintenance : le produit a-t-il des fonctions de télécollecte (ex. statistiques d'utilisation), voire de prise en main à distance ? Le produit doit-il être connecté à un serveur de licences sur Internet ?
• Secrets de l'éditeur : y a-t-il un seul mot de passe "root" pour accéder à tous les logiciels du même vendeur ? (Variante : un générateur de mots de passe reposant sur un algorithme trivial). Y a-t-il des "backdoors" - à des fins de support technique bien sûr ? Les clés cryptographiques servant à signer les mises à jour sont-elles bien protégées ?
• Sécurité de l'éditeur : l'éditeur est-il en mesure d'assurer la sécurité de ses infrastructures de développement et de support ? Un éditeur de produit CSPN ne devient-il pas automatiquement OIV ? Faut-il révoquer la certification en cas de compromission de l'éditeur ?

Utiliser le crowdsourcing

Concevoir et implémenter des logiciels robustes est une tâche ardue dans laquelle presque tous ont échoué. Identifier de manière exhaustive les problèmes de sécurité dans un logiciel complexe en moins d'un mois est une tâche impossible.

C'est pourquoi il ne faut pas avoir la prétention d'y arriver seul, mais au contraire exploiter la horde grouillante et infatigable des auditeurs en sécurité, qui besognent à longueur de journée les mêmes produits chacun dans leur coin (mais pour des clients différents).

Aujourd'hui la meilleure tactique pour un consultant en sécurité qui empile les failles consiste à les vendre à des tiers (essentiellement américains) ou à les garder sous le coude pour réussir son prochain audit – du même produit mais chez un autre client.

Les auditeurs certifiés PASSI ont déjà l'obligation de remonter gracieusement les failles découvertes au CERTA – mais il est probable que le nombre de certifiés PASSI (qui est nul aujourd'hui, la phase expérimentale venant seulement de se conclure) ne va pas exploser pour des raisons que j'évoquerai à la rentrée dans un autre billet.

Il reste donc à affiner la deuxième approche : mettre en place un Bug Bounty au niveau de l'ANSSI

La solution ultime

Le lecteur qui a eu le courage et la patience d'arriver jusqu'ici découvrira enfin la solution ultime permettant de résoudre tous les maux évoqués ci-dessus : il s'agit tout simplement d'arrêter de délivrer des labels.

Il m'a été donné d'auditer un grand nombre de produits commerciaux, expérience qui s'est enrichie de la lecture des rapports de mes pairs. Et j'ai désormais acquis la certitude qu'il est impossible de réaliser une dichotomie manichéenne entre les "bons" et les "mauvais" produits.

Certes, il existe des produits que leurs tares congénitales vouent à la roche Tarpéienne. Il serait d'ailleurs d'utilité publique d'en informer le plus grand nombre.

Mais en ce qui concerne les autres, un bon rapport d'évaluation ne va pas dire : "ok, on a rien trouvé". Un bon rapport va identifier les forces du produits (par exemple un stockage sécurisé des mots de passe), énumérer des problèmes à remonter à l'éditeur (comme des failles d'implémentation à corriger), préciser les limites de mise en œuvre à l'intérieur desquelles le produit reste relativement sûr (en général : ne pas activer les options de rétrocompatibilité).

La seule valeur ajoutée que peut apporter l'ANSSI dans le processus, c'est de collecter tous les rapports d'audit rédigés en France, y ajouter ses travaux dans des domaines que je sais nombreux par les offres de stage qui apparaissent et qui disparaissent sur son site, et publier le tout sous licence ouverte. Ainsi le niveau de sécurité des produits serait en permanence réévalué par la communauté, qui profiterait des fichiers "IDB" et autres scripts Python de tous ceux qui ont travaillé sur le sujet auparavant.

Un exemple "neutre" auquel s'applique parfaitement cette réflexion est celui du logiciel TrueCrypt. Car la version certifiée par l'ANSSI est documentée comme étant vulnérable à l'extraction du mot de passe en mémoire, lorsque le logiciel est utilisé pour le chiffrement du volume de démarrage (ce qui limite la portée d'une assertion réductrice telle que : "TrueCrypt est CSPN"). Certaines failles ont été corrigées depuis, mais personne n'a pris soin de retravailler sur une version plus récente de TrueCrypt … qui n'apporte rien de moins que le support Windows 7 et Mac OS 10.6+, entre autres.

Conclusion

La sécurité informatique est le cancer de l'industrie logicielle. Il n'y a pas d'argent pour la prévention. Seuls les malades s'intéressent au sujet, mais il est en général trop tard. Et pourtant, tout le monde y sera confronté un jour ou l'autre.

Dans ces conditions, relever le niveau de l'édition logicielle peut sembler une gageure, même pour une administration aussi puissante que l'ANSSI.

Si la CSPN partait d'une bonne intention, la décrépitude des produits les plus anciennement certifiés, ainsi que la soudaine certification de produits hautement symboliques, fait courir un risque à tout le processus de création de confiance. Car le moindre pestiféré emportera tous les autres, surtout s'il existe des alternatives plus connues, plus sûres et pourtant non certifiées.

J'espère que la lecture de ce billet constructif aura été source d'inspiration pour les quelques personnes qui détiennent un réel pouvoir sur ce sujet, et source de divertissement pour les autres.

Sur ce, bonnes vacances et rendez-vous à la rentrée pour de nouvelles aventures !