Jak certyfikaty SSL ujawniają poufne informacje.

Certyfikat SSL

Certyfikat SSL to pierwszy krok w zapewnieniu bezpieczeństwa użytkowników, a HTTPS, SMTPS, IMAPS, POP3S stały się standardowymi protokołami dla ruchu internetowego. Certyfikaty te niosą ze sobą ocean informacji. Mogą one przekazywać poufne dane potencjalnym atakującym. Wynika to z nowych badań przeprowadzonych przez Detectify Labs, które przeanalizowały ponad 900 milionów publicznych certyfikatów SSL/TLS.

Zabezpieczenie witryny za pomocą certyfikatu SSL/TLS nie jest już opcjonalne. Nawet w przypadku firm, które nie mają w sieci poufnych informacji o klientach. Chociaż certyfikaty Secure Sockets Layer (SSL) lub Transport Layer Security (TLS) stanowią podzbiór szyfrowanej komunikacji, są one kluczowym elementem z punktu widzenia bezpieczeństwa użytkowników. Dostawcy tacy jak Let’s Encrypt poprawili bezpieczeństwo w Internecie dzięki zautomatyzowanym sposobom łatwej i bezpłatnej konfiguracji protokołu HTTPS. Dzięki temu szyfrowanie jest łatwo dostępne dla mniejszych firm.

Gdy informacje są szyfrowane podczas korzystania z certyfikatów SSL, ryzyko ich ujawnienia nadal istnieje, ponieważ firmy używają opisowych nazw domen. W nowym badaniu przeprowadzonym przez Detectify Labs sprawdzono ponad 900 milionów publicznych certyfikatów SSL/TLS. Odkryto pułapki, które mogą prowadzić do ujawnienia lub narażenia danych firmy przez złośliwych cyberprzestępców.

Certyfikat SSL – pięta achillesowa firmy

Dane z dziennika logów dla certyfikatów mogą ujawnić infrastrukturę cyfrową, oprogramowanie i produkty używane przez organizacje wewnętrznie i zewnętrznie. Informacje te może wykorzystać atakujący. Badacze z Detectify przeanalizowali wzorce związane z bezpieczeństwem SSL. Zobaczyli, co można ujawnić po zebraniu i zmaganiu się z tymi publicznie dostępnymi danymi.

Detectify zbierał codziennie blisko 10 milionów logów certyfikatów od lipca 2021 r. Które generowane były przez organizacje wydające, w tym Let’s Encrypt, Digicert, Amazon i Google. Badanie wykazało, że większość nowo certyfikowanych domen posiada opisowe nazwy stwarzające potencjalne ryzyko wycieku danych. Zagrożenie bezpieczeństwa nasila się, gdy domeny są certyfikowane w fazie przejściowej cyklu rozwoju, zanim zostaną publicznie uruchomione. Jak powiedział współzałożyciel i starszy badacz bezpieczeństwa Detectify, Fredrik Nordberg Almroth: „To daje konkurentom (wystarczająco dużo czasu) na działania marketingowe lub inne działania, które mogą odciągnąć ruch od planowanych wydarzeń.”. Dla przykładu, jeśli firma X pracuje nad produktem Y i ustawia domenę wstępnie na 'next-gen-of-prod-y.staging.compx.com 6 miesięcy przed oficjalną datą ogłoszenia produktu, konkurenci mogą potencjalnie wykorzystać taką informację.

Almroth poinformował, że podczas wdrażania nowych nazw domen firmy muszą zawsze wybierać nazwy kodowe lub losowe ciągi zamiast opisowych nazw produktów. „Niezależnie od tego, czy dane SSL stanowią ryzyko, czy nie, powinieneś być tego świadomy. Nazwy domen nieuchronnie zostaną zaindeksowane i pojawią się w Internecie, nawet jeśli dotyczą czegoś wewnętrznego. Wszystko, co możesz zrobić, to upewnić się, że nie ujawniasz ważnych informacji”. Co więcej, możesz wiedzieć, czy ktoś wystawił certyfikat za pomocą GoDaddy. Z drugiej strony złośliwy atakujący może zobaczyć wszystkie Twoje domeny, które mają certyfikat SSL.

Nie ufaj ślepo kłódce w adresie URL

Podatności SSL obejmują między innymi słabe algorytmy haszujące, wygasłe certyfikaty SSL lub typu wildcard oraz słabe klucze RSA. Korzystając z tych metod, złośliwi hakerzy stale dostosowują swoje techniki obfuskacji. Celem jest aby wykorzystać zaufanie użytkowników do protokołu HTTPS jako zaufanego znacznika wyboru bezpiecznej witryny, przyjmując ten standard dla złośliwych witryn. W rzeczywistości 83% stron phishingowych miało włączone szyfrowanie SSL.

