C

iekawa podatność pojawiła się w systemd, która bazuje na jednej z ucieczek z programu sudo. Otóż wersje systemd w wersji sprzed 247 umożliwiają eskalację uprawnień poprzez ominięcie ograniczeń uprawnień nakładanych przez konfigurację (/etc/sudoers) programu sudo dla danego użytkownika. Na przykład systemd w podatnych wersjach nie ustawia wartości „1” dla zmiennej LESSSECURE, dlatego program less biorący udział w tym łańcuchu zdarzeń jest w stanie uruchomić inny program (np. powłokę shell) z uprawnieniami administratora systemu. Wystarczy zmusić terminal do przekazania danych wyjściowych polecenia systemctl do programu less, co możemy bardzo prosto osiągnąć poprzez zmniejszenie okna samego terminala.
[ czytaj całość… ]

P

ocząwszy od wersji 4.19 jądra systemu Linux możliwe jest uniemożliwienie otwierania FIFO lub zwykłych plików niebędących własnością użytkownika w globalnie zapisywalnych katalogach z ustawionym sticky bit (np. /tmp). Ochronę tę można stosować osobno dla FIFO, zwykłych plików, symlinków / hardlinków poprzez odpowiednie ustawienia z poziomu sysctl. Ustawienia te oparte są na łatce HARDEN_FIFO, która znajdowała się w projekcie Openwall Solar Designera, a ich celem jest utrudnienie ataków polegających na spoofingu danych. Poniżej znajduje się krótka lista starych luk, którym można było zapobiec dzięki tej funkcji (niektóre z nich pozwalają nawet na eskalację uprawnień):
[ czytaj całość… ]

C

lamAV to silnik antywirusowy typu open source, który jest szeroko stosowany na serwerach pocztowych oraz różnych komercyjnych, „zamkniętych skrzynkach”. 15 lutego 2023 roku na blogu programu został opublikowany biuletyn bezpieczeństwa szczegółowo opisujący potencjalną lukę umożliwiającą zdalne wykonanie kodu w swoim parserze systemu plików HFS+ (głównym problemem jest brak sprawdzania rozmiaru podczas kopiowania bloków do bufora węzła). Luce tej nadano CVE: CVE-2023-20032. Co ciekawe podczas analizy poprawek tych luk Jared Stroud natknął się na otwarty pull request wskazujący, że nieuprzywilejowani użytkownicy mogą wyłączyć daemona clamav.
[ czytaj całość… ]

1

7 listopada 2022 roku główny programista kryptowaluty Bitcoin – Luke Dashjr poinformował na swoim koncie Mastodon, że ktoś nieautoryzowany uzyskał dostęp do jego serwera Linux. Doprowadziło to do ukierunkowanego napadu na jego kryptowalutę, a także kradzież jego klucza PGP. Badacz bezpieczeństwa Taha Karim otrzymał od Luka kopię znalezionych na serwerze próbek publikując niedawno ich analizę. Początkowy wektor infekcji serwera nadal pozostaje niepotwierdzony, ponieważ padło parę podejrzeń w tym podłączenie szkodliwego nośnika bezpośrednio do serwera. W ramach ataku rzekomo skradziono 200 BTC o wartości na ten czas 3,6 miliona dolarów. Nie jest też jasne, w jaki sposób atakujący przeskoczyli z serwera na stację roboczą (lub odwrotnie).

Podczas przeprowadzonej analizy wyodrębniono dwa narzędzia: DARKSABER – nieco zmodyfikowany wariant TinyShell, który jest otwartym oprogramowaniem typu backdoor, zapewniając zdalne wykonanie powłoki, a także przesyłanie plików. Warto zauważyć, że backdoor ten jest trudny do zmodyfikowania lub przejęcia kontroli (w przypadku wykrycia) bez znajomości tajnego klucza, który jest używany do uwierzytelniania i szyfrowania komunikacji klient – serwer przy użyciu algorytmu szyfrowania AES-CBC-128 (odbywa się weryfikacja dla każdego wysłanego / odebranego pakietu). SHADOWSTRIKE – zwrotna powłoka TCP na platformę *nix napisana w języku Perl również oparta o otwarty i znany skrypt autorstwa pentestmonkey – perl-reverse-shell. Posiada on ciekawą opcję ustawiania nazwy procesu pod którą ukrywa się skrypt maskując sesję „mrocznego operatora”.

Ciekawy aspekt stanowi tutaj wykorzystanie właśnie TinyShell, ponieważ narzędzia oparte na tym rozwiązaniu były wykorzystywane przez wiele grup APT (ang. Advanced Persistent Threat) począwszy od takich jak APT31, PassCV, ChamelGang lub grupy UNC, jak UNC1945 lub UNC2891 oraz liczne ataki ukierunkowane od 2012 roku (nie tylko na platformy Linux).

Poniżej znajduje się przykładowa reguła YARA pozwalająca wykryć TinyShell w systemie Linux:

