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