W innym przypadku skrypt acme.sh jest łatwo dostępny, ponieważ jest napisany w powłoce shell i obsługuje więcej dostawców DNS niż inni podobni klienci. Doradca ds. bezpieczeństwa Frans Rosen zdołał wystawić certyfikaty SSL podpisane przez Let’s Encrypt dla każdej domeny hostowanej przez dostawców takich jak AWS CloudFront i Heroku.

Pomimo rygorystycznych procesów weryfikujących wydawanie certyfikatów, wydawanie fałszywych certyfikatów się zdarza. Aby monitorować fałszywe certyfikaty, ustanowiono nowy protokół nazwany Certificate Transparency (CT). Protokół obejmuje publicznie dostępne dzienniki publikujące wszystkie certyfikaty w momencie ich wystawienia. Dzięki temu każdy certyfikat należący do dowolnej domeny można łatwo zweryfikować.

Urzędy certyfikacji (CA) są teraz zmuszone do przesyłania swoich certyfikatów do dzienników CT po tym, jak Google wprowadziło to jako obowiązek. Nadal prowadzony jest szereg dzienników CT, które są używane do monitorowania wydajności i zgodności dzienników. Facebook również uruchomił narzędzie do monitorowania przejrzystości certyfikatów, aby wspierać przejrzystość certyfikatów. CT okazał się szczególnie pomocny w wykrywaniu błędnego wystawiania certyfikatów w przypadku, gdy firma Symantec wydała fałszywy certyfikat dla Google.

Podobnie Microsoft ogłosił swój najnowszy poradnik dotyczący poprawek, który zawierał metody zabezpieczania szyfrowania SSL. Rozszerzył domyślne ustawienia SSL „aby jeszcze bardziej wzmocnić domyślną ochronę Internet Explorera przed sprytnymi napastnikami”. Chociaż te nowe zabezpieczenia zwiększają bezpieczeństwo, jeśli ataki SSL są skierowane na przeglądarki użytkowników, zabezpieczenia SSL będą miały ograniczoną skuteczność w stosunku do atakującego, który już włamał się do twoich systemów.

Dane SSL mogą być czymś więcej niż nieszkodliwym zbiorem danych

Oprócz opisowych nazw domen istnieje wiele sposobów na złamanie protokołu SSL, co może zagrażać twojej firmie. Na przykład atakujący mogą ponownie wykorzystać certyfikaty ze słabym kluczem RSA dla wielu domen. W 2015 r. wersja 3 protokołu SSL stała się przestarzała ze względu na podatność na ataki POODLE i wykrycie krytycznej luki, która umożliwiała złośliwym napastnikom wydobycie tajnych informacji z zaszyfrowanej komunikacji.

Przykładem przydatnych informacji, które można uzyskać z certyfikatów, są alternatywne nazwy podmiotu (SAN). To pole zawiera listę wszystkich domen, które posiadają ważny certyfikat. W ten sposób można połączyć wiele złośliwych domen, które współdzielą certyfikat.

Kolejne czerwone światło to nieprawidłowo podpisane certyfikaty X.509. Zawierają co najmniej jedno naruszenie ograniczeń nałożonych na nie przez RFC 5280. Oznacza to, że główny lub pośredni urząd certyfikacji niepoprawnie podpisał certyfikat. Certyfikaty, które nie spełniają ograniczeń w swoich rozszerzeniach, mogą zostać odrzucone przez niektóre programy. Istnienie takich certyfikatów wskazuje albo na przeoczenie procesu podpisywania, albo na złośliwe zamiary.

Wygasłe certyfikaty SSL

Wygaśnięcie certyfikatów SSL nie może zagwarantować poufności danych swoich użytkowników. Prowadzi to do zwiększonego prawdopodobieństwa udanego fałszowania DNS lub ataków typu Man-in-the-middle na usługi, których dotyczy problem. Chociaż odwołanie SSL jest możliwe w przypadku nazw domen, które zostały naruszone podczas cyberataków lub błędnie wydane przez urzędy certyfikacji. Inną bardziej podstępną formą luk w zabezpieczeniach SSL jest sytuacja, w której same urzędy certyfikacji są narażone na ataki SSL.

