Process Herpaderping: postrzelone i wybitnie złośliwe omijanie zabezpieczeń

Pogląd o nieskuteczności oprogramowania antywirusowego, choć trafny, często wywodzi się z nieprawidłowych przesłanek. Istotnie, słabość antywirusów polega na nieuniknionej "nieaktualności" definicji i ograniczeniu mechanizmów maszynowych. Ale istnieje więcej powodów, przez które walka ze złośliwym oprogramowaniem jest nierówna. Wiele wirusów wykorzystuje sztuczki, które wyprowadzają narzędzia ochronne w pole, nawet przy aktualnych definicjach.

Można zakończyć taką dyskusję i posłużyć się jakimś przesadzonym ogólnikiem na temat niskiego bezpieczeństwa i wad projektowych Windows. Ale można też przyznać, że twórcy złośliwego oprogramowania są po prostu biegli w nadużyciach każdego modelu zabezpieczeń i Windows nie jest tu żadnym szczególnie niechlubnym przypadkiem. Stanie się to szczególnie jasne, gdy zrozumie się skalę problemu dzięki przykładom.

Techniką pokazującą, w jak trudnej funkcjonujemy rzeczywistości, jest metoda o skocznej nazwie herpaderping. Polega ona na podmianie zawartości pliku wykonywalnego na dysku po tym, jak został on zmapowany do pamięci, ale niezablokowany przed modyfikacją. Blokada ta wcale nie zachodzi bowiem natychmiast i nie jest całkowita.

Takie opisanie zjawiska sprawia wrażenie, że jest ono proste, ale tak naprawdę powinno ono stanowić jedynie wysoce teoretyczne zagrożenie. Konieczna jest zaawansowana znajomość zależności czasowych i pełna kontrola nad nimi, by zrobić z tego użytek. Niestety, ktoś wpadł już na pomysł, jak to zrobić.

Proces przebiega następująco: zapisujemy plik wykonywalny na dysk, po czym nie zamykamy uchwytu do niego. Otwarty uchwyt oznacza, że system operacyjny pozwala pisać do pliku, bo uznaje że ten "jest gdzieś otwarty". Jednocześnie, otwarty plik można wykonywać. To, że jest otwarty, nie przeszkadza w tym. Dlatego kolejnym krokiem jest wykonanie go.

Potoczne rozumienie zakłada, że w momencie wykonania, plik jest, w całości, "ładowany do pamięci", której menedżer trzyma łapę na jego miejscu na dysku, uniemożliwiając modyfikację. Niestety, pogląd ten jest bardzo odległy od rzeczywistości. "Uruchamianie programu" przebiega wszakże inaczej: uruchomienie nowego procesu to funkcja przyjmująca jako parametr uchwyt do obiektu przechowującego plik jako zmapowany obraz.

Co dokładnie oznacza to przepiękne zdanie? Ano to, że program nie jest po prostu ładowany do pamięci. Sporządzana jest mapa pliku, a system trzyma ją w obiekcie. Następnie ta mapa jest używana jako przepis do stworzenia nowego procesu. Dopiero teraz można "ruszyć" z działaniem procesu, uruchamiając jego główny wątek. Są inne metody uruchamiania procesów, ale nie mają znaczenia w tym konkretnym przypadku.

Można tu wysnuć kilka wniosków. Na przykład: cechą procesu jest obraz, z którego powstał. Przy błędnym założeniu, że EXE ląduje w całości pamięci i jest niezmienne, można uznać, że uruchomiony proces na pewno powstał z tego samego pliku, który właśnie znajduje się na dysku. Tymczasem po zmapowaniu pliku i przygotowaniu procesu dla niego, możliwa jest zmiana jego zawartości, w sposób niezakłócający mapy, ale efektywnie dostarczający inny kod niż ten "z którego uruchomiono proces".

Tak właśnie działa herpaderping. Modyfikuje plik po zmapowaniu, ale przed wykonaniem głównego wątku, korzystając z tego, że system wciąż umożliwia zapis do niego. To wysoce złośliwa sztuczka, podobnie jak tzw. drążenie procesów oraz doppelganging. Wymyślenie jej wymaga zaawansowanej wiedzy, a metoda korzysta z nieprzyzwoicie marginalnych niuansów. Nikt nie zaplanował ochrony przed takim trikiem, bo nie zakładano że znajdzie się ktoś zdolny do tak chorych nadużyć.

Podatność trudno naprawić, ale trudno też wykryć. Systemowe narzędzia do audytowania procesów, w szczegółach Zdarzenia 4688, informują jedynie o ścieżce dostępu do pliku z którego powstał proces. I tyle. Jeżeli coś podmieniło pół EXE-ka w międzyczasie, system nie będzie o tym wiedział. Dopiero od niedawna pakiet Sysmon potrafi wykrywać, że podczas stworzenia procesu nastąpiła podmiana obrazu w sposób odróżniający go od pliku leżącego na dysku.

Microsoft wie o sprawie, ale zadecydował, że wyżej opisane zjawisko nie stanowi zagrożenia o poziomie usprawiedliwiającym prędką poprawkę i/lub inne środki zaradcze. Trudno zresztą o inną odpowiedź w przypadku aż tak niskopoziomowej zmiany. Do jej wprowadzenia potrzebna jest praca najlepszych ludzi. Co ciekawe, przed atakiem chroni oparta o wirtualizację ochrona Defendera (Device Guard), ale jej skonfigurowanie bez spięcia w domenę jest... męczące i częściowo nieosiągalne. Być może wraz ze wzrostem popularnościi zagrożenia, stanie się włączone domyślnie.