Wtyczki (nie)bezpieczeństwa dla WordPressa cz. 1/3

Typowy poradnik bezpieczeństwa WordPressa wygląda mniej więcej tak, że odpalasz Youtuba, przychodzi jakiś bloger, poleca wtyczkę bezpieczeństwa, którą sam używa, lub od której odpalą mu procent, i wmawia wam w kilkuminutowym filmie, że to jest rozwiązanie na wasze wszystkie problemy z pola security WP. W porównaniu z poradnikami prawdziwych specjalistów, którzy posługują się językiem wysoko technicznym, te pierwsze filmy wygrywają w zasięgach. Dzieje się tak dlatego, że ludzie nie rozumieją technicznych zagadnień, a bloger mówi im w prostych słowach, co chcą usłyszeć: Zainstaluj to i zero problemów. Chciałbym, żeby takie rozwiązania działały w naszym wymiarze, ale nasze uniwersum z natury nie jest monochromatyczne, dlatego przyjrzymy się dziurom bezpieczeństwa we wtyczkach… od bezpieczeństwa.

Żeby było jasne nie potępiam żadnego plugina od security, bo wychodzę z założenia, że lepsze byle jakie zabezpieczenie niż jego brak. Niemniej jednak chciałbym wam zwrócić uwagę, że sama wtyczka bezpieczeństwa może posiadać dziury i nie warto wierzyć we wszystkie marketingowe banialuki o stuprocentowym bezpieczeństwie.
Lista wtyczek, jaką zobaczysz jest subiektywna i dotyczy 9 pierwszych wyników (w tej części 3/9) z wordpress.org po wpisaniu „security” w pole wyszukiwania wtyczek. Same dziury są opisane na podstawie stron: www.cvedetails.com, www.exploit-db.com, www.vuldb.com i cve.mitre.org

Wordfence Security

Absolutny lider wśród wtyczek bezpieczeństwa, jeśli spojrzymy na ilość instalacji. Skąd się bierze fenomen tej wtyczki? Nie wiem, ale przyznam się, że dawno temu sam uległem czarowi marketingowej propagandy i myślę, że większość wordpressowych devsów miała taki moment w swoim życiu. Czar trwał, dopóki jedna z moich ówczesnych witryn nie została zhakowana przez jakiegoś cyber-łobuza z Ukrainy, a przynajmniej na to wskazywały logi serwera.
Nawet w opisie wtyczki Wordfence sugeruje, że Twoja witryna jest bezpieczna, a ich wtyczka jest najlepsza na świecie… ? Jedyny plus Wordfence to ich blog o bezpieczeństwie i polecam go każdemu, kto na serio przejmuje się bezpieczeństwem swojej strony opartej na CMSie WordPressa.

Dziury

2020
Błąd opublikowany przez niejakiego Mehrano Feiziego na łamach exploit-db, ale niezweryfikowany i bez przydzielonego numeru CVE. Szczerze to nie wiem, co myśleć o tym błędzie, bo o samym autorze w sieci jest niewiele, a swoje odkrycia publikuje dopiero od niecałego roku. Sam błąd oznaczono jako EDB-ID:48061 i rzekomo dotyczy biblioteki wordfenceClass.php. Skoro jednak został opublikowany, to uznałem, że warto o nim wspomnieć, a ocenę zostawiam wam.

2019
Exploit (CVE-2019-9669) opisany oryginalnie przez edgescan.com, dotyczył ataku XSS i został opisany pod numerem CVE-2019-9669. Dla nieświadomych wyjaśniam, że XSS to atak Cross-site scripting, który pozwala na wstrzykiwanie kodu z zewnątrz (z reguły JS) i wykonania nieautoryzowanego działania. Na stronie edgscan.com znajdziecie przykłady złośliwych payloadów. Błąd dotyczył wersji 7.2.3

2014
Dziura znaleziona w starej wersji Wordfence, a mianowicie w 5.2.3, a na moment pisania tego posta ostatnia wersja była oznaczona numerem 7.4.11, więc jeśli aktualizujesz wtyczki, to nie masz się czego obawiać. Sam exploit mógł służyć do przejęcia ciasteczek z sesji admina. Więcej info znajdziecie tutaj.

Warto wspomnieć, że serwis vuldb.com wspomina o dwóch podatnościach z 2014 roku, które też dotyczyły ataku XSS. Pierwszy bag dotyczył wersji 5.1.1 (CVE-2014-4664), a drugi 5.1.4 (CVE-2014-4932). Bez numeru CVE ciężko orzec jednoznacznie, czy błąd opisywany powyżej (dla wersji 5.2.3) nie jest którymś z tych wspomnianych przed chwilą. Jednak jest to mało prawdopodobne, a to oznacza 3, mniej lub bardziej poważne, podatności XSS w ciągu jednego roku.

