wirtualne patchowanie (virtual patching)

Wirtualne patchowanie (virtual patching) to blokowanie prób wykorzystania znanej podatności w warstwie, która stoi przed aplikacją, bez zmiany samego kodu. OWASP definiuje je jako warstwę egzekwowania polityki bezpieczeństwa, która zapobiega wykorzystaniu znanej podatności i raportuje takie próby ^[1]. Sekurak opisuje wirtualną poprawkę jako mechanizm w warstwie zabezpieczeń, który wykrywa i blokuje złośliwy kod, zanim dotrze on do chronionego zasobu ^[2]. Najczęściej jest to reguła WAF, napisana pod jedną konkretną lukę.

Jak działa

Wirtualna poprawka nie usuwa błędu. Zmienia to, co do błędu dociera. Zapora analizuje żądanie HTTP, rozpoznaje wzorzec charakterystyczny dla danej podatności, na przykład niedozwolony znak w jednym parametrze, i odrzuca żądanie, zanim trafi do aplikacji. Patchstack ujmuje to tak, że kod źródłowy aplikacji pozostaje niezmieniony, a mimo to próba wykorzystania się nie udaje ^[5].

Przykładem jest reguła ModSecurity z artykułu Sekuraka, dotycząca wtyczki WordPressa podatnej na blind SQL injection przez parametr orderby ^[2]. Reguła odrzuca żądania do admin.php, w których ten parametr zawiera przecinek ^[2].

SecRule REQUEST_FILENAME "/admin.php" "phase:2,t:none,t:normalisePath,t:lowercase,t:urlDecodeUni,chain,deny,log,id:1001"
SecRule ARGS_GET:orderby "," "t:urlDecode"

Przebieg zablokowanej próby pokazuje schemat poniżej.

RYS. 1Wirtualna poprawka w zaporze

OWASP wyróżnia dwa modele reguł ^[1]. Różnią się tym, co jest opisane wprost.

Etapy procesu

OWASP opisuje wirtualne patchowanie jako proces złożony z sześciu etapów: przygotowania, identyfikacji, analizy, utworzenia poprawki, wdrożenia z testami oraz etapu odzyskiwania i dalszych działań ^[1]. Sekurak, opierając się na zasadach OWASP, wymienia tę samą szóstkę, z monitorowaniem jako ostatnim krokiem ^[2].

RYS. 2Sześć etapów wirtualnego patchowania według OWASP

Etap testów jest ważny, bo zbyt szeroka reguła blokuje zwykłych użytkowników. Taki fałszywy alarm (false positive) bywa równie kosztowny jak przepuszczony atak.

Kiedy się stosuje

OWASP wymienia powody, dla których podatnego kodu nie da się poprawić od razu: zespół programistów jest zajęty innymi projektami, oprogramowanie pochodzi od zewnętrznego dostawcy i nie można go modyfikować, a prace zlecone na zewnątrz wymagają nowego cyklu projektu ^[1]. Wirtualna poprawka zamyka okno między ujawnieniem błędu a wdrożeniem prawdziwej łatki (patch). To okno jest groźne, bo według CERT Polska po upublicznieniu krytycznej podatności atakujący szybko przygotowują exploity, a luki pozwalające na zdalne wykonanie kodu będą najpewniej wykorzystywane na szeroką skalę ^[3]. CERT Polska zaleca zakładać, że niezałatany system stanie się celem ataku niezależnie od tego, czy jest wystawiony do internetu ^[3].

Typowe sytuacje to:

• zero-day, dla którego producent nie wydał jeszcze poprawki;
• n-day, gdy poprawka istnieje, ale aktualizacja wymaga testów;
• porzucona wtyczka, której nikt już nie poprawi.

W WordPressie

Na stronach WordPress wirtualne poprawki dotyczą głównie wtyczek i motywów, bo tam leży większość luk. Według raportu Patchstack w 2020 roku z wtyczek i motywów pochodziło 96,22% zgłoszonych podatności, a w 2021 roku 99,42% ^[5]; zob. podatność we wtyczce i podatność w motywie.

Reguły mogą działać w jednym z trzech miejsc: w zaporze po stronie hostingu, w usłudze pośredniczącej typu CDN albo reverse proxy, albo we wtyczce bezpieczeństwa uruchamianej przed kodem WordPressa. Opis wtyczki Patchstack w katalogu WordPress.org mówi o regułach nakładanych na konkretną stronę tylko wtedy, gdy wykryto na niej daną podatność ^[4]. Mają one chronić podatne komponenty bez modyfikowania kodu strony ^[4]. Wersja płatna ma według tego opisu ponad 12 000 takich reguł ^[4].

Wirtualna poprawka dla wtyczki działa tylko wtedy, gdy zapora widzi żądanie. Jeśli podatność leży w zadaniu wykonywanym w tle albo w kodzie wywoływanym przez inną drogę, reguła na wejściu HTTP jej nie zatrzyma.

Wirtualna poprawka a aktualizacja

Obie metody rozwiązują ten sam problem w innym miejscu. Różnice zestawia tabela poniżej.

Sekurak już w 2013 roku, opisując zaporę naxsi, zwracał uwagę, że reguły modelu negatywnego pozwalają szybko zablokować znaną lukę bez modyfikowania samej aplikacji ^[6]. Ten sam tekst wskazuje, że model pozytywny, oparty na liście dozwolonych treści, lepiej chroni przed atakami nieznanymi, ale wymaga więcej pracy przy wdrożeniu ^[6]. Wirtualna poprawka pisana pod jedną podatność jest więc zwykle regułą wąską i negatywną, a jej jakość zależy od tego, jak dokładnie opisano warunek wykorzystania luki.

W praktyce reguła powinna zostać usunięta albo przejrzana po aktualizacji komponentu. Reguły pozostawione bez przeglądu mogą z czasem blokować zmienione już funkcje strony i utrudniać ustalenie, dlaczego zapora odrzuciła konkretne żądanie. Z tego powodu OWASP przewiduje na końcu procesu etap dalszych działań ^[1], a Sekurak opisuje go jako monitorowanie ^[2].

Ograniczenia

• Nie zastępuje aktualizacji. OWASP podkreśla, że poprawki w kodzie i wirtualne patchowanie nie wykluczają się nawzajem ^[1]. Sekurak ostrzega, by nie polegać wyłącznie na wirtualnym patchowaniu jako alternatywie dla aktualizacji ^[2].
• Obejście reguły. Model negatywny łatwiej obejść ^[1].
• Trzeba wiedzieć, co łatać. Reguła powstaje dla znanej podatności, więc wymaga aktualnej wiedzy o zainstalowanych komponentach; zob. zarządzanie podatnościami.

CERT Polska zwraca uwagę, że terminowe aktualizacje wymagają wysiłku, ale ich brak w chwili incydentu może mieć nieodwracalne skutki ^[3]. Wirtualne patchowanie jest więc częścią zarządzania poprawkami (patch management), a nie jego końcem.