W zamierzchłych czasach pojawiły się pierwsze informacje o malware, który był cyfrowo podpisany. Zdziwienie związane z tym faktem skomentowałem we wpisie Kapcie z nóg... czyli po co podpisywać programy. Pisałem wówczas, że podpisy cyfrowe określają źródło pochodzenia aplikacji oraz potwierdzają integralność aplikacji. Teraz, po trzech latach, warto te stwierdzenia nieco zrewidować.
Skąd pochodzi podpisany kod
W 2009 roku Didier Stevens udowodnił rzecz oczywistą - korzystając z kolizji w funkcji MD5 możliwe jest wygenerowanie "wrogiej" aplikacji, której podpis będzie taki sam, jak aplikacji "niewinnej". Można na ten temat przeczytać we wpisie Playing With Authenticode and MD5 Collisions. Oznacza to tyle, że programom podpisanym z użyciem MD5 ufać nie można do końca. Nie można mieć pewności co do źródła ich pochodzenia oraz ich integralności.
To, że coś jest technicznie możliwe wcale nie znaczy, że będzie wykorzystywane. Może okazać się, że są inne, łatwiejsze, sposoby osiągnięcia tego samego celu. Wpis Corporate Identity Theft Used to Obtain Code Signing Certificate opisuje przypadek, gdy wykorzystana została jedna z innych metod - kradzież tożsamości. Co ciekawe ofiarą ataku padła firma, która nie zajmowała się produkcją oprogramowania. Zastanawiam się, czy kradzież tożsamości dokonana była właśnie w celu wystawienia certyfikatu, czy raczej najpierw miała miejsce kradzież tożsamości, a wystawienie certyfikatu to tylko jeden ze sposobów jej wykorzystania. Warto też pamiętać, że nie jest to pierwszy przypadek, gdy certyfikaty zostały wystawione nieupoważnionym osobom. Przykład: Update Available to Revoke Fraudulent Microsoft Certificates Issued by VeriSign. W tym przypadku również mogło chodzić o podpisywanie (wrogich) programów (patrz: MS01-017), a całe zdarzenie miało miejsce w 2001 roku.
Podpisany był również kod użyty w ataku wykorzystującym błąd w przetwarzaniu plików *.lnk. Dla przypomnienia cała historia opisana jest między innymi tutaj: Nowy atak na wszystkie Windowsy. W tym wypadku miała miejsce kradzież klucza należącego do firmy Realtek oraz JMicron. Ten drugi był wykorzystywany po unieważnieniu pierwszego certyfikatu.
Powyższe przykłady zmniejszają zaufanie do podpisanego kodu. Nawet jeśli pod względem technicznym wszystko jest OK, wykorzystane są mocne algorytmy, to zawsze zostaje drugi czynnik, ten bardziej ludzki. Certyfikat może zostać wystawiony nieuprawnionym osobom a zdobycie kluczy wykorzystywanych do podpisywania kodu może być (już jest) celem atakujących. Swoją drogą ciekawe, czy pojawią się w przyszłości różne "poziomy zaufania" przy podpisach kodu. Teoretycznie bardziej można ufać podpisowi złożonemu przy użyciu klucza wygenerowanego i przechowywanego w HSM niż z użyciem klucza przechowywanego w postaci "zwykłego" pliku. W końcu certyfikaty Extended Validation Certificates to nie tylko inne GUI w przeglądarkach, ale również inne procedury w trakcie wystawiania certyfikatu. Mają one zapewnić (zwiększyć prawdopodobieństwo), że osoba dysponująca takim certyfikatem jest rzeczywiście tym, za kogo się podaje.
