Ce post n’a rien de neuf, mais fera office de remember quand la même chose arrivera de nouveau.

Il y a maintenant quelques mois, je me suis retrouvé en face d’un petit problème avec mon raspi 3 et l’image RaspBian du moment.

Pour configurer la première fois mon raspi, j’utilise un câble console/USB (USB to TTL Serial), qui fait aussi office d’alimentation pour le raspi. Cela permet d’avoir un shell lors de la première connexion.

Le câble utilisé est celui-ci :
https://www.modmypi.com/image/cache/data/rpi-products/gpio/debug/USB-to-TTL-Serial-Cable-Debug-Console-Cable-for-Raspberry-Pi-2-800×609.jpg

Sauf que je me suis retrouvé avec l’impossibilité d’obtenir un shell à travers le câble console. Le symptôme est simple : rien ne s’affiche à l’écran.

Pour résoudre ce problème, j’ai donc dû connecter un écran et un clavier. En effet, la méthode consistant à ajouter la ligne

enable_uart = 1

dans le fichier config.txt n’a pas suffit…

Donc voici les étapes :

1. Ajouter la ligne enable_uart= 1 dans le fichier /boot/config.txt
2. Étendre le système de fichiers grâce à la commande raspi-config
3. Installer la commande rpi-update
4. Lancer la commande rpi-update en admin (donc sudo rpi-update) pour mettre à jour le firmware du raspi
5. Rebooter

Normalement, une fois ces étapes effectuées, la sortie par le câble console devrait fonctionner.

Nous étions restés la dessus : Retour sur armadito antivirus.

Pour faire un résumé extrêmement rapide : l’idée de faire un projet orienté sécurité défensive (open-source) est une bonne idée et peut permettre de faire avancer les choses, l’idée de faire un antivirus a au moins 20 de retard. La question est donc pourquoi ?

A quoi sert un antivirus ?

Certains pourraient dire à rien et je ne serai pas loin d’être d’accord. Dans l’absolu, un antivirus n’est pas utile si vous avez une petite idée de ce que vous faites lorsque vous naviguez/connectez des périphériques, etc. Une bonne gestion des droits doit suffire, mais ce n’est pas le sujet qui nous intéresse. Quoique…

Comment juger de l’efficacité d’un antivirus ?

Plusieurs critères sont généralement mis en jeu (l’objet de cet article n’est pas de discuter de tous ces critères donc cette liste est loin d’être exhaustive) :

• Le taux de reconnaissance des menaces “connues”
• Le taux de détection des menaces “non connues”
• L’utilisation des ressources du système : mémoire, CPU, etc.
• On pourrait rajouter des choses comme : vitesse de scan, protection web, etc.

Les deux derniers points étant plus du confort d’utilisation qu’autre chose, nous ne les détaillerons pas.

Les menaces connues ? C’est le plus simple et ça dépend essentiellement de la capacité de l’entreprise derrière l’antivirus à intégrer les menaces qu’elle détecte et à dispatcher ces mises à jour.

Le nerf de la guerre, ce sont les menaces non connues. Comment savoir si le binaire que l’utilisateur veut exécuter est sain ou malveillant ? et c’est bien là toute la question.

Je ne sais pas s’il est pertinent de faire une liste des techniques utilisées par les entreprises pour déterminer si un programme est malveillant ou non.

On va juste essayer de faire un “meta”-tour de ces techniques pour pouvoir introduire la suite :

• Le pattern matching : on détecte un ensemble d’instructions qui correspondent à un comportement malveillant. Actuellement, c’est (sûrement?) YARA qui est le plus utilisé
• Analyse comportementale : est-ce que le fichier correspond à un comportement déjà observé ?
• Sandbox : exécution du fichier pour savoir ce qu’il fait

Même si on parle ici de menaces non connues, toutes ces techniques se basent sur des “choses” connues. Mais dans ce cas, comment traiter les fichiers jamais vus par les antivirus et qui donc ne rentrent pas dans une de ces catégories ?

Prenons un exemple simple : imaginons un programme exécuté par un utilisateur depuis son Bureau. Ce programme va :

• Lire le contenu du dossier courant
• Se connecter à un site
• Envoyer une image qui se trouve sur ce Bureau sur le site.

Comment savoir si ce comportement est un comportement malveillant ou pas ? La première réponse est de regarder le site sur lequel le programme se connecte. Mais l’identification d’un nom de domaine est un problème de recherche assez complexe et pas aussi trivial qu’il n’y paraît (Domain Generation Algorithm). Sans rentrer plus dans le détail du fichier, il n’est donc pas évident de savoir si ce comportement est malveillant.

