Exploit na WP File Manager! Co robić? Jak żyć?

Od początku września tego roku swoje smutne żniwo zbiera luka z wtyczki File Manager dedykowana pod WordPressa oznaczona kodem CVE-2020-25213. Mimo wydanej łatki do wersji 6.9, która załatwiała problem ludzie do dziś skarżą się na zhakowane strony. U nas na stronie – mimo braku tej wtyczki – jest to najbardziej skanowana podatność przez boty. Jeśli już padłeś ofiarą takiego buga, to możesz posprzątać sam lub wynająć firmę taką jak nasza, która usunie intruza i zabezpieczy stronę. A żeby uniknąć takich sytuacji w przyszłości zastosuj się do 5 porad, które pozwolą Ci spokojnie spać. Przy okazji pamiętaj, że nie ma w 100% bezpiecznych systemów i tak samo nasze porady zmniejszą wektor ataku i nie są rozwiązaniem na każdy problem.

1. Nie korzystaj z takich wtyczek

Wiem jak banalnie brzmi taka rada, ale każda wtyczka, która daje możliwość edycji plików lub zarządzania folderami i plikami z poziomu kokpitu WordPressa to jest najgorsza z możliwych rzeczy (zaraz po słabym haśle) z punktu widzenia bezpieczeństwa. Jeśli haker lub malware wbił się na stronę – pomijając jaką drogą – to dzięki takim pluginom ułatwiasz mu atak.
To jest trochę jak z ludźmi, którzy robią prostą wizytówkę firmy w internecie na CMSie zamiast na prostym HTMLu. Taka strona z reguły nie jest aktualizowana i z czasem staje się podatna na ataki. Prosta zasada – korzystajcie z tego, co jest warunkiem koniecznym do użytkowania waszej strony, czyli nie dodawaj sobie zbędnych funkcji. Zamiast wtyczek typu File Manager używaj dedykowanych opcji w cPanelu, DirectAdmin, etc lub przez szyfrowane połączenie FTP.

2. Włącz automatyczną aktualizację wtyczki

Jeśli cenisz sobie wygodę bardziej niż bezpieczeństwo i musisz używać dodatków pokroju File Manager to pamiętaj, żeby ustawić sobie automatyczną aktualizację. To zwiększy Twoje szanse na przyszłość i być może odpowiedni patch zostanie wydany szybciej, niż bot zaatakuje Twoją stronę. Ale to trochę igranie z ogniem.

3. Separacja stron na serwerze

Na stronie wtyczki File Manager jest wpis developera, któremu przez lukę tego plugina padło 75 stron. Żeby uniknąć takich sytuacji włącz koniecznie na swoim koncie hostingowym separacje stron www. Jeśli nie widzisz nic takiego w swoim panelu admin, to napisz do hostingu. Lepiej sprzątać po jednej stronie niż po 50 – mimo że podatną wtyczkę mogła mieć tylko jedna witryna na serwerze.

4. Zmień domyślną nazwę folderu plugins

Dużo specjalistów z dziedziny bezpieczeństwa web aplikacji będzie krytykować takie rozwiązanie, ale ja jestem jak najbardziej jego zwolennikiem i już tłumaczę dlaczego. Większość botów, które szukają dziur we wtyczkach odpytuje serwer po standardowych ścieżkach jakaśtamdomena.xyz/wp-content/pugins/nazwa-wtyczki. Zmieniając nazwę folderu bot z automatu dostanie 404 albo 403 i sobie pójdzie. Oczywiście są bardziej uparte boty i szukają niestandardowych linków np. dodając z przodu www, website, admin, test i temu podobne nazwy, czyli jakaśtamdomena.xyz/test/wp-content/pugins/nazwa-wtyczki
Nie pamiętam, żeby szukały innej nazwy dla folderu z pluginami, więc spokojnie można stwierdzić, że to Ci odsieje większość takich skanów. Nazwę pluginu można zmienić wklejając poniższy kod do pliku wp-config.

define('WP_PLUGIN_DIR', '/pelna/sciezka/do/folderu/wp-content/nowanazwa');
define('WP_PLUGIN_URL', 'https://twojadomena.abc/wp-content/nowanazwa');

Oczywiście poprawiamy ścieżkę i domenę zgodnie z parametrami naszego konta hostingowego. I nie zapomnij zmienić nazwy folderu na nową.

5. Blokuj dostęp do wykonywalnych plików

To jest kolejna rzecz, którą stosujemy w standardzie w naszych projektach i mimo luki atakujący nie miałby do niej dostępu. Z reguły pliki wykonywalne na serwach to pliki z rozszerzeniami php, exe, cgi, i podobnymi i zawsze trzeba je chować przed światem zew. Można to zrobić na dwa sposoby, które warto stosować jednocześnie. Pierwszy to uprawnienia folderów np. 777 to już jest za dużo uprawnień i dobrze jest je zmniejszyć do 755.
Drugi sposób to plik .htaccess do którego możemy wkleić dyrektywy, które pomogą nam chronić pliki wykonywalne.
Wszystko zależy od tego jaki masz serwer, a ja poniżej wkleję dwa przykłady, które powinny działać na Apache 2.4+

Options -Indexes
Options -ExecCGI
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi 

<Files ^(*.php|*.php3|*.php4|*.phtml|*.pl|*.py|*.jsp|*.asp|*.sh|*.cgi)>
order deny,allow
deny from all
</Files>

Pamiętaj żeby przetestować kod u siebie na serwerze zanim go dodasz do strony. Jeśli nie wiesz jaki masz serwer lub nie wiesz jak to zrobić, skontaktuj się z helpdeskiem firmy u której masz hosting.