Jeśli atakujący zauważy słaby algorytm podpisu lub wygasły certyfikat, może zostać wykorzystany do nasłuchiwania ruchu w witrynie. Może również być wykorzystany do utworzenia innego certyfikatu z tym samym podpisem – umożliwiając atakującemu podszycie się pod usługę, której dotyczy problem. Właściciele domen powinni zwrócić szczególną uwagę, jeśli zauważą nowe certyfikaty wystawiane przez nieznane urzędy certyfikacji. Może to wskazywać na atak lub przejęcie zapomnianej subdomeny.

Słabe algorytmy haszujące

Algorytm haszujący jest używany do dostarczenia certyfikatu z podpisem cyfrowym, aby upewnić się, że jego zawartość nie została zmieniona. Algorytmy haszujące występują w różnych typach, z których niektóre zostały złamane kryptograficznie i podlegają kolizji haszowania; atak, który ułatwiłby generowanie fałszywych certyfikatów. Jeśli takie ataki powiodą się, złośliwy atakujący może podszywać się pod zaufaną usługę. Dzięki temu może mieć dostęp do wszystkich danych przekazywanych między użytkownikiem a tą usługą.

Wszystkie certyfikaty podpisane przy użyciu słabych algorytmów mieszających, takich jak SHA-1 i MD5, są ponownie wystawiane. Mają również obowiązek używania algorytmów mieszających SHA-2. Chodzi o to, że nie powinieneś być w stanie złamać krypto. Więc jeśli potrafisz przejść przez ten rodzaj ataku, wiesz, że poniosłeś porażkę.

SHA-1 był głównym algorytmem od 2011 do 2015 roku. Jednak SHA-1 doświadczył wielu ataków kolizyjnych, co czyni SHA-2 nowym standardem. Jeśli dzisiaj otrzymujesz certyfikat SSL/TLS, musisz używać co najmniej tego standardu.

Czasami można spotkać się z certyfikatami używającymi SHA-2 384-bit. Odmiana 224-bitowa nie jest zatwierdzona do użytku z publicznie zaufanymi certyfikatami, a odmiana 512-bitowa jest mniej powszechnie obsługiwana przez oprogramowanie. SHA-2 prawdopodobnie pozostanie na razie w użyciu. Jednak gdyby został wykryty nieoczekiwany atak na algorytm, skłoniłoby to do wcześniejszego przejścia na wyższy standard.

Długość klucza RSA

Klucze SSL mogą obecnie zostać naruszone bez wiedzy właścicieli certyfikatów SSL. Przyczyną jest to, że większość certyfikatów SSL nie jest unieważnianych, dopóki nie wygaśnie. Oznacza to, że ​​informacje zaszyfrowane przez te certyfikaty mogą pozostać prywatne, nawet jeśli klucze SSL zostaną skradzione.

Istnieją trzy podstawowe sposoby, w jakich klucze SSL mogą zostać złamane:

1. Atakujący włamują się do systemów używanych przez urzędy certyfikacji w celu wydawania certyfikatów SSL
2. Kradzież kluczy SSL, gdzie autoryzowani użytkownicy certyfikatów włączając administratorów witryn i pracowników firm IT mając dostęp do kluczy SSL padną ofiarą kradzieży a więc ich hasła lub klucze zostaną wykradzione.
3. Gdy atakujący wystawia fałszywy certyfikat SSL dla nazwy domeny należącej do innej organizacji bez wiedzy jej właściciela.

Co więcej, certyfikat SSL podpisany przy użyciu klucza RSA mniejszego niż 2048 bitów jest uważany za słaby. Biorąc pod uwagę postęp w mocy obliczeniowej, jest on coraz bardziej podatny na złamanie w rozsądnym czasie. Udany atak tego rodzaju zapewniłby atakującemu dostęp w postaci zwykłego tekstu do zaszyfrowanych danych. Wszystko w trakcie ich przesyłania między klientem a serwerem. W rzeczywistości klucze 2048-bitowe mogą być do przejęcia dopiero za pięć do dziesięciu lat. Narodowy Instytut Standardów i Technologii (NIST) wydał NIST SP 800-57 w maju 2020 r. Głównym wnioskiem jest to, że 2048-bitowe klucze RSA nie są zalecane do użytku po 2030 r.

Aby zapewnić większe bezpieczeństwo kluczy prywatnych, firma Almroth sugeruje, że firmy muszą generować własne klucze prywatne w bezpiecznym i zaufanym środowisku. Najlepiej na serwerze, na którym zostaną wdrożone, lub na urządzeniu zgodnym ze standardem FIPS lub Common Criteria.

