Jak skontrolować plik wykonywalny, aby upewnić się, że nie jest złośliwy?

Zastanawiałem się, czy istnieje narzędzie lub technika uruchamiania pliku wykonywalnego w izolowanym środowisku, może na maszynie wirtualnej. Podczas działania programu chcę móc kontrolować aplikację, tzn. Zobaczyć wszystko, co robi plik wykonywalny (dostęp do plików i sieci).

W ten sposób chcę być w stanie sprawdzić, czy plik wykonywalny jest złośliwy, tj. Wykonuje operacje, których nie powinien (odczytywać / zapisywać plików, nasłuchiwać / podłączać do portów sieciowych, ...).

Nie miałbym nic przeciwko graficznemu interfejsowi.

jest narzędziem lub może maszyną wirtualną do uruchamiania w nim pliku wykonywalnego

Tak, nazywa się to wirtualizacją aplikacji .

LXC (Linux Containers) jest często używanym narzędziem do konfiguracji. Umożliwia skonfigurowanie całkowicie oddzielnej sieci dla tej aplikacji i „piaskownicę” na maszynie wirtualnej, podobnie jak chroot. Jest to głównie ze względów bezpieczeństwa („więzienie”), a nie do kontroli.

Myślę, że wyjaśnienie kompletnych kontenerów LXC, a także dokładny audyt, jest nieco poza zakresem pytania. Poniżej znajduje się jednak trochę, jak zacząć.

Podczas działania programu chcę widzieć wszystko, co robi plik wykonywalny (dostęp do plików i sieci).

Można to osiągnąć za pomocą stracei zadałem to samo pytanie w systemach Unix i Linux:

• Jak monitorować otwarte pliki procesu w czasie rzeczywistym? (obejmuje również sieć)

Jak tam odpowiedziałem , sprowadza się to w zasadzie do

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

Ważne: gdy zobaczysz, że tak się dzieje, szkody już miały miejsce.

Kontener aplikacji LXC

Z tego artykułu . Sprowadza się do:

1. lxc-macvlan.conf plik konfiguracyjny:

   # 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. Uruchom za pomocą lxc-execute:

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

Pamiętaj, że LXC oferuje zarówno pojemniki systemowe, jak i aplikacyjne. Szukasz pojemników z aplikacją tutaj.

To, czego szukasz, to narzędzie, które pokazuje, jak program wchodzi w interakcje z systemem (a dokładniej z jądrem). Programy współpracują z systemem za pomocą syscall. Przykłady syscalli to:

• open - służy do otwierania pliku;
• readoraz write- służy do odczytu / zapisu z / do deskryptora pliku;
• connect - służy do podłączenia gniazda do peera;
• wiele, wiele innych (patrz man syscalls).

Chodzi o to, że syscalls można śledzić za pomocą ptrace(2). Zasadniczo szukasz narzędzi zbudowanych wokół ptrace. Jednym z takich narzędzi jest strace(1)aplikacja terminalowa, która przyjmuje argument jako argument i wyprowadza:

• wywołania systemowe, które wywołuje program;
• argumenty użyte do wywołania syscalls;
• wynik syscalls.

Wyjście jest w stylu C. Oto przykład:

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

Tam widzisz, że cat testotwiera plik o nazwie test, odczytuje jego zawartość ( hello) i umieszcza go na standardowym wyjściu.

stracemoże generować dużo danych wyjściowych, więc przeczytaj jego stronę man stracepodręcznika man ( ), zwłaszcza dokumentację danych -ewyjściowych, która pozwoli ci zobaczyć tylko te wywołania systemowe, którymi jesteś zainteresowany.

Niestety nie znam graficznych ani łatwych w użyciu alternatyw. Jeśli chcesz ich szukać, ptracepowinno być jednym ze słów kluczowych wyszukiwania.

Jeśli chodzi o izolację, istnieje wiele technologii. Najczęściej używane są chrooty, kontenery Linux (które są obecnie w fazie rozwoju i są niekompletne), wirtualizacja oprogramowania i parawirtualizacja. Jest to jednak temat zbyt obszerny, by go omawiać. Sugeruję otwarcie nowego pytania, jeśli chcesz uzyskać więcej informacji.

Spójrz na AppArmor . Możesz dodać ograniczony profil pliku wykonywalnego i wprowadzić go w tryb „narzekać”, w którym akcje będą dozwolone, ale zalogowane, co moim zdaniem spełnia twoje wymagania.

Ale zauważ, że to naprawdę nie wystarczy. Sprytny złośliwy plik binarny może wykryć, że jest obserwowany i nie może wykonywać złośliwych działań, z wyjątkiem przypadków, gdy nie jest obserwowany.

AppArmor wykracza poza to i pozwala na zawsze ograniczyć aplikację tylko do zatwierdzonych operacji. Aplikacje, które trafią do Centrum oprogramowania Ubuntu, są dostarczane z profilami AppArmor.

Jak już zidentyfikowałeś, lepiej byłoby zapewnić maszynę wirtualną do izolacji, szczególnie jeśli masz powody, by sądzić, że plik wykonywalny jest złośliwy. Ale nawet to nie jest idealne, ponieważ luki w platformie wirtualizacji (zarówno sprzętowej, jak i programowej) mogą zostać wykorzystane przez złośliwy kod w celu wyłamania się. Oto przykład podatności na zagrożenia wirtualizacji w świecie rzeczywistym: http://www.kb.cert.org/vuls/id/649219

Możesz utworzyć przystawkę .

Przystawki są „ograniczone do systemu operacyjnego i innych aplikacji za pośrednictwem mechanizmów bezpieczeństwa, ale mogą wymieniać zawartość i funkcje z innymi przystawkami zgodnie z precyzyjnymi zasadami kontrolowanymi przez użytkownika i domyślnymi systemami operacyjnymi”. (z http://snapcraft.io/docs/snaps/intro )

Zapewniają one dodatkową izolację oprócz AppArmor, na przykład również używając seccomp .

Ponadto przystawka może być samodzielna w celu łatwej dystrybucji i aktualizacji atomowych w systemie.

Dziękuję, odpowiedzi były bardzo pomocne ...

Znalazłem to również: https://downloads.cuckoosandbox.org/docs/

Jest to bardzo interesujące narzędzie do analizy złośliwego oprogramowania, które znajduje się na maszynie wirtualnej