Wczoraj wieczorem na moim telefonie pojawiła się informacja, która sprawiła, że natychmiast odpaliłem system automatycznie aktualizujący wszystkie strony, którymi się opiekuję. Informacja dotyczyła Contact Form 7, czyli jednej z najpopularniejszych wtyczek do formularzy kontaktowych w WordPressie (ponad 5 milionów aktywnych instalacji, i to tylko tych z repozytorium WordPress.org). Nagłówki kolejnych alertów (i informacji) grzmiały o możliwości podrzucenia na serwer np. pliku PHP, a tym samym – przynajmniej potencjalnie, jeśli ktoś nie używa PHP Pools i/lub open_basedir – przejęcia całego serwera. Brzmiało groźnie, więc na szybko, w międzyczasie jak prewencyjnie aktualizowały się strony, postanowiłem przeczytać, co o tej podatności w internetach piszą… Podwójne znaczenie.

Podatność w Contact Form 7 5.3.1 i starszych

Ale by cokolwiek sensownego ustalić, najpierw musiałem przebić się przez alarmujące nagłówki o ponad 5 milionach podatnych stron, a jak liczyć dostęp do całego konta na hostingu czy serwera, to można by pewnie liczyć to w dziesiątkach milionów. Po odfiltrowaniu nagłówków z technopudelków (choć widziałem, że i kilka poważnych serwisów, zajmujących się m.in. bezpieczeństwem, postanowiło w tych klimatach pojechać… ;-)).

Okazało się, że faktycznie, ryzyko istnieje, ale skorzystanie z tej podatności przez kogoś jest prawie tak samo prawdopodobne, jak to, że na spacerze, na który idziemy za kilku minut, spotkam kosmitów. Takich prawdziwych, a nie tylko „umysłowych”.

An unrestricted file upload vulnerability has been found in Contact Form 7 5.3.1 and older versions. Utilizing this vulnerability, a form submitter can bypass Contact Form 7’s filename sanitization, and upload a file which can be executed as a script file on the host server.

Podatność polega na obejściu mechanizmu filtrowania typu plików poprzez zastosowanie podwójnego rozszerzenia (plik.php.jpg), co powoduje, że… Właśnie w tym rzecz, że w tym kontekście najprawdopodobniej powoduje niewiele. Bo by atak się udał, to jak się zdaje:

1. Formularz musi mieć opcję przesyłania plików
2. Należy zgadnąć, w jakim podkatalogu o losowej nazwie zostanie plik zapisany
3. Trzeba zdążyć z działaniem przed skasowaniem pliku z serwera, co następuje po przesłaniu wiadomości
4. Serwer musi umożliwiać wykonywanie plików o rozszerzeniach np. plików graficznych (choć możliwe, że mamy do czynienia z jakimś sposobem na „zgubienie” drugiego rozszerzenia, np. za pomocą jakiegoś znaku specjalnego)
5. Serwer musi działać na innym webserwerze niż Apache2 (brak obsługi plików .htaccess)

I choć oczywiście każdy z tych elementów jest potencjalnie – mniej lub bardziej –  możliwy, to szanse na to, że zdarzą się wszystkie, raczej jest mało prawdopodobne. Ale pewność będziemy mieli gdy poznamy szczegóły błędu, a tymczasem i tak zachęcam do jak najszybszej aktualizacji wtyczki Contact Form 7 do wersji 5.3.2 lub nowszej.