3

lipca odnośnik do eksploita umożliwiającego uzyskanie uprawnień administratora w systemie Linux rozprzestrzenił się w różnych społecznościach na Telegramie i Twitterze. Napisała nawet o tym prasa branżowa. Rzekomy kod dowodu koncepcji (Proof of Concept – PoC) błędu opisanego w CVE-2023-35829 niestety okazał się zupełnie czymś innym niż pierwotnie zakładano. Przed usunięciem fałszywego profilu użytkownika ChriSanders22 z serwisu GitHub kod PoC został oznaczony gwiazdką przez ponad 100 użytkowników, a 25’ciu rozgałęziło go na swoje konta. Kilka osób, które uruchomiło kod bez jego weryfikacji zauważyło dziwne zmiany w plikach konfiguracyjnych powłoki bash – $HOME/.bashrc. Jak to? Co ma wspólnego exploit z dopisywaniem czegoś o plików powłoki? Otóż jeśli przyjrzeć się bliżej procesowi kompilacji to można zauważyć, że plik Makefile odwoływał się do binarnego pliku alocal.m4:
[ czytaj całość… ]

Z

nalezienie tylnego wejścia (ang. backdoor) uruchomionego w systemie Linux nie zawsze może być trywialne. Tylne furtki służą do interakcji atakującego z hostem w czasie rzeczywistym i są konsekwencją / kolejnym krokiem włamania do systemu. Sposród różnych backdoorów, które można wykorzystać w środowisku *nix jest bardzo dobrze znany bindshell, czyli powłoka, która nasłuchuje na określonym porcie TCP/IP. Uruchomi ona wszystko, co zostanie wysłane do tego portu i odpowie danymi wyjściowymi z przesłanych poleceń. Jej wariantem jest odwrócona powłoka (ang. reverse shell), ponieważ zamiast łączenia się atakującego z ofiarą, napastnik powoduje (np. poprzez podatną webaplikację), że to system ofiary łączy się do niego z powrotem. Dlaczego to takie ważne? Ponieważ większość funkcji filtrowania sieci jest skonfigurowana tak, aby szczegółowo blokować ruch przychodzący z internetu. Jednak bardzo często ruch wychodzący jest nieograniczony lub znacznie mniej filtrowany. Dlatego odwrócony bindshell jest świetnym sposobem na przeskakiwanie zapór ogniowych i innych mechanizmów ochrony.
[ czytaj całość… ]

C

zasami użytkownicy systemów stacjonarnych wychodzą z błędnego założenia, że jeśli dla kluczowych plików (typu: .bashrc, .bash_profile, .profile) w swoim katalogu domowym zmienią właściciela na administratora (root) – będzie to znaczne utrudnienie dla atakującego, aby zmusić użytkownika do uruchomienia szkodliwego skryptu lub pliku, a tym samym osiągnąć eskalację uprawnień na systemie. Nic bardziej mylnego. Należy pamiętać, że jeśli nasz użytkownik posiada prawa zapisu do katalogu, w którym znajdują się pliki nie z jego prawami to nadal może je usunąć:

agresor@darkstar:~$ ls -la
total 36
drwxr-xr-x 5 agresor agresor 4096 Jun 14 21:09 .
drwxr-xr-x 3 root    root    4096 Dec  1  2019 ..
-rw------- 1 agresor agresor 2214 Jun 14 20:59 .bash_history
-rw-r--r-- 1 root    root     220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 root    root    3771 Apr  4  2018 .bashrc
drwx------ 2 agresor agresor 4096 Dec  1  2019 .cache
drwx------ 3 agresor agresor 4096 Dec  1  2019 .gnupg
drwxrwxr-x 3 agresor agresor 4096 Dec  6  2019 .local
-rw-r--r-- 1 agresor agresor  807 Apr  4  2018 .profile
-rw-r--r-- 1 agresor agresor    0 Dec  1  2019 .sudo_as_admin_successful
agresor@darkstar:~$ chmod 777 .bashrc
chmod: changing permissions of '.bashrc': Operation not permitted
agresor@darkstar:~$ echo "# Malware code" >> .bashrc
-bash: .bashrc: Permission denied
agresor@darkstar:~$ cat .bashrc > /tmp/foo && rm -f .bashrc && cat /tmp/foo > .bashrc
agresor@darkstar:~$ echo "# Malware code" >> .bashrc
agresor@darkstar:~$ tail -1 .bashrc
# Malware code

Dlatego jeśli dojdzie do sytuacji, w której dana aplikacja pozwoli na wykonanie polecenia na systemie – ochrona plików poprzez zmianę ich właściciela będzie nieskuteczna – ze względu na możliwość ich usunięcia i odtworzenia pierwotnego właścicielstwa. W celu umożliwienia takiego “zabezpieczenia” należy zmienić właściciela katalogu $HOME na konto administratora oraz nadanie bezpiecznego atrybutu tekstu (ang. save-text attribute / sticky bit) na ten katalog – ale taki ruch może mieć jeszcze gorsze konsekwencje niż pozostawienie standardowych uprawnień. Bardziej rozsądnym rozwiązaniem, które nie bazuje na prawach dostępu – jest nałożenie (chattr +i .bashrc) atrybutu niezmienności (ang. immutable) na w/w pliki z poziomu administratora.