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

3

lipca odnośnik do eksploita umożliwiającego uzyskanie uprawnień administratora w systemie Linux rozprzestrzenił się w różnych społecznościach na Telegramie i Twitterze. Napisała nawet o tym prasa branżowa. Rzekomy kod dowodu koncepcji (Proof of Concept – PoC) błędu opisanego w CVE-2023-35829 niestety okazał się zupełnie czymś innym niż pierwotnie zakładano. Przed usunięciem fałszywego profilu użytkownika ChriSanders22 z serwisu GitHub kod PoC został oznaczony gwiazdką przez ponad 100 użytkowników, a 25’ciu rozgałęziło go na swoje konta. Kilka osób, które uruchomiło kod bez jego weryfikacji zauważyło dziwne zmiany w plikach konfiguracyjnych powłoki bash – $HOME/.bashrc. Jak to? Co ma wspólnego exploit z dopisywaniem czegoś o plików powłoki? Otóż jeśli przyjrzeć się bliżej procesowi kompilacji to można zauważyć, że plik Makefile odwoływał się do binarnego pliku alocal.m4:
[ czytaj całość… ]

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

O

prócz analizy najczęściej używanych haseł z publikacji danych logowania – możemy sprawdzić jakie najczęściej znaki pojawiają się w hasłach. Nawet jeśli użytkownicy umieszczają w swoich hasłach do serwisów mieszankę liter, cyfr i symboli to nadal mogą paść ofiarą często używanych kombinacji. Poniższe wyciągi pokazują popularność poszczególnych znaków, aby zidentyfikować znaki na klawiaturze, po które ludzie sięgają najczęściej podczas tworzenia swoich haseł. Liczby takie jak 0, 1 i 2, a także symbole takie jak kropka, podkreślenie i znak „małpy” („@”) są nadal powszechne i można je łatwo odgadnąć.
[ czytaj całość… ]

O

penSSH – Secure Shell Server zapewnia bezpieczny, szyfrowany zdalny dostęp do systemów *niksowych. Po stronie serwera znajduje się plik authorized_keys w katalogu .ssh (głównym folderze użytkownika), w którym można skonfigurować uwierzytelnianie za pomocą klucza publicznego. Przy normalnej konfiguracji użytkownik uzyskuje pełny dostęp do systemu, w którym skonfigurowano uwierzytelnianie. Jednak w niektórych przypadkach, takich jak automatyczne operacje na zdalnych serwerach (np. wdrażanie kodu, tworzenie kopii zapasowych, uruchamianie konkretnych skryptów), sensowne jest ograniczanie dostępu do kilku lub nawet jednego polecenia. Oprócz ograniczenia poleceń dla danego użytkownika zapobiegamy również kompromitacji zdalnego serwera w przypadku przejęcia klucza prywatnego.
[ 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ść… ]

O

podpisywaniu commitów przez SSH już wiemy. Ale czy wiesz, że możesz użyć polecenia ssh-keygen do podpisywania i weryfikowania podpisów na dowolnych danych, takich jak pliki w wypuszczane wersje oprogramowania? Funkcja ta została dodana wraz w wersją OpenSSH 8.0, dlatego jeśli używasz Debian Bullseye / Ubuntu 20.04 lub nowsze – masz już zainstalowaną wystarczająco nową wersję SSH, aby korzystać z tej funkcjonalności. W dodatku jeśli korzystasz z serwisu GitHub lub jakiejkolwiek innej usługi, która używa kluczy SSH do uwierzytelniania to pewnie masz już klucz SSH, którego można użyć do generowania podpisów (jeśli nie to zajmiemy się tym później). Dystrybucja kluczy SSH jest łatwa, ponieważ publiczne klucze SSH to krótkimi jednowierszowymi ciągami, które łatwo skopiować. W dodatku możemy użyć wspomnianego serwisu GitHub jako dystrybutora kluczy – możesz pobrać klucze publiczne SSH dla dowolnego użytkownika odwiedzając adres URL w postaci: https://github.com/$nazwa_użytkownika.keys np. NFsec.
[ czytaj całość… ]