Ważne jest, aby śledzić, kto otrzymał dostęp do kluczy prywatnych. Jeśli klucz prywatny został naruszony, unieważnij wszystkie certyfikaty dla tego klucza. Następnie wygeneruj nową parę kluczy i wydaj nowy certyfikat dla nowej pary kluczy. Ponadto odnawiaj certyfikaty tak często, jak to praktycznie możliwe, używając za każdym razem świeżo wygenerowanego klucza prywatnego.

Certyfikat SSL typu Wildcard

Certyfikaty wieloznaczne automatycznie pokrywają wszystkie nazwy hostów w ich domenie. Administratorzy serwerów często tworzą samopodpisane certyfikaty „Wildcard” na żądanie, korzystając z bezpłatnego OpenSSL. Może to być wygodne dla administratorów, ale wiąże się również z ryzykiem poręczenia dla nieuczciwych hostów. W rzeczywistości amerykańska Agencja Bezpieczeństwa Narodowego (NSA) ostrzega przed zagrożeniami wynikającymi z używania certyfikatów o szerokim zakresie do uwierzytelniania wielu serwerów w organizacji. Otwierają one drzwi do włamań typu ALPACA (protokoły warstwy aplikacji pozwalające na atak międzyprotokołowy) w którym osoby atakujące mogą potencjalnie ukraść pliki cookie, prywatne dane użytkownika lub przeprowadzić ataki cross-site scripting. Pomimo sprawdzonych luk w zabezpieczeniach, wspomniane wcześniej badania Detectify Labs wykazały, że około 13% zebranych domen używa tak zwanych certyfikatów wieloznacznych.

Powiedzmy na przykład certyfikat dla *. google . com byłby ważny dla https://YY.google.com/ i https://XX.google.com/ ale nie dla https://google.com/ lub https://my.mail.google.com/. Gwiazdka jest dopasowaniem dla jakiegokolwiek pojedynczego segmentu w nazwie hosta ale nic poza nim. Mowa tu o segmentach oddzielanych znakiem kropki (.). W rezultacie gdyby XX.google.com został zhakowany, zostałby również zhakowany YY.google.com ponieważ certyfikat na XX.google.com był certyfikatem Wildcard dla *.google.pl . Potencjalny złodziej może go użyć do podszywania się pod serwer. Może przechwycić ruch e-mail od innych osób, mimo że serwer nigdy nie został zhakowany.

Używanie certyfikatu typu Wildcard na publicznie dostępnym serwerze sieciowym zwiększa ryzyko. Cyberprzestępcy wykorzystają ten serwer do hostowania złośliwych stron internetowych w kampaniach phishingowych. Aby wyeliminować ten problem, organizacje powinny unikać używania certyfikatów Wildcard w systemach produkcyjnych, zwłaszcza tych dostępnych publicznie. Zamiast tego, Almroth twierdzi, że lepiej jest używać certyfikatów specyficznych dla subdomeny, które są często zmieniane.

Klucz do ograniczania wycieków SSL

Aby chronić się przed zaawansowanym, trwałym złośliwym oprogramowaniem, organizacje muszą identyfikować wszystkie systemy korzystające z SSL/TLS. Muszą również instalować nowe klucze i certyfikaty na serwerach, unieważniać wrażliwe certyfikaty. Muszą też sprawdzać, czy nowe klucze i certyfikaty są zainstalowane i działają.

Ponadto należy upewnić się, że wybrany urząd certyfikacji oferuje takie usługi, jak certyfikaty Extended Validation (EV), masowe/automatyczne wydawanie certyfikatów za pośrednictwem intuicyjnego interfejsu API lub protokołu ACME, łatwe zarządzanie cyklem życia certyfikatu i usługi monitorowania oraz wsparcie dla integracji z obszerną listą rozwiązań firm trzecich.

Mówiliśmy już o przejmowaniu subdomen i tworzeniu scenariusza ataku poprzez zwiększenie liczby ataków. Ciągłe monitorowanie swoich certyfikatów powinno być częścią działań każdej organizacji w celu ochrony ataku z zewnątrz.

Chociaż SSL jest prawie niemożliwy do zhakowania, konieczne jest podjęcie niezbędnych kroków, aby zapewnić żeby Twój certyfikat nie został naruszony, ponieważ jest to kolejny punkt, do którego można uzyskać dostęp. Pamiętaj — nigdy nie polegaj na SSL, aby zadbać o jakiekolwiek aspekty bezpieczeństwa sieci za wyjątkiem tworzenia zaszyfrowanych połączeń.