Weryfikacja plików binarnych poleceń przed wykonaniem

Czy są jakieś metody sprawdzenia, co faktycznie wykonujesz ze skryptu bash?

Powiedzieć skrypt bash dzwoni kilka poleceń (na przykład: tar, mail, scp, mysqldump) i są chętni, aby upewnić się, że tarjest rzeczywista, prawdziwa tar, która jest do ustalenia przez rootużytkownika będącego właścicielem pliku i katalog nadrzędny, a tylko jeden z uprawnieniami do zapisu a nie jakiś /tmp/surprise/tarz www-datalub apache2będąc właścicielem.

Jasne, że wiem o PATHi środowisku, jestem ciekawy, czy można to dodatkowo sprawdzić w działającym skrypcie bash, a jeśli tak, to w jaki sposób?

Przykład: (pseudo-kod)

tarfile=$(which tar)
isroot=$(ls -l "$tarfile") | grep "root root"
#and so on...

Zamiast sprawdzania poprawności plików binarnych, które zamierzasz wykonać, możesz uruchomić odpowiednie pliki binarne od samego początku. Np. Jeśli chcesz się upewnić, że nie zamierzasz uruchomić /tmp/surprise/tar, po prostu uruchom /usr/bin/tarskrypt. Alternatywnie, ustaw swoją $PATHrozsądną wartość przed uruchomieniem czegokolwiek.

Jeśli nie ufasz plikom /usr/bin/i innym katalogom systemowym, nie ma możliwości odzyskania zaufania. W twoim przykładzie sprawdzasz właściciela ls, ale skąd wiesz, że możesz mu zaufać ls? Ten sam argument dotyczy innych rozwiązań, takich jak md5sumi strace.

Tam, gdzie wymagane jest wysokie zaufanie do integralności systemu, stosowane są specjalistyczne rozwiązania, takie jak IMA . Ale nie jest to coś, czego można użyć ze skryptu: cały system musi być skonfigurowany w specjalny sposób, z koncepcją niezmiennych plików.

Jeśli intruz uzyskał dostęp do twojego systemu i jest w stanie go zmodyfikować $PATH(co nie powinno obejmować /tmpw żadnych okolicznościach), jest już za późno, aby zacząć martwić się o własność plików wykonywalnych.

Zamiast tego powinieneś przeczytać o tym, jak radzić sobie z włamaniem .

Lepiej skoncentrować się na całkowitym unikaniu włamań.

Jeśli masz system, w którym tego rodzaju sprawy mają znaczenie, dobrym pomysłem może być odizolowanie jego części, które muszą być publiczne, od części, które muszą być prywatne, a także przeprowadzenie audytu sposobów komunikacji między nimi.

Jest to możliwe do pewnego stopnia poprzez weryfikację md5sumpliku. Tak więc w systemach korzystających z aptzarządzania pakietami - w moim szczególnym przypadku Ubuntu 16.04 - znajduje się plik /var/lib/dpkg/info/tar.md5sums, w którym przechowywane są sumy md5 wszystkich plików pochodzących z tarinstalacji. Możesz więc napisać prostą instrukcję if, która sprawdza, czy dane wyjściowe md5sum /bin/tarpasują do zawartości tego pliku.

To oczywiście zakłada, że ​​sam plik nie został zmieniony. Może się to oczywiście zdarzyć tylko wtedy, gdy atakujący uzyska dostęp do roota / sudo, w którym to momencie wszystkie zakłady są wyłączone.

Tak, istnieje metoda: wbudowana type. W przeciwieństwie do whichpolecenia, które wyszukuje tylko w ŚCIEŻCE, typepowie ci, czy nazwa polecenia jest faktycznie słowem kluczowym zastrzeżonym, wbudowanym, aliasem, funkcją lub plikiem dyskowym.

$ type -t foobar || echo "Not found"
Not found

$ type -t echo
builtin

$ enable -n echo; type -t echo; type -p echo
file
/usr/bin/echo

