Błąd w CryptoAPI może przekonać niedowiarków do aktualizacji Windows

Rzadko się zdarza, że od ogłoszenia podatności do opublikowania działających i powtarzalnych eksploitów upływa tak niewiele czasu. Gdy aktualizacje łatają znane i opublikowane podatności, złośliwe narzędzia są dostępne przed stosownymi łatkami. Gdy jednak podatność jest nowa, hakerzy potrzebują trochę czasu na zgłębienie zagadnienia i opracowania dowodu na wykorzystanie słabości.

Microsoft w swoim pozornie fachowym portalu MSRC tradycyjnie udziela bardzo ogólnych informacji na temat łatanych dziur. W większości przypadków są to te same frazy przeklejane już od niemal dwóch dekad. Notatki CVE przydzielone do nich również nie zawierają zbyt wiele szczegółów. A ponieważ dziś aktualizacje Windows są serwowane w wielkich paczkach, trudno je badać różnicowo.

Na szczęście więcej szczegółów o wtorkowej dziurze CVE-2020-0601 udziela CERT i NSA, które identyfikują źródło problemu w pliku crypt32.dll (Microsoft Crypto API) i jego realizowanej w nim obsługi funkcji WinAPI CertGetCertificateChain(). Eksport ten sprawdza, czy ścieżka certyfikacji w pliku certyfikatu jest prawidłowa. Łańcuch zaufania w plikach PFX polega na tym, że Główny Urząd Certyfikacji (Root CA) nie musi podpisywać wszystkich certyfikatów samodzielnie. Może podpisać certyfikaty urzędom niższego rzędu i wszystkie certyfikaty wydawane przez takie urzędy będą zaufane na prawach tych podpisanych przez urząd główny.

Dzięki temu, Root CA jest używany okazjonalnie, do mianowania (i odwoływania!) urzędów pobocznych. Wrogie przejęcie urzędu kończy się obowiązkowym unieważnieniem jego autoryzacji i wszystkich wystawionych kluczy (to przytrafiło się firmie Symantec). Z kolei przejęcie Root CA lub skuteczna metoda podszycia się pod niego... oznacza załamanie jedynego działającego sposobu na poświadczanie cyfrowej tożsamości. Jest to innymi słowy "koniec świata". CertGetCertificateChain() wydaje się być skory do zbyt łatwego stwierdzania poprawności certyfikatów, jeżeli są one stworzone za pomocą ECC (kryptografia oparta o krzywą eliptyczną).

Yolan Romailler z firmy Kudelski Security wykonał kawał wymagającej roboty aby zidentyfikować, zrozumieć i opisać problem. Według jego sprawozdania, CryptoAPI nie sprawdza wszystkich pól certyfikatu podczas porównywania go z wzorcem. W certyfikatach ECC możliwe jest zrekonstruowanie klucza prywatnego na bazie klucza publicznego, ale taki klucz prywatny pasuje do publicznego tylko pod określonymi, domyślnie nieznanymi warunkami. To wciąż może być niejasne bez konieczności przedstawiania zaplecza matematycznego.

Upraszczając (i narażając się na ogień krytyki purystów), sprawa wygląda tak: klucz prywatny jest zmienną w równaniu, którego rozwiązaniem jest klucz publiczny. Nie znając równania, nie znamy klucza prywatnego. Podstawiając jednak inną zmienną pod owy klucz prywatny, klucz publiczny dalej może być prawidłowy. Taki scenariusz to kolizja. Podstawiając jednak w pełni własny klucz prywatny, nie otrzymamy (bez kolizji) wyniku w postaci pasującego klucza publicznego, jeżeli nie pogmeramy w samym równaniu.

To jest właśnie źródło problemu w CryptoAPI: algorytm powinien sprawdzić klucz publiczny, wziąć równanie i otrzymać pasujący wzorzec, dowodzący, że w jego obliczaniu brał udział zaufany klucz prywatny. Zamiast tego jednak bierze klucz oraz akceptuje całą klasę równań. Dzięki temu liczba akeptowalnych rozwiązań, dowodzących rzekomo, że użyto właściwego klucza prywatnego – rośnie. Tylko jedno jest prawdziwe, reszta natomiast pozwala fałszować tożsamość.

