Wprowadzenie
WordPress to najpopularniejszy system blogowy w Internecie.
Średnio już co 3 strona korzysta właśnie z tego systemu do obsługi swoich treści.
Jednak przez te lata wokół tego narzędzia narosło wiele mitów.
Czy WordPress jest bezpieczny?
Czy korzystanie z niego niesie za sobą jakieś konsekwencje?
Ja jestem Kacper Szurek a to kolejny odcinek podcastu Szurkogadanie, w którym postaram się odpowiedzieć na to pytanie.
Podcast ten można również znaleźć na Spotify oraz Google i Apple Podcasts oraz Anchor.
Zaczynajmy!
Ilość błędów
Aby odpowiedzieć na postawione w tytule pytanie, spróbujmy prześledzić liczbę podatności, które odnaleziono w całym ekosystemie.
Skorzystam z tego celu ze strony WPScan Vulnerability Database1, która jest agregatorem wszystkich błedów jakie są obecnie znane a dotyczą tego systemu.
Na stronie głównej, możemy wyczytać że obecnie skatalogowano ponad 14000 błędów.
Dużo jak na jeden tylko skrypt.
Na podstawie takich danych możemy zatem odnieść złudne wrażenie, że wykorzystanie WordPressa do budowania swojej marki w Internecie może nie być najlepszym pomysłem.
A jak jest w rzeczywistości?
Podatności na tej stronie zostały podzielone na 3 główne kategorie.
Pierwsza - podatności w samym WordPressie, tak zwanym core - czyli silniku strony.
Dalej podatności w rozszerzeniach (lub pluginach) - czyli dodatkowych funkcjach, które doinstalowujemy do naszej strony aby uzyskać dodatkowe opcje i możliwości.
Oraz ostatnia - błędy w tematach - czyli kawałkach kodu odpowiedzialnych za wygląd naszej witryny.
XSS
Rozpatrując bezpieczeństwo z uwzględnieniem tych kategorii sytuacja wygląda zgoła inaczej.
Okazuje się bowiem, że ostatnia znana podatność pochodzi z marca 2019 roku.
Jest ona oznaczona jako atak XSS przy użyciu komentarza.
W krótkich słowach XSS pozwala na wykonanie złośliwego kodu JS w obrębie naszej domeny.
Tylko, że przechodząc do szczegółów tego błędu okazuje się, że aby go wykorzystać, konieczne jest wykonanie kilku specyficznych punktów.
Aby ktoś zaatakował naszą stronę, my - jako administrator - musimy się zalogować do panelu administratora.
Następnie - będąc zalogowanymi - musimy przejść do złośliwej strony, która to dopiero wykona złośliwy kod.
Bardziej podpada to zatem pod atak socjotechniczny niż błąd sam w sobie.
Zwłaszcza, jeżeli na naszej stronie wyłączone sa komentarze.
A to nie jest nic szczególnego - zwłaszcza na witrynach małych firm, które bardziej przypominają wizytówki z cennikiem i informacjami kontaktowymi niż duże portale informacyjne.
Wtedy to - złośliwy atakujący musiałby przesłać nam odnośnik do zewnętrznej strony przy użyciu innej metody - na przykład poprzez email.
Co więcej - musielibyśmy ten link otworzyć - będąc jednocześnie zalogowanymi do serwisu.
Code Execution
No dobrze, popatrzmy zatem na kolejny błąd.
Tym razem z lutego. Widzimy że jest to Code Execution - czyli wykonanie kodu.
Brzmi złowrogo? I rzeczywiście - jest to jeden z najgorszych rodzajów podatności na jakie możemy się natknąć, ponieważ umozliwia wykonanie dowolnego kodu na naszej stronie, co oznacza iż potencjalny atakujący zdobywa pełną kontrolę nad naszym serwisem.
Tylko, że tym razem mamy do czynienia z podatnością authenicated.
Tłumacząc to na język polski - aby tym razem ktoś mógł zaatakować naszego bloga - musi posiadać konto użytkownika w tym serwisie.
Czytając opis tego błędu okazuje się, iż w tym przypadku "atakujący musi posiadać uprawnienia autora".
A to jest bardzo rzadka sytuacja.
Dlaczego?
WordPress standardowo posiada kilka wbudowanych grup użytkowników.
W zależności od tego do jakiej grupy jestesmy przypisani - otrzyzmujemy odpowiednie uprawnienia do wyoknywania pewnych czynności.
Autor to osoba, który może publikować i zarządzać własnymi wpisami.
Jest to więc osoba, której administrator ufa na tyle, aby dać jej możliwość dodawania nowych tresci do serwisu.
Możemy więc założyć, że zwykłemu atakującemu ciężko będzie uzyskać dostęp do takiego konta.
Owszem, może pozyskać login i hasło używając chociażby phishingu - czyli ataku, w którym podszywamy się pod kogoś lub coś, aby uzyskać nieautoryzowany dostęp.
Tylko, że phishing - to nie podatność w WordPressie, a atak socjotechniczny na który jest narażony kazdy z nas.
Mamy zatem dwie podatności, które na papierze wyglądają kiepsko - w praktyce jednak będą trudne do wykorzystania.
Wychodzi więc na to, że od ponad pół roku nie opublikowano żadnej nowej krytycznej podatności w samym silniku.
Skąd więc tak zła sława tego narzędzia?
Pluginy
Chodzi o rozszerzenia - czyli pluginy.
Są to dodatkowe kawałki kodu, tworzone przez niezależnych twórców, które drastycznie zwiększają możliwości samego systemu.
Śmiem twierdzić, że to właśnie dzięki nim WordPress jest taki popularny.
Obecnie w katalogu pluginów znaleźć można ponad 55 tysięcy dodatków.
To dzięki nim system ten nie jest tylko systemem blogowym.
Przy pomocy paru kliknięć może stać się sklepem internetowym, galerią zdjęć czy też platformą społecznościową.
Kluczowym jest fakt, iż każdy kto posiada odrobinę więdzy programistycznej może dołożyć swoją cegiełkę tworząc nowy dodatek, który to następnie może być uruchomiony na dowolnej stronie.
Z jednej strony jest to świetna wiadomość dla użytkowników.
Na chwilę obecną istnieje spora szansa iż nawet bez posiadania wiedzy programistycznej możemy stworzyć rozbudowaną stronę korzystając jedynie z gotowych rozwiązań.
Spróbuj samemu przeszukać bazę podając słowa kluczowe.
Poszukujesz systemu do zarządzania pracą salonu fryzjerskiego? Nie ma problemu.
Masz dużo zdjęć i chcesz posegregować je w galerii. To tylko parę kliknięć.
Chcesz stworzyć zaawansowaną ankietę dla swoich użytkownikow? To też już jest.
Znalezienie odpowiedniego wyglądu strony to rownież parę kliknięć.
Na rynku pojawiło się sporo firm, które przygotowują szablony właśnie pod ten jeden konkretny system.
Za parę dolarów możesz stać się posiadaczem ładnie wyglądającej witryny, w której należy zmienić jedynie logo, dodać parę zdjęć i już.
Kto tworzy dodatki?
Tylko, że jest jedno ale.
Te rozszerzenia nie są tworzone przez Automattic2 - czyli firmę odpowiedzialną za rozwój WordPressa - ale przez użytkowników.
To sprawia, że większość kodu nie przechodzi żadnej kontroli jakości.
Nikt nie sprawdza tych dodatkowych funkcjonalności.
Owszem - użytkownicy zgłaszają na forach, że coś błędnie działa - ale mało kto zwraca uwagę na bezpieczeństwo samego kodu.
To sprawia, że wraz z instalacją każdego dodatkowego rozszerzenia - nasza witryna staje się coraz bardziej niebezpieczna.
Ale oczywiście nie należy popadać w paranoję.
- Nie wszystkie rozserzenia są złe.
Zwłaszcza, że te najpopularniejsze są rozwijane i wspierane przez firmy, które z ich działania uczyniły swoje źródło dochodów.
Bezpieczeństwo
Podsumowując: bezpieczeństwo Twojej strony w głównej mierze zależy od ilości i jakości rozszerzeń jakie na niej zainstalujesz.
Podczas doboru warto sugerować się ilością instalacji.
Popularne aplikacje zazwyczaj są częściej aktualizowane.
Można też sprawdzić historię błędów danego dodatku.
Trzeba pamiętać iż posiadanie podatności w przeszłości niekoniecznie dyskwalifikuje dane rozszerzenie.
Dlaczego? Żadna aplikacja nie jest w 100% bezpieczna.
Zawsze prędzej czy później ktoś odnajdzie coś co działa nie tak jak trzeba lub też zostaną wynalezione nowe techniki ataków.
Ważniejsza od ilości jest szybkość i odpowiedź producentów na taki incydent.
Jeżeli bowiem błąd po jego zgłoszeniu zostanie szybko załatany, oznacza to iż firma traktuje takie sprawy poważnie.
W takich sytuacjach przy standardowym używaniu WordPressa zazwyczaj nic nam nie grozi.
Większość błedów bowiem jest odnajnowana przez osoby zawodowo zajmujące się bezpieczeństwem.
Przed opublikowaniem wszystkich informacji na temat danej podatności, najpierw informuje się o jej wykryciu producenta.
Wyznacza się również odpowiedni czas w którym powinien zareagować.
W przypadku WordPressa - rozszerzenia mogą być aktualizowane automatycznie bez naszej wiedzy.
Oznacza to, że nie musimy śledzić serwisów informujących o błędach.
Producent sam wyda poprawkę a ona to automatycznie zainstaluje się na naszym serwerze.
Dodatkowe zabezpieczenia
No dobrze, ale słuchacze tego podcastu interesują sie bezpieczeństwem.
Co więcej można zrobić aby podnieść bezpieczeństwo naszej strony?
Odpowiedzią rynku na to pytanie są rozszerzenia, których jedynym celem jest ochrona naszej strony przed atakami.
Jest ich co najmniej kilka.
Nie chcę tutaj faworyzować któregokolwiek z nich.
Wszystkie działają mniej więcej podobnie i oferują podobny zestaw narzędzi.
Wybór należy do Ciebie drogi słuchaczu i od Twoich osobistych preferencji.
Najpopularniejsze to Wordfence security, all in one wp security, sucuri security, cerber security czy też ithemes security.
Spróbuję teraz opisać najważniejsze funkcje, które można w nich spotkać, a także wyjaśnić dlaczego korzystanie z nich może pozytywnie wpłynąć na Twoje bezpieczeństwo.
Bruteforce
Po pierwsze - zabezpieczenie przed atakami brute force.
Skrypt monitoruje jak często dana osoba próbuje się zalogować do panelu administratora.
W przypadku wystąpienia zbyt dużej liczby błędnych prób - dostęp do logowania z danego adresu IP jest blokowany na jakiś czas.
Jest to szczególnie istotne w nieco większych instalacjach.
O ile nasze hasło może być odpowiednio długie i skomplikowane, to co z hasłami naszych współpracowników?
Czy oni również są świadomi tych zagrożeń?
Naturalnym rozszerzeniem tego zabezpieczenia jest lista adresów IP, które sa blokowane z automatu.
Jak powstają takie listy?
Niektóre z rozszerzeń wysyłają informacje statystyczne do serwerów swoich twórców.
Tam te informacje sa agregowane i przetwarzane.
Patrząc z perspektywy globalnej - jeżeli jeden adres IP próbuje logować się na wiele róznych instancji WordPressa to coś tutaj nie gra.
Ciężko jest bowiem uwierzyć, że jedna osoba posiada i nadzoruje 100 innych stron.
Dzięki temu proaktywnie blokujemy dostęp potencjalnie niebezpiecznym osobom.
2FA
Inna opcja, która według mnie powinna zostać wbudowana do standardowej instalacji to dwuskładnikowe uwierzytelnienie.
Czyli - oprócz loginu i hasła uzytkownik musi podać dodatkowy składnik.
Tutaj opcje są różne.
Może to być kod SMS, jednorazowy kod ze specjalnej aplikacji na telefon czy po prostu przepisanie klucza z wiadomości email.
Dzięki temu - nawet jeżeli ktoś wykradnie nasze hasło przy pomocy ataku phishingowego - nie będzie w stanie wykorzystać go do zalogowania się na nasze konto.
Dalej - jeżeli jesteśmy jedynymi autorami bloga i tak się składa, że nasz dostawca Internetu udostępnia nam stały adres IP - możemy zablokować dostęp do panelu administrator tylko dla tego konkretnego adresu.
Dzięki temu nawet jeżeli ktoś posiada nasze dane do logowania nie będzie mogł ich wykorzystać.
Oczywiście - ma to swoje minusy.
Wtedy to treści będziemy mogli edytować jedynie z poziomu tego jednego, konrketnego dostawcy Internetu.
Problematyczne są również sytuacje, w których nasz adres IP się zmienia.
Geolokalizacja
Niejakim rozszerzeniem tego zabezpieczenia jest geolokalizacja użytkowników.
Jeżeli nasz serwis jest po polsku i tylko w takim języku sprzedajemy nasze produkty mało prawdopodobnym jest, iż ktoś z Francji będzie chciał korzystać z naszej oferty.
Takie podejście ma swoje minusy.
Po pierwsze Polacy mogą mieszkać również poza granicami naszego kraju - wtedy stracą dostęp do naszej treści.
Po drugie - nie powstrzyma to zaawansowanych atakujących, którzy przecież mogą wykupić serwer w Polsce i z niego kierować ataki w naszą stronę.
Standardowo, WordPress w kilku miejscach zwraca numer wersji, która jest aktualnie używana na naszej stronie.
Jest to potencjalnie interesująca infromacja dla atakujących.
Jeżeli bowiem pojawi się jakaś nowa podatność na konkretną wersję WordPressa, będą oni mogli poszukiwać potencjalnych celów ataku koszystając z wyszukiwarek.
One to zaindeksują numer wersji z której korzystamy - warto więc usunąć tą informację.
Dalej - strona to nie tylko tekst ale także pliki graficzne.
Zazwyczaj są one przechowywane w specjalnie przeznaczonym do tego celu katalogu.
W przypadku prawidłowo skonfigurowanego WordPressa, tylko te katalogi pozwalają na zapisywanie w nich nowych plików.
Przez to zachowanie, to właśnie tam najczęściej trafiają złośliwe pliki w przypadku wykorzystania jakiejś podatności.
Wykorzystanie luk bowiem zazwyczaj przebiega dwuetapowo.
Najpierw zdobywa się dostęp do systemu a następnie zapisuje w nim nowy plik php - tak zwany backdoor.
On to przyjmuje komendy od atakującego a następnie je wykonuje.
Dzięki temu - ktoś kto raz uzyskał dostęp do naszej strony, nie musi za kazdym razem korzystać z podatności, a odnosi się bezpośrendio do wysłanego wcześniej pliku.
Jeżeli zablokujemy możliwyość wykonywania plików php w katalogach z mediami - znacząco utrudnimy życie przestępcom.
Będą mogli umieścić złośliwy plik na naszym serwerze ale nie da im on żadnej wartości.
Edytor plików
Nie zawsze podatności bezpośrednio prowadzą do możliwości wykonania zdalnego kodu na atakowanym serwerze.
Czasami uzyskuje się jedynie dostęp do konta administratora.
Tylko, że w przypadku WordPressa jest to równoznaczne z możliwością wykonania dowolnego kodu.
Dlaczego? Ponieważ posiada on wbudowany edytor plików.
Dzięki niemu możemy z poziomu interfejsu webowego zmodyfikować dowolny plik szablonu czy rozszerzenia bez logowania się poprzez ssh lub też ftp.
A ponieważ rozsrzerzenia to pliki PHP - jeżeli możemy je edytowac - możemy dodać do nich dowolny kod.
Z jednej strony wygoda - z drugiej dodatkowy punkt dla atakujących.
Można zatem wyłaczyć tą opcję dodając stałą DISALLOW_FILE_EDIT w pliku wp-config.php
Wtedy to modifykacja plików nie będzie możliwa.
wp-login.php
Inna opcja to zmiana adresu pliku wp-login.php.
Jeżeli bowiem chcemy się zalogować - korzystamy własnie z tego adresu.
Jest to więc swego rodzaju zabezpieczenie poprzez zaciemnienie.
Możemy zmienić nazwę tego pliku na taką znaną tylko nam.
Wtedy nawet jeżeli ktoś pozna nasze dane do logowania - nie będzie wiedział gdzie je wpisać.
Kolejna drobna przeszkoda przed atakującymi.
Jeżeli Twoja strona to tylko prosta wizytówka rozważ wyłączenie opcji rejestracji i komentowania.
Jak opowiadałem na samym poczatku - sporo odnajdowanych podatności wymaga posiadania konta w serwisie.
Jeżeli wyłączysz rejestrację - jedyną osobą posiadającą konto będziesz Ty oraz inne, upoważnione przez ciebie osoby.
Zmniejsza się zatem wektor ataku - gdyż atakujący musiałby w inny sposób uzyskać dostęp do panelu administratora.
Serwer powinien zostać skonfigurowany w taki sposób, aby nie wyświetlał listy plików, które znajdują się w danym katalogu.
Może Cię to uchronić przed zaindeksowaniem przez wyszukiwarkę plików, które znalazły się w katalogu przez pomyłkę.
Integralność plików
Niektóre narzędzia pozwalają sprawdzać integralność naszej instalacji.
Po ich zainstalowaniu tworzą one wewnętrzną liste wszystkich plików na naszym serwerze wraz z ich sumami kontrolnymi.
Następnie cyklicznie - co zdefiniowany czas - cała procedura jest ponawiana.
Wtedy to można porównać czy jakiś plik został dodany, zmieniony czy też usunięty.
Dzięki temu - w ostateczności - jeżeli jakiś atakujący uzyskał dostęp do naszego serwera - jesteśmy w stanie dostrzec jakie zmiany w nim poczynił.
Kradzione szablony
Na sam koniec warto wspomnieć o wersjach nulled rozszerzeń i szablonów.
Są to nieautoryzowane kopie płatnych skryptów, które można znaleźć za darmo w Internecie.
Odradzam jednak używanie tego rodzaju plików.
Po pierwsze jest to nielegalne i nieetyczne.
Co więcej - nigdy nie mamy pewności, czy w kodzie źródłowym takiego rozserzenia nie znajduje sie dodatkowy złośliwy kod.
XMLRPC
Ostatnim punktem na liście jest wyłączenie protokołu XMLRPC.
Powstał on dawno temu, kiedy to stały dostęp do Internetu nie był taki popularny jak dzisiaj.
W tamtych czasach wpisy na bloga pisało sie offline.
Następnie w momencie publikacji odpowiednia aplikacja wysyłała żądanie do serwera - tworząc nowy wpis.
W dzisiejszych czasach, opcja ta jest wykorzystywana jeżeli korzystamy z mobilnego interfejsu zarządzania na telefon komórkowy.
Jeżeli jednak nie korzystamy ze zdalnego zarządzania - warto ją wyłaczyć.
Dlaczego?
Ponieważ protokół ten może być wykorzystany w atakach typu brute force.
Normalnie, aby sprawdzić czy podany login i hasło jest prawidłowy musimy wysłać do serwera jedno żądanie.
Jeżeli chcemy sprawdzić 100 takich kombinacji - konieczne jest wysłanie 100 żądań.
A każde z nich swoje trwa.
W przypadku protokołu XMLRPC - serwer może sprawdzić kilka kombinacji naraz, co znacząco przyspiesza tego rodzaju atak.