Napisał: Patryk Krawaczyński
11/12/2021 w Bezpieczeństwo
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ść… ]
Napisał: Patryk Krawaczyński
27/01/2021 w Bezpieczeństwo
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ść… ]
Napisał: Patryk Krawaczyński
23/09/2016 w Bezpieczeństwo
F
undacja OpenSSL wydała tuzin poprawek na wykryte podatności w swojej kryptograficznej bibliotece wliczając w to drastyczne błędy, które mogą prowadzić do przeprowadzenia ataków Denial-of-Service (DoS). Podatności istnieją w wersjach: 1.0.1, 1.0.2, 1.1.0 i zostały odpowiednio poprawione w: 1.0.1u, 1.0.2i oraz 1.1.0a. Pierwszy błąd zgłosił Shi Lei z chińskiej firmy ds. bezpieczeństwa Qihoo 360 – polega on na możliwości wysłania obszernych żądań typu „status” do rozszerzenia OCSP podczas negocjacji połączenia, co może spowodować wyczerpanie się pamięci na atakowanym serwerze. Drugą luką, która również umożliwia atak DoS jest przesłanie pustego rekordu do funkcji SSL_peek(), co spowoduje jej zawieszenie. Poza tym naprawiono dwanaście innych problemów niskiego ryzyka. Warto odnotować sobie, że wsparcie dla OpenSSL 1.0.1 kończy się 31 grudnia 2016 roku dlatego użytkownicy powinni zaktualizować swoje systemy do wyższej wersji w celu uniknięcia jakichkolwiek problemów z bezpieczeństwem w przyszłości.
Więcej informacji: OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304), OpenSSL Security Advisory [22 Sep 2016]
Napisał: Patryk Krawaczyński
06/04/2016 w Bezpieczeństwo
P
anowie z osławionego błędu związanego z GRUB2 ujawniają bardzo proste obejście mechanizmu ASLR. Każdy użytkownik, który mógł uruchomić aplikacje 32-bitowe na maszynie x86 – mógł za pomocą prostego polecenia wydanego z poziomu powłoki bash (ulimit -s unlimited) wyłączyć mechanizm Address Space Layout Randomization. Nie jest to luka sama w sobie, ale prosty i bardzo stary trik, jak obejść mechanizm dodatkowego zabezpieczenia, aby ułatwić sobie eksplorację innego błędu.
Więcej informacji: CVE-2016-3672 – Unlimiting the stack not longer disables ASLR
Napisał: Patryk Krawaczyński
21/02/2016 w Bezpieczeństwo
K
rytyczny błąd przepełnienia bufora na stosie został odkryty w sposobie w jaki biblioteka libresolv (glibc) przeprowadza podwójne zapytania DNS typu A/AAAA. Osoba atakująca może potencjalnie doprowadzić do zdalnego wykonania kodu (z uprawnieniami użytkownika uruchomiającymi bibliotekę) lub zawieszenia systemu poprzez specjalnie spreparowany ruch sieciowy w odpowiedzi DNS (PoC). Problem ten występuje tylko wtedy, gdy libresolv jest wywołana z modułu nss_dns usługi NSS (CVE-2015-7547).
[ czytaj całość… ]
Napisał: Patryk Krawaczyński
20/01/2016 w Ataki Internetowe
Security Losses from Obsolete and Truncated Transcript Hashes – jeśli jesteś zwolennikiem teorii, że ataki kolizji nie są jeszcze możliwe przeciwko takim funkcją skrótu, jak SHA-1 lub MD5 – to powinieneś zapoznać się z pracą dwóch badaczy z INRIA (The French Institute for Research in Computer Science and Automation), którzy przedstawili nowy rodzaj ataku przyśpieszającego pilną potrzebę odejścia od tych algorytmów kryptograficznych.
[ czytaj całość… ]
Napisał: Patryk Krawaczyński
19/01/2016 w Ataki Internetowe, Bezpieczeństwo
P
erception Point ujawnił nową lukę bezpieczeństwa typu zero-day w jądrze systemu Linux, która umożliwia nieuprawnione podniesienie praw użytkownika do roli administratora (root). Luka istniała od 2012 roku, a aktualnie dotyka każdą maszynę wyposażoną w jądro Linux w wersji 3.8 i wyższej (oprócz dziesiątek milionów serwerów i komputerów podatne są także telefony z systemem Android KitKat i nowsze). Wykorzystując tą podatność atakujący są w stanie kasować i wyświetlać prywatne dane oraz instalować szkodliwe oprogramowanie. Kernel security team zostało już powiadomione i dzięki Red Hat Security team poprawki powinny zacząć pojawiać się w najbliższym czasie. Zalecamy jak najszybszą aktualizację.
Więcej informacji: Analysis and Exploitation of a Linux Kernel Vulnerability (CVE-2016-0728)
Napisał: Patryk Krawaczyński
15/01/2016 w Ataki Internetowe, Bezpieczeństwo
O
d wersji 5.4 (wypuszczonej w marcu 2010 roku), klient OpenSSH obsługuje nieudokumentowaną funkcjonalność o nazwie „roaming„: jeśli połączenie do serwera SSH zostanie nieoczekiwanie przerwane i jeśli serwer wspiera tą funkcjonalność – klient jest w stanie odnowić połączenie i odzyskać zawieszoną sesję SSH. Chociaż roaming nie jest jeszcze wspierany po stronie serwera OpenSSH jest standardowo włączony w kliencie i posiada dwie podatności, które mogą zostać wykorzystane przez szkodliwy (lub zaufany ale skompromitowany) serwer SSH: wyciek informacji (poprzez ujawnienie danych z pamięci) oraz przepełnienie bufora (z wykorzystaniem stosu).
[ czytaj całość… ]
Napisał: Patryk Krawaczyński
09/12/2013 w Bezpieczeństwo
W
maju 2012 roku opublikowano lukę w PHP CVE-2012-1823. Dotyczy ona tylko serwerów, które posiadają skonfigurowaną obsługę języka PHP jako skrypty CGI. Chociaż nie jest to domyślna konfiguracja w większości systemów – w takich dystrybucjach jak Debian i Ubuntu instalując paczkę php5-cgi i zostawiając domyślne ustawienia serwera Apache – pozwalające na dostępność binarnych plików w ścieżce http://serwer/cgi-bin/php5 wystawiamy nasz serwer na eksplorację luki. O zasadzie luki możemy przeczytać tutaj.
[ czytaj całość… ]
Napisał: Patryk Krawaczyński
09/05/2026 (5 dni temu) w Bezpieczeństwo
K
olejny łańcuch prowadzący do lokalnej eskalacji uprawnień został odkryty jądrze Linux. Za pomocą błędów w podsystemach sieciowych ESP (IPsec) (CVE-2026-43284) oraz RxRPC (CVE-2026-43500) umożliwia lokalnemu użytkownikowi uzyskanie uprawnień administratora. Dirty Frag należy do tej samej klasy błędów, co słynne Dirty Pipe i Copy Fail. Głównym problemem nadal pozostaje niewłaściwa obsługa stron pamięci podręcznej (ang. page cache). W normalnych warunkach system operacyjny powinien dbać o to, aby dane modyfikowane przez jądro były odizolowane od plików tylko do odczytu. Jednak w przypadku Dirty Frag mechanizmy szybkiej deszyfracji w modułach esp4, esp6 oraz rxrpc deszyfrują dane bezpośrednio do fragmentów pamięci, które nie należą wyłącznie do jądra systemu. Dzięki temu atakujący można nadpisać w pamięci RAM fragmenty dowolnych plików systemowych (np. /etc/passwd lub programy z bitem SUID, jak /usr/bin/su.
Można powiedzieć, że jest to następca Copy Fail – tutaj też w przeciwieństwie do wielu innych błędów typu LPE atak jest przewidywalny i ma bardzo wysoką skuteczność. Atakujący też używa wywołania systemowego splice() do zmapowania pamięci podręcznej pliku systemowego do potoku (ang. pipe), a następnie wymusza na jądrze zapisanie danych w to samo miejsce. Wygląda to mniej więcej tak:
- Atakujący otwiera plik systemowy (np.
/etc/passwd) do odczytu i używa wywołania systemowego splice(). Powoduje to, że strony pamięci podręcznej tego pliku zostają podpięte pod bufor potoku. W tym momencie potok nie zawiera kopii danych, ale bezpośrednio „wskazuje” na fizyczną pamięć, w której system przechowuje treść pliku.
- Kolejnym krokiem jest wykorzystanie protokołów sieciowych jądra, takich jak ESP (ang. Encapsulating Security Payload) lub RxRPC, aby wysłać specjalnie sformatowany pakiet sieciowy, który wymaga od jądra systemu procesu „złożenia” lub „odszyfrowania”.
- Podczas odszyfrowywania lub weryfikacji pakietu, jądro wykonuje operację zapisu, która kopiuje dane z pakietu sieciowego bezpośrednio do bufora potoku przygotowanego w kroku pierwszym. System jednak nie tworzy prywatnej kopii danych przed ich modyfikacją, lecz operuje bezpośrednio na oryginalnej stronie pamięci podręcznej. Ponieważ bufor wskazuje na pamięć podręczną pliku systemowego, jądro nieświadomie nadpisuje treść pliku w pamięci RAM.
System operacyjny „myśli”, że to tylko tymczasowe dane w potoku, podczas gdy w rzeczywistości modyfikowany jest chroniony plik systemowy. Każdy kolejny proces odczytujący ten plik zobaczy już zmodyfikowaną wersję. Pokazuje to, jak mogą być złożone interakcje między optymalizacją wydajności, a zarządzaniem pamięcią w jądrze systemu. Dlaczego ten łańcuch podatności wykorzystuje dwa moduły? Ponieważ przy wykorzystaniu ESP są wymagane uprawnienia do tworzenia przestrzeni nazw użytkownika (unshare), co na niektórych systemach może być zablokowane. Wariant z RxRPC nie wymaga takich uprawnień, więc działa tam, gdzie wariant ESP zawodzi. Z kolei jeśli w systemie brakuje modułu RxRPC, atakujący próbuje wykorzystać wariant ESP. W ten sposób oba warianty wzajemnie uzupełniają swoje słabe strony. Do czasu wypuszczenia poprawionych wersji modułów w jądrach systemowych mitygacją pozostaje zablokowanie ładowania wadliwych modułów na podatnych systemach:
sh -c \
"printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
> /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
Należy mieć jednak na uwadze, że spowoduje to błędy w działaniu połączeń VPN/IPsec opartych na tym standardzie oraz straceniu dostępu do rozproszonego systemu plików AFS, który bazuje na RxRPC.
Więcej informacji: Dirty Frag Write Up, Copy Fail 2: Electric Boogaloo, Dirty Frag: Linux Kernel Local Privilege Escalation via ESP and RxRPC
Ostatni komentarz :