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

10

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.

Ouss
źródło
2
@EliahKagan: Jeśli dobrze rozumiem pytanie, OP prosi o „narzędzie, w którym widzę wszystko, co robi plik wykonywalny” - wyobraź sobie, że możesz uruchomić, sandbox somebinarya wyimaginowany sandboxprogram zarejestruje wszystkie pliki somebinaryodczytane lub zapisane, wszystkie Adresy IP / porty podłączone, przesyłane dane itp. Byłoby to przydatne, chciałbym również wiedzieć, czy coś takiego istnieje (i w rzeczywistości bez takiego narzędzia obserwowanie programu działającego na maszynie wirtualnej byłoby bezcelowe, ponieważ ty i tak nie mogę powiedzieć, co tam robi). Dobre pytanie.
Siergiej
2
Odpowiednie pytanie na temat UL.SE, które wcześniej zadałem: Jak monitorować otwarte pliki procesu w czasie rzeczywistym? (nie tylko pliki, ale także sieć) Pamiętaj, że gdy zobaczysz, że tak się dzieje, szkody już miały miejsce.
gertvdijk
2
Zadałem pytanie dotyczące meta dotyczące zamknięcia tego pytania: meta.askubuntu.com/questions/5871/… - Nie sądzę, że powinno być zamknięte.
Siergiej

Odpowiedzi:

10

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 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.

gertvdijk
źródło
1
LXC nie jest jeszcze gotowy i jest obecnie niebezpieczny. Na przykład /sysnie jest wirtualizowany, a zmiany wprowadzone /sysw kontenerze są wprowadzane /sysw hoście. Szybkie wyszukiwanie w sieci zawiera kilka artykułów dokumentujących „ucieczkę” z kontenera. LXC będzie dobrym rozwiązaniem problemu, ale obecnie nie jest i nie powinno być używane jako narzędzie bezpieczeństwa.
Andrea Corbellini
1
Nawiasem mówiąc, przykładowa konfiguracja nie korzysta z lxc.mountopcji. Oznacza to, że system plików całego użytkownika jest dostępny przez uruchomienie.
Andrea Corbellini
10

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.

Andrea Corbellini
źródło
5

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.

Robie Basak
źródło
5

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

Robie Basak
źródło
1

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.

Robie Basak
źródło
0

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

Ouss
źródło