Krytyczna podatność w Windowsach. Można podrabiać podpis cyfrowy (w tym certyfikaty SSL/TLS)

[Grandalf]

Zaczęło się od

Zaloguj lub Zarejestruj się aby zobaczyć!

(CVE-2020-0601), mówiących o błędzie w microsoftowym

Zaloguj lub Zarejestruj się aby zobaczyć!

:

the vulnerability in question resides in a Windows component known as

Zaloguj lub Zarejestruj się aby zobaczyć!

, a Windows module that Microsoft says handles “certificate and cryptographic messaging functions in the CryptoAPI.

W tym samym poście możemy też poczytać, że podatność zgłosiło amerykańskie NSA i dotyczy ona Windowsów 10 oraz 2016 Servera. W końcu i Microsoft

Zaloguj lub Zarejestruj się aby zobaczyć!

potwierdzając że możliwe jest ominięcie podpisu binarek – tj. atakujący może tak przygotować złośliwą binarkę aby wyglądała że jest poprawnie podpisana przez zaufanego dostawcę (prawdopodobnie dowolnego):

An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider.

Co więcej, możliwe jest zastosowanie tego samego

Zaloguj lub Zarejestruj się aby zobaczyć!

do przygotowania „lewych” (choć wyglądających na podpisane przez zaufane CA) certyfikatów SSL/TLS (a przynajmniej pewnych z nich):

By exploiting this vulnerability, an attacker may be able to spoof a valid X.509 certificate chain on a vulnerable Windows system. This may allow various actions including, but not limited to, interception and modification of TLS-encrypted communications or spoofing an

Zaloguj lub Zarejestruj się aby zobaczyć!

signature.

​

Intrygujące jest to, że podatność

Zaloguj lub Zarejestruj się aby zobaczyć!

(pokazanych jest też tutaj kilka innych ciekawych scenariuszy ataku). Podatne są Windowsy 10 / Windows 2016/2019 Server. Łatajcie się jak najszybciej.

źródło:

Zaloguj lub Zarejestruj się aby zobaczyć!

 

[Grandalf]

Zaloguj lub Zarejestruj się aby zobaczyć!

 

[spamtrash]

pokazal...

na niezalatanym systemie poprawnie skonfigurowany Kaspersky wali po oczach ze nie jest to zaufany cert.

 

[Skasowany użytkownik 6404]

Rzadko się zdarza, że od ogłoszenia

Zaloguj lub Zarejestruj się aby zobaczyć!

do opublikowania

Zaloguj lub Zarejestruj się aby zobaczyć!

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
Trudno dostępne szczegóły

Microsoft w swoim

Zaloguj lub Zarejestruj się aby zobaczyć!

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

Zaloguj lub Zarejestruj się aby zobaczyć!

, które identyfikują źródło problemu w pliku crypt32.dll (

Zaloguj lub Zarejestruj się aby zobaczyć!

) i jego realizowanej w nim obsługi funkcji WinAPI

Zaloguj lub Zarejestruj się aby zobaczyć!

. 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.

Windows zawiera wiele zaufanych certyfikatów. Zarówno na poziomie komputera, jak i użytkownika

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

Zaloguj lub Zarejestruj się aby zobaczyć!

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ą).

Analiza zagrożenia

Yolan Romailler z firmy Kudelski Security

Zaloguj lub Zarejestruj się aby zobaczyć!

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.

Krzywa eliptyczna używana w ECDSA (via Desmos)

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.

Algorytm fałszowania zaufania

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.

Aktualizacje są ważne

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,

Zaloguj lub Zarejestruj się aby zobaczyć!

. 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.

Zrodlo: dobreprogramy.pl

Zaloguj lub Zarejestruj się aby zobaczyć!

 

[Grandalf]

Analiza możliwości wykorzystania podatności w CryptoAPI

Zaloguj lub Zarejestruj się aby zobaczyć!

 

[Grandalf]

Zaloguj lub Zarejestruj się aby zobaczyć!