10:14
9/12/2013

Podlegający francuskiej agencji do spraw cyberbezpieczeństwa (ANSSI) urząd certyfikacyjny (CA) wygenerował fałszywe certyfikaty dla kilku domen Google. To pozwalało np. podsłuchiwać połączenie z GMailem, o ile połączenie ofiary przechodziło przez urządzenia na których wykorzystano ten certyfikat.

Kto i po co podrabia certyfikaty Google?

Google w swoim oświadczeniu ogranicza się do skąpego w detale komunikatu, że fałszywy certyfikat był wykorzystywany do “inspekcji szyfrowanego ruchu poprzez komercyjne urządzenie działające w prywatnej sieci i za zgodą jej użytkowników“. Z lektury nieocenionego Reddita dowiemy się jednak, że winnym jest tak naprawdę francuskie Ministerstwo Finansów, któremu ANSSI przekazała klucz pośredniego CA (dzięki temu mogli generować “zaufane” certyfikaty dla dowolnych domen).

Zaufane w tym kontekście oznacza, że takie certyfikaty nie wzbudzają żadnego komunikatu z ostrzeżeniem w przeglądarce (cała ścieżka certyfikacji była poprawna i zaufana — tyle tylko, że certyfikat GMaila nie był tym, z którego Google korzysta na codzień).

chrome6skull

ANSSI opublikowała już oświadczenie w tej sprawie, z którego wynika, że… był to “błąd ludzki”:

As a result of a human error which was made during a process aimed at strengthening the overall IT security of the French Ministry of Finance, digital certificates related to third-party domains which do not belong to the French administration have been signed by a certification authority of the DGTrésor (Treasury) which is attached to the IGC/A.
The mistake has had no consequences on the overall network security, either for the French administration or the general public. The aforementioned branch of the IGC/A has been revoked preventively. The reinforcement of the whole IGC/A process is currently under supervision to make sure no incident of this kind will ever happen again.

Jak Google odkryło fałszywy certyfikat?

Przeglądarka Google Chrome wykorzystuje tzw. Certificate Pinning, czyli hardkodowanie fingerprintu klucza w kodzie programu. Oprócz zwyczajnej weryfikacji ścieżki zaufania w ramach PKI, Google Chrome sprawdza także, czy jest to rzeczywiście ten certyfikat, który wykorzystują na swoich serwerach …i zapewne od razu raportuje wykrycie innego klucza do centrali.

Pinning zaimplementowany w Google po ataku na Comodo jest w zasadzie jedyną ochroną przed problemami związanymi z zaufaniem w infrastrukturze CA/PKI — ale Google przecież nie będzie zaszywał w kodzie ID wszystkich serwisów na świecie działających po HTTPS – robi to dla kilku największych (tu lista), dzięki czemu może np. wykrywać podsłuchiwanie Facebooka w Syrii, czy trwające prawie 2 miesiące rozszyfrowywanie ruchu do 500+ serwisów w Iranie, kiedy to na skutek włamania do DigiNotar wygenerowano tak ciekawe certyfikaty jak pasujące do domen *.*.com

Jak ty możesz się chronić przed podstawieniem fałszywego certyfikatu?

W zasadzie pierwszym krokiem, powinno być usunięcie z systemowego (i przeglądarkowego) magazynu root CA, tych certyfikatów, którym nie ufasz (firmy dokonują “inspekcji”, czyli tak naprawdę podsłuchu połączeń swoich pracowników poprzez wstrzyknięcie własnego CA do magazynów certyfikatów na stacjach roboczych).

Niestety, przeglądanie magazynu pod kątem niezaufanych certyfikatów nie jest wcale takie proste — nazwy i powiązania są zbyt enigmatyczne dla przeciętnego Kowalskiego, a dodatkowo, nie zawsze można usunąć root CA z urządzenia, nawet jeśli należy do organizacji wojskowej innego kraju. Nie mówiąc już o tym, że usunięty certyfikat pewnie wróci po aktualizacji programu…

Podejrzany certyfikat w iOS

Podejrzany certyfikat w iOS

Użytkownicy Firefoksa mogą jednak skorzystać z rozszerzenia Certificate Patrol, które zapamiętuje fingerprinty certyfikatów SSL na odwiedzanych przez nas stronach i ostrzega, jeśli zmienią się przy kolejnej wizycie. Godny uwagi w tym kontekście jest również Convergence oraz Perspectives-project jak i projekt Google o nazwie Certificate Transparency.

Jeśli jesteś developerem aplikacji mobilnej, warto zahardkodować fingerprint certyfikatu w swojej aplikacji — w zasadzie tylko to gwarantuje, że połączenie nie będzie dało się podsłuchać. Urządzenia mobilne (a raczej niektóre biblioteki kryptograficzne przez nie wykorzystywane) mają to do siebie, że często nie pokazują użytkownikom komunikatów błędów związanych z certyfikatami SSL — po cichu je akceptując.

PKI jest zepsute, to nie pierwszy problem tego typu