$ echo() { printf "(echoing) %s\n" "$*"; }; type -t echo
function

$ alias echo="/bin/echo 'I say: ' "; type -t echo
alias

Ponadto type -aotrzymasz wszystkich kandydatów do twojego dowództwa (od pierwszego do ostatniego wyboru):

$ type -a echo
echo is aliased to `/bin/echo 'I say: ' '
echo is a function
echo () 
{ 
    printf "(echoing) %s\n" "$*"
}
echo is a shell builtin
echo is /usr/local/bin/echo
echo is /bin/echo

Wreszcie, jeśli martwisz się tylko plikami binarnymi na dysku, możesz użyć, type -Paaby uzyskać wszystkie pliki binarne w ŚCIEŻCE (w tej samej kolejności, jak powyżej):

$ type -Pa tar
/home/me/bin/tar                <= oh oh, is this normal?
/bin/tar

To powiedziawszy, typesam nie powie dokładnie, jakie polecenie zostanie w końcu wywołane. Na przykład, jeśli tarjest aliasem, który wywołuje binarnym (np alias tar="/tmp/tar") wtedy typepowie to jest alias.

Możesz sprawdzić, które polecenia są dokładnie wykonywane przez skrypt, używając strace. Na przykład:

strace -f -e execve ./script.sh

Za pomocą następującego skryptu:

#!/bin/bash
touch testfile.txt
echo "Hello" >> testfile.txt
cat testfile.txt
rm testfile.txt

stracepoda dokładną ścieżkę do poleceń wykonanych przy użyciu z -e execveparametrem:

execve("./script.sh", ["./script.sh"], [/* 69 vars */]) = 0 
Process 8524 attached
[pid  8524] execve("/usr/bin/touch", ["touch", "testfile.txt"], [/* 68 vars */]) = 0 
[pid  8524] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8524, si_status=0, si_utime=0, si_stime=0} --- 
Process 8525 attached [pid > 8525] execve("/bin/cat", ["cat", "testfile.txt"], [/* 68 vars */]) = 0
Hello [pid  8525] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8525, si_status=0, si_utime=0, si_stime=0} --- 
Process 8526 attached [pid > 8526] execve("/bin/rm", ["rm", "testfile.txt"], [/* 68 vars */]) = 0
[pid  8526] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8526, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

Parametry (od strace man):

-f: Śledź procesy potomne, ponieważ są one tworzone przez aktualnie śledzone procesy w wyniku wywołań systemowych fork (2), vfork (2) i clone (2). Pamiętaj, że -p PID -fdołączą wszystkie wątki PID procesu, jeśli jest on wielowątkowy, a nie tylko wątek z id_wątku = PID.

-e trace=file: Śledź wszystkie wywołania systemowe, które przyjmują nazwę pliku jako argument. Można to potraktować jako skrót, dla -e trace=open,stat,chmod,unlink,...którego przydatne jest sprawdzenie, do jakich plików odnosi się proces. Ponadto użycie skrótu zapewni, że nie zapomnisz przypadkowo dołączyć do listy połączenia takiego jak lstat.

Linux OS jest oparty na plikach i wiele poleceń wykonanych w systemie Linux prawdopodobnie rozwiąże niektóre zmiany w plikach znajdujących się na twoim komputerze. Z tego powodu może to najlepsze rozwiązanie twojego problemu. Możesz przetestować swoje komendy pod kątem wszelkich zmian w systemie plików przed jego wykonaniem.

Istnieje polecenie „strace”, które rozkłada polecenie na części…

Jeśli naprawdę chcesz zagłębić się w grę, sprawdź dekompilatory skryptów, które mają zostać wykonane. Innymi słowy, musisz sprawdzić interpretację asemblera tego polecenia. Na bash tam objdump -d. Skrypty bin systemu Linux są tworzone głównie w Cjęzyku programowania, więc używaj dobrego Cdekompilatora.