Temat z gatunku tych prostszych, natomiast ponieważ czasami coś, co wydaje się oczywiste (pewnej grupie ludzi) wcale takie oczywiste nie jest (dla innej grupy ludzi), postanowiłem o tym napisać. Bezpośrednia motywacja to ostatnia rozmowa ze znajomymi na ten temat.
Odrobinę o mitmowaniu SSL
SSL teoretycznie ma zapewniać bezpieczeństwo przesyłanych danych, przy czym w tym wypadku należy to rozumieć nieco szerzej:
- przesyłane dane są szyfrowane, więc nikt postronny nie powinien wiedzieć co jest przesyłane,
- autentyczność/tożsamość podmiotów biorących udział w komunikacji jest potwierdzona/zweryfikowana,
Początek połączenia SSL to tak zwany SSL Handshake (tu używam zamienne SSL i TLS, choć nie jest to do końca to samo, ale na tym poziomie szczegółowości - wystarczy). W trakcie tej operacji następuje:
- potwierdzenie tożsamości serwera względem klienta,
- opcjonalne potwierdzenie tożsamości klienta wobec serwera (jeśli jest "dwustronny SSL", czyli klient też przestawia się certyfiaktem),
- ustalenie parametrów szyfrowania dalszej części połączenia,
Potwierdzenie tożsamości serwera względem klienta wygląda w ten sposób, że:
- serwer prezentuje klientowi swój certyfikat,
- serwer udowadnia klientowi fakt posiadania klucza prywatnego właściwego dla tego certyfikatu,
Dodatkowo klient sprawdza, czy certyfikat serwera jest prawidłowy, czyli między innymi sprawdza czy:
- certyfikat jest ważny (data ważności od, data ważności do),
- nie został odwołany (listy CRL, OCSP),
- został użyty w prawidłowym zastosowaniu (np. nie można użyć do SSL certyfikatu przeznaczonego wyłącznie do podpisywania maili),
- został wystawiony przez zaufane CA,
Jeśli zaprezentowany przez serwer certyfikat jest prawidłowy, połączenie zostaje nawiązane. Jeśli są jakieś wątpliwości - decyzja czy połączenie powinno być nawiązane jest delegowana na użytkownika (te wszystkie mniej lub bardziej irytujące komunikaty błędów).
Załóżmy teraz, że z jakichś powodów chcemy zaglądać do ruchu SSL. Na przykład:
- przy testach aplikacji chcemy zobaczyć ruch między serwerem i przeglądarką/klientem (np. Fiddler, Burp),
- by chronić istotne/cenne dane przed wyciekiem (wszelakie systemy DLP),
- zrobić ogólne "kuku" (źli panowie w czarnych kapeluszach),
W pierwszym przypadku sprawa jest trywialna. Instalujemy narzędzie (np. Fiddler) i aktywujemy inspekcję SSL. Fiddler generuje wówczas własny certyfikat, który będzie używał jako certyfikat CA, czyli do wystawiania kolejnych certyfikatów. W tej chwili przy próbie nawiązania połączenia z przeglądarki stwierdzi ona, że certyfikat jest nieprawidłowy i wyświetlony zostanie stosowny alert. My oczywiście wiemy dlaczego ten certyfikat jest nieprawidłowy, w końcu z reguły robimy MitM na samych siebie, więc mamy do wyboru - albo mozolnie akceptować kolejne ostrzeżenia od przeglądarki, albo zaufać tym nowym certyfikatom. A najłatwiej to zrobić ufając tylko jednemu certyfikatowi - temu, który Fiddler używa jako certyfikat CA.
Drugi przypadek wygląda często tak, że do naszej sieci wstawiamy huczącą skrzynkę, która robi praktycznie dokładnie to samo, co Fiddler. Korzystając z odpowiedniego certyfikatu generuje "właściwe" certyfikaty dla przechwytywanych połączeń SSL. Cały problem sprowadza się do tego, by klienci ufali tym certyfikatom. I tu sytuacja zwykle może być dość prosta, bo systemy DLP stosuje się często w środowiskach korporacyjnych, w których również stacje użytkowników pozostają pod kontrolą korporacyjnego IT. A to oznacza, że do zaufanych CA może zostać dodany dowolny certyfikat, w tym certyfikat wykorzystywany przez DLP do podpisywania "końcowych" certyfikatów.
Jakby tego było mało niektóre CA są/były tak miłe, że wystawiały certyfikat dla subordinate CA, jeśli zostały wystarczająco ładnie poproszone. Posiadacz takiego certyfikatu w praktyce dysponował własnym CA, za pomocą którego mógł wystawiać własne certyfikaty. Najfajniejsze w tym było oczywiście to, że te certyfikaty były automatycznie zaufane na klientach, zakładając oczywiście, że CA wystawiające taki subordinate CA było zaufane. Gdy sprawa wyszła na jaw, rozpętało się małe piekiełko.
I w zasadzie tutaj już można wprowadzić trzeci przypadek, czyli tych złych czarnokapeluszników, którzy MitM na SSL robią z sobie tylko znanych, ale zapewne ZŁYCH (w sensie evil a nie incorrect) powodów. Im bardzo zależy na tym, by mieć możliwość przechwytywania SSL jak największej ilości użytkowników, bez modyfikacji na stacjach użytkowników oraz oczywiście w taki sposób, by użytkownicy nie zorientowali się, że coś jest nie tak.
Tu na początek jedna uwaga - oczywiście jeśli atakujący może wykonać na stacji ofiary swój kod, może również dodać swój własny certyfikat do zaufanych. Tylko tak po prawdzie, jeśli ten atakujący ma już taki dostęp do stacji, prawdopodobnie nie musi robić MitM, te same cele może osiągnąć w inny sposób. Z tego powodu załóżmy, że atakującym bedzie chodzić o pozyskanie certyfikatu automatycznie zaufanego u klientów bez konieczności wprowadzania jakichkolwiek zmian po stronie klienta.
W tym miejscu dochodzimy do miejsca, w którym wyraźnie widać, że PKI to wspaniały pomysł, który się jednak nie do końca sprawdził. Nie, nie chodzi o matematykę/kryptografię, to raczej działa. Problem jest w całej obudowie i zaufaniu. A bardziej obrazowo - to, że ktoś jest zaufany (trusted) nie znaczy jeszcze, że jest godny zaufania (trustworthly).
Jeśli popatrzymy na listę zaufanych CA w systemie/przeglądarce, to nagle okaże się, że są ich miliony. No dobrze, nie miliony tylko dziesiątki, ale to i tak dużo. Poza tym certyfikaty "końcowe" z reguły nie są wystawiane przez RootCA. RootCA mają pod sobą kilka SubCA, które mogą mieć pod sobą kolejne SubCA, które (...), aż na końcu jedno z tych CA wystawia ten właściwy certyfikat.
Atakujący może między innymi:
- włamać się do RootCA lub SubCA i wystawić dowolny certyfikat (patrz historia DigiNotar),
- wystawić/otrzymać certyfikat dla SubCA bez włamywania się (np. były przypadki omyłkowego wystawienia certyfikatów, które mogły być użyte jako certyfikat CA do wystawiania kolejnych certyfikatów, patrz TURKTRUST),
- wystawić/otrzymać certyfikat dla nazwy domenowej, której w rzeczywistości nie kontrolują (stary dobry social engineering, przykładów było wiele),
Jaki to wszystko ma efekt? Niestety, z faktu, że przeglądarka nie skarży się na certyfikat, który otrzymała wcale jeszcze nie wynika to, że rzeczywiście połączyliśmy się z tym serwerem, z którym chcieliśmy się połączyć. Niestety wciąż może być tak, że ktoś robi nam MitMa.
Rozwiązaniem tego problemu, oczywiście tylko do pewnego stopnia, jest tak zwany certificate pinning. W tym przypadku sprawdzamy, czy aby na pewno certyfikat, który dostaliśmy jest tym, który spodziewaliśmy się dostać. Jest tylko jeden mały problem - skąd mamy wiedzieć jaki certyfikat powinniśmy dostać?
Na zakończenie temat do przemyśleń - dlaczego strony takie jak ta są pozbawione jakiegokolwiek sensu?
Przekonałem się, że czasem wszechmocna indoktrynacja 'magicznej kłódeczki' zewsząd płynąca jest tak silna, że trudno było mi przekonać znajomych, że to bezpieczeństwo wcale nie jest takie proste, jakby się wydawało
https://www.eff.org/observatory