Oficjalne repozytorium WordPressa jest uważane za najbezpieczniejsze źródło darmowych wtyczek. Wpadki zdarzają się jednak nawet najlepszym, czego dowodem może być sytuacja sprzed dwóch dni, kiedy to w jednym z rozszerzeń wykryto złośliwy kod. Warto dodać, że kod ten siedział sobie spokojnie w repozytorium przez ponad dwa tygodnie.

Sprawa dotyczy wtyczki Custom Content Type Manager, która nie jest szczególnie popularna, ale ma swoje grono użytkowników (ponad 10 tysięcy aktywnych instalacji). Ostatnia aktualizacja rozszerzenia miała miejsce w maju 2015 – od tamtej pory autor nie wykazywał żadnej aktywności. Nie jest to ani dziwne, ani niepokojące – wielu autorów z różnych powodów porzuca swoje wtyczki.

17 lutego do listy kontrybutorów wtyczki (czyli osób, które mogą przesyłać zmiany w kodzie do repozytorium) został dodany użytkownik wooranker. Nie do końca wiadomo jak to się stało. Konto autora wtyczki mogło zostać przejęte, mogło też dojść do sprzedaży rozszerzenia przez autora. Tak czy inaczej wooranker mógł od tej pory dowolnie modyfikować kod wtyczki, co też zaczął robić.

Autorzy wtyczek (szczególnie takich, które od jakiegoś czasu nie są rozwijane) od dawna są nękani propozycjami odkupienia ich rozszerzeń. Kilka tygodni temu temat został poruszony na blogu Make WordPress Plugins, gdzie ostrzegano autorów przed sprzedawaniem swoich wtyczek podejrzanym osobom, które mogą w ten sposób próbować wykonywać nie do końca etyczne działania (na przykład dodawać własne linki do stron użytkowników). Być może tutaj mieliśmy do czynienia z taką właśnie sytuacją.

Złośliwy kod dodany przez woorankera pozwalał na zdalny dostęp do strony korzystającej z wtyczki, instalował na serwerze skrypt, który tworzył potajemnie nowe konto „support” z uprawnieniami administratora, a także modyfikował pliki WordPressa, tak aby przesyłały na zewnętrzny serwer loginy i hasła do kont innych administratorów strony. Dodatkowo instalował też skrypt śledzący, zbierający adresy stron odsyłających użytkowników do zainfekowanej witryny. Cały mechanizm działania złośliwego kodu został (jak zwykle) świetnie opisany na blogu Sucuri.

5 marca ekipa opiekująca się oficjalnym repozytorium wtyczek cofnęła wszystkie zmiany w kodzie dokonane przez woorankera. Stało się to ponad dwa tygodnie po tym, jak złośliwy kod trafił do repozytorium. Trudno oszacować, ile stron zostało w tym czasie zainfekowanych, a cofnięcie zmian we wtyczce nie usuwa modyfikacji dokonanych przez złośliwy kod w plikach WordPressa ani utworzonego konta z uprawnieniami administratora. Tak więc jeśli ktoś korzysta z tej wtyczki, to powinien „przeinstalować” WordPressa (zastąpić wszystkie jego pliki plikami pobranymi z oficjalnej strony), usunąć wszystkie podejrzane konta, a także zmienić hasła do wszystkich pozostałych kont.

Jaki z tego wniosek? Czy dało się w ogóle uniknąć takiej sytuacji? Czy możemy zrobić coś, aby na własną zabezpieczyć się przed tego typu problemami?

Jeśli spojrzymy na listę modyfikacji, jakie codziennie trafiają do repozytorium wtyczek, to dojdziemy do wniosku, że kilkuosobowa ekipa nie jest w stanie zweryfikować każdej z nich. To jest po prostu niewykonalne. Być może przekazanie społeczności części zadań związanych z weryfikacją wtyczek (tak jak ma to miejsce w przypadku motywów) byłoby jakimś rozwiązaniem. Ale z tego co pamiętam, zespół opiekujący się wtyczkami nie jest zbyt chętny do zrobienia takiego kroku.

Większość użytkowników WordPressa nie jest w stanie samodzielne zweryfikować każdej aktualizacji. Z kolei wstrzymywanie się z instalacją uaktualnień, szczególnie tych usuwających błędy związane z bezpieczeństwem, może przysporzyć nam wielu innych, potencjalnie poważniejszych problemów. Wygląda na to, że mimo wszystko powinniśmy ufać wtyczkom pochodzącym z oficjalnego repozytorium, nawet jeśli raz na jakiś czas zdarzy się jakaś wpadka.

Na pewno warto jednak korzystać z wtyczek wciąż rozwijanych przez autorów i (co przykro mi pisać) najpopularniejszych, ponieważ duża liczba użytkowników jest w stanie szybciej wychwycić błędy czy jakieś podejrzane zachowania rozszerzenia.

Opis całej sytuacji wraz ze szczegółową analizą działania złośliwego kodu można znaleźć na blogu Sucuri.