La réponse est donc aujourd’hui simple : on ne peut pas (bon ok, on peut estimer dans une certaine mesure grâce à l’utilisation des différentes techniques, mais il est rare de pouvoir être sûr à 100% sans une analyse fine, voir manuelle, du fichier). Et heureusement d’ailleurs, car sinon toutes les recherches sur ce sujet seraient déjà finies et on risquerait de s’ennuyer.

Si on est capable d’estimer cette potentielle menace, qui doit prendre la décision : l’antivirus ou l’utilisateur ? L’un comme l’autre peuvent se tromper et par conséquent compromettre le système par une mauvaise décision.

Mais alors, quelle est la solution ?

La solution est à la fois simple mais complexe (surtout à mettre en place). Il suffit de ne pas autoriser l’exécution de programme qui ne sont pas reconnus “comme de confiance” par l’administrateur. Cela ne peut passer que par un contrôle fin des programmes et des autorisations données aux utilisateurs. En contrôlant les accès sur le système, nous sommes capables de bloquer les actions qui sont considérées comme illégitimes. On fera donc la distinction entre malveillant (qui va potentiellement attaquer le système) et illégitime (qui sont des actions non souhaitées).

Cette philosophie est décrite dans ce que l’on appelle : les mécanismes de contrôle d’accès obligatoire. Ils autorisent uniquement les programmes présents dans la politique de sécurité à réaliser des actions définies sur le système. Tout binaire exécuté par la suite et non présent dans la politique sera (en théorie) bloqué. Il existe des implémentations sur les systèmes Linux : SELinux et GrSecurity (pour les deux plus connus).

Ces mécanismes ont toutefois des inconvénients majeurs :

• Ils sont extrêmement complexes à configurer : il faut autoriser chaque action une à une pour chaque programme du système. Cela peut rapidement être long et fastidieux.
• Ils contraignent à figer le système. Une fois la politique appliquée, tout programme non autorisé sera bloqué. Et à chaque mise à jour/ajout de programme, il est nécessaire de refaire tout ou une partie de la politique pour s’assurer du bon fonctionnement du système.
• Ils n’empêchent pas l’exploitation des programmations, mais en réduisent les conséquences sur le système. Pour empêcher l’exploitation, il est nécessaire d’utiliser des mécanismes externes à l’image de PaX sur Linux.

Grâce à ces mécanismes de protection, nous sommes capables de :

• (pré)calculer, par avance, l’ensemble des opérations autorisées sur le système.
• vérifier des propriétés de sécurité : est-ce qu’un utilisateur peut aller lire des fichiers interdits ?

Toutes ces opérations se basent sur la politique de contrôle d’accès établie qui se doit donc d’être parfaite.

Quelles conclusions tirer de tout cela ?

La première conclusion est que, tant que l’on fera confiance aux antivirus pour protéger les systèmes, nous aurons un temps de retard. Les attaques de types Stuxnet montrent bien que, dès que les attaquants utilisent des techniques un peu différentes, les antivirus ne sont plus capables de protéger quoique ce soit.

Le seconde conclusion est qu’il existe des mécanismes capables de protéger les systèmes “by design” (en admettant qu’il n’y ait pas de problèmes dans ces mécanismes). Cette notion est loin d’être nouvelle puisqu’elle date des années 70, Anderson.

