Certyfikaty HTTPS stanowią jeden z filarów bezpieczeństwa w internecie, jednak nie są jego gwarancją. Pisaliśmy już, że w pewnych sytuacjach system ten nie zapewnia bezpieczeństwa użytkownikom. Teraz omówimy, co może niemiło zaskoczyć właścicieli stron internetowych.
Dwa aktualne certyfikaty dla tej samej domeny
Rejestracja domeny i certyfikat HTTPS są często kontrolowane przez różne organizacje, zatem okresy ważności dla domen i certyfikatów niekoniecznie będą się pokrywały. Prowadzi to do sytuacji, w której poprzedni i bieżący właściciele równocześnie dysponują aktualnymi certyfikatami dla tej samej domeny.
Czym grozi taka sytuacja i jak często problem ten występuje w prawdziwym życiu? Podczas konferencji DEF CON 26 badacze Ian Foster i Dylan Ayrey zaprezentowali swoje wnioski dotyczące tego problemu. Według nich sprawa jest znacznie bardziej skomplikowana, niż wydaje się na pierwszy rzut oka — i jest to zaskakująco częsty problem.
Najbardziej oczywistym zagrożeniem wynikającym z sytuacji, gdy ktoś inny dysponuje aktualnym certyfikatem do Twojej domeny, jest atak Man-in-the-Middle na użytkowników danej strony internetowej.
Foster i Ayrey użyli bazy certyfikatów projektu Certificate Transparency i zidentyfikowali 1,5 miliona sytuacji, w których różne osoby posiadały różne osoby — co stanowi odsetek niemal 0,5% wszystkich stron w internecie. W jednej czwartej tych przypadków starszy certyfikat jest nadal aktualny, co oznacza, że 375 tysięcy domen jest podatna na atak Man-in-the-Middle.
Jednak to nie wszystko. Dosyć powszechną praktyką jest tworzenie jednego certyfikatu dla kilkudziesięciu, a nawet setek domen. Na przykład Foster i Ayrey znaleźli certyfikat obejmujący 700 domen, i — jak twierdzą badacze — na jego liście znajdują się różne, bardzo popularne domeny.
Niektóre z tych 700 domen są na sprzedaż. Każda osoba może zarejestrować jedną z nich i uzyskać dla niej certyfikat HTTPS. Pozostaje pytanie, czy nowy właściciel domeny ma prawo unieważnić poprzedni certyfikat w celu ochrony swojej strony przed atakiem typu Man-in-the-Middle?
Czy można unieważnić certyfikat?
Tak, certyfikat może zostać unieważniony. Centra certyfikacji umożliwiają podjęcie takich kroków, jeśli dowolna informacja wyświetlana w certyfikacie jest niepoprawna lub wprowadza w błąd. Takie cofnięcie jest realizowane w ciągu 24 godzin otrzymania stosownego powiadomienia.
Foster i Ayrey przyjrzeli się, jak to się odbywa w rzeczywistości. Okazało się, że procedura ta znacznie się różni dla różnych centrów certyfikacji. I tak organizacja Let’s Encrypt stosuje zautomatyzowane narzędzie, które pomaga w bardzo krótkim czasie cofnąć certyfikat — dzieje się to prawie natychmiast. W innych centrach certyfikacji należy skontaktować się z odpowiednią osobą, więc nie odbywa się to tak szybko. Czasami unieważnienie certyfikatu wymaga poczekania znacznie dłużej niż wspomniane 24 godziny; a w najgorszych przypadkach może to być nawet niemożliwe. Na przykład korespondencja między badaczami a Comodo zakończyła się sugestią ze strony tej firmy, aby zapomnieli o tym certyfikacie SSL i zamówili nowy.
Tak czy inaczej, w znacznej większości przypadków certyfikat rezydualny zostanie cofnięty. Z jednej strony nowy właściciel domeny będzie mógł zabezpieczyć się przed atakiem Man-in-the-Middle, który wykorzystuje lukę związaną z posiadaniem certyfikatu rezydualnego. Jednak z drugiej strony oznacza to, że inna osoba może zakupić dowolną domenę, która podlega „współdzielonemu” certyfikatowi, i cofnąć go, co negatywnie wpłynie na korzystanie z pozostałych stron, które są z nim skojarzone.
Czy ten problem jest powszechny? Tak w jeszcze większym stopniu niż poprzedni: swoje certyfikaty z innymi domenami, których rejestracja już wygasła, współdzieli aż 7 milionów domen — czyli ponad 2% internetu! 41% poprzednich certyfikatów nadal jest aktualne. Wobec tego w tej chwili kilka milionów domen jest podatnych na atak DoS, w którym wykorzystywana jest możliwość unieważnienia certyfikatu.
Wróćmy jednak do wspomnianego certyfikatu dla 700 domen. Aby pokazać, jak pilny jest ten problem, badacze zakupili jedną z trzech domen, które obejmuje ten certyfikat. Teraz teoretycznie mogą przeprowadzić atak DoS na setki aktywnych stron.
Jak się zabezpieczyć
W sumie na ataki MitM podatnych jest 375 000 domen, a kilka dodatkowych milionów — na ataki DoS przy użyciu certyfikatów rezydualnych. Jak wiadomo, na tej liście mogą znajdować się również Twoje domeny. Raport został zaprezentowany na największej konferencji poświęconej lukom w cyberbezpieczeństwie, więc z pewnością ktoś już szuka dziurawych domen. W jaki sposób właściciele domen mogą się zabezpieczyć przed tym zagrożeniem? Foster i Ayrey sugerują zastosowanie się do kilku porad:
- Używaj nagłówka Expect-CT HTTP z dyrektywą „enforce”, aby mieć pewność, że dla Twojej domeny zaufane są tylko te certyfikaty, które znajdują się w bazie Certificate Transparency.
- Sprawdź w bazie Certificate Transparency, czy Twoje domeny mają aktualne certyfikaty wydane dla poprzednich właścicieli. Możesz tego dokonać poprzez narzędzie Facebooka o nazwie Certificate Transparency Monitoring. Aby uprościć to zadanie, badacze zaoferowali własne narzędzie, którego może użyć każdy do wyszukiwania domen narażonych na opisane tu luki.
Z naszej strony możemy dodać kilka innych porad:
- Przejrzyj wszystkie firmowe strony internetowe pod kątem ewentualnych certyfikatów rezydualnych dla Twoich domen. Jeśli któreś zaniepokoją Cię, skontaktuj się z centrum certyfikacji i poproś o unieważnienie ich.
- Nie pobieraj jednego certyfikatu dla wielu domen, zwłaszcza jeśli w Twojej firmie tworzy się wiele stron i powiązanych domen, ale nie monitoruje się ich działania. Jeśli rejestracja dla takiej „porzuconej” domeny wygaśnie i ktoś ją przejmie, osoba ta będzie musiała jedynie unieważnić taki certyfikat, aby zakłócić działanie Twoich pozostałych stron.
- Rozważ zawczasu sytuację zhakowania certyfikatu. Wówczas będzie trzeba szybko go unieważnić, a jak wynika z badania, niektóre centra certyfikacji reagują dosyć powoli — być może dobrym pomysłem jest więc związanie się z tymi, które działają sprawniej.