Pierwszy potwierdzony atak na Adobe Readera omijający sandbox

Adobe ponad dwa lata temu wprowadziło nowy mechanizm bezpieczeństwa do swojego popularnego czytnika PDF-ów – sandboxing. Okazał się on całkiem skuteczny – dopiero kilka dni temu potwierdzono istnienie ataku, który potrafi go ominąć.

Sandboxing (czyli umieszczenie w piaskownicy) to oddzielenie części systemu, w której uruchamiany jest potencjalnie niebezpieczny kod, od części zaufanej. Z tej metody zabezpieczania systemu operacyjnego przed błędami przeglądarek lub ich wtyczek korzysta między innymi Acrobat Reader, Java, Silverlight czy Chrome. O ile zabezpieczenia Chroma czy Javy były już wielokrotnie przełamywane, o tyle sandbox Acrobat Readera do tej pory dzielnie stawiał czoła włamywaczom. Co prawda kilka miesięcy temu opisywaliśmy plotki mówiące o istnieniu exploita, potrafiącego wyjść z „piaskownicy” (oraz kontrowersje związane z jego autorstwem), jednak jego prawdziwość nigdy nie została potwierdzona przez niezależne źródła.

Ciekawe odkrycie

12 lutego firma FireEye ogłosiła odkrycie nowego błędu typu 0day w Adobe Readerze (szybko potwierdzonego przez Adobe), wykorzystywanego w rzeczywistych atakach. Co prawda nie podała od razu szczegółów, ukrywając je do czasu wypuszczenia przez Adobe aktualizacji, jednak temat wzbudził duże zainteresowanie innych badaczy i szybko pojawiło się sporo informacji na temat nowego zagrożenia. Błąd okazał się dotykać wiele wersji Adobe Readera, zarówno na platformie Windows, jak i OS X oraz Linux.

Niewinna aplikacja wizowa

W zidentyfikowanej fali ataków exploit rozsyłany był pod postacią pliku PDF, udającego turecką aplikację wizową (Visaform Turkey.pdf, MD5 f3b9663a01a73c5eca9d6b2a0519049e). W serwisie VirusTotal był po raz pierwszy sprawdzany 11go lutego, z kolei czasy kompilacji poszczególnych elementów, wykorzystywanych w trakcie infekcji, wahają się między 24 stycznia a 4 lutego 2013. Data utworzenia samego PDFa wskazuje na 8 listopada 2012. Po próbie otwarcia dokumentu pojawia się komunikat o treści „Adobe Reader could not allocate enough memory. Please close some applications and try again. The error code is 21.”, podczas kiedy w tle tworzona jest złośliwa biblioteka dll, przechodząca na pewien czas w stan uśpienia, po czym instalująca właściwy program.

Wygląd złośliwego pliku (źródło: Sophos)

Włoski autor kodu?

W kodzie źródłowym znajduje się między innymi informacja, które wersje Readera były celem ataku: 10.0.1.434, 10.1.0.534, 10.1.2.45, 10.1.3.23, 10.1.4.38, 10.1.4.38ARA, 10.1.5.33, 11.0.0.379, 11.0.1.36, 9.5.0.270, 9.5.2.0, 9.5.3.305. Co ciekawe, kod zawiera sporo słów pochodzących w języka włoskiego, pisanych w charakterystyczny sposób (dIAVOLO”, “bENEDETTO”, “sENTIRSI”, “aPPARENZA”, “fISAMENTE”, “pRESUNSI”, “cOCOLLE”, “sCHIUMA”, “pENITENZA”). Dobór nazw zmiennych sugeruje także, że autor kodu czytał – lub przynajmniej znał – twórczość Dantego Alighieri. Dla odmiany hiszpańska domena serwera C&C (http://bolsilloner.es) umieszczona była na irlandzkim serwerze.

To nie była robota amatorów

Złośliwy kod używa wielu zaawansowanych technik. Oprócz sztuczek aktywnie utrudniających inżynierię wsteczną kodu lub wykonanie w środowisku wirtualnym, szyfruje komunikację z serwerem algorytmem AES, korzystając z kryptografii klucza publicznego RSA, a dzięki technice return oriented programming omija zabezpieczenia DEP oraz ASLR. Potrafi także infekować zarówno systemy 32 jak i 64-bitowe, a shellcode każdorazowo dobiera w zależności od wersji atakowanego oprogramowania. Co ciekawe, adres serwera C&C był na stałe zdefiniowany w kodzie programu – najwyraźniej jego autorzy nie chcieli implementować mechanizmu aktualizacji adresu C&C, by ewentualny odkrywca egzemplarza złośliwego kodu nie mógł ustalić adresów kolejnych serwerów sterujących używanych w następnych falach ataków.

Co robić?

Adobe pracuje nad aktualizacją kodu, tymczasem użytkownicy muszą korzystać z różnych sposobów obejścia problemu. Poniżej prezentujemy trzy możliwe opcje – alternatywne oprogramowanie, dodatkowe opcje bezpieczeństwa w Adobe Readerze oraz narzędzie, blokujące próby ataku.

Metoda 1: Alternatywne oprogramowanie

Adobe Reader to najpopularniejszy czytnik dokumentów PDF, zatem też jest najczęściej atakowany. Na rynku istnieje wiele alternatyw – im mniej popularne, tym większa szansa, że błędy w nich odkryte nie będą używane do masowych ataków na użytkowników. Możliwe alternatywy dla Adobe Readera to na przykład Foxit, Sumarta, Nitro lub czytnik wbudowany w przeglądarkę Chrome.

Metoda 2: Tryb chroniony

Użytkownicy Adobe Readera XI mogą włączyć dodatkową ochronę, aktywując opcję „Protected View” (Edit -> Preferences -> Security (Enhanced) -> All files).

Tryb chroniony Adobe Readera

Opcja ta nie jest domyślnie włączona, ponieważ poważnie ogranicza funkcjonalność czytnika – jednak z drugiej strony blokuje również zagrożenia takie, jak opisywany powyżej exploit. Co ważne, opcji tej nie posiadają dostępne wersje Adobe Readera dla platform OS X oraz Linux. Użytkownicy Maków mogą wrócić do wbudowanej przeglądarki, a użytkownicy Linuxa skorzystać z jednej z dostępnych alternatyw.

Metoda 3: EMET lekiem na całe zło

Dla użytkowników systemów z rodziny Windows prostym rozwiązaniem może być uruchomienie EMET-a, darmowego narzędzia od Microsoftu, potrafiącego blokować ataki typu return-oriented programming. Ważne przy tym, by korzystać z wersji 3.5, ponieważ wcześniejsze wydania posiadają mniej mechanizmów ochronnych. Poniższy zrzut ekranu dowodzi, że EMET 3.5 potrafi zapobiec opisywanemu powyżej zagrożeniu.

EMET w akcji

Dla wnikliwych

Wszystkim zainteresowanym szczegółami technicznymi polecamy dwa artykuły – FireEye, McAfee oraz Erica Romanga. Zapewne możemy się spodziewać kolejnych analiz w najbliższych dniach.