La question qu’il faut donc se poser est pourquoi n’avons-nous pas plus de projet proposant ce genre de solution alors que l’on sait qu’elles proposent un modèle de protection efficace ? Alors que l’on voit (dans les grandes conférences de sécurité, certains diraient de hacker) uniquement des choses orientées vers le pentest ou de la recherche de vulnérabilités et n’apporte rien à l’état de l’art…(ce n’est pas moi qui le dit mais Brad Spengler

Depuis maintenant quelques jours, bon nombre de personnes critiquent/jugent un projet qui est arrivé sur GitHub et qui se nomme Armadito Antivirus. Ce projet est porté par la société Teclib’.

Avant toute polémique, le but de ce billet n’est pas de savoir si ces sources sont issues ou non du projet DAVFI. Pour ceux qui ne comprennent pas, je vous laisserai chercher avec votre moteur de recherche préféré pourquoi j’écris ça. Non, ici le but est de s’interroger sur la pertinence ou pas de ce projet, pertinence scientifique bien sûr.

Qu’est-ce que Armadito Antivirus ? Pour le savoir, allons voir ce qui est dit sur le site (extrait au 9/07/2016) :

Armadito Antivirus is an open-source antivirus that protects your computers and servers from malware and viruses.

Armadito includes classical signature-based malware detection and provides innovative heuristic detection modules for binaries (MS-Windows and GNU/Linux) and for PDF documents.

An intuitive and user-friendly interface gives access to all Armadito’s features: on-demand scanning, real-time protection, quarantine zone, threat detection journal…

Armadito is remotely manageable for enterprises and organisations using a central administration console.

Un projet open-source, qui semble être développé par une entreprise française, en voila deux bons points.

Est-ce une réelle bonne idée ?

Un projet open-source ?

Premier point, et même si beaucoup de personnes pensent que non, je trouve que c’est une bonne idée. Nous avons ici un antivirus (souverain ?) dont tout le monde peut lire/vérifier/compiler les sources et se faire sa propre idée. On ne pourra pas leur reprocher de cacher des backdoors, puisque si backdoors il y a, on pourra les repérer en lisant le code source mis à notre disposition. La plupart des personnes qui râlent sur ce projet pestent aussi sur le fait que les autres projets ne publient pas leur code. Nous avons accès à tout (en tout cas pour l’instant).

Alors oui, quelqu’un qui publie son code source s’expose à ce genre de critiques : ça ne fait pas ci, il faudrait faire comme ça, etc. Mais on attend toujours la publication d’outils utiles de la part de ces mêmes personnes pour faire avancer la (recherche ?) sécurité informatique plutôt que de critiquer de manière gratuite.

Un outil pour faire la sécurité défensive

Second point, enfin un outil défensif. On trouve énormément d’outils offensifs : fuzzing, recherche de vuln, exécution d’exploits, pentest, etc. Mais peu d’outils défensifs qui font réellement de la protection. De plus, ce genre d’outil s’utilise généralement quand il est trop tard. Certes ce n’est qu’un antivirus, et il en existe pléthore, mais il a le mérite d’exister. A voir s’il sera efficace ou s’il mourra de sa belle mort tout comme Tiranium Antivirus. Je ne m’attarderai pas sur la description donnée sur le site qui vante ses qualités de détections et de protection, le mieux étant de tester pour se rendre compte de la réelle efficacité ou non d’un produit, chose que je n’ai pas encore faite.

Est-ce réellement une si bonne idée ?

On pourrait essayer de faire des paragraphes entiers à défendre le projet mais il est nécessaire de se poser la question du réel intérêt scientifique de ce (genre de) projet. Dans l’idée, les deux points positifs que je retiendrai sont le côté open-source et un outil de sécurité défensive. Mais cela ne rattrape pas ce qui va suivre.

Faire un antivirus ?

Nous sommes en 2016, l’informatique existe depuis maintenant plusieurs dizaines d’années, Internet a explosé depuis les années (19)95 et, avec, les menaces informatiques. On est passé du virus, aux spywares, aux rootkits, aux ransomware, etc. Les malware deviennent de plus en plus évolués et complexes à étudier et à supprimer d’un système. Dans ce cyber-digital-monde-de-pirate (poke Gof), la réalisation d’un antivirus montre juste le retard de l’industrie dans la protection des systèmes. On verra pourquoi dans un prochain article.

On peut noter, de plus, que le marché propose déjà un très (trop ?) grand nombre de logiciels anti-truc : antivirus, antimalware, antispyware, etc. Je ne vais pas m’amuser à tous les citer, je risquerai d’en oublier une bonne partie. Mais la multitude des outils n’a pas fait baisser la menace, ni rendu le surf plus sûr, ni éradiqué la faim dans le monde.

La plupart de ces outils sont (que je considère comme) des outils de détections. Ils ne sont pas capables d’anticiper les menaces et dès que quelque chose sort un peu de l’ordinaire (une exploitation d’une faille inconnu, un cheminement non conventionnel pour un malware), tous les outils sont dépassés. On pourrait aussi discuter des méthodes innovantes de protection pro-actives, mais il faudrait déjà comprendre ce que ça veut dire. Aucun outil n’est réellement capable de faire de la protection du système de manière efficace, c’est-à-dire bloquer un binaire avant son exécution. Un antivirus s’utilise en amont, pour protéger le système, pas pour supprimer les choses qu’il trouve, encore faut-il qu’il soit capable de le faire.

Les entreprises proposant des antivirus ou des antimalware ne sont que dans la réaction et non dans l’anticipation/la création. C’est pour cela qu’ils seront toujours derrière en matière de protection. Il n’y a que très peu de recherches (que ce soit académique ou industrielle) proposant des méthodes de protections efficaces, qui ne reposent pas sur des “choses” que l’on a déjà vu.

Donc, même si ce projet a le mérite d’exister et propose des choses, il ne va pas faire avancer la recherche ni la sécurité informatique. Ce n’est qu’un outil de plus parmi la longue liste d’outils antimachin qui ne sera pas efficace pour protéger de manière efficace un système et ces utilisateurs.

Une petite note amusante : le CERT-FR a déjà publié une note concernant une vulnérabilité dans cet antivirus CERT-FR

Nous verrons dans un prochain article les remèdes et les solutions à cela.

Un remerciement à Gof pour sa relecture.