rule TinyShell
{
meta:
author = "Mandiant "
strings:
$sb1 = { C6 00 48 C6
         4? ?? 49 C6 
         4? ?? 49 C6 
         4? ?? 4C C6 
         4? ?? 53 C6 
         4? ?? 45 C6 
         4? ?? 54 C6 
         4? ?? 3D C6
         4? ?? 46 C6 
         4? ?? 00 }
$sb2 = { C6 00 54 C6 
         4? ?? 4D C6
         4? ?? 45 C6
         4? ?? 3D C6 
         4? ?? 52 }
$ss1 = "fork" ascii fullword wide
$ss2 = "socket" ascii fullword wide
$ss3 = "bind" ascii fullword wide
$ss4 = "listen" ascii fullword wide
$ss5 = "accept" ascii fullword wide
$ss6 = "alarm" ascii fullword wide
$ss7 = "shutdown" ascii fullword wide
$ss8 = "creat" ascii fullword wide
$ss9 = "write" ascii fullword wide
$ss10 = "open" ascii fullword wide
$ss11 = "read" ascii fullword wide
$ss12 = "execl" ascii fullword wide
$ss13 = "gethostbyname" ascii fullword wide
$ss14 = "connect" ascii fullword wide
condition:
uint32(0) == 0x464c457f and 1 of ($sb*) and 10 of ($ss*)
}

Detekcja:

FILE: /root/tsh/tshd SCORE: 70 TYPE: ELF SIZE: 63720
FIRST_BYTES: 7f454c4602010100000000000000000003003e00 / 
MD5: 9cbfbbd7a5df3fb77d110062a905b90d
SHA1: f361a0398992624eb000ebabc09ca875ed57a269
SHA256: 1f889871263bd6cdad8f3d4d5fc58b4a32669b944d3ed0860730374bb87d730a 
CREATED: Thu Feb  2 19:33:12 2023 
MODIFIED: Thu Feb  2 19:33:12 2023 
ACCESSED: Thu Feb  2 20:02:28 2023
REASON_1: Yara Rule MATCH: TINYSHELL SUBSCORE: 70
DESCRIPTION: not set REF: - AUTHOR: Mandiant
MATCHES: 
Str1: c60048c6400549c6400149c640064cc6400253c6400745c6400354c640083dc6400446c6400900 
Str2: c60054c640034dc6400145c640043dc6400252 

Więcej informacji: Trellix Insights: UNC2891 performing unauthorized cash withdrawals

Wiadomości jądra Linux po starcie systemu powinny być dostępne tylko dla administratora. To samo tyczy się jego wskaźników. Analogicznie możemy postąpić z logami jądra, które są wyświetlane na konsoli podczas i po starcie serwera. Za ich wyświetlanie odpowiedzialna jest jedna z najbardziej znanych funkcji z interfejsu jądra Linuksa – printk(). Jest to standardowe narzędzie, które służy do wyświetlania wiadomości i zazwyczaj najbardziej podstawowy sposób na śledzenie i debugowanie kodu jądra. Jeśli jesteśmy zaznajomieni z printf(3) to można powiedzieć, że printk() jest na nim oparty, chociaż ma pewne funkcjonalne różnice: jego komunikaty mogą zostać określone za pomocą poziomu szczegółowości (na czym się skupimy tutaj) oraz ciąg formatu (ang. format string) – choć w dużej mierze zgodny z C99, nie podąża dokładnie za tą samą specyfikacją.
[ czytaj całość… ]

M

atthieu Barjole oraz Victor Cutillas z Synacktiv zgłosili podatność w sudoedit (sudo -e), która pozwala złośliwemu użytkownikowi z uprawnieniami sudoedit na edycję dowolnych plików. Podatność dotyczy wersji sudo od 1.8.0 do 1.9.12p1 włącznie. Wersje sudo sprzed wydania 1.8.0 konstruują wektor argumentów w inny sposób i nie są dotknięte tym błędem. Przypomnijmy, że sudo (su „do”) to najpopularniejszy program w systemach Linux, który pozwala administratorowi systemu delegować uprawnienia wybranym użytkownikom (lub grupom użytkowników) dając im możliwość uruchamiania niektórych (lub wszystkich) poleceń jako administrator (root) lub inny użytkownik, zapewniając jednocześnie ścieżkę audytu poleceń i ich argumentów.
[ czytaj całość… ]

S

ystemy wieloużytkownikowe zaprojektowane są na udostępnianie dużej liczby informacji użytkownikom. Wiele z tych informacji jest „publiczna” i może być współdzielona pomiędzy różnymi użytkownikami. Nigdy nie można lekceważyć wpływu takich informacji na bezpieczeństwo. Poniżej znajduje się prosty skrypt, który umożliwia złośliwemu użytkownikowi podsłuchiwanie naciśnięć klawiszy innych użytkowników przy użyciu takich informacji. Atak wykorzystuje zwykłe nieuprzywilejowane konto i informacje o procesie ujawnione przez wirtualny system plików procfs (ang. process file system) obsługiwany przez m.in. system Linux. Zawiera on hierarchię plików wirtualnych, które opisują aktualny stan jądra, w tym dane statystyczne o pamięci procesów i niektórych ich wartościach rejestrów. Są one używane przez takie programy jak ps i top, aby zbierać i prezentować informacje o systemie oraz pomagać w debugowaniu oprogramowania. Domyślnie wiele z tych plików jest czytelnych dla wszystkich użytkowników systemu, co w naturalny sposób rodzi obawy, czy ich zawartość nie może ujawnić wrażliwych informacji innego użytkownika.
[ czytaj całość… ]

