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

K

to ma informację ten ma władzę. Jeśli pamiętamy serwis umożliwiający nam rekonesans przez listę certyfikatów, czy innego tego typu rozwiązania – to możemy dojść do wniosku, że wszystkie te rozwiązania mają opóźnienia w czasie. No chyba, że będziemy codziennie wykonywać z nich zrzut danych i porównywać różnicę, ale to może być trochę czasochłonne. Czy istnieje możliwość stworzenia prostego mechanizmu, który będzie w czasie rzeczywistym śledził dla nas pojawienie się domen lub subdomen będących w centrum naszego zainteresowania ?
[ czytaj całość… ]

P

oniższa konfiguracja (podobnie, jak w przypadku nginx) serwera Apache dla komunikacji po https pozwala na uzyskanie oceny A+ w teście przeprowadzanym przez firmę Qualys SSL Labs. Innymi mechanizmami, które zostały zwarte to: HSTS, DNS CAA, OSCP oraz HTTP2. Stosując poniższą konfigurację należy liczyć się, że może ona nie działać (lub niektóre jej funkcjonalności) z starszymi przeglądarkami i aplikacjami typu Java.

  Protocols http/1.1 h2

  SSLEngine on
  SSLCompression off
  SSLSessionTickets off
  SSLUseStapling on

  SSLCertificateFile /etc/apache2/ssl/root.pem
  SSLCertificateKeyFile /etc/apache2/ssl/server.key
  SSLCertificateChainFile /etc/apache2/ssl/root.pem

  SSLProtocol -All +TLSv1.2
  SSLHonorCipherOrder on
  SSLCipherSuite "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128:!AES256-SHA:\
                  !AES256-SHA256:!AES256-GCM-SHA384:!AES256-CCM8:!AES256-CCM:\
                  !DHE-DSS-AES256-SHA:!SRP-DSS-AES-256-CBC-SHA"

  SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparams4096.pem"
  SSLOpenSSLConfCmd ECDHParameters secp384r1
  SSLOpenSSLConfCmd Curves secp521r1:secp384r1

  Header always append Strict-Transport-Security "max-age=31536000;"

Plik dhparams4096.pem wygenerujemy poleceniem (może to zająć nawet kilkanaście minut):

openssl dhparam -out /etc/ssl/certs/dhparams4096.pem 4096

[ czytaj całość… ]