Prawidłowe API kryptograficzne, np. OpenSSL, bardzo prędko zorientuje się, że coś jest nie tak. Zgłosi problem, informując użytkownika "no super, że odpowiedź przy zadanym wejściu się zgadza, szkoda tylko, że rozwiązujesz inne równanie!". Certyfikaty to nie tylko cyferki. Zamiast sprawdzać wyłącznie zgodność odcisków, należy sprawdzić także zastosowany generator, a więc (w uproszczeniu) upewnić się, że rozwiązuje się to samo zagadnienie matematyczne. Romailler przytacza więcej szczegółów związanych z faktoryzacją i wyliczaniem klucza w algorytmie eliptycznym.

Poza detalami matematycznymi, oferowane jest również rozwiązanie, tworzące "fałszywy" certyfikat:

Odnaleźć certyfikat policzony metodą ECC, wystawiony za pomocą urzędu, któremu Windows domyślnie ufa (każdy system ma listę takich urzędów, w przeciwnym razie nie ufałby nikomu) Wyciągnąć klucz publiczny z certyfikatu (jest to perfekcyjnie wykonalne i normalne, klucz publiczny jest publiczny, używa się go do potwierdzania autentyczności treści podpisanych tajnym, prywatnym) Stworzyć klucz prywatny z fałszywymi wartościami równania podanymi na sztywno (generator) Stworzyć urząd certyfikacji, w którym dopuszczalnej jest stosowanie autorskiego generatora (openssl przyjmie wszystko, nawet idiotyzmy) Stworzyć własny certyfikat Podpisać stworzony certyfikat z użyciem podstawionego urzędu

Powyższa procedura pozwala wystawić własny certyfikat, na dowolną domenę i posiadany przez dowolną instytucję, podpisany jakimś urzędem, a Windows będzie twierdzić, że to certyfikat podpisany przez urząd prawdziwie zaufany.

Warto tutaj przytoczyć mądrości wygłaszane przez przeciwników aktualizowania Windows, twierdzących że łatane podatności są rzadkie, a przed niebezpieczeństwem uchroni antywirus, na co dowodem mają być czyste wyniki skanów antywirusowych. Tu nie ma wirusa. Tu nie ma włamania. Żadnego podrzuconego EXE, żadnego zdalnego wykonania kodu.

Wystarczy połączyć się z źle chronionym publicznym Wi-Fi z zatrutym DNS. Logowanie do poczty zgłosi, że certyfikat jest zaufany, więc wszystko jest w porządku. Szkoda, że jego wystawcą nie będzie Wirtualna Polska albo Google, ale np. Adolf Hitler lub Sułtan Kosmitów, zatrudnieni w firmie Wyższa Szkoła Robienia Hałasu. Argument "mam komputer stacjonarny i nie wychodzę z domu" nie jest tutaj poprawną metodą negowania zagrożenia, ponieważ to tylko przykład pierwszy z brzegu. Możliwości wykorzystania luk w kryptografii jest znacznie, znacznie więcej.

Naturalnie, świat nie płonie. Co prawda początkowo oczekiwano, że wykorzystanie podatności 2020-0601 będzie znacznie trudniejsze, ale załatane systemy, poinstruowane hostingi i nowe przeglądarki internetowe powinny zmitygować najbardziej oczywiste ataki. Swoją drogą, zagrożony jest tylko Windows 10. Wcześniejsze wersje Windows po prostu w ogóle nie obsługiwały sparametryzowanych certyfikatów ECC i nie rozumiały takich plików. Windows 7 jest więc bezpieczny pod tym względem, bo jest za stary żeby działać z nowoczesną kryptografią. Podobnie jak Windows 95.