edytor plików motywów i wtyczek

Edytor plików motywów i wtyczek to wbudowane w panel WordPressa narzędzie, które pozwala oglądać i zmieniać kod motywu oraz wtyczek bezpośrednio w przeglądarce. Dokumentacja opisuje edytor motywu jako ekran do podglądu i zmiany dowolnego kodu w plikach szablonów i arkuszy stylów motywu ^[4]. Z punktu widzenia bezpieczeństwa edytor zamienia konto administratora w możliwość zapisu kodu PHP na serwerze. Dlatego jednym z podstawowych kroków, z których składa się utwardzanie (hardening), jest jego wyłączenie stałą DISALLOW_FILE_EDIT ^[2].

Jak działa

Dostęp do edytorów wyznaczają uprawnienia. edit_themes daje dostęp do edytora plików motywu, a edit_plugins do edytora plików wtyczek ^[3]. Oba istnieją od wersji 2.0 ^[3]. Na pojedynczej witrynie ma je tylko administrator, a w sieci Multisite wyłącznie superadministrator ^[3]. Zasady przydziału opisuje hasło role i uprawnienia użytkowników.

Zapis działa tylko wtedy, gdy plik jest zapisywalny dla serwera. W przeciwnym razie edytor pokazuje komunikat, że trzeba najpierw zmienić uprawnienia pliku ^[4]. Dokumentacja ostrzega też, że edytor nie tworzy kopii zapasowych, a błąd w pliku PHP bieżącego motywu może unieruchomić stronę tak, że edytorem nie da się go już naprawić ^[4].

Od wersji 4.9 WordPress zabezpiecza zapis plików PHP. Przed zapisem kopiuje starą treść pliku, a po zapisie wysyła zapytanie zwrotne (loopback) do ekranu edytora z tymi samymi ciasteczkami użytkownika ^[5]. Jeśli wystąpi błąd krytyczny, przywracana jest pierwotna wersja pliku; to samo dzieje się, gdy błąd pojawi się na stronie głównej ^[5]. Wersja 4.9 dodała też podświetlanie składni i sprawdzanie błędów w CSS, HTML, JS i JSON przed zapisem ^[5]. Te mechanizmy chronią przed pomyłką, nie przed złymi zamiarami.

W WordPressie

WordPress daje dwie stałe w pliku wp-config.php, które zamykają edytor. Ich zakres jest różny.

Dokumentacja utwardzania podaje, że wpisanie DISALLOW_FILE_EDIT jest równoważne odebraniu wszystkim użytkownikom uprawnień edit_themes, edit_plugins i edit_files ^[2]. Samo edit_files jest już oznaczone jako nieużywane ^[3].

// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

DISALLOW_FILE_MODS jest mocniejsza: blokuje instalowanie i aktualizowanie dodatków z panelu, więc zdefiniowanie jej wyłącza edytor bez osobnego DISALLOW_FILE_EDIT ^[1]. Ma jednak koszt: aktualizacje trzeba wtedy wykonywać inną drogą, na przykład przez SFTP albo narzędzia hostingu. Obie stałe należą do zestawu, który opisuje hasło utwardzanie pliku wp-config.php (hardening).

Oficjalna dokumentacja sama odradza pracę w edytorze z powodów niezwiązanych z bezpieczeństwem. Zmiany w plikach motywu przepadną przy jego aktualizacji; zalecane jest użycie motywu potomnego ^[4]. Oficjalny opis stałej DISALLOW_FILE_EDIT mówi o ochronie przed nadgorliwymi użytkownikami, którzy mogliby zmienić wrażliwe pliki i unieruchomić stronę ^[1].

Zagrożenia i skutki

Edytor nie jest podatnością, lecz skraca drogę od przejęcia panelu do przejęcia serwera. Atakujący, który zdobędzie konto administratora, na przykład przez przejęcie konta albo nieautoryzowane konto administratora, może wkleić do pliku motywu lub wtyczki dowolny kod PHP. Przebieg pokazuje schemat poniżej.

RYS. 1Od XSS w panelu do kodu na serwerze

Sekurak w poradniku zabezpieczania WordPressa pokazuje właśnie taki łańcuch: XSS we wtyczce, uruchomiony w przeglądarce administratora, wykorzystuje edytor do wstrzyknięcia kodu w pliki wtyczki i wykonania poleceń na serwerze ^[6]. Autor uznaje ten przykład za wystarczającą motywację do wyłączenia edytorów szablonów i wtyczek ^[6]. W ten sposób podatność we wtyczce po stronie przeglądarki kończy się jako zdalne wykonanie kodu (RCE).

Kod zapisany w pliku motywu działa jak webshell. MITRE ATT&CK opisuje webshell jako skrypt na publicznie dostępnym serwerze WWW, który daje przeciwnikowi dostęp do serwera jako bramy do sieci ^[7]. Wstrzyknięty kod bywa też tylną furtką (backdoor), która przetrwa zmianę haseł.

Jak się bronić

• Wyłączyć edytor stałą DISALLOW_FILE_EDIT albo, jeśli aktualizacje idą inną drogą, DISALLOW_FILE_MODS ^[1].
• Stosować zasadę najmniejszych uprawnień. MITRE ATT&CK zaleca, by katalog WWW mogły modyfikować tylko uprawnione konta ^[7]. W WordPressie oznacza to niewielu administratorów i sprawdzone uprawnienia plików.
• Chronić konta administratorów przez uwierzytelnianie dwuskładnikowe (2FA), bo stała zamyka edytor, ale nie zamyka innych dróg do kodu, takich jak instalacja wtyczki z pliku.
• Zmiany w kodzie wprowadzać w środowisku testowym (staging) i wdrażać przez system kontroli wersji albo SFTP, a nie w panelu produkcyjnym. Dokumentacja przypomina, że edytor nie robi kopii zapasowych ^[4].
• Obserwować pliki: monitorowanie integralności plików pokaże zmianę w pliku motywu, której nikt nie planował.

Stała nie zastępuje usunięcia pierwotnej luki. Zamyka jedną, najkrótszą ścieżkę od przejętego panelu do serwera.

Historia i przykłady

Uprawnienia edit_themes i edit_plugins istnieją w WordPressie od wersji 2.0 ^[3], więc edytor jest jednym z najstarszych narzędzi panelu. Największa zmiana przyszła w wersji 4.9, opisanej przez zespół rdzenia w październiku 2017 roku ^[5]. Edytor dostał podświetlanie składni, automatyczne uzupełnianie i sprawdzanie błędów ^[5], a przy pierwszym otwarciu edytora motywu lub wtyczki pojawia się ostrzeżenie; w edytorze motywu zawiera ono odnośnik do panelu Dodatkowy CSS w Customizerze ^[5]. Kilka miesięcy wcześniej, w lipcu 2017 roku, Sekurak opublikował poradnik z przykładem ataku przez edytor i zaleceniem wyłączenia go stałą DISALLOW_FILE_EDIT ^[6]. Oba teksty pokazują dwie strony tego samego narzędzia: rdzeń uczynił edytor bezpieczniejszym dla pomyłek, a środowisko bezpieczeństwa zaleca wyłączać go na produkcji.