UWAGA! Zagrożenie WordPressa! Pilnie zaktualizuj wtyczkę Contact Form 7
0
Najczęściej czytane
Pilnie zaktualizuj wtyczkę Contact Form 7
Dnia 17 grudnia 2020 roku wykryto podatność CVE-2020-35489 wtyczki Contact Form 7 systemu WordPress. Wspomniana podatność umożliwia przestępcom wykonanie prawie dowolnego kodu źródłowego w języku PHP (albo innym skryptowym języku) na Twoim hostingu albo na serwerze, co oznacza prawie nieograniczone możliwości dla przestępców.
Wtyczka Contact Form 7 jest jedną z najpopularniejszych wtyczek do konstruowania najróżniejszych elektronicznych formularzy na stronach opartych o CMS WordPress:
Contact Form 7
Czym grozi podatność CVE-2020-35489 wtyczki Contact Form 7?
Podatność CVE-2020-35489 wtyczki Contact Form 7 grozi uzyskaniem dostępu do danych i plików na hostingu lub serwerze przez przestępców. Konsekwencje tego mogą być różne. Jeśli ktoś prowadzi sklep internetowy lub platformę szkoleniową w oparciu o WordPress, no to istnieje ryzyko że ktoś pozyska wszystkie dane sklepu - zamówienia, prywatne dane klientów, a w najbardziej nieudanych wypadkach (czyli najbardziej udanych z punktu widzenia przestępcy) nawet dostęp do płatności - może przekierować płatności klientów sklepu do siebie.
Poza tym, podatność CVE-2020-35489 wtyczki Contact Form 7 pozwała m.in. na wprowadzanie wirusa do systemu. Więc jeśli dotknie - jest to naprawdę groźna podatność.
Czy podatność CVE-2020-35489 wtyczki Contact Form 7 zagraża wszystkim użytkownikom WordPressa?
Nie. Ale tych komu zagraża jest dużo. Jeśli ktoś nie korzysta z wtyczki Contact Form 7 to jego to nie dotyczy. Jeśli ktoś używa Contact Form 7, ale nie używa funkcjonalności załączania plików do formularza przez użytkownika - też, raczej, nie dotyczy. Jeśli ktoś ma dobrze skonfigurowany serwer, to serwer sam zadba o to by nic złego się nie stało. Ale...
Ale, znając życie, dysponując sporym doświadczeniem w obsłudze stron opartych o WordPress, szczególnie w Polsce, dobrze skonfigurowanych serwerów u klientów jeszcze nie widziałem. Problem polega na tym że duża część klientów, zamawiających stronę opartą o WordPress, to albo tacy klienci którzy kompletnie nic nie wiedzą na temat branży IT i ktoś, czasem, sprzeda im stronę zbudowaną na WordPress tam gdzie normalnie WordPress w ogóle nie może mieć zastosowania, albo tacy którzy nie potrafią zrozumieć dlaczego praca informatyka kosztuje i zamawiają usługę od pierwszego lepszego freelancera, z listy posortowanej po cenie rosnąco. Ewentualnie, od agencji marketingowej, czyli firmy z kompletnie innej branży (bo z marketingu). Reasumując, jeśli masz stronę na WordPress i wtyczkę Contact Form 7, raczej nie licz na to że masz bezpiecznie skonfigurowanego serwera i on Cię uchroni przed atakiem hackerskim. Lepiej dmuchać na zimno, czyli jak najszybciej odświeżyć wtyczkę Contact Form 7.
Jak odświeżyć wtyczkę Contact Form 7?
Wejdź do panelu administratora Twojego WordPressa, wybierz punkt wtyczki i znajdź tam wśród zainstalowanych wtyczek Contact Form 7 i sprawdź czy masz wadliwą wersję (tj niżej niż 5.3.2):
Wersja wtyczki contact Form 7
Jeśli masz wadliwą wersję - zaktualizuj ją.
Jeśli korzystasz z wtyczki Easy Updates Manager lub innej blokującej aktualizacje, przypilnuj żeby na czas wykonywania opisanej tutaj czynności zezwolić na pobieranie aktualizacji Contact Form 7 (pomiń ten krok jeśli nie używasz blokowania aktualizacji):
Easy Updates Manager
Po dokonaniu aktualizacji Contact Form 7 nie zapomnij z powrotem zablokować aktualizacje (o ile do tej pory była zablokowana).
Po odblokowaniu aktualizacji odśwież listę wtyczek i obok Contact Form 7 pojawi się uruchom aktualizację (o ile masz panel administratora w języku polskim). Po angielsku to będzie Update albo Upgrade. Kliknij w uruchom aktualizację naprzeciwko Contact Form 7 i zaczekaj aż aktualizacja się skończy:
Komunikat o aktualizacji Contact Form 7
Po ukończeniu aktualizacji w panelu administratora pojawi się odpowiedni komunikat:
Komunikat o ukończonej aktualizacji
Jeśli miałeś lub miałaś zablokowane aktualizacje - nie zapomnij powyłączać je z powrotem.
Co zmienili w kodzie źródłowym wtyczki Contact Form 7?
A teraz informacje dla zaawansowanych.
Nie po to blokujemy aktualizacje, żeby cokolwiek instalować. Otóż, drodzy czytelnicy i czytelniczki bloga informatycznego, czasem warto zbadać co niesie w sobie ta czy inna aktualizacja. Więc, zbadałem.
Wrzuciłem do pustego foldera kod źródłowy wtyczki Contact Form 7 w wersji 5.2.2, stworzyłem tam repozytorium GIT i odświeżyłem kod do wersji 5.3.2:
Badanie Contact Form 7 za pomocą GIT
Odświeżyłem kod do wersji 5.3.2 i zbadałem różnicę:
Badanie Contact Form 7 v.5.3.2 (1)
oraz
Badanie Contact Form 7 v.5.3.2 (2)
Zmieniono 40 plików? Już się boję tej aktualizacji...
Zacznijmy od readme.txt:
Contact Form 7 v.5.3.2, ReadMe
No i, rzeczywiście, zmian było dużo. Block Editor, mail template, z datami coś pogrzebali. A nam chodzi o to:
Więc powtórzmy badanie, ale zbadajmy zmiany tylko od wersji 5.3.1 do 5.3.2:
Contact Form 7, zmiany z wersji 5.3.1 do 5.3.2
Właśnie, mniej-więcej tyle zmian oczekiwałbym. Czyli jest w porządku. Zmieniono 4 pliki, a więc zbadajmy je po kolei.
Wersja:
Contact Form 7 v.5.3.2, readme.txt
Plik formatting.php:
Contact Form 7 v.5.3.2, formatting.php
No i o to chodziło. To jest sens całej aktualizacji. Użyli tutaj dodatkowo regularnego wyrażenia /[\pC\pZ]+/i które kasuje nam wszystkie spacje i niektóre niewidoczne znaki (pewnie, przestępcy dopisywali jakieś cuda na kiju do pliku i ładowali kod źródłowy na hosting czy na serwer).
Contact Form 7, funkcja wpcf7_antiscript_file_name()
Jak widzimy z kodu źródłowego funkcji wpcf7_antiscript_file_name(...), w linijce 342 kasują wszystkie spacje i inne dziwne znaki z nazwy pliku, jeśli plik nie zawiera kropki, w linijce 347 następuje wyjście z funkcji, a jeśli jest co-najmniej jedna kropka - obrabiają nazwę pliku dalej. W linijce 350 wylistowane niebezpieczne (z punktu widzenia autora tego kodu) rozszerzenia plików, a w linijce 357, o ile nazwa pliku zawiera niebezpieczne rozszerzenie, dodają do nazwy tej niebezpiecznej części podkreślnik. A w linijce 364 to i w ogóle dodają _.txt w razie czego.
Czy to jest bezpieczne? Chmm... No nie wiem. Zdecydowanie lepiej niż było, ale wyznaczenie ścieżki algorytmu na podstawie znaków w nazwie plików... Dla mnie nie brzmi przekonująco. Chyba że dalej w kodzie jest weryfikacja treści pliku, ale wątpię. Bo co jeśli wyślę plik ze skryptem PHP z rozszerzeniem .html czy .pdf, to co serwer z tym zrobi? Czy na pewno żaden serwer na świecie go nie uruchomi?
O ile dobrze rozumiem, jest to funkcjonalność która pozwała użytkownikom naszej strony przesłać plik w załączniku do wiadomości. Jeśli jest to możliwe, najlepiej zrezygnować z takiej funkcjonalności wcale.
Wracając do tematu pozostałych zmienionych plików (akismet.php i wp-contact-form-7.php), tam nic zbyt ciekawego nie ma (akismet.php):
Contact Form 7 v.5.3.2, akismet.php
oraz wp-contact-form-7.php:
Contact Form 7 v.5.3.2, wp-contact-form-7.php
Jeśli znalazłe[-a]ś w tekście, literówkę, błąd stylistyczny albo inny błąd językowy - bardzo proszę o napisanie poprawki w komentarzu pod artykułem albo przez formularz kontaktowy. Dziękuję!
Wesprzyj wolne media - udostępnij tę publikację!
Jeśli ta publikacja jest dla Ciebie wartościowa - proszę udostępnij ją w social media. To pomaga promować nieocenzurowaną wiedzę.
Publikuję tutaj wiele materiałów nieocenzurowanych przez producentów propagandy i twórców opinii społecznej. Dlatego wyszukiwarki boja się że niektóre publikacje dotrą do szerokiej publiczności i na potęgę tną mi zasięgi.
Jeśli słowo Wolność nie jest Ci obce - pomóż mi w rozpowszechnianiu nieocenzurowanej wiedzy, czyli udostępnij tę publikację w social media.
Dziękuję!
Witajcie na blogu informatycznym!