Kryptografia jest trudna, a jej implementacja jeszcze bardziej skomplikowana, gdyż nawet subtelne błędy mogą skutkować bardzo poważnymi konsekwencjami. Nawet Microsoftowi zdarza się robić bardzo poważne w skutkach błędy.
Wraz ze styczniową paczką aktualizacji (Microsoft Patch Tuesday) Microsoft poza krytycznymi podatnościami opublikował jedną, która skupiła zainteresowanie badaczy na całym świecie. Błąd w bibliotece kryptograficznej crypt32.dll pozwala na dosyć swobodne sfałszowanie certyfikatu, tak by został uznany przez system Windows (i programy wykorzystujące błędną bibliotekę) za zaufany. Podstawową przyczyną tej usterki jest wadliwa implementacja kryptografii krzywej eliptycznej (Elliptic Curve Cryptography – ECC) w kodzie Microsoftu. Firma opublikowała aktualizację zabezpieczeń systemu Windows, która poprawia ten błąd. Luka została odkryta przez amerykańską Agencję Bezpieczeństwa Narodowego (NSA), która opublikowała oficjalne ostrzeżenie i poradnik, jak poradzić sobie z zagrożeniem.
Gdzie leży problem
Skrócony opis działania kryptografii opartej o krzywe eliptyczne (ECC) w przystępny sposób opisuje Tal Be’ery.
ECC opiera się na różnych parametrach. Parametry te są znormalizowane dla wielu krzywych. Jednak dotychczasowa implementacja w bibliotece kryptograficznej Microsoftu nie sprawdzała wszystkich parametrów. Parametr G (generator) nie był kontrolowany, w związku z czym atakujący mógł dostarczyć swój własny generator. W takim wypadku system, próbując zweryfikować certyfikat względem zaufanego urzędu certyfikacji, poszukiwał tylko pasujących kluczy publicznych, a następnie i tak używał generatora z certyfikatu. MicrosoftECCProductRootCertificateAuthority.cer jest domyślnie zaufanym głównym urzędem certyfikacji (CA) korzystającym z ECC w systemie Windows 10. Wszystko zatwierdzone przy użyciu tego certyfikatu staje się zatem automatycznie zaufane.
Powierzchnia zagrożenia
Błąd w bibliotece kryptograficznej dotyczy tylko wersji systemu operacyjnego Windows 10. W jego początkowej wersji (kompilacja 1507, TH1) Microsoft dodał obsługę parametrów ECC konfigurujących krzywe eliptyczne. Wcześniej system Windows obsługiwał tylko nazwane krzywe ECC. To właśnie ta zmiana kodu, która dodała obsługę parametrów ECC, spowodowała lukę w sprawdzaniu poprawności certyfikatu. Podatność nie jest regresyjna (nie dotyczy wcześniejszych wersji oprogramowania) i nie wpłynęła na wersje systemu Windows, które nie obsługują parametrów ECC konfigurujących krzywe.
Lista wersji systemu operacyjnego zawierające „dziurawą” bibliotekę:
- Windows 10 for 32-bit Systems
- Windows 10 for x64-based Systems
- Windows 10 Version 1607 for 32-bit Systems
- Windows 10 Version 1607 for x64-based Systems
- Windows 10 Version 1709 for 32-bit Systems
- Windows 10 Version 1709 for ARM64-based Systems
- Windows 10 Version 1709 for x64-based Systems
- Windows 10 Version 1803 for 32-bit Systems
- Windows 10 Version 1803 for ARM64-based Systems
- Windows 10 Version 1803 for x64-based Systems
- Windows 10 Version 1809 for 32-bit Systems
- Windows 10 Version 1809 for ARM64-based Systems
- Windows 10 Version 1809 for x64-based Systems
- Windows 10 Version 1903 for 32-bit Systems
- Windows 10 Version 1903 for ARM64-based Systems
- Windows 10 Version 1903 for x64-based Systems
- Windows 10 Version 1909 for 32-bit Systems
- Windows 10 Version 1909 for ARM64-based Systems
- Windows 10 Version 1909 for x64-based Systems
- Windows Server 2016
- Windows Server 2016 (Server Core installation)
- Windows Server 2019
- Windows Server 2019 (Server Core installation)
- Windows Server, version 1803 (Server Core Installation)
- Windows Server, version 1903 (Server Core installation)
- Windows Server, version 1909 (Server Core installation)
Przypadki użycia
Istotą problemu w odkrytej podatności jest to, iż możliwe jest podpisanie certyfikatu z dowolną nazwą domeny i nazwami alternatywnymi, który zostanie rozpoznany przez CryptoAPI systemu Windows jako certyfikat zaufany. W takiej sytuacji powstaje kilka możliwych scenariuszy do wykorzystania, które mogą doprowadzić do kompromitacji systemu operacyjnego lub ujawnienia poufnych danych.
- Podpisanie certyfikatu SSL dla serwisu WWW
Możliwe jest umieszczenie certyfikatu (uznanego za zaufany) na stronie WWW podszywającej się pod oryginalną stronę (np. bank, urząd czy system pocztowy) i w ten sposób przeprowadzenie ataku Man-in-the-Middle (MitM). W zbliżonym scenariuszu możliwe jest wykorzystanie serwisu jako tzw. „wodopój”, by infekować ofiary. Tu certyfikat ma uwiarygodnić przed ofiarą oryginalność serwisu. - Podpisanie fałszywym certyfikatem oprogramowania
Podpisując złośliwy kod oprogramowania zaufanym certyfikatem, atakujący jest w stanie ominąć kilka elementów ochrony przed infekcją. Zwiększa prawdopodobieństwo uruchomienia samego programu, gdyż bardzo często na stacjach komputerowych można uruchamiać tylko podpisane cyfrowo oprogramowanie. Zmniejsza także szanse wykrycia złośliwego oprogramowania przez rozwiązania antymalware’owe i antywirusowe. Tu sztuczka polega na sposobie oceny oprogramowania przez silniki decyzyjne rozwiązań antywirusowych, które o złośliwości badanej próbki rozstrzygają na podstawie wielu czynników („zachowania w systemie”, komunikacji sieciowej, utylizacji zasobów komputera itp.). W tym wypadku sprawdzany jest również podpis cyfrowy. Jeżeli program jest podpisany zaufanym certyfikatem, to program uznawany jest za nieszkodliwy i jego ocena przesuwa się w kierunku legalnych.
Łącząc scenariusz pierwszy z drugim, można szybko zauważyć, że ta jedna podatność, mimo iż nie jest klasy RCE (Remote Execution Code, umożliwiającej zdalne wykonanie złośliwego kodu na komputerze ofiary), pozwala na dostarczenie i uruchomienie złośliwego oprogramowania.
Wykrywanie i mechanizmy ochronne
Oficjalnie Microsoft przyznaje, iż w systemie nie ma dodatkowych mechanizmów ochronnych ani obejść problemu pozwalających ograniczyć wykorzystanie podatności.
Microsoft wprowadził funkcję publikowania w dzienniku zdarzeń wpisu po wykryciu próby wykorzystania znanej podatności. Gdy w aplikacji działającej w trybie użytkownika dojdzie do takiej próby, zostanie wywołana funkcja CveEventWrite. Podobno poprawka dla CVE-2020–0601 to pierwszy kod wywołujący ten interfejs API.
Dla systemów z zainstalowaną ostatnią aktualizacją, gdy wykryta zostanie próba wykorzystania znanej luki, system generuje zdarzenie o identyfikatorze 1 w dzienniku zdarzeń systemu Windows – po każdym ponownym uruchomieniu..
Poniższe jednolinijkowe polecenie w PowerShell (tzw. oneliner) pozwala szybko sprawdzić w dzienniku, czy istnieje jakieś zdarzenie związane z CVE-2020-0601:
Get-WinEvent -FilterHashtable @{ LogName ='Application'; Id = 1; ProviderName = 'Microsoft-Windows-Audit-CVE' } | select -Prop
W oparciu o powyższy wpis do dziennika zdarzeń wielu dostawców rozwiązań bezpieczeństwa przeprowadza detekcję prób wykorzystania tej podatności. Trzeba mieć świadomość, że nie wykrywa się w ten sposób ataków na niezaktualizowane systemy.
By w rzeczywistości wykryć atak wykorzystujący tę lukę – niezależnie od tego, czy system ofiary jest podatny czy zaktualizowany – konieczna jest analiza używanych certyfikatów. Te z nich, które zawierają jawnie zdefiniowane parametry krzywej eliptycznej, które tylko częściowo pasują do krzywej standardowej, są podejrzane. Na tym można oprzeć detekcję prób wykorzystania omawianej luki. Ten sposób detekcji (wraz z kodami skryptów) opisuje analiza portalu Zeek. Kod wykorzystujący ten błąd wymaga certyfikatu zawierającego wyraźnie zdefiniowaną krzywą. Ponadto używane krzywe są manipulowane przez złośliwy program, co oznacza, że nie znajdują się na liście standardowych krzywych. Jeżeli parametry krzywej (generator, kolejność i inne) podano bezpośrednio w certyfikacie, oznacza to próbę wykorzystania opisywanej podatności.
źródło: https://blog.zeek.org/2020/01/detecting-cve-2020-0601-with-zeek.html
Poniżej jeden z przykładów reguły snort wykrywającej ten atak:
alert tcp any any -> any any (msg: "ATTACK [PTsecurity] Suspicious explicitly-defined ECC parameters. Possible CVE-2020-0601 crafted certificate"; flow:established; content:"|06 07 2a 86 48 ce 3d 02 01 30 82|"; content:"|06 07 2a 86 48 ce 3d 01 01 02|"; within:200; reference: cve, 2020-0601; reference: url, github.com/ollypwn/cve-2020-0601; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; classtype: trojan-activity; sid: 10005695; rev: 1;)
Potwierdzenie koncepcji (PoC)
Podatność szybko zyskała zainteresowanie badaczy, którzy pokazali przykłady kodów wykorzystujących podatność (PoC, Proof-of-Concept). Szybko można było przeanalizować sposób przygotowania certyfikatu, który podszywał się pod zaufany w Windows certyfikat Root CA MicrosoftECCProductRootCertificateAuthority. Potem ten certyfikat mógł już służyć do podpisywania innych certyfikatów oraz podpisywania kodu. Kolejny przykład pokazywał, jak utworzyć certyfikat dla swojej strony, by wyglądał jak certyfikat github.com.
Natomiast jedną z lepszych analiz problemu wraz z przykładem użycia, kodami i serwisem weryfikującym opracowała firma analityczna Kudelski Security.
Mając już takie całkiem niewinne, ale potwierdzające łatwość wykorzystania, kody programów (tzw. PoC), można oczekiwać ofensywy poważnego złośliwego oprogramowania. Obecnie w różnych portalach analitycznych (tj. VirusTotal, JoeSandbox) pojawiają się próbki malware’u podpisane tak przygotowanymi certyfikatami (próbka związana z pierwszym PoC). Istnieje nawet możliwość znalezienia znanej dotychczas próbki, tj. ransomware’u WannaCry, podpisanej „zaufanym” certyfikatem – brzmi groźnie.
Rekomendacje
Najważniejszym zaleceniem jest jak najszybsze zainstalowanie wszystkich poprawek z biuletynu Microsoftu ze stycznia 2020 roku. W przypadku dużych organizacji, gdzie automatyczne aktualizacje w całym przedsiębiorstwie nie są możliwe, zaleca się nadanie wysokich priorytetów (aktualizacje w pierwszej kolejności) komputerom pracowników oraz systemom realizującym krytyczne usługi.
Zalecana priorytetyzacja
- Urządzenia sieciowe, serwery lub serwery proxy z systemem Windows, które wykonują sprawdzanie poprawności TLS.
- Komputery obsługujące infrastrukturę krytyczną (np. kontrolery domeny, serwery DNS, serwery aktualizacji, serwery VPN, IPSec).
- Priorytet należy również nadać dla aktualizacji komputerów pracowników (uwzględniając sposób wykorzystania tych komputerów i idące za tym wysokie ryzyka):
- komputery bezpośrednio eksponowane na ataki z internetu,
- komputery regularnie używane przez uprzywilejowanych użytkowników.
Analiza zagrożenia
| Rodzaj zagrożenia | Podatność |
| Numer | CVE-202-0601 |
| Oprogramowanie | Windows CryptoAPI (Crypt32.dll) |
| CVSS v.3 | 8.1 (HIGH) |
| CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N | |
| Powierzchnia |
Windows 10 Windows Server 2016 Windows Server 2019 |
| Łatwość wykorzystania | Tak |
| PoC – istnieje? | Tak |
| PoC – publiczny? | Tak |
| Eksploit – istnieje? | Tak |
| Eksploit – publiczny? | Tak |
| Malware – istnieje? | Tak |
| Malware – w użyciu? | Tak (in the wild) |
| Znane kampanie | Nie |
Powyższa tabela, przy tradycyjnej analizie zagrożenia, wypełnia wszystkie wymagania nakazujące aktualizować w trybie natychmiastowym.
Podsumowanie
Pewną ironią sytuacji jest fakt, iż podatność nie dotyczy systemu Windows 7, który w dniu ogłoszenia tej niezwykłej luki zakończył swój cykl życia i wsparcia. W ten sposób użytkownicy posiadający niewspierany i nierozwijany system mogą czuć się nieco bezpieczniejsi (przynajmniej w perspektywie wykorzystania tej podatności), niż użytkownicy systemu Windows 10, którzy jeszcze nie przeprowadzili aktualizacji.
Jak zauważają badacze z Kudelski Security, luka nie może być wykorzystana do przeprowadzenia aktualizacji systemu Windows z fałszywego repozytorium. Aktualizacje Windows są podpisywane przy użyciu certyfikatów RSA (zamiast certyfikatów ECC), a ich łańcuch certyfikatów RSA jest przypięty do pliku binarnego Windows Update. Oznacza to, że aktualizacje Windows nie są w tym przypadku narażone na ataki typu Man-in-the-Middle.
Przygotowanie fałszywego certyfikatu jest bardzo proste, jednak przeprowadzenie skutecznego ataku na dużą skalę już takie nie jest. Sama podatność umożliwia dostarczenie malware’u do ofiary, ale by atak się powiódł, potrzebny jest taki złośliwy kod, który nie zostanie wykryty przez systemy obronne ofiary, dlatego mówi się, że hakerzy-amatorzy (script kiddies) nie będą w stanie jej wykorzystać. Niemniej podatność ta może być wykorzystywana przez zaawansowane grupy APT (state sponsored), które mają potencjał do uzbrojenia i przeprowadzenia ataku. Możliwe, że to właśnie stało się powodem upublicznienia podatności przez NSA – woleli ochronić wszystkich obywateli (ryzyko jest ogromne, bo i powierzchnia ataku jest ogromna), niż w skrytości korzystać z odkrycia.
Jeżeli chcesz łatwo sprawdzić, czy Twój system jest podatny i możesz paść ofiarą sfałszowanych certyfikatów, możesz to zrobić na stronie firmy badawczej Kudelski Security.
Na koniec nie pozostaje nic innego, jak przypomnieć o obowiązkowej aktualizacji wszystkich eksploatowanych systemów – zanim będzie za późno.
Komentarze
ECC bardzo mnie ciekawią, ale nigdy nie miałem siły i wiedzy przebić się przez model matematyczny i zrozumieć o co w tych krzywych chodzi i dlaczego są takie ważne.
A tu widzę ECC na z3s i myślę – wow! W końcu ktoś wytłumaczy jak chłop krowie na miedzy jak to działa! No i czytam „ECC opiera się na różnych parametrach. Parametry te są znormalizowane dla wielu krzywych.”.
Heh. To tak jakby ktoś opisywał zasadę działania komputera jako „Działanie komputera opiera się na różnych programach. Programy zbudowane są w wielu komputerach na podstawie podobnych składników”.
Czyli jak nic nie powiedzieć ciągle mówiąc.
@Morris: polecam poniższe
– https://youtu.be/dCvB-mhkT0w (Elliptic Curve Cryptography Overview)
– https://youtu.be/NF1pwjL9-DE (Elliptic Curves – Computerphile)
– https://youtu.be/nybVFJVXbww (Elliptic Curve Back Door – Computerphile)
Mnie też bardzo ciekawi kryptografia krzywych eliptycznych. Jednak artykuł nie jest o tym. Artykuł miał pokazać, jak niedopracowana implementacja funkcji kryptograficznej, może skutkować poważnymi konsekwencjami.Ważne było by ująć – jak zweryfikować istnienie podatności, jak ją ograniczać, jakie mogą być scenariusze wykorzystania. Temat jest dosyć rozległy i nie można go wyczerpać w każdym elemencie. Stąd w artykule tak dużo odnośników do materiałów rozszerzających wiedzę, tak by każdy mógł sam podjąć się analizy.
Polecam, ponadto co już zostało podlinkowane:
https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
Warto też dodać że (już parę dobrych lat temu) na WAT powstał narodowy szyfrator oparty o krzywe eliptyczme https://ctt.wat.edu.pl/wp-content/uploads/technologie/bezpieczenstwo/szyfrator-narodowy.pdf
Ale to rozwiązanie zamknięte, którego bezpieczeństwo opiera się na zapewnieniach prof. Gawineckiego i jego zespołu.
Na ECC to w 2005 roku crackmesy były robione.
Dzięki za fajny i wyczerpujący artykuł. Skąd jednak wiadomo o tym, że podatność ta jest wykorzystywana in-the-wild? Próbki na VT widziałem, nie analizowałem żadnej z nich, ale bardziej kojarzyło mi się to z zabawą badaczy w podpisywanie znanych próbek malwaru spoofowanym certem niż z faktycznym tworzeniem złośliwego kodu, który ma komuś zaszkodzić. W Internecie również nie znalazłem informacji popartej jakimiś konkretnymi przykładami, które wskazywałyby, iż jakiś threat actor używa tej podatności.
Analizy wskazują Threat Actor’ów, którzy uzbroili już malware w tę podatność i wyszli z produktem na rynek. Natomiast trzeba mieć na względzie, że podatność ta ułatwia dostarczenie złośliwego oprogramowania, nie zaś samą eksploitację, a sam payload, czy końcowy malware jest niezmieniony.
hej Irq, mógłbyś podać przykłady?
A można wywalic z magazynu zaufanych cert CA MS. Czy jedyna konsekwencja bedzie koniecznosc manualnego potwierdzania wyjatku. Czy mozna by tak postapic selektywnie dla danych zastosowan certyfikatow. Jednym alowem manualnie zarzadzac i sterowac zaufaniem a nie bazowac na domyslnym
Tak się zastanawiam odnośnie tej podatności.
Podatność pozwalała m.in. podpisać stronę internetową fałszywym certyfikatem i Windows potwierdzał taki certyfikat jako poprawny. Oczywiście podatność na pewno w Edge/IE była. O ile pamiętam, równierz chrome korzysta z windowsowego potwierdzania certyfikatu, więc również był podatny. A co z Firefoxem? W nim o ile pamiętam jest własny manager certyfikatów, ale czy całkiem odizolowany od Windowsa? Czy jednak Firefox był w tym wypadku bezpieczny?