Is there a reliable way to check whether a binary executable potentially tries to access the internet (e.g. to phone home) prior to running it?

I guess that many binaries use ioctl / socket / connect from glibc to access the internet. Meaning, making an objdump and check for these functions may reveal some information in this regard. But is this sufficient? Are there ways to access the internet by not using these glibc functions? How can I detect those?

  • I'd run it in a network namespace with a default route to a dummy network interface. Run wireshark on that interface, and it's easy to see if it tries to access the internet, without allowing it to actually do that. – dirkt Mar 23 '17 at 22:08

Programs can access the Internet in a variety of ways, e.g. using libraries such as libcurl. You can detect those using ldd and check which symbols are being used in the binary using objdump again, and read the documentation to figure out what the various functions do.

But if you’re trying to check a hostile binary, that won’t be enough either: the binary could call the kernel using system calls directly to open sockets etc., or it could load libraries using dlopen(3) to make it harder to detect their use.

If you want to run the binary without network access at all, you can unshare it from the network namespace:

unshare -n binary

You need to do this as root though, so you might want to su back to some other user (perhaps not your own either, if it’s a hostile binary):

unshare -n su sacrificialuser -c binary

As pointed out by Gilles, that doesn’t protect you from other side-effects the execution of the binary might have, including setting up a cronjob which accesses the network on the executable’s behalf for whatever purpose.

Alternatively, you could set up iptables or nftables rules to drop (and log) all network traffic from the binary; or better yet, set up a VM and run the binary inside that (and then stop the VM).

  • Thanks a lot for your answer! I'm currently trying to collect some measures that could be taken to prevent the detection of accessing the network. In this regard, I guess the use of dlopen could again be detected using objdump, right?. Could you elaborate a bit on the other method you mentioned that involves using the kernel to open sockets? How would that work? – bonanza Mar 22 '17 at 8:47
  • 2
    You could detect the use of dlopen using objdump, yes, but you’d still need to figure out what was being loaded and which functions were being called. See this SO answer for an example of calling a kernel system call without going through the C library — that allows you to call socket(2) (or any other syscall) without anything showing up in objdump’s output. – Stephen Kitt Mar 22 '17 at 15:16
  • 1
    Unsharing the network namespace isn't enough to ensure that an untrusted executable won't access the network. The program could store code elsewhere and cause it to be executed, e.g. write to a browser profile directory, register a crontab, etc. A properly configured virtual machine is the easy way. – Gilles 'SO- stop being evil' Mar 22 '17 at 21:35
  • @Gilles Actually, virtual machines are worse. Locks are for honest people... – Satō Katsura Mar 23 '17 at 8:01
  • @SatoKatsura VM can be buggy like any other software, but no, they aren't “worse”. The third little pig's house wouldn't resist a nuclear blast, but it's adequate to the threat it means to defend against. – Gilles 'SO- stop being evil' Mar 23 '17 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.