Warto nadmienić, że fałszywe certyfikaty są przede wszystkim generowane w wyniku włamań do infrastruktury zaufanych urzędów certyfikacyjnych. Tak było w przypadku Comodo, potem izraelskiego StartSSL-a i DigiNotar.

W przypadku wpadki francuskiego Ministerstwa Finansów zagrożenia dla globalnego internetu raczej nie było. Nie zmienia to jednak faktu, że ten incydent kolejny raz pokazuje, jak niedopracowanym, pod kątem bezpieczeństwa, jest współcześnie wykorzystywany model PKI.

Przeczytaj także:

11 komentarzy

Dodaj komentarz
  1. Pewnie chcieli podsłuchiwać pracowników przez MiTM.

    W jednej z firm, w której pracowałem, też taka “pomyłka” się trafiła: nagle ni z tego ni z owego – bez żadnego ostrzeżenia, obwieszczenia, czy bez podpisywania nowych regulaminów – wszystkie strony HTTPS serwowane poprzez firmowy proxy zaczęły przedstawiać się certyfikatami podpisanymi przez wewnętrzny Root CA tejże firmy, wstrzyknięty do windowsowego zbioru zaufanych certyfikatów przez system do zdalnego zarządzania. Po jakichś dwóch tygodniach wszystko wróciło do normy. Nie było żadnego oficjalnego komunikatu na ten temat.

    Może faktycznie komuś się palec omsknął przy zmianach w konfiguracji proxy, może jakieś nieporozumienie na linii kierownictwo – technicy, może “balon próbny”, a może próba złapania jakiegoś “szpiega” – kto tam wie…

    • Certificate Pinning w Chromie powinien to wykryć.

    • Pewnie by wykrył, ja wykryłem w inny sposób.

  2. Mam wyp… wszystkie certyfikaty z Chromium? Przeciez nie ma “Certificate Patrol” na Chroma :((.

  3. Jest chyba w HTTPS Everywhere, i Google stosuje certificate pinning.

    Tez promuja http://www.certificate-transparency.org/ dzieki czemu kazdy bedzie mogl sobie skryptedm zrobic certificate patrol :)

  4. Jedyną możliwością bezpiecznej wymiany kluczy fizycznych instytucji jest wybranie się tam fizycznie po klucz publiczny. Mniej bezpiecznie, ale jednak może być dostawa na cd pocztą. Ewentualnie można sobie wyobrazić też, że powstają lokalne w miastach urzędy certyfikatów (organizacje prywatne), do których się fizycznie udajemy i wtedy to oni jeżdżą po świecie zbierając certyfikaty. Aktualizacja certyfikatów mogłaby się już w wielu przypadkach odbywać online.
    Nie widzę innej możliwości. Projekt convergence ma jedną, dużą wadę: nie wiadomo jak w bezpieczny sposób pobrać listę zaufanych certyfikatów…

  5. A czy te dodatki nie inwigiluja nas aby za mocno?
    Bede sie czepial jednego i instalowaj jakis syf?

    To lepiej zapisac sobie na kartce fingerprint banku i za kazdym razem weryfikowac powiedzmy 4 pierwsze cyfry i kolejny bank np. czwarta grupa po 4

  6. Mój pracodawca jakiś czas temu zmienił własne proxy na takie utrzymywane przez zewnętrzną firmę. Podczas korzystania przez IE nie widać różnicy (może poza innym wygladem komunikatów o blokadzie strony). Kiedy jednak odpaliłem sobie Operę z pendriva, zaczęły się sypać ostrzeżenia o niezaufanym certyfikacie podczas otwierania każdej strony https – wystawcą za każdym razem była firma administrująca naszym proxy. Oczywiście nikt nikogo o tym nie informował -podejrzewam że informacja jest zaszyta w jakimś enigmatycznym punkcie regulaminu, który akceptuje się podczas pierwszej autoryzacji na proxy.

    Zastanawia mnie, czy da się jakoś obejść taką podmianę certyfikatu, czy jedynym wyjściem jest nie używanie firmowego łącza do zaszyfrowanych stron.

    • Musiałbyś puszczać cały ruch przez zaszyfrowany tunel z jakąś lokalizacją, której ufasz np. komputer w domu. Tunel pewnie musiałby symulować ruch HTTP, żeby przejść przez proxy.

    • “Mój pracodawca jakiś czas temu zmienił własne proxy na takie utrzymywane przez zewnętrzną firmę. ” – napisze wprost: Twoj pracodawca jest skonczonym durniem.

  7. […] Musicie bowiem wiedzieć, że przeglądarka Google Chrome, z racji wbudowanego w swój kod źródłowy (czyli niemożliwego do wyłączenia) mechanizmu o nazwie HTTPS Certificate Pinning, skutecznie uniemożliwia podstawienie fałszywego certyfikatu HTTPS pod kilka kluczowych domen (m.in. Facebooka i GMaila) — po prostu nie otworzy strony, która przedstawia się innym niż zahardcodowany certyfikat, wyświetlając przy tym duże czerwone ostrzeżenie użytkownikowi. […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.