P

lik lastlog, znajdujący się w ścieżce /var/log/lastlog, jest plikiem typu „niegęstego” (ang. sparse file), który próbuje wykorzystać przestrzeń systemu plików bardziej efektywnie, gdy sam plik jest częściowo pusty. Osiąga się to poprzez zapisywanie krótkich informacji (metadanych) reprezentujących puste bloki na nośniku danych zamiast rzeczywistej „pustej” przestrzeni, która tworzy blok, zużywając w ten sposób mniej miejsca. Pełny blok jest zapisywany na nośniku jako rzeczywisty rozmiar tylko wtedy, gdy blok zawiera „rzeczywiste” (niepuste) dane. Dla codziennego użytkowania systemu Linux oznacza to, że jego zgłaszany rozmiar (np. przez polecenie ls) może być znacznie większy niż rzeczywista przestrzeń, jaką zajmuje na dysku.
[ czytaj całość… ]

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.