Dziś, na blogu RIPS Technologies pojawił się opis dość ciekawej podatności w WordPressie, która pozwala skasować właściwie dowolne pliki WordPressa (i ew serwera, jeśli procesor PHP ma do nich tego typu dostęp) użytkownikom, którzy mogą zarządzać plikami multimedialnymi (upload i kasowanie plików).

WordPress File Delete to Code Execution

Z informacji na blogu wynika, że podatność została zgłoszona ponad 7 miesięcy temu do ekipy odpowiedzialnej za rozwój WordPressa, ale dotąd – łącznie z najnowszą wersją, 4.9.6 – podatność ta nie została załatana. A umożliwia ona każdej osobie, która może zarządzać plikami multimedialnymi (kasowanie) w WordPressie skasowanie właściwie dowolnego pliku, ingerując z poziomu swojej przeglądarki w standardowy proces usuwania multimediów.

Na szczęście nie jest to proces banalny, i oprócz tego, że użytkownik naszej strony musi mieć takie uprawnienia (spotykane), oraz „złe intencje” (bywa, ale… raczej mało kto wpuszcza do siebie przypadkowe osoby) to jeszcze musi wiedzieć jak wykonać dodatkowe operacje, które pozwolę podstawić plik do usunięcia w miejsce oryginalnej miniatury do skasowania.

Na wspomnianym blogu pojawia się informacja, że w ten sposób atakujący może skasować plik wp-config.php i tym samym zainicjować ponowny proces instalacji WordPressa, podając swoje dane uwierzytelniające dla głównego administratora strony.

I choć faktycznie wykasowanie pliku wp-config.php spowoduje zainicjowanie procesu konfiguracji strony, ale by go ukończyć niezbędne będzie podanie m.in. danych dostępowych do bazy danych, a można chyba śmiało założyć, że atakujący nie powinien ich posiadać:

Przynajmniej do bazy na naszym serwerze, bo oczywiście można to obejść, poprzez podstawienie zewnętrznej bazy danych, do której atakujący będzie znał uprawnienia, i wtedy może sobie postawić na bazie naszego WordPressa własną stronę, z własną treścią (przejęcie strony).

Atakujący może też np. wykasować pliki index.php chroniących foldery WordPressa przed wyświetleniem listy plików w nich się znajdujących. Ale to też jest zagrożenie w dużej mierze potencjalne, bo prawidłowo skonfigurowany webserwer nie powinien na taką operację (listowanie plików) pozwolić również w przypadku braku pliku index.php (czy np. index.html). A nawet jeśli, to… w większości instancji WordPressa pozyskane w ten sposób informacje jeśli już w ogóle się do czegoś przydadzą, to tylko w naprawdę specyficznych sytuacjach (i np. przy błędach w konfiguracji zabezpieczeń bazy danych). I tu wracamy do tego, że zapewne większość z nas obcych do swojego WordPressa nie wpuszcza, zwłaszcza z takimi uprawnieniami jak kasowanie plików multimedialnych…

I choć nie ma co panikować, to jednak jest to jakieś zagrożenie, i na pewno warto, by ekipa odpowiedzialna za rozwój WordPressa czym prędzej je wyeliminowała, wypuszczając odpowiednią poprawkę. Bo nigdy nie wiadomo, czy wśród ekipy zarządzającej jakąś stronę nie znajdzie się ktoś, kto ma akurat „gorszy dzień”, i w ramach odreagowania nie uzna, że warto pobawić się w złośliwego chochlika.

Na obecną chwilę – jeśli istnieje taka potrzeba – możecie zastosować np. poprawkę wskazaną przez ekipę, która opisała podatność:

add_filter( 'wp_update_attachment_metadata', 'rips_unlink_tempfix' );
function rips_unlink_tempfix( $data ) {
    if( isset($data['thumb']) ) {
        $data['thumb'] = basename($data['thumb']);
    }
    return $data;
}

Powyższy kod najlepiej dodać do pliku functions.php naszego motywu (najlepiej potomengo). Oczywiście jest to rozwiązanie tymczasowe, do czasu (ewentualnego) pojawienia się oficjalnej poprawki…