NFsec Logo

Brudny potok – CVE-2022-0847

08/03/2022 w Bezpieczeństwo Możliwość komentowania Brudny potok – CVE-2022-0847 została wyłączona

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

Nadużywanie rozszerzonych możliwości kontenerów Dockera do eskalacji uprawnień

03/07/2021 w Bezpieczeństwo Możliwość komentowania Nadużywanie rozszerzonych możliwości kontenerów Dockera do eskalacji uprawnień została wyłączona

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 możliwości Linuksa (ang. capabilities).
[ czytaj całość… ]

Podsumowanie ucieczek z sudo: GTFOBins (skaner)

14/03/2021 w Bezpieczeństwo Możliwość komentowania Podsumowanie ucieczek z sudo: GTFOBins (skaner) została wyłączona

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

Kroniki Shodana: Docker cz.II

31/03/2020 w Pen Test Możliwość komentowania Kroniki Shodana: Docker cz.II została wyłączona

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

Luka w runC – ucieczka z kontenera

13/02/2019 w Bezpieczeństwo 2 komentarze.

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

Podniesienie uprawnień dla użytkowników z UID większym niż INT_MAX

05/12/2018 w Bezpieczeństwo Możliwość komentowania Podniesienie uprawnień dla użytkowników z UID większym niż INT_MAX została wyłączona

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

Nawet jak developujesz używaj sudo dla dockera

11/07/2018 w Bezpieczeństwo Możliwość komentowania Nawet jak developujesz używaj sudo dla dockera została wyłączona

J

eśli nie używasz dockera z pomocą docker-machine (standardowo na systemie OSX oraz Windows) to może dojść do sytuacji, gdy polecenia dockera doprowadzą do przejęcia hosta na którym zostały uruchomione. Jeśli dodamy naszego użytkownika systemu do grupy dockera lub zmienimy uprawnienia do gniazda sieciowego – to Twój użytkownik lub szkodliwe oprogramowanie będzie mógło uzyskać uprawnienia administratora bez konieczności podawania hasła.
[ czytaj całość… ]

2-letnia luka powraca do jądra Linuksa

08/10/2017 w Bezpieczeństwo Możliwość komentowania 2-letnia luka powraca do jądra Linuksa została wyłączona

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

systemd – nazwy użytkowników zaczynające się od liczb otrzymują roota

16/07/2017 w Bezpieczeństwo Możliwość komentowania systemd – nazwy użytkowników zaczynające się od liczb otrzymują roota została wyłączona

L

uka została ujawniona podczas zgłoszenia błędu na githubie. systemd nie potrafi obsłużyć odpalenia procesu użytkownika, którego login zaczyna się od liczby np. 0day i tym samym uruchamia proces z prawami administratora zamiast owego użytkownika. Brzmi to dość drastycznie:

> In case of bug report: Expected behaviour you didn’t see
The process started by systemd should be user previlege

> In case of bug report: Unexpected behaviour you saw
The process started by systemd was root previlege

[ czytaj całość… ]

Stack Clash – kurs kolizyjny pamięci w systemach *nix

20/06/2017 w Bezpieczeństwo 1 komentarz.

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