Włamali się do Adobe i podpisywali złośliwy kod jego certyfikatem

Możliwość podpisywania złośliwego kodu zaufanym certyfikatem znanego dostawcy jest Świętym Graalem wielu internetowych przestępców. Włamanie do serwera Adobe, umożliwiającego podpisywanie kodu, musiało być ich wielkim sukcesem.

Kilka lat temu system Windows wprowadził ograniczenia dla programów, które nie są podpisane zaufanym certyfikatem. Niechętnie takie programy wykonuje, wyświetla różne niepokojące komunikaty użytkownikowi, krótko mówiąc, przeszkadza przestępcom. Również niektóre mechanizmy antywirusowe przypisują dużo większy poziom zaufania plikom opatrzonym prawidłową, zaufaną sygnaturą, znacznie zwiększając możliwość prześliźnięcia się tak spreparowanych plików przez mechanizmy ochronne.

Ze względu na zastosowane mechanizmy kryptograficzne, podrobienie oryginalnego podpisu jest bardzo trudne (choć, jak pokazali autorzy wirusa Flame, nie jest całkiem niemożliwe). W związku z tym przestępcy próbują ukraść oryginalny certyfikat (jak w przypadku wirusa Stuxnet) lub dostać się do serwerów, umożliwiających podpisywanie kodu. Ten ostatni scenariusz miał miejsce kilka miesięcy temu w Adobe.

Wczoraj Adobe ogłosiło, że odkryło włamanie, które miało miejsce w… lipcu 2012. I nie odkryło go dzięki analizie swojej infrastruktury, lecz dopiero po otrzymaniu próbek złośliwego kodu, podpisanego prawidłowym certyfikatem przez przestępców.

Jak doszło do włamania

Analiza powłamaniowa wykazała, że przestępcy najpierw uzyskali przyczółek w infrastrukturze Adobe (prawdopodobnie dostęp do komputera jednego z pracowników), który następnie wykorzystali do przejęcia kontroli nad jednym z serwerów odpowiadających za kompilację i tworzenie finalnej wersji jednej z aplikacji. Jak twierdzi Adobe, serwer ten nie spełniał zwyczajowych wymogów bezpieczeństwa, jednak problem ten nie został nigdy zidentyfikowany. Włamywacze, po uzyskaniu dostępu do serwera, wykorzystali go do zażądania podpisów cyfrowych dwóch aplikacji swojego autorstwa.

Jaka była skala włamania?

Adobe twierdzi, że klucze prywatne, niezbędne do podpisywania kodu, przechowywane są w sprzętowym module kryptograficznym i ich bezpieczeństwo nie zostało naruszone. Infrastruktura odpowiedzialna za podpisywanie kodu przyjmowała żądania podpisu jedynie od zaufanych serwerów w sieci wewnętrznej – to właśnie wykorzystali przestępcy, zdobywając kontrolę nad jedną z zaufanych maszyn.

Adobe zapewnia, że maszyna przejęta przez włamywaczy nie miała dostępu do kodu źródłowego żadnego kluczowego oprogramowania firmy, w szczególności nie był zagrożony kod źródłowy Adobe Readera, Flash Playera, Shockwave Playera oraz Adobe AIR. Według dostępnych informacji serwer miał dostęp jedynie do kodu Adobe Muse, aplikacji Adobe Story AIR  oraz usług desktopowych Acrobat.com.

Jaki kod został podpisany?

Analiza dwóch próbek kodu podpisanego przez przestępców wykazała, że jedna próbka była standardowym narzędziem PwDump7, służącym do wyciągania hashy haseł w systemach Windows (podpisane były oba pliki niezbędne do prawidłowego działania tego narzędzia, libeay32.dll oraz PwDump7.exe). Drugi plik o nazwie myGeeksmail.dll okazał się być filtrem ISAPI, jednak jego przeznaczenie nie jest znane. Zwykle filtry te służą do modyfikowania zachowania serwera IIS w oparciu o zdefiniowane kryteria ruchu przychodzącego, zatem mogły służyć np. do przeprowadzenia ataków typu MiTM. Co istotne, w jednym z największych repozytoriów złośliwego kodu, prowadzonym przez F-Secure, nie znaleziono innych niż wyżej opisane próbek kodu podpisanego tym samym certyfikatem. Oznacza to, że możliwość podpisania kodu była prawdopodobnie wykorzystana jedynie w bardzo ściśle ukierunkowanym ataku. Więcej informacji o podpisanych plikach można znaleźć w biuletynie bezpieczeństwa Adobe.

Co zrobiło Adobe?

Oczywiście natychmiast po wykryciu zagrożenia Adobe wyłączyło fragment infrastruktury opanowany przez włamywaczy. Przeprowadziło również śledztwo, dzięki czemu poznało prawdopodobny mechanizm włamania. Certyfikat wykorzystany przez przestępców zostanie odwołany 4 października, by umożliwić wszystkim użytkownikom aplikacji legalnie nim podpisanych aktualizację do nowszej wersji. Adobe opracowało także bardzo szczegółowy komunikat dotyczący wszystkich aspektów tego niefortunnego incydentu oraz wskazówki dotyczące konieczności aktualizacji poszczególnych produktów.