porzucona wtyczka

Porzucona wtyczka to wtyczka WordPressa, której autor przestał rozwijać i łatać, a która nadal działa na stronach. Znane w niej błędy pozostają nienaprawione, bo nikt nie wyda poprawionej wersji. OWASP zalicza do typowych przyczyn podatności korzystanie z oprogramowania, które jest podatne, nieobsługiwane lub nieaktualne ^[5]. Porzucona wtyczka to w WordPressie najczęstsza postać takiego nieobsługiwanego komponentu.

Jak do tego dochodzi

Wtyczka to zwykle praca jednej osoby albo małej firmy. Autor może zmienić zajęcie, zamknąć działalność albo sprzedać projekt. Strona, która ją zainstalowała, tego nie zauważa: wtyczka działa jak wcześniej, tylko przestają przychodzić aktualizacje. Problem ujawnia się dopiero wtedy, gdy ktoś znajdzie w kodzie podatność. Schemat poniżej pokazuje ten przebieg.

RYS. 1Jak porzucona wtyczka staje się luką

Po publikacji opisu błędu luka staje się n-day: jest znana, a na stronach z porzuconą wtyczką nie ma i nie będzie łatki (patch).

Porzucenia nie ogłasza się oficjalnie, więc trzeba je rozpoznać po pośrednich oznakach. Należą do nich: długi czas od ostatniej wersji, brak odpowiedzi autora na forum wsparcia, zgłoszenia błędów bez reakcji, znikająca strona producenta albo zamknięta strona wtyczki w katalogu WordPress.org. Żadna z tych oznak osobno nie przesądza sprawy. Dojrzała, prosta wtyczka może długo nie wymagać zmian. Ryzyko rośnie, gdy kilka oznak występuje naraz, a wtyczka przetwarza dane od odwiedzających, na przykład formularze lub przesyłane pliki.

Porzucone bywają też wtyczki płatne spoza katalogu. Ich aktualizacje przychodzą z serwera producenta, więc po wygaśnięciu licencji albo likwidacji firmy strona przestaje dostawać poprawki bez żadnego komunikatu w panelu.

W WordPressie

Katalog wtyczek WordPress.org ma własne zasady zamykania. Według dokumentacji wtyczki zamyka się z powodu naruszenia wytycznych, problemów z bezpieczeństwem albo na prośbę autora ^[1]. Zespół może też zamknąć wtyczkę automatycznie, gdy po zatwierdzeniu przez 6 miesięcy nie trafił do repozytorium żaden kod, gdy repozytorium SVN jest uszkodzone od ponad 12 miesięcy albo gdy plik readme oznacza wtyczkę jako przestarzałą ^[1].

Po zamknięciu strona wtyczki w katalogu jest oznaczona jako zamknięta, a paczki ZIP nie są generowane; nie da się jej pobrać ze strony ani zainstalować z panelu WordPressa ^[1]. Powód zamknięcia staje się publiczny po 60 dniach, bez szczegółów ^[1]. Zamknięcie blokuje nowe instalacje, ale nie usuwa wtyczki ze stron, na których już działa.

Porzucenie nie zawsze kończy życie wtyczki. WordPress.org pozwala przejąć wtyczki, które nie są już rozwijane: trzeba najpierw spróbować skontaktować się z autorem, zaktualizować kod do bieżących standardów i poprosić zespół wtyczek o przegląd ^[1].

Porzucona wtyczka różni się od kilku pokrewnych przypadków:

Ostatni przypadek opisuje też hasło fałszywa wtyczka.

Zagrożenia i skutki

CERT Polska wśród zaleceń dla właścicieli przejętych stron podaje utrzymywanie aktualnych wersji CMS, jego wtyczek, rozszerzeń i motywów ^[3]. Przy porzuconej wtyczce tego zalecenia nie da się spełnić przez aktualizację, bo nowszej wersji nie ma.

Skutki zależą od rodzaju błędu: od XSS (Cross-Site Scripting) po zdalne wykonanie kodu (RCE) i webshell na serwerze. Każda zainstalowana i nieużywana wtyczka zwiększa powierzchnię ataku, nawet gdy jest wyłączona, jeśli jej pliki da się wywołać bezpośrednio.

Osobnym ryzykiem jest zmiana właściciela porzuconego projektu. Przejęcie popularnej wtyczki z dużą bazą instalacji to forma ataku na łańcuch dostaw (supply chain attack): nowa wersja z tylną furtką (backdoor) trafia na strony przez zwykłą aktualizację.

Jak się bronić

OWASP zaleca proces zarządzania poprawkami (patch management), który obejmuje usuwanie nieużywanych zależności, stałą inwentaryzację wersji komponentów i śledzenie baz podatności ^[5]. Wprost wymienia też monitorowanie bibliotek i komponentów, które nie są utrzymywane; gdy łatanie nie jest możliwe, sugeruje wirtualne patchowanie (virtual patching) ^[5].

W WordPressie przekłada się to na kilka praktyk:

• przegląd listy wtyczek i sprawdzenie, czy każda ma aktualizacje i czy jej strona w katalogu nie jest zamknięta;
• usuwanie nieużywanych wtyczek, zgodnie z dokumentacją WordPressa ^[6];
• zastąpienie porzuconej wtyczki utrzymywanym odpowiednikiem albo przeniesienie jej funkcji do własnego kodu;
• reguły WAF blokujące znane ataki na lukę, która nie zostanie załatana;
• regularne skanowanie podatności. W Polsce system Artemis CERT Polska ma moduł wordpress_plugins, który sprawdza, czy wtyczki WordPress są aktualne ^[4].

Historia i przykłady

W grudniu 2017 roku Sekurak opisał wtyczkę CAPTCHA z około 300 000 instalacji, która po przekazaniu innej firmie otrzymała aktualizację z tylną furtką ^[2]. Złośliwy kod pojawił się w wersjach od 4.3.6 do 4.4.4, pierwszy raz 7 grudnia 2017 roku; wersja 4.4.5 go usunęła ^[2]. Sekurak zaznaczył też, że oficjalni właściciele wtyczki nie mieli wówczas możliwości jej aktualizacji ^[2]. Przypadek pokazuje, że wtyczka pozbawiona dotychczasowego opiekuna może stać się zagrożeniem także wtedy, gdy nadal otrzymuje aktualizacje.