Google Hack na WordPressa! Jak się bronić?

Jakiś czas temu zrobiliśmy akcję „Index of”, czyli szukaliśmy stron metodą zwaną Google Hacklub Google Dork i informowaliśmy adminów i właścicieli witryn o fakcie publicznego dostępu do wrażliwych danych i plików, które potencjalnie mogą ułatwić włamanie na stronę lub doprowadzić do incydentu RODO. Wysłaliśmy ok. 20-25 mejli z taką informacją i odpisał nam (przy okazji dziękując) tylko jeden admin strony. Część osób nawet nie zareagowała na nasze mejle i w ogóle nie zabezpieczyła stron. Niektórzy pewnie machnęli ręką, a inni nie znają się na tyle, żeby załatać tę dziurę, ale z drugiej strony nie przyznają się do tego, bo to oznacza obnażenie swojej słabości… Pomijając faktyczne powody, to nie najlepiej świadczy to o osobach, które administrują często serwisami, które żądają od nas osobistych danych. Żeby nie być gołosłownym, to wklejam przykład z życia z przełomu listopada i grudnia 2020: https://niebezpiecznik.pl/post/potezny-wyciek-polis-ubezpieczeniowych-zawartych-z-roznymi-towarzystwami/
Jeśli nie chcesz wyjść na pajaca jak osoby, które dopuściły do potężnego wycieku danych, a potem udawały, że nie ma takiej strony, to przeczytaj nasz poradnik, który w 7 punktach wskaże, na co zwrócić uwagę.

Śmietnik

W akcji „Index of” trafiliśmy na profil, który zawierał czyjeś prywatne zdjęcie z wakacji, a mieścił się w folderze o niewinnej nazwie Prywatne. Mimo wysłanej informacji nie dostaliśmy zwrotnego mejla, a potem nawet nie sprawdzaliśmy czy admin tamtej strony poprawnie spożytkował informacje od nas. Jeśli chce, żeby jego prywatne eskapady były na publicznym forum to jego sprawa. Jednak jeśli Ty należysz do osób, które chcą dbać o swoją i użytkowników prywatność, to nie traktuj serwera jak tymczasowe miejsce dla prywatnych plików, bo jeśli nawet nie zaindeksuje je Google, to mogą one wyciec w trakcie włamania. Porządek na serwerze i świadomość CMSa to podstawa bezpieczeństwa i jeśli nie wdrożysz tego u siebie, to możesz hakerów zaprosić na kawę i napisać im hasła do serwetce. Co się chłopaki będą męczyć.

Dostęp do plików

Już pisaliśmy o tym nieraz, bo jest to jedna z podstawowych rzeczy jakie trzeba zabezpieczyć w WordPressie i nie tylko ze względu na Google Dorking. Nie będziemy tu cytować gotowych kodów, bo to wszystko zależy od serwera na jakim stoi strona. Inny kod będzie dla Apache, a inny dla LiteSpeeda. Jednak podpowiemy, co możesz zrobić, żeby ograniczyć dostęp do wrażliwych plików.
Po pierwsze zweryfikuj uprawnienia folderów, bo to często jest kluczowy czynnik, który zaważy nad ryzykiem dostępu do wrażliwych danych. Informacje o najbardziej optymalnych uprawnieniach folderów znajdziesz w internecie, a same uprawnienia możesz zmienić na kilka sposobów. Jednym z nich jest bezpośredni z panelu administracyjnego np. DirectAdmin. Drugim sposobem jest zmiana przez FTP, np. w programie Filezilla, ale nie wszystkie hostingi na to pozwalają. Jeśli masz maszynę dedykowaną, to możesz chmodować uprawnienia z terminala. Żebyś zrozumiał jaki kod odpowiada jakim uprawnieniom dorzucam pomocną stronę.
Drugą rzeczą jaką trzeba zrobić to wyłączenie listowania folderów, czasem nazywanym indeksowaniem. Z reguły są na to różne dyrektywy w htaccess, dlatego musisz znaleźć odpowiednią dla swojego serwera. Najlepiej w dokumentacji dedykowanej rozwiązaniu z jakiego korzystasz.
Trzeci aspekt na jaki trzeba zwrócić uwagę to blokowanie dostępu do plików wykonywalnych PHP. Jedni preferują blokowanie najbardziej wrażliwych plików jak wp-config czy xmlrpc, a inni wszystkie pliki o rozszerzeniu php. Ja tylko zwrócę uwagę, że najbardziej optymalna jest ta druga metoda, przy czym warto ją rozszerzyć o blokadę starszych wersji PHP np. plików z rozszerzeniem php5. Dodatkowo można zablokować inne pliki, które będą wykonywalne na serwerach opartych o UNIXowe rozwiązania, np. plików bazujących na Pythonie, które mają rozszerzenie .py lub .py3.
Przy okazji można zablokować inne formaty plików, które mogą się przyczynić do wycieku danych, np. txt, xml, bak, bkp, dmp, sql…
Wszelkie podpowiedzi dyrektyw, które zabezpieczą pliki poprzez .htaccess znajdziesz w dokumentacji swojego serwera lub firmy hostingowej.

Głębokie ukrycie

