P

oprzez wykorzystanie dowolnych komentarzy zawierających specjalny znak nowej linii: “\n” i za pośrednictwem poleceń iptables oraz iptables-save możemy nadpisać dowolny plik z prawami administratora i częściowo kontrolować zapisane wiersze – częściowo, ponieważ moduł komentarzy w iptables pozwala na umieszczenie 256 znaków, a zapis pliku poprzez iptables-save wprowadza pewne dane z utworzonych reguł zapory ogniowej (ang. firewall), które są dodawane przed i po wstrzykniętym komentarzu. W systemie Linux jest przynajmniej jeden plik, który nie przejmuje się niepotrzebnymi wierszami i je ignoruje, a jest nim (nie)sławny plik /etc/passwd.
[ czytaj całość… ]

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ść… ]

C

lamAV to silnik antywirusowy typu open source, który jest szeroko stosowany na serwerach pocztowych oraz różnych komercyjnych, “zamkniętych skrzynkach”. 15 lutego 2023 roku na blogu programu został opublikowany biuletyn bezpieczeństwa szczegółowo opisujący potencjalną lukę umożliwiającą zdalne wykonanie kodu w swoim parserze systemu plików HFS+ (głównym problemem jest brak sprawdzania rozmiaru podczas kopiowania bloków do bufora węzła). Luce tej nadano CVE: CVE-2023-20032. Co ciekawe podczas analizy poprawek tych luk Jared Stroud natknął się na otwarty pull request wskazujący, że nieuprzywilejowani użytkownicy mogą wyłączyć daemona clamav.
[ czytaj całość… ]

M

atthieu Barjole oraz Victor Cutillas z Synacktiv zgłosili podatność w sudoedit (sudo -e), która pozwala złośliwemu użytkownikowi z uprawnieniami sudoedit na edycję dowolnych plików. Podatność dotyczy wersji sudo od 1.8.0 do 1.9.12p1 włącznie. Wersje sudo sprzed wydania 1.8.0 konstruują wektor argumentów w inny sposób i nie są dotknięte tym błędem. Przypomnijmy, że sudo (su “do”) to najpopularniejszy program w systemach Linux, który pozwala administratorowi systemu delegować uprawnienia wybranym użytkownikom (lub grupom użytkowników) dając im możliwość uruchamiania niektórych (lub wszystkich) poleceń jako administrator (root) lub inny użytkownik, zapewniając jednocześnie ścieżkę audytu poleceń i ich argumentów.
[ czytaj całość… ]

P

odatność o nazwie Dirty Pipe została znaleziona w jądrze Linuksa od wersji 5.8, a dokładniej od commit’u f6dd975583bd ("pipe: merge anon_pipe_buf*_ops"). W funkcjach copy_page_to_iter_page i push_pipe element "flags" nowej struktury bufora potoku nie był odpowiednio inicjalizowany, przez co mógł zawierać nieaktualne wartości. Luka ta umożliwia nieuprzywilejowanemu użytkownikowi na zapis stron w pamięci podręcznej, a tym samym dowolnych danych do dowolnych plików, nawet jeśli są one w trybie O_RDONLY – tylko do odczytu, immutable (chattr +i) – posiadają atrybut, niepozwalający nawet administratorowi ich modyfikować lub są zamontowane na systemie plików do tylko do odczytu – MS_RDONLY. Dotyczy to także procesów SUID, które są uruchamiane z prawami administratora. Max Kellermann, który jest autorem luki wspomina, że jest ona podobna do CVE-2016-5195 “Dirty Cow“, ale łatwiej ją wykorzystać. Ze względu na odpowiedzialne ujawnienie podatności została ona załatana już w wersjach jądra: 5.16.11, 5.15.25 oraz 5.10.102.
[ czytaj całość… ]

W

yobraźmy sobie następujący scenariusz. Wyciekł klucz SSH umożliwiający zalogowanie się do zwykłego konta platformy wdrożeniowej. Był on używany do wdrażania i aktualizacji repozytoriów za pomocą ansible. Umożliwia on zalogowanie się na powłokę systemową grupy serwerów, na której są budowane i uruchamiane kontenery Docker. Samo konto nie posiada żadnych dodatkowych uprawnień ani grup. Zastanówmy się teraz w jaki sposób możemy dokonać eskalacji uprawnień wykorzystując jedną z przestrzeni nazw (ang. namespace) kontenera Docker oraz rozszerzonej zdolności Linuksa (ang. capabilities).
[ czytaj całość… ]

Jest to ostatni wpis odnośnie ucieczek (1, 2, 3, 4) z sudo. Aktywnie utrzymywana, wyselekcjonowanych plików binarnych oraz skryptów Linuksa, których można użyć do ominięcia lokalnych ograniczeń bezpieczeństwa w źle skonfigurowanych systemach jest zawarta w projekcie GTFOBins (alternatywa dla systemu Windows to LOLBAS). Projekt gromadzi wykorzystanie zaimplementowanych funkcjonalności *niksowych plików binarnych, które mogą być wykorzystane do wyłamywania się z ograniczeń powłok, poleceń sudo, eskalacji uprawnień, czytania zastrzeżonych plików, czy uruchamiania powłok zwrotnych. Należy mieć na uwadze, że nie jest to lista eksploitów, a programy wymienione w GTFOBins same w sobie nie są podatne na ataki. Raczej projekt ten jest kompendium wiedzy o tym, jak wykorzystać je jeśli, któreś z nich uruchamiane jest z prawami administratora lub w ograniczonych środowiskach / powłokach.
[ 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ść… ]

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ść… ]

U

żytkownicy posiadający UID większy od INT_MAX posiadają możliwość wykonania dowolnego polecenia za pomocą systemctl. Błąd nie tkwi w samym systemd, jak mogliśmy się przyzwyczaić, ale w narzędziu pkttyagent, w którym PolicyKit (polkit) podczas wystąpienia błędu twierdzi, że użytkownik jest uprawniony do wykonania polecenia. Przykład działania takiego zachowania:

$ systemctl --version
systemd 239
$ pkttyagent --version
pkttyagent version 0.115
$ id 
uid=4000000000(someuser) gid=100(users) groups=100(users)
$ systemctl stop sshd.service
(pkttyagent:3342): GLib-GObject-WARNING **: 13:28:53.802: value "-294967296" 
of type 'gint' is invalid or out of range for property 'uid' of type 'gint' **
ERROR:pkttyagent.c:156:main: assertion failed: 
(polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
$ systemctl is-active sshd.service
inactive

Luka sama w sobie nie jest groźna, ponieważ do stworzenia użytkownika z takim UID są już wymagane prawa administratora. Można ją jednak użyć do zamaskowania użytkownika, który ma podniesione prawa, a nie ma przypisanego UID/GID=0. Do czasu naprawienia luki można użyć obejścia w postaci wyłączenia polkit’a:

systemctl mask polkit && systemctl stop polkit

Więcej informacji: systemd issue, polkit issue, CVE-2018-19788