Comment puis-je auditer un exécutable pour m’assurer qu’il n’est pas malveillant?

Je me demandais s’il existait un outil ou une technique pour exécuter un fichier exécutable dans un environnement isolé, peut-être une machine virtuelle. Pendant que le programme est en cours d’exécution, je souhaite pouvoir auditer l’application, c’est-à-dire tout voir ce que l’exécutable est en train de faire (access aux fichiers et au réseau).

Ce faisant, je veux pouvoir vérifier si l’exécutable est malveillant, c’est-à-dire effectuer des opérations qu’il ne devrait pas (lire / écrire dans des fichiers, écouter / se connecter à des ports réseau, …).

Cela ne me dérangerait pas d’avoir une interface graphique.

est un outil ou peut-être une machine virtuelle pour exécuter un exécutable à l’intérieur

Oui, cela s’appelle la virtualisation d’applications .

LXC (Conteneurs Linux) est un outil couramment utilisé pour configurer cela. Il vous permet de configurer un réseau complètement séparé pour cette application et de le “mettre en sandbox” dans une sorte de machine virtuelle, un peu comme un chroot. Ceci est principalement pour des raisons de sécurité (une “prison”), pas vraiment pour l’audit.

Je pense que c’est un peu en dehors du cadre de la question d’expliquer les conteneurs LXC complets et de savoir comment l’auditer exactement. Vous trouverez ci-dessous un aperçu de la procédure à suivre.

Pendant que le programme est en cours d’exécution, je veux pouvoir voir tout ce que l’exécutable est en train de faire (access aux fichiers et au réseau).

Ceci peut être accompli en utilisant strace et j’ai posé la même question sous Unix et Linux:

  • Comment surveiller les fichiers ouverts d’un processus en temps réel? (couvre également le réseau)

Comme répondu là-bas, il s’agit essentiellement de

 strace -t -e trace=open,close,read,getdents,write,connect,accept command-here 

Important: une fois que cela se produit, les dégâts sont déjà causés.


Conteneur d’application LXC

De cet article . Cela revient à:

  1. lxc-macvlan.conf configuration lxc-macvlan.conf :

     # example as found on /usr/share/doc/lxc/examples/lxc-macvlan.conf # Container with network virtualized using the macvlan device driver lxc.utsname = alpha lxc.network.type = macvlan lxc.network.flags = up lxc.network.link = eth0 # or eth2 or any of your NICs lxc.network.hwaddr = 4a:49:43:49:79:bd lxc.network.ipv4 = 0.0.0.0/24 
  2. Lancez-le en utilisant lxc-execute :

     sudo lxc-execute -n bash-test2 -f lxc-macvlan.conf /bin/bash 

Notez que LXC propose des conteneurs de type système et application. Vous recherchez des conteneurs d’application ici.

Ce que vous recherchez est un outil qui montre comment un programme interagit avec le système (plus précisément avec le kernel). Les programmes interagissent avec le système à l’aide d’appels système. Voici des exemples d’appels système:

  • open – utilisé pour ouvrir un fichier;
  • read and write – utilisé pour lire / écrire depuis / dans un descripteur de fichier;
  • connect – utilisé pour connecter une prise à un homologue;
  • beaucoup, beaucoup d’autres (voir les man syscalls ).

Le problème est que: les appels système peuvent être suivis à l’aide de ptrace(2) . Donc, fondamentalement, vous recherchez des outils construits autour de ptrace . strace(1) est l’un de ces outils. Il s’agit d’une application qui prend une commande en tant qu’argument et qui génère:

  • le système appelle le programme appelle;
  • les arguments utilisés pour faire les appels système;
  • le résultat des appels système.

La sortie est en mode C. Voici un exemple:

 $ strace cat test execve("/bin/cat", ["cat", "test"], [/* 55 vars */]) = 0 /* ... */ open("test", O_RDONLY) = 3 /* ... */ read(3, "hello\n", 32768) = 6 write(1, "hello\n", 6) = 6 read(3, "", 32768) = 0 /* ... */ 

Vous voyez que cat test ouvre un fichier nommé test , lit son contenu ( hello ) et le place sur la sortie standard.

strace peut produire beaucoup de résultats, assurez-vous donc de lire sa page de manuel ( man strace ), en particulier la documentation de la sortie -e qui vous permettra de voir uniquement les appels système qui vous intéressent.

Malheureusement, je n’ai pas connaissance d’alternatives graphiques ou faciles à utiliser. Si vous souhaitez les rechercher, ptrace doit être l’un de vos mots clés de recherche.


À propos de l’isolement, il existe de nombreuses technologies. Les chroots, les conteneurs Linux (en cours de développement et incomplets), la virtualisation et la paravirtualisation de logiciels sont les plus utilisés. Cependant, c’est un sujet beaucoup trop vaste pour être discuté. Je suggérerais d’ouvrir une nouvelle question si vous souhaitez avoir plus de détails.

Jetez un coup d’œil à AppArmor . Vous pouvez append un profil limité à un exécutable et le mettre en mode “plainte”, où les actions seront autorisées mais journalisées, ce qui, à mon avis, répond à vos besoins.

Mais notez que cela ne suffit pas vraiment. Un binary malveillant malin peut détecter qu’il est sous observation et ne pas effectuer d’actions malveillantes sauf s’il n’est pas observé.

AppArmor va plus loin que cela et permet à une application d’être toujours restreinte aux seules opérations approuvées. Les applications qui se retrouvent dans le Centre logiciel Ubuntu sont livrées avec des profils AppArmor.

Comme vous l’avez indiqué, une machine virtuelle serait préférable pour fournir une isolation, en particulier si vous avez des raisons de croire qu’un fichier exécutable est malveillant. Mais même ceci n’est pas parfait, car les vulnérabilités de la plate-forme de virtualisation (à la fois matérielle et logicielle) peuvent être exploitées par un code malveillant afin de se faire connaître. Voici un exemple de vulnérabilité de la virtualisation dans le monde réel: http://www.kb.cert.org/vuls/id/649219

Vous pouvez créer un cliché .

Les clichés sont “limités au système d’exploitation et à d’autres applications par des mécanismes de sécurité, mais ils peuvent échanger du contenu et des fonctions avec d’autres clichés conformément à des règles précises contrôlées par l’utilisateur et par défaut du système d’exploitation”. (de http://snapcraft.io/docs/snaps/intro )

Celles-ci fournissent une isolation supplémentaire en plus d’AppArmor, par exemple en utilisant également seccomp .

En outre, un composant logiciel enfichable peut être autonome pour une dissortingbution facile et des mises à jour atomiques sur votre système.

Merci, les réponses ont été très utiles …

J’ai aussi trouvé ceci: https://downloads.cuckoosandbox.org/docs/

Ce qui est un outil très intéressant pour parsingr les logiciels malveillants dans une machine virtuelle