Powyższy podtytuł jest niczym innym jak marketingowym bełkotem (dzisiaj noszącym znamiona informatycznej beki) użytym po raz pierwszy przez PRowców banku PKO BP, którzy nieudolnie próbowali przekonać redakcję Niebezpiecznika, że pliki ukryte w folderach o nietypowych nazwach są bezpieczne, np. jeśli użyjesz nazwy n7yl6blb8lfdr1t zamiast aktadluznikow.
Cała historia tutaj: https://niebezpiecznik.pl/post/glebokie-ukrycie-danych-w-pko-bp/
Może i jest to rozwiązanie, ale jeśli nie zabezpieczysz odpowiednio folderu, to nie ma to znaczenia dla pająka spod bandery Google. Jak jest coś do zaindeksowania i jest do tego dostęp, to zmiana nazwy folderu nie ma znaczenia, bo Google i tak wyświetli to w wynikach.
Sama taktyka głębokiego ukrycia nie jest zła jeśli robisz to z głową i podpowiemy Ci zaraz jak to my to robimy, bo sami to stosujemy.
Po pierwsze wyciągamy z pliku wp-config dane dotyczące bazy i przenosimy je w zew pliku do innego folderu. Folder ten ma z reguły losową nazwę, uprawnienia ustawione na 500 i dostęp do niego zwraca kod 403, co zmniejsza ryzyko wycieku danych w przypadku dostępu do piku wp-config. W naszym poradniku o bezpieczeństwie WordPressa, który znajdziesz na tym blogu, dowiesz się jak to zrobić.
Innym przykładem jest zmiana nazwy folderu wtyczek. Oczywiście Google jak będzie chciał to zaindeksuje tę ścieżkę, ale odsiewa to automatyczne boty, które skanują serwis pod kątem standardowych linków, czyli plugins. Pamiętaj, żeby zabezpieczyć w tym przypadku też dostęp do wrażliwych plików jak w akapicie o Dostępie do plików.

Backup na serwerze

Kolejny błąd adminów lub właścicieli witryn to trzymanie kopii zapasowych na tym samym serwerze co strona. Błąd, bo często niezabezpieczenie dostępu do plików wyłoni taki backup, który z założenia ma być tylko dla nas, na światło dzienne i będzie dostępny dla każdego, a zwłaszcza dla hackerów.
Jeśli nawet zabezpieczymy stronę, to nie oznacza, że kopia jest bezpieczna, ponieważ bot włamując się na stronę i infekując jej kod od razu zainfekuje backup. Potem mimo przywrócenia kopii zapasowej nasza strona ciągle jest dostępna dla niepowołanych ludzi.
Jeśli już musisz robić backup na serwerze ręcznie lub automatycznie, pamiętaj, żeby go ściągnąć na komputer, a kopię z serwera usunąć.

Backup w chmurze

To jest jakieś rozwiązanie, bo na pewno uchroni zaindeskowanie przez Google kopii zapasowej na naszym hostingu, ale z drugiej strony, jeśli korzystasz z zewnętrznego serwera i nieumiejętnie zabezpieczysz na nim kopie, to też istnieje ryzyko, że Google go tu znajdzie. Dlatego jeśli nie potrafisz bezpiecznie konfigurować backupu w cloudzie, to korzystaj z automatycznych, ale zaufanych rozwiązań. Swoją droga niebawem na naszym firmowym blogu, który właśnie czytasz, pojawi się taki poradnik.

Robots.txt

Dziwi mnie jeszcze, że są tak naiwni admini, którzy wierzą, że jak wrzucą jakiś link do pliku robots.txt to uchronią wrażliwe dane. Może faktycznie pająk Google posłucha i nie pójdzie w to miejsce, ale jednocześnie innym złośliwym botom dajesz znak, że jest tam coś ciekawego, co potencjalnie może się przydać atakującemu. Tak wygląda plik robots.txt banku PKO BP (tak tego samego od głębokiego ukrycia), który zabrania botowi od Google indeksowania folderu test123, gdzie prawdopodobnie testuje się nowe webaplikacje wchodzące potem w skład strony tego banku. Nic tylko pogratulować….

Najlepszym rozwiązaniem jest w ogóle nie dodawać takich bardzo wrażliwych linków do pliku robots.txt, a porządnie je zabezpieczyć (jak w akapicie z Dostępem do plików). Wtedy Google zaindeksuje 403 lub 401, a nie oryginalną zawartość folderu. Żeby zmniejszyć dodatkowo ryzyko, można usunąć lub wykluczyć wrażliwe adresy z mapy strony oraz z wtyczki lub CDNa, który będzie odpowiedzialny za cache naszej witryny.

Testuj stronę

Za każdym razem, gdy ktoś zleci nam zabezpieczenie strony, np. wykupując pakiet SEO Firewall, jednym z testów jakie wykonujemy podczas audytu strony jest właśnie podatność na Google Hacking. Pomaga nam to spojrzeć na stronę, nad którą przyszło nam pracować w kompleksowym i szerszym spektrum, dlatego Tobie też sugeruję wykonywać takie testy i wpisać je sobie w plan cyklicznych audytów. To naprawdę pomaga, bo możesz być pewny, że wszystko dobrze zabezpieczyłeś, a podczas testów sobie to zweryfikujesz. Jesteśmy tylko ludźmi i popełniamy błędy, nawet jak nam się wydaje, że jest inaczej, więc sprawdzanie naszych działań powinno być na porządku dziennym. Tym bardziej w takim żywym organizmie jak WordPress.
Jedną z najlepszych baz z jakich korzystamy w tej materii jest https://www.exploit-db.com/google-hacking-database a resztę sobie wygooglasz .