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

Je me demandais s'il existe un outil ou une technique pour exécuter un exécutable dans un environnement isolé, peut-être dans une machine virtuelle. Pendant l'exécution du programme, je souhaite pouvoir auditer l'application, c'est-à-dire voir tout ce que fait l'exécutable (accès 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 aux ports réseau, ...).

Cela ne me dérangerait pas quelque chose avec 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 des applications .

LXC (Linux Containers) 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. C'est principalement à des fins de sécurité (une "prison"), pas vraiment pour l'audit.

Je pense que c'est un peu en dehors de la portée de la question d'expliquer les conteneurs LXC complets ainsi que la façon de les auditer exactement. Ci-dessous, cependant, un peu sur la façon de commencer.

Pendant que le programme est en cours d'exécution, je veux pouvoir voir tout ce que fait l'exécutable (accès aux fichiers et au réseau).

Cela peut être accompli en utilisant straceet j'ai posé la même question sur Unix et Linux:

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

Comme on y a répondu , cela revient essentiellement à

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

Important: une fois que vous voyez cela se produire, les dommages ont déjà eu lieu.

Conteneur d'application LXC

De cet article . Cela revient à:

1. lxc-macvlan.conf fichier de configuration:

   # 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. Démarrez-le en utilisant lxc-execute:

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

Notez que LXC propose à la fois le système et le type d'application des conteneurs. 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 noyau). 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;
• readet write- utilisé pour lire / écrire depuis / vers un descripteur de fichier;
• connect - utilisé pour connecter une prise à un pair;
• beaucoup, beaucoup d'autres (voir man syscalls).

Le point est le suivant: les appels système peuvent être tracés à l'aide de ptrace(2). Donc, fondamentalement, vous recherchez des outils construits autour ptrace. L'un de ces outils est strace(1), qui est une application terminale qui prend une commande comme argument et génère:

• le système appelle le programme appelle;
• les arguments utilisés pour effectuer 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
/* ... */

Là, vous voyez qui cat testouvre un fichier nommé test, lit son contenu ( hello) et le place sur la sortie standard.

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

Malheureusement, je ne connais pas d'alternatives graphiques ou faciles à utiliser. Si vous souhaitez les rechercher, ptracedevrait ê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 des logiciels sont les plus utilisés. Cependant, c'est un sujet beaucoup trop vaste pour être discuté. Je suggère d'ouvrir une nouvelle question si vous souhaitez avoir plus de détails.

Jetez un œil à AppArmor . Vous pouvez ajouter un profil limité pour un exécutable et le mettre en mode "plainte", où les actions seront autorisées mais enregistrées, ce qui, je pense, répond à vos exigences.

Mais notez que ce n'est pas vraiment suffisant. Un binaire malicieux intelligent peut être en mesure de détecter qu'il est sous observation et ne pas effectuer d'actions malveillantes, sauf lorsqu'il n'est pas observé.

AppArmor va plus loin et permet à une application d'être limitée pour toujours aux seules opérations approuvées. Les applications qui se retrouvent dans Ubuntu Software Center sont livrées avec des profils AppArmor.

Comme vous l'avez identifié, une machine virtuelle serait préférable de fournir l'isolement, en particulier si vous avez des raisons de croire qu'un exécutable est malveillant en premier lieu. Mais même cela 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 du code malveillant afin de se déclencher. Voici un exemple d'une vulnérabilité de virtualisation dans le monde réel: http://www.kb.cert.org/vuls/id/649219

Vous pouvez créer un composant logiciel enfichable .

Les snaps sont "confinés à partir du système d'exploitation et d'autres applications via des mécanismes de sécurité, mais peuvent échanger du contenu et des fonctions avec d'autres snaps selon des politiques précises contrôlées par l'utilisateur et les paramètres par défaut du système d'exploitation". (depuis http://snapcraft.io/docs/snaps/intro )

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

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

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

J'ai également trouvé ceci: https://downloads.cuckoosandbox.org/docs/

Ce qui est un outil très intéressant pour analyser les logiciels malveillants lorsqu'ils se trouvent dans une machine virtuelle