J

akiś czas czemu firma Elastic weszła w rozwiązania typu SIEM (ang. Security Information and Event Management oraz EDR (ang. Endpoint Detection and Response). Jako, że jej rozwiązania od dawna wywodzą się z korzeni open source – firma udostępniła otwarte repozytorium reguł wykrywania różnych ataków i technik. Reguły w tym repozytorium są uporządkowane według rozwiązania lub platformy zachowując spłaszczoną strukturę. Każdy katalog zawiera od kilku do kilkunastu plików .toml, a w nich opisane reguły detekcyjne wraz z referencjami i taktykami ATT&CK. W drugim repozytorium znajdziemy artefakty zawierające logikę ochrony wykorzystywaną do zatrzymywania zagrożeń w systemach operacyjnych Windows, macOS i Linux. Obejmuje to reguły ochrony przed złośliwym oprogramowaniem napisane w EQL (ang. Event Query Language), a także sygnatury YARA stosowane zarówno do zawartości plików, jak i pamięci. Repozytoria te stanowią bardzo dużą bazę wiedzy odnośnie procesu proaktywnej detekcji zagrożeń (ang. threat hunting), którą możemy przełożyć na reguły dedykowane we własnych rozwiązaniach. Jeśli za ich pomocą nauczymy się wykrywania nowych technik i zagrożeń to świetnie! Ale jeszcze lepiej podzielić się także własną logiką wykrywania ze światem i pomóc innym podnieść poprzeczkę we własnych systemach detekcyjnych.

Więcej informacji: Continued leadership in open and transparent security

T

imestomping jest powszechną techniką, która odnosi się do zmiany sygnatur czasowych plików (czasu modyfikacji, dostępu, utworzenia i ostatniej zmiany) na systemie plików. Taktyka ta jest powszechnie wykorzystywana przez cyberprzestępców do ukrywania swoich narzędzi w systemie plików ofiary. Osiąga się to, sprawiając wrażenie, że pliki zostały utworzone poza ramami czasowymi incydentu (znacznie wcześniej niż nastąpiło naruszenie systemu) lub naśladowania plików znajdujących się w tym samym folderze, gdzie nastąpiła infekcja. W ten sposób takie obce pliki będą trudniejsze do znalezienia lub całkowicie pominięte przez śledczych lub przez różne narzędzia do analizy.
[ czytaj całość… ]

J

ak zauważył Chris Siebenmann prawie każdy system Linux (a tak naprawdę, każdy system Unix) posiada systemowy „schowek” dla głównych certyfikatów CA. Możemy przez to rozumieć katalog, w którym przechowywana jest lista wszystkich certyfikatów CA, które są domyślnie zaufane przez większość oprogramowania wykorzystującego TLS. Z różnych rozsądnych powodów, wiele dystrybucji Linuksa wykorzystuje magazyn CA Mozilli jako swój systemowy czasami wprowadzając pewne zmiany. Na czym polega więc problem? Sednem jest fakt, że Mozilla oraz Microsoft właśnie przestały ufać głównym certyfikatom TrustCor w swoich przeglądarkach. Oznacza to, że certyfikaty wydane od 1 grudnia przez tego CA nie będą zaufane, a główne certyfikaty zostaną usunięte z przeglądarek po wygaśnięciu. O ile zmiana w przeglądarkach zadziała się dość szybko to należy zauważyć, że w systemach takich jak Linux, które bazują na głównym magazynie certyfikatów Mozilli będą w pełni ufać TrustCor przez co najmniej kolejny rok lub dłużej ze względu na opóźnienia w wydaniu i instalacji aktualizacji paczki ca-certificates. Możemy być zdezorientowani dlaczego systemy Linuksowe tak długo będą ufać certyfikatom TrustCor. Mniej istotnym powodem są opóźnienia jakie wynikną z aktualizacji spakowanych kopii magazynu Mozilli (powstała nawet na ten temat praca naukowa pt. Tracing Your Roots: Exploring the TLS Trust Anchor Ecosystem), a później skłonienie użytkownika do zastosowania tej aktualizacji. Dość znamiennym przykładem mogą tutaj być dystrybucje Ubuntu oraz Debian, które same cofnęły usunięcie certyfikatu Symantec z pakietu Mozilli, ponieważ program nuget używał jeszcze certyfikatów, które nie zostały odnowione, więc tymczasowo przywrócono te od Symantec. Ważniejszym problemem może wydawać się ograniczony model tradycyjnego przechowywania certyfikatów CA w systemach *nix.
[ czytaj całość… ]