L

OLD to kolejny projekt kierowany przez społeczność, który zapewnia wyselekcjonowaną listę wszystkich sterowników Windows, które mogą zostać wykorzystane przez atakujących do obejścia systemów bezpieczeństwa i uruchomienia złośliwego oprogramowania. Projekt został zainspirowany pracą Michaela Haaga (Atomics on Friday), który zauważył potrzebę śledzenia złośliwych sterowników, których aktorzy używają w celu uniknięcia wykrycia i ma na celu pomoc specjalistom ds. bezpieczeństwa bycie na bieżąco w rozpoznawaniu potencjalnych zagrożeń. Podobnie jak inne tego rodzaju projekty jest on typu open source, który z zadowoleniem przyjmuje wkład społeczności zajmującej się bezpieczeństwem. Dzieląc się wiedzą i doświadczeniem, możemy pomagać sobie nawzajem w uzyskiwaniu aktualnych informacji i lepszej ochronie przed pojawiającymi się zagrożeniami. Niezależnie od tego, czy jesteś badaczem bezpieczeństwa, osobą reagującą na incydenty czy administratorem systemu autorzy mają nadzieję, że LOLD będzie cennym źródeł informacji w walce z cyberatakami. Dla przypomnienia: inne tego typu projekty to: GTFOBins, LOLBas, LOTS, Filesec, MalAPI.

Więcej informacji: LOLDrivers

Przeglądając na bieżąco raporty odnośnie szkodliwego oprogramowania przeznaczonego dla systemów Linux – można dojść do wniosku, że wszystkie warianty można połączyć poprzez wykrywanie poleceń curl lub wget ściągających ładunek z publicznego adresu IP:

=~ (curl|wget).*(\b25[0-5]|\b2[0-4][0-9]|\b[01]?[0-9][0-9]?)
   (\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}(:[0-9]+)?\/.+.*

W celu wykluczenia fałszywych alarmów (szczególnie w centrach danych) można połączyć to z regułą, która wykluczy komunikację w ramach lokalnych sieci:

!=~ (curl|wget).*((127(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|
    (10(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|
    (192\.168(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2})|
    (172\.(?:1[6-9]|2\d|3[0-1])(?:\.(25[0-5]|2[0-4][0-9]|
    [01]?[0-9][0-9]?)){2}|169\.254\.169\.254|0\.0\.0\.0))(:[0-9]+)?\/.+.*

Więcej informacji: How Malicious Actors Abuse Native Linux Tools in Attacks, Log4j Attack Payloads In The Wild, Triaging a Malicious Docker Container, Attackers exploit CVE-2021-26084 for XMRig crypto mining on affected Confluence servers, Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild, DreamBus Botnet – Technical Analysis, Threat Alert: Kinsing Malware Attacks Targeting Container Environments

D

zielenie się zagrożeniami w branży bezpieczeństwa pozostaje głównie doraźną pracą, wypełnioną martwymi punktami, pułapkami i frustracją. W idealnym świecie prywatne firmy i agencje rządowe gromadzą i udostępniają odpowiednie, aktualne i dokładne informacje o nowych lub trwających cyberatakach tak szybko, jak to możliwe. Pozwala to innym konsumentom tych informacji uniknąć poważnych naruszeń (lub zminimalizować szkody spowodowane atakiem), a dostawcy usług, których infrastruktura (np. domeny, serwery) została wykorzystana do przeprowadzania ataków na bieżąco blokuje i usuwa wrogich klientów. Niestety nie zawsze tak jest, szczególnie jeśli chodzi o unieszkodliwianie wrogich obiektów. Niemniej istnieje OTX – Open Threat Exchange zapewniając otwarty dostęp do globalnej społeczności badaczy cyberzagrożeń i specjalistów ds. bezpieczeństwa z różnych firm.
[ czytaj całość… ]