How do I audit an executable to make sure it is not malicious?

Solution 1:

is a tool or maybe a virtual machine to run an executable inside it

Yes, this is called Application virtualization.

LXC (Linux Containers) is a commonly used tool to set this up. It allows you to set up completely separated network for this application and it "sandboxes" it into a sort of virtual machine, much like a chroot. This is mainly for security purposes (a "jail"), not really for auditing.

I think it's a little bit outside the scope of the question to explain the complete LXC containers as well as how to audit it exactly. Below is a little bit on how to get started, though.

While the program is running, I want to be able to see everything that the executable is doing (file and network access).

This can be accomplished using strace and I've asked the same question on Unix&Linux:

• How do I monitor opened files of a process in realtime? (also covers network)

As answered there, it comes down to basically

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

Important: once you see it happening, the damage already took place.

LXC application container

From this article. It comes down to:

1. lxc-macvlan.conf configuration file:

   # 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. Start it using lxc-execute:

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

Note that LXC offers both system and application type of containers. You're looking for application containers here.

Solution 2:

What you are looking for is a tool that shows how a program interacts with the system (more specifically, with the kernel). Programs interact with the system using syscalls. Examples of syscalls are:

• open -- used to open a file;
• read and write -- used to read/write from/to a file descriptor;
• connect -- used to connect a socket to a peer;
• many, many others (see man syscalls).

The point is: syscalls can be traced using ptrace(2). So, basically, you are looking for tools built around ptrace. One of such tools is strace(1), which is a terminal application that takes a command as an argument and outputs:

• the system calls the program is calling;
• the arguments used to make the syscalls;
• the result of the syscalls.

The output is in a C-fashion. Here is an example:

$ 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
/* ... */

There you see that cat test is opening a file named test, reading its content (hello) and placing it on the standard output.

strace can produce much output, so be sure to read its man page (man strace), especially the documentation of the -e output that will let you see just the syscalls you are interested in.

Unfortunately, I'm not aware of graphical or easy-to-use alternatives. If you want to look for them, ptrace should be one of your search keywords.

About the isolation, there are many technologies out there. Chroots, Linux containers (which are currently under development and incomplete), software virtualization and paravirtualization are the most used. However this is a topic way too large to discuss. I'd suggest opening a new question if you wish to have more details.

Solution 3:

Take a look at AppArmor. You can add a limited profile for an executable and put it into "complain" mode, where actions will be permitted but logged, which I think fulfils your requirements.

But note that this isn't really enough. A clever malicious binary may be able to detect that it is under observation and not perform malicious actions except when it is not being observed.

AppArmor goes further than this and allows an application to forever be restrained to only approved operations. Apps that end up in the Ubuntu Software Centre ship with AppArmor profiles.

Solution 4:

As you've identified, a virtual machine would be better to provide isolation, particularly if you have reason to believe that an executable is malicious in the first place. But even this isn't perfect, since vulnerabilities in the virtualization platform (both hardware and software) can be exploited by malicious code in order to break out. Here's an example of a real world virtualization vulnerabilty: http://www.kb.cert.org/vuls/id/649219