Weryfikacja plików binarnych poleceń przed wykonaniem

13

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...
Miloš Đakonović
źródło
2
Jeśli jesteś tak paranoikiem, użyj własnych plików binarnych!
Ipor Sircer,
8
Oprócz whichniepoprawnego powiedzenia, co tarzrobi, na co odpowiedziała xhienne, lsmoże zostać zhakowany w celu zwrócenia fałszywych informacji o plikach, jeśli takie istnieją. grepMoże również zostać zhakowany w celu zwrócenia fałszywych informacji; można tego uniknąć, używając zamiast tego dopasowywania powłok, ale następnie można włamać się do powłoki. A powłoka może zostać zhakowana, aby dać błędne wyniki type- lub zastąpiona całkowicie, ponieważ wymienność powłoki była ważną innowacją Uniksa w porównaniu z 50-letnimi systemami operacyjnymi. Zobacz adres Turinga Kena Thompsona z 1984 r. Żółwie są na dole.
dave_thompson_085
2
Nie mogę odpowiedzieć na to pytanie w przypadku Linuksa - tylko AIX - który ma komponent o nazwie Trusted Execution ( TE) - który ma bazę danych z podpisami (tj. Bardziej rozbudowaną niż suma kontrolna MD5. Gdy TE jest aktywny ORAZ plik znajduje się w bazie danych, możesz wybrać czy program działa - czy tylko ostrzega, że ​​nie jest on zgodny z bazą danych. Ponadto istnieją dwa inne ustawienia: (zaufana ścieżka PATH) TEPi TLP(zaufana ścieżka LIBrary). Można wykonywać tylko programy w TEP i biblioteki mogą być ładowane tylko katalog jest zawarty w TLP W Linux I jest coś, co nazywa się „AppArmor”, które może ci pomóc
Michael Felt
1
Możesz mieć tego rodzaju bezpieczeństwo, ale nie ze skryptu - do czasu wykonania skryptu w niekontrolowanym środowisku jest już za późno. Z tego co wiesz, wszystko, co możesz zobaczyć, to chroot ustawiony przez atakującego.
Charles Duffy,
2
... jeśli chcesz mieć zaufany system do samego końca, musisz przejść do ChromeOS: podpisuj oprogramowanie układowe kluczem wbudowanym w sprzęt; twój bootloader / jądro zweryfikowane przez firmware; partycja głównego systemu operacyjnego jest tylko do odczytu przy użyciu sygnatur blokowych do weryfikacji; itp. Istnieją również podejścia podobne do tego, co omawia @MichaelFelt - patrz architektura pomiaru integralności - ale wpływ na wydajność jest wyższy, a poziom integralności zmniejszony (ponieważ sprawdzanie podpisów binarnych nie pomaga w atakach za pomocą plików wykonywalnych zawartość).
Charles Duffy,

Odpowiedzi:

24

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.

Dmitrij Grigoriew
źródło
Który zepsuje się, gdy różne dystrybucje zdecydują się wstawić binaria /binzamiast /usr/bin.
Damian Yerrick
IMA jest jednym z dwóch podejść gotowych do produkcji - drugim jest podejście dm-verity zastosowane przez ChromeOS w celu sprawdzania poprawności rootfów na poziomie bloku.
Charles Duffy,
@DamianYerrick Fair uwaga. Ustaw $PATHwięc obie ścieżki, jeśli potrzebna jest obsługa wielu dystrybucji.
Dmitrij Grigoryev,
AIX TE (z RBAC lub bez) byłby trzecim wbudowanym jądrem „gotowym do produkcji”, które to osiągnie - być może więcej. TE, raz włączone, aby być więcej niż pasywne - uniemożliwi otwieranie plików i / lub wykonywanie programów. Ponadto użycie aplikacji i biblioteki może być ustawione wyłącznie na TEP (zaufana ścieżka wykonania) lub TLP (zaufana ścieżka biblioteki). Zobacz ibm.com/support/knowledgecenter/en/ssw_aix_61/ ... podstawowe informacje
Michael Felt
6

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.

Kusalananda
źródło
4

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.

Sergiy Kolodyazhnyy
źródło
8
Ale jak weryfikujesz /usr/bin/md5sum?
Dmitrij Grigoryev
Jeśli atakujący jest w stanie zastąpić /bin/tarlub /usr/bin/tar, jest bardzo prawdopodobne, że może również po prostu zastąpić md5sumlub /var/lib/dpkg/info/tar.md5sums. Lub $SHELL.
Jonas Schäfer
1
Myślę, że wspomniałem już w poprzednim akapicie, że aby coś takiego mogło się zdarzyć, atakujący musiałby uzyskać dostęp do systemu root, i w tym momencie wszystko jest możliwe. W przypadkach, gdy atakujący nie ma dostępu do roota, ale może zmienić zmienną PATH dla użytkownika lub utworzyć alias, w którym tarwskazuje inny plik binarny, będzie to działać. Kiedy system zostanie przejęty na poziomie root, masz jedną opcję, a następnie - nuke go z orbity
Sergiy Kolodyazhnyy
3

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.

Xhienne
źródło
type -aobejmuje wszystkie formularze (np. zarówno alias, jak i program zewnętrzny)
dave_thompson_085
Dziękuję @dave, to naprawdę interesujące, zaktualizowałem swoją odpowiedź
xhienne
1
typepowie ci inasfar, jak wie bash, ale jeśli jesteśmy pod kontrolą złośliwego atakującego, nie ma powodu, aby wierzyć, że to, co myśli, że bash wie, odzwierciedla rzeczywistą prawdę. Z tego co wiesz, istnieje LD_PRELOADmoduł przechwytujący każde pojedyncze wywołanie biblioteki C.
Charles Duffy,
1
@CharlesDuffy Masz oczywiście rację. Nie chciałem odpowiadać w kwestii bezpieczeństwa. Po prostu proponuję odpowiedź na pytanie u góry: „Czy są jakieś metody sprawdzenia, co faktycznie wykonujesz ze skryptu bash” i zaproponowałem alternatywę dla which.
xhienne
Nigdy wcześniej nie widziałem enable. Skorzystałem z rad zawartych w tych odpowiedziach, aby type enablesprawdzić, czy jest to wbudowana powłoka, a następnie help enablezobaczyć, co robi.
Joe
3

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.

Zumo de Vidrio
źródło
3
Nie jest to w żaden sposób użyteczne dla skryptu do przeprowadzania automatycznych testów i nie ma szczególnego powodu, aby sądzić, że stracesam nie został obalony.
Charles Duffy,
0

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.

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj

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.


źródło