O tym, że dokumenty PDF mogą zawierać złośliwy kod wiemy nie od dziś. W przeciągu ostatnich kilku lat na pewno spotkaliście się z informacjami, że wykryto podatność w dokumentach PDF polegającą na wywołaniu z nich zewnętrznego kodu/skryptu (np. poprzez funkcje Javascript) i innych (link). Cyberprzestępcy wykorzystując takie podatności zaczęli masowo wysyłać mailingi z fałszywymi fakturami lub dokumentami w plikach PDF. Spowodowało to, że w firmach, a nawet wśród normalnych użytkowników zaczął panować strach przed otwieraniem takich typów dokumentów (w szczególności maili). W konsekwencji zaczęto jeszcze bardziej uważać na otwierane załączniki, w szczególności, jeśli wiadomość e-mail zawiera załącznik w postaci pliku z rozszerzeniem „zip”/”rar”. Oczywiście po tych incydentach z PDF firmy Adobe i Foxit załatały główne problemy w swoich aplikacjach. Jak to zwykle bywa w ramach rozwoju technologii i badań powstały kolejne pomysły na wykorzystanie luk w PDF do złych celów. W firmach zaczęto implementować zaawansowane systemy brzegowe analizujące załączniki i ich kod oraz blokujące je przed dotarciem do użytkowników końcowych. Obecnie PDF stał się ponownie tematem nowego ataku.
Do napisania tego artykułu skłoniła nas niedawna informacja o ciekawej luce bezpieczeństwa (podatności) w PDF odkrytej przez firmę CheckPoint w maju 2018r. a w szczególności, jak się okazało, jej dalszych (nienaprawionych) przez ponad pół roku losach.
Postanowiliśmy wspólnie z firmą APPEAL sprawdzić w środowisku jak problem wygląda w rzeczywistości. Wykonaliśmy scenariusze ataku wykorzystujący tą podatność i sprawdziliśmy oczywiście systemy zabezpieczeń. Dzielimy się tym z Wami i ostrzegamy przed niebezpieczeństwem. Zapraszamy zatem do lektury.
Na czym polega nowa luka bezpieczeństwa w dokumentach PDF?
W maju 2018r analitycy bezpieczeństwa z firmy CheckPoint odkryli, że możliwe jest wykorzystanie obiektów słownikowych pliku PDF w celu osadzenia w nim ścieżki UNC (ścieżki odwołującej się do zasobu/pliku na sieci np. na jakimś komputerze). Podobnie jak w przypadku innych podobnych ataków, gdy użytkownik otworzy plik, próba autoryzacji do tej ścieżki nastąpi w tle z aktualnymi danymi uwierzytelniającymi użytkownika. Osoba atakująca, która monitoruje ruch, może przechwycić wartość hasha NTLM (zakodowane hasło użytkownika).
Pracownicy CheckPoint, którzy odkryli lukę/podatność udowodnili, że dotyczy ona zarówno aplikacji Adobe oraz Foxit – najpopularniejszych aplikacji do tworzenia i podglądu dokumentów PDF!!!
Co to dla nas oznacza?
Luka w zabezpieczeniach PDF (opisana pod kodem CVE-2018-4993, jest błędem, który może spowodować wyciek poświadczeń z protokołu usługi uwierzytelniania Windows NT LAN Manager (NTLM). Wyciek danych odbywa się bez żadnej interakcji z użytkownikiem, co oznacza, że przy otwieraniu dokumentu PDF nawet nie jesteśmy świadomi, że jego poświadczenia (login i hash NTLMv2 hasła) oraz informacja o domenie są wysyłane dalej do sieci i to niekoniecznie do właściwego serwera. Przy czym poświadczenia te mogą zostać ujawnione, wówczas, gdy atakujący prześle specjalnie spreparowany plik PDF do ofiary.
W świecie firm i „korpo”, gdzie format dokumentów PDF używany jest „na potęgę” oznacza to tyle, że cyberprzestępcy rozsyłając albo publikując jeden dokument PDF w sieci będą mogli pobrać zakodowane w NTLMv2 hasła wszystkich użytkowników, którzy go otworzą! Oczywiście nie wpadajmy w paranoję, ale informacja o danej podatności na pewno pozwoli nam się przygotować i opracować procedurę ochrony.
Poniższy ekran przedstawia sekcję, która zawiera wymagane wpisy dodane do PDF (fragment kodu pobrany ze strony internetowej CheckPoint w celu wyjaśnienia problemu).
Wywołanie dokumentu (dummy_file) z zewnętrznej lokalizacji (ścieżki UNC) atakującego (adres IP serwera atakującego – attacker_smb_server) zaszyte w funkcji w dokumencie PDF.
Jako dowód koncepcji tego ataku, nijaki użytkownik DeepZec opracował skrypt w języku Python o nazwie Bad-PDF, za pomocą którego można wygenerować złośliwy plik PDF i automatycznie przechwycić hash konta w momencie otwarcia tego pliku PDF przez użytkownika w sieci.
W Internecie istnieje także wersja skryptu Worse-PDF opracowana przez nijakiego 3gstudent pozwalająca na wstrzyknięcie tego złośliwego kodu do istniejącego pliku PDF. Zatem w świecie dokumentów PDF robi się coraz ciekawiej.
Czy mamy do czynienia z prawdziwym atakiem „Zero-day”?
Co prawda Foxit naprawił podatność w wydaniu 9.1, natomiast w przypadku firmy Adobe sytuacja przedstawia się nieco gorzej. W dniu 14 maja 2018r firma ogłosiła, że jej nowe wydanie wersji Adobe Reader’a 2018.011.20040 zawiera łatkę zgłoszonego przez firmę CheckPoint problemu z możliwością kradzieży hashy NTLM użytkowników (szczegóły: CVE-2018-4993). Jak się później okazało załatali tylko jeden z dwóch typów akcji GoTo wykonywanych podczas osadzania zdalnych dokumentów i plików w PDF.
Przypomnijmy, że dwa typy akcji GoTo dostępne w PDF to: GoToR (GoToRemote) oraz GoToE (GoToEmbedded)
Obie są podatne odwołują się do innego dokumentu PDF.
Dopiero na początku listopada 2018r badacze z firmy EdgeSpot odkryli, że Adobe załatało problem połowicznie! Mianowicie poprawiło tylko wywołanie akcji GoToR, a nie GoToE. Na podstawie ich badań nad złośliwymi plikami PDF, które oba zawierały typ akcji GoToE okazało się, że luka nadal występuje.
Po zgłoszeniu tego problemu do firmy Adobe podatność została zidentyfikowany jako nowa pod numerem CVE-2018-15979 i załatana została dopiero 13 listopada 2018r! Szczegóły tutaj.
Oznacza to, że przez pół roku mieliśmy do czynienia z oficjalnie dostępną, niezałataną podatnością (zero-day), która tak naprawdę nie została do końca naprawiona! W przypadku Adobe Reader’a , czyli najpopularniejszej aplikacji do odczytu PDF’ów, oznacza to tyle, że jeśli na komputerach w firmie nie zaktualizowaliśmy Reader’a do wersji przynajmniej 2018.011.20040 (załatwienie problemu w wywołaniem akcji GoToR), a najlepiej do wersji 2019.008.20081 (gdzie problem według Adobe jest całkowicie wyeliminowany) możemy być nadal podatni na możliwość wycieku naszego hasła.
Przy okazji tego problemu nasuwa się pytanie: Po co aktualizować PDF? Przecież to tylko aplikacja do odczytu PDF! A jednak, dużo może.
Co w trawie piszczy? Czyli jak wygląda problem w rzeczywistości.
Pokusiliśmy się o stworzenie i sprawdzenie scenariusza, w którym zasymulowaliśmy atak przy użyciu zainfekowanego złym kodem dokumentu PDF oraz różnych wersji narzędzia Adobe Reader (podatnego i zabezpieczonego). Na końcu przedstawiliśmy wyniki.
1.
W pierwszym kroku postanowiliśmy wykorzystać skrypt w języku Python – Bad-PDF, w którym utworzyliśmy zainfekowany plik PDF w celu kradzieży hashy NTLM. Metoda w naszym scenariuszu jest w stanie pobrać hash-e użytkownika (NTLMv1 / NTLMv2) z komputerów Windows, wykorzystując lukę w zabezpieczeniach pliku PDF. Bad-Pdf odczytuje hashe NTLM za pomocą detektora Responder wbudowanego w nasz system KALI Linux.
W celu utworzenia dokumentu musieliśmy podać adres IP, gdzie znajduje się Responder (nasz serwer Kali), nazwę wynikowego pliku PDF oraz interfejs sieciowy, przez który będziemy nasłuchiwać uwierzytelnień użytkownika w momencie otwarcia pliku PDF.
2.
Kopiujemy utworzony plik „faktura.pdf” na stację Windows 10 lub przesyłamy mailem. Na stacji Windows jest zainstalowana wersja Adobe Reader 2018.011.2032. Próba uruchomienia pliku „faktura.pdf” i wynik po stronie naszego serwera nasłuchującego pokazuje poniższy ekran:
Użytkownik Appeal\OfiaraPDF i jego NTLMv2 hash został przechwycony przez nasz serwer.
Po stronie aplikacji Adobe użytkownik nie jest informowany, że w tle PDF coś się dzieje. Nie otrzymuje nawet żadnych powiadomień ani komunikatów od aplikacji. Jedyny komunikat jaki się pojawia, to w chwili zamykania PDF – aplikacja pyta się, czy chcemy zapisać zmiany w PDF.
Widzimy tutaj duża podatność.
3.
Dodatkowo przeskanowaliśmy na VirusTotal nasz plik „faktura.pdf”, aby sprawdzić przez ile silników bezpieczeństwa jest on wykrywany. Wynik całkiem, całkiem, bo 16/60.
Na powyższym ekranie widać jak niektóre skanery prawidłowo rozpoznają podatność w pliku „faktura.pdf” z podaniem kodu CVE.
4.
W kolejnym kroku testu zaktualizowaliśmy naszą aplikację Adobe Acrobat do najnowszej (na chwilę obecną) wersji, czyli 2019.008.20081. Wersja ta zgodnie z informacją na stronie Adobe powinna posiadać rozwiązanie problemu. Wynik otwarcia pliku „faktura.pdf”:
Ku naszemu zdziwieniu tym razem na ekranie monitora pojawia się komunikat bezpieczeństwa Adobe z potwierdzeniem lub blokadą próby komunikacji z adresem „\\192.168.1.20\test”, czyli naszego serwera nasłuchującego. Swoją drogą ciekawi nas, czy użytkownicy będą w stanie go zrozumieć i nie klikać „Allow” 🙂
Z ciekawości klikamy przycisk „Allow” i sprawdzamy po stronie naszego serwera nasłuchującego, czy i tym razem otrzymamy hash użytkownika.
Jak widać i w tym przypadku hash hasła dotarł do serwera nasłuchującego. Responder pominął jedynie ponowne przechwycenie tego samego hash’a.
5.
Dalsze kroki to już tylko dekodowanie plików logów Responder’a zawierających hash’e haseł użytkowników i mamy wszystkie loginy oraz hasła użytkowników. Można to wykonać w bardzo łatwy sposób, ale nie jest to przedmiotem naszego scenariusza. Pamiętajmy jednak, im bardziej skomplikowane hasła użytkownika, tym trudniej będzie je zdekodować przez tego typu oprogramowanie. O tym jakie słabe hasła potrafią być w organizacjach pisaliśmy tutaj, a dekodowaniu haseł z wykradniętych hash’y tutaj.
Jak sobie radzić z problemem?
Przede wszystkim powinniśmy jak najszybciej zaktualizować wszystkie wersje oprogramowania Adobe Reader w firmie do ostatniej wersji z 13 listopada 2018: link
Inne wskazówki bezpieczeństwa to:
- Wyłączenie zewnętrznego dostępu do usługi SMB na zaporze sieciowej w celu zapobiegnięcia przedostawania się hashy NTLM do Internetu
- Microsoft wydał opcjonalne rozszerzenie zabezpieczeń(link) pod koniec ubiegłego roku, które zapewnia klientom możliwość wyłączenia uwierzytelniania NTLM SSO jako metody dla zasobów publicznych. W przypadku zastosowania tej metody nie poprawi ona luki dotyczącej oprogramowania Adobe Acrobat DC i Adobe Acrobat Reader DC, tylko zabezpieczy mechanizm uwierzytelniania.
- Monitorowanie procesu Adobe Readera i jego komunikacji z Internetem.
- Skanowanie plików przez rozwiązania do bezpieczeństwa brzegowego i antywirusy.
- Monitorowanie użycia kont użytkowników w Active Directory (logowania). Wszelkie próby logowania z nietypowych adresów lub jednoczesne zalogowania na to samo konto z wielu komputerów powinny być osobno analizowana. Nigdy nie mamy pewności, że ktoś inny nie przechwycił naszego hasła w ten (opisywany tutaj), czy inny sposób.
- Przydatne byłoby także zastosowanie systemów do wykrywania w sieci nietypowej aktywności z końcówek. System wykorzystujący sztuczną inteligencję miałby tutaj również zastosowanie w kontekście wykrycia nietypowych dotychczas połączeń ze stacji do Internetu.
- Uświadomić użytkowników, aby nie klikali i akceptowali dziwnych komunikatów po otwarciu takiego PDF np. „Pozwól”, „Allow” itp.
- Analiza słabych haseł użytkowników w firmie – pisaliśmy o tym tutaj
Podsumowanie
Jak się okazuje w dokumentach PDF możemy umieszczać instrukcje, które skonstruowane w odpowiedni sposób i przy użyciu technik pozyskiwania informacji w sieci są łatwym kąskiem dla cyberprzestępców w kontekście kradzieży haseł. Aktualizacja aplikacji Adobe nie rozwiązuje do końca problemów, ponieważ nadal daje użytkownikowi możliwość decydowania o tym, czy PDF ma się połączyć z zewnętrznym źródłem. Zabezpieczenie mechanizmów uwierzytelniania Microsoft wydaje się być skutecznym sposobem na ograniczenie tego typu ataku, ale musicie go najpierw dokładnie przetestować w konkretnej architekturze Waszych sieci.
Bez budowania odpowiedniej świadomości bezpieczeństwa wśród użytkowników w firmie i odpowiedniej konfiguracji systemów bezpieczeństwa będziemy nadal narażeni na sukcesy działań cyberataków wskazanych w tym artykule. Zalecamy do cyklicznych przeglądów infrastruktury oraz do zabezpieczenia środowiska Active Directory przed niepowołanym dostępem.