2012
Bug z października 2012 także dotyczył ataku XSS i w konsekwencji dotyczył przejęcia ciasteczek użytkownika, więc jak końcowy odbiorca był adminem strony, to pozamiatane. Pierwsze wzmianki o błędzie zostały umieszczone w serwisie securityfocus.com. Jak widać, Wordfence bardzo lubi się z XSSem 😉 Sam błąd dotyczył archaicznej wersji 3.3.5.

Jetpack

Jetpack sam w sobie nie jest zaprojektowany stricte jako wtyczka bezpieczeństwa, ale raczej przedstawia się jako wtyczka od wszystkiego. A jak coś jest od wszystkiego, to jest do niczego i Jetpack jest tego świetnym przykładem. Moim skromnym zdaniem to jedna z najczęściej kompromitowanych wtyczek w historii WordPressa, a mimo to ma ponad 5 mln aktywnych instalacji. Czy ludzie są tak naiwni, czy może lubią, kiedy ich strona zamula i jest nafaszerowana exploitami, które zaraz ktoś ogłosi? ? Nie wiem, dlatego przejdźmy do dziur.

Dziury

2018
W tym roku odnotowano buga (CVE-2018-20966), jednak działał on tylko z wtyczką WooCommerce. Rodzajem ataku był XSS, tylko dotyczył strony z produktami w sklepie.

2016
W 2018 roku też opublikowano dwie podatności, CVE-2016-10706 dotyczyło ataku XSS przez link z serwisu Vimeo, a druga, CVE-2016-10705, dotyczyła ataku XSS przez moduł lajków. Obydwie podatności dotyczyły jednak wersji plugina z 2016 roku i w tym samym roku zostały załatane.

2015
Typowy rok i typowy XSS. Dziura oznaczona jako CVE-2015-9359 dawała okazję nieautoryzowanego wykonanie kodu z zewnątrz. Dotyczył on starej wersji 3.4.3.

2014
W tym roku odnotowano tylko jeden błąd, ale dotyczył on bezpośrednio XML-RPC, czyli jednego z najbardziej wrażliwych elementów WordPressa. Z tego, co można się dowiedzieć z sieci, sprawę pierwsze opisały securityfocus.com (BID:66789) i secunia.com (SECUNIA:57729) i tam znajdziecie więcej szczegółów.

2011
Ten rok obfitował tylko w jednego buga (CVE-2011-4673), ale za to groźnego, bo SQL Injection. SQL Injection w wielkim skrócie to nieautoryzowane wykonanie zadań w bazie danych lub wyciągnięcie z niej informacji, które nie powinny być dostępne publicznie.

All In One WP

Prawie milion subskrypcji może robić wrażenie, ale ja nie mam o tej wtyczce gorszego lub lepszego zdania. Jeśli mnie ktoś pyta o wtyczkę bezpieczeństwa, to odpowiadam jak z antywirusami – bierz coś z pierwszej dziesiątki. Coś co ci będzie pasowało. Swoją drogą nie przypominam sobie większych podatności w przypadku tego plugina, ale sami autorzy piszą, że ich wtyczka wyniesie bezpieczeństwo na wyższy poziom. Dlatego zobaczmy, na jakim poziomie były podatności dotyczące tego dodatku do WordPressa.

Dziury

2016
W 2019 roku opisano kilka błędów z 2016 roku, które oznaczono odpowiednio CVE-2016-10888, CVE-2016-10887, CVE-2016-10868, CVE-2016-10867 i CVE-2016-10866. Trochę dużo jak na jeden rok. Tym bardziej, że dwa pierwsze dotyczą SQL Injection, a trzy pozostałe XSS w różnych wariantach. Słabo jak na bezpieczeństwo na wyższym poziomie…

2015
W 2015 nie było lepiej i znowu opublikowano 2 x informację o błędach, które ułatwiały atak SQL Injection, a zostały oznaczone jako CVE-2015-9310 i CVE-2015-0894. Do tego doszły dwie podatności na różne warianty ataków XSS i jedna wrażliwa na atak typ CSRF. W wielkim skrócie atak CSRF polega na wykorzystaniu uprawnień ofiary i tak spreparowaniu wysyłanych przez nią żądań do serwera, aby przyniosło to określone, czyli potrzebne hakerowi efekty.
Jak widać, ten rok niczego nie nauczył autorów wtyczki i przez dwa lata mieli wtyczkę dziurawą jak sito…

2014
To był słaby rok na dziury w tym pluginie, bo odnotowano tylko dwie CVE-2014-6242 i drugą nieoznaczoną.
Jedna dotyczyła SQL Injection, a druga Persistent XSS (więcej o naturze ataku znajdziesz tutaj) Twórcy chyba taki standard preferują XSS + SQL Injection 😉