C

loudflare udostępnił publicznie usługę Radar, w której są zawarte dane o rankingu domen: Domian Rankings Worldwide. Tutaj należy mieć świadomość, że dane pochodzą z ich publicznego serwera DNS, z którego nie koniecznie musi korzystać cały internet. Niemniej jednak jest to dobra próbka, aby przeprowadzić eksperyment podobny do analiz nagłówka HTTP. W pliku pobranym 28.09.2024 znalazło się 1.008.856 domen. Finalnie udało połączyć się z 750.892 domenami w celu pobrania informacji o ich certyfikacie TLS. Aby szybko pozyskać te dane został zmodyfikowany kod skryptu httpsrvreaper na bazie którego powstał sslsrvreaper. Jest on na tyle prosty, że czyta z pliku tekstowego domains.txt adresy, z jakimi ma się połączyć i zapisać ich metadane TLS w formacie JSON, na przykład:
[ czytaj całość… ]

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

ak zauważył Chris Siebenmann prawie każdy system Linux (a tak naprawdę, każdy system Unix) posiada systemowy “schowek” dla głównych certyfikatów CA. Możemy przez to rozumieć katalog, w którym przechowywana jest lista wszystkich certyfikatów CA, które są domyślnie zaufane przez większość oprogramowania wykorzystującego TLS. Z różnych rozsądnych powodów, wiele dystrybucji Linuksa wykorzystuje magazyn CA Mozilli jako swój systemowy czasami wprowadzając pewne zmiany. Na czym polega więc problem? Sednem jest fakt, że Mozilla oraz Microsoft właśnie przestały ufać głównym certyfikatom TrustCor w swoich przeglądarkach. Oznacza to, że certyfikaty wydane od 1 grudnia przez tego CA nie będą zaufane, a główne certyfikaty zostaną usunięte z przeglądarek po wygaśnięciu. O ile zmiana w przeglądarkach zadziała się dość szybko to należy zauważyć, że w systemach takich jak Linux, które bazują na głównym magazynie certyfikatów Mozilli będą w pełni ufać TrustCor przez co najmniej kolejny rok lub dłużej ze względu na opóźnienia w wydaniu i instalacji aktualizacji paczki ca-certificates. Możemy być zdezorientowani dlaczego systemy Linuksowe tak długo będą ufać certyfikatom TrustCor. Mniej istotnym powodem są opóźnienia jakie wynikną z aktualizacji spakowanych kopii magazynu Mozilli (powstała nawet na ten temat praca naukowa pt. Tracing Your Roots: Exploring the TLS Trust Anchor Ecosystem), a później skłonienie użytkownika do zastosowania tej aktualizacji. Dość znamiennym przykładem mogą tutaj być dystrybucje Ubuntu oraz Debian, które same cofnęły usunięcie certyfikatu Symantec z pakietu Mozilli, ponieważ program nuget używał jeszcze certyfikatów, które nie zostały odnowione, więc tymczasowo przywrócono te od Symantec. Ważniejszym problemem może wydawać się ograniczony model tradycyjnego przechowywania certyfikatów CA w systemach *nix.
[ czytaj całość… ]

W

iele nowoczesnych serwisów internetowych stosuje automatyczne wydawanie i odnawianie certyfikatów TLS. Dla firm dostępne są usługi komercyjnych wystawców SSL. Dla wszystkich innych dostępne są bezpłatne usługi, takie jak Let’s Encrypt i ZeroSSL. Jednak bardzo często popełniany jest błąd w sposobie w jaki konfiguruje się wdrożenie darmowych wersji certyfikatów TLS. Pozwala on każdemu odkryć prawie wszystkie nazwy domen i subdomen używanych przez ten sam serwer webowy. Jak wiemy, istnieje takie coś jak Certyficate Transparency (CT), czyli internetowy standard bezpieczeństwa służący do monitorowania i audytu wystawiania certyfikatów TLS. Tworzy on system logów publicznych, które służą do rejestrowania wszystkich certyfikatów wydawanych przez publicznie zaufane urzędy certyfikacji (CA). Do przeszukiwania dzienników CT możemy używać serwisów: crt.sh, certstream, a także Censys, który również pozwala na przeszukiwanie wyników skanowania certyfikatów w internecie.
[ czytaj całość… ]

W

yobraźmy sobie, że nasz system został zainfekowany przerobionym i trudnym do wykrycia implantem sieciowym. W swojej przeróbce został on uzbrojony w moduł inwigilacji oparty o eCapture. Jest to zwinne narzędzie napisane w języku Go, które również wykorzystuje technologię eBPF. Umożliwia ona uruchamianie programów zamkniętych w piaskownicy jądra systemu operacyjnego. Dzięki temu potrafi przechwycić zaszyfrowaną komunikację sieciową bez konieczności “podpinania” Urzędu Certyfikacji (ang. Certificate Authority), któremu należy zaufać. Zamiast tego wpina się w funkcje SSL_write / SSL_read współdzielonej biblioteki SSL, aby uzyskać kontekst tekstowy i wysłać tak uzyskane wiadomości do przestrzeni użytkownika za pomocą map eBPF.
[ czytaj całość… ]

W

ypożyczanie domen (ang. domain borrowing) jest ulepszoną techniką domain fronting. Tą ostatnią można łatwo wykryć jeśli w sieci znajduje się urządzenie deszyfrujące ruch HTTPS i porównuje wartości nagłówków SNI i HOST. Jednak wypożyczanie domen pozwala na ukrywanie ruchu C2 i innej komunikacji za pomocą CDN w celu obejścia zapór sieciowych i systemów IDS. Jak wygląda normalny, niepodejrzany ruch sieciowy, który się monitoruje, ale nie blokuje? Na pewno jest szyfrowany (HTTPS); odnosi się do domen z poprawnymi certyfikatami TLS, które są znane i mają dobrą reputację w sieci; nawet rozszyfrowany wygląda jak poprawny (SNI == HOST); nie jest blokowany ze względu na możliwość utraty generycznego ruchu od dużego gracza w internecie.
[ 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ść… ]

W

iele firm zamiast wystawiać w internecie swoje usługi na przypisanych do nich blokach IP (ASN) w coraz większym stopniu polegają na usługach chmur publicznych, takich jak Amazon AWS, Microsoft Azure czy Google Cloud Platform. Ponieważ infrastruktura chmury publicznej szybko staje się normą, podczas rozpoznawania zasobów danej firmy można stracić wiele obiektów skanując tylko zakresy sieci tej organizacji. Jeśli chcemy osiągnąć szybkie i najczystsze wyniki możemy połączyć ze sobą narzędzia: masscan oraz tls-scan. Oto jak hipotetycznie przeskanować zakres adresów IP i certyfikaty największych dostawców chmury publicznej w celu identyfikacji ich zasobów.
[ czytaj całość… ]

L

et’s Encrypt to organizacja non-profit oraz projekt open-source zapewniający dostęp do bezpłatnych certyfikatów SSL. Pozwala na automatyczne przedłużanie ważności certyfikatów, które domyślnie wystawiane są na okres 3 miesięcy i są zgodne z najpopularniejszymi przeglądarkami internetowymi. Od ponad roku oprócz CA Let’s Encrypt istnieje możliwość uzyskania darmowych certyfikatów od firmy Bypass. Firma ta jest europejskim CA (ang. Certificate Authority) oferującym darmowe certyfikaty, których ważność wynosi 180 dni. Teraz do grona darmowych dostawców dołącza trzeci CA – ZeroSSL (również 90 dni). Każdy z tych dostawców jest kompatybilny z narzędziami ułatwiającymi zarządzanie certyfikatami, jak CertBot oraz ACME. Osoby zainteresowane napisaniem własnych rozwiązań mogą również wykorzystać REST API. W przypadku problemów technicznych z jednym dostawcą istnieje teraz alternatywa pozwalająca na szybkie przełączenie się na inne CA.

P

odczas słuchania Rozmowy Kontrolowanej z udziałem Michała Purzyńskiego padło narzędzie Observatory od Mozilli. Okazuje się, że w jednym miejscu jesteśmy w stanie sprawdzić konfigurację kilku mechanizmów bezpieczeństwa naszej strony. Od nagłówków HTTP (w tym szczególnie ustawień polityki CSP) poprzez konfigurację TLS, a na opcjonalnych testach dla SSH kończąc. Dodatkowo jeśli interesuje nas wygenerowanie bezpiecznych konfiguracji dla najpopularniejszych serwerów możemy wykorzystać narzędzie Mozilla SSL Configuration Generator.

Więcej informacji: Konfiguracja nagłówków bezpieczeństwa na A+, HTTP Strict Transport Security – wymuszamy SSL na przeglądarkach, Konfiguracja SSL dla Apache na 5+, Konfiguracja SSL dla nginx na 5+, Audytujemy algorytmy szyfrowania SSH