WordPress to niewątpliwie wspaniały system zarządzania treścią. Jestem szczęśliwy, że mogę używać go od wielu lat jako bazę dla moich stron internetowych. Jednak jak każdy system zarządzania treścią pozwalając – jak sama nazwa mówi – na zarządzanie treścią – ma drzwi. A drzwi to słaby punkt. Jeszcze słabszym są okna a takowe także ma. Oczywiście to konsekwencja tego za co kochamy CMS-y, czyli ich możliwości zarządzania treścią. Choć brzmi to może trochę enigmatycznie, zaraz sprawę wyjaśnię…
Historia prawdziwa.
Był 07 lutego 2017 r. Jak codzień wszedłem na swoją stronę aby dodać coś nowego do portfolio, lub napisać coś na blogu. Jednak szybko zapomniałem po co na nią wszedłem. Moim oczom zamiast ostatniego artykułu o bezpieczeństwie ukazał się napis, którego nie będę tutaj cytował po prostu go pokażę:
Niecenzuralne słowa zostały przeze mnie zamazane, gdyż akurat te, choć w obcym języku są wszystkim doskonale znane:)
Pomyślałem sobie – pięknie. Chciałem właśnie napisać kolejny artykuł o bezpieczeństwie, a tu ktoś właśnie potwierdził moje słowa, że nie ma stuprocentowego sposobu na zabezpieczenie w jakże bolesny sposób. Nie żebym dowiedział się w tej chwili czegoś nowego, ale dlaczego akurat ja? Nie ma już kogo atakować? 😀 Tyle pracy, tak wiele zachodu, drzwi stalowe, z zamkiem biometrycznym, okute i zaryglowane, a ktoś wlazł do środka. Jakim cudem? Przecież to niemożliwe… A jednak. Nie drzwiami – oknem. Szybko jednak dodam, że wcale nie wlazł do środka, tylko wrzucił kamień i wybił szybę wystawową. Zatem wszystkie zabezpieczenia jakie miałem nie okazały się bezskuteczne i nie było tak źle jak się mogło wydawać. Strona była względnie bezpieczna, choć ostatni artykuł został zniszczony (odwracalnie)… Ale nie uprzedzajmy faktów.
Tutaj warto zatrzymać się na chwilę aby wyjaśnić wszystkim moim czytelnikom pogmatwany nieco wstęp do tego artykułu. Otóż CMS (Content Management System – System Zarządzania Treścią) posiada bo posiadać musi drzwi. Jak inaczej klient, który chce zarządzać swoją stroną ma się do niego zalogować? Musi posiadać bramę w której podasz login i hasło, a więc posłużysz się kluczem. Brama może być tak jak w moim przypadku zamknięta na sto spustów i zamki biometryczne, ale istnieje jeszcze coś takiego jak okno (poza tym i tak każde drzwi są do sforsowania solidnym łomem;). Oknem nazwiemy tu lukę w zabezpieczeniach programu, niestety dotąd nie znaną. Problem z przyrównaniem do rzeczywistego życia jest taki, że w swoim domu wiesz ile masz okien. W CMS mogą pojawić się nowe których świadom nie jesteś. Głupio to brzmi, prawda? Nie wiem ile mam okien, to jak mogę się zabezpieczyć? Dlatego może lepiej przyrównać to nie do domu, a do mrowiska. Mrówki ryjąc sobie pogmatwane tunele w ziemi czasem mogą spowodować otwarcie się nowych wejść. Jedne z nich powstaną bo kopały za blisko powierzchni, inne powstaną bo ktoś inny rył w pobliżu ich korytarzy i wreszcie nieraz dokopią się do nowych systemów korytarzy, które nie wiadomo gdzie prowadzą, nie są zbadane i mogą zawierać wiele innych nowych tuneli z nowymi wejściami. Jakbym nie rozbudowywał tego obrazka na którym chcę oprzeć omawiany problem jest to sprawa skomplikowana i dość trudna do zilustrowania. Ale sens i istotę problemu na pewno już rozumiesz. Możesz nie być świadom tego ile luk pozostało w systemie jaki ktoś dla ciebie stworzył a takim niezwykle skomplikowanym systemem dróg i możliwości m.in. WordPress jest. Dobra wiadomość jest taka, ze twórcy WP i mnóstwo osób współtworzących go cały czas pełną parą walczy z nowymi zapadającymi się korytarzami i dlatego najczęściej sami jesteśmy winni tego, że system pozostanie dziurawy, pomimo iż drzwi zamkniemy na sto spustów a nie „zamkniemy okien” dzięki aktualizacjom. Nasza wina polega na braku czujności, które nazywają się aktualizacjami. To one łatają nasz system operacyjny (np.: Windows), programy antywirusowe a także system na jakim oparta jest strona, czyli system WordPress. Zatem możemy teraz wrócić do wątku co zrobić kiedy ze zgrozą odkryjecie że ktoś włamał się na wasz system…
Co zrobić? Zachować spokój, ale działać szybko i konkretnie!
Pierwsze co zrobiłem, kiedy zauważyłem wtargnięcie na swoją stronę, to musiałem mieć pewność, czy ktoś wszedł do środka i czy użył do tego drzwi czy okna. Jeśli wszedł do środka – wszystko na serwerze jest spalone. Baza danych, pliki strony, być może i kopie na serwerze. Wszystko. Jeśli jest kopia na nośniku offline to pół biedy, kiedy jej brak, czeka nas łatanie i rycie. Kiedy ktoś wejdzie do środka, to najgorsza ze wszystkich możliwości. Nie wiesz wtedy jakie zniszczenia wyrządzi, jakie furtki otworzy i co pozostawi otwarte. Może się to mścić na tobie długi czas. Jednak kiedy tylko wrzuci kamień przez okno, wiesz gdzie zniszczenia się zaczynają i gdzie kończą. Mój przypadek należał szczęśliwie do tego właśnie lżejszego.
Pierwsza czynność – natychmiast popraw wizualny aspekt strony. Nikt nie ma prawa zobaczyć na mojej stronie obraźliwych sformułowań niezależnie od języka w jakim są one podane. Takie wybite okno nie jest dobrą wizytówką. Można do tego celu użyć wtyczki Maintenace – pokazującej, że strona jest w trybie serwisowania. Ja tego robić nie musiałem. Błyskawicznie udało mi się wycofać zmiany jakie naniesiono. Było to łatwe, gdyż obejmowały wyłącznie ostatni wpis, a zatem jego usunięcie to dwa kliknięcia. To od razu dało do myślenia, że szkody są za małe jak na włamanie do zaplecza. Co więcej i równie ważne Google również nie może zaindeksować „bredni” jakie ktoś powypisywał na stronie. Każda minuta się liczy w tej materii!
Druga sprawa, wszystko notuj. Zanotuj godzinę poprzednich odwiedzin na twojej stronie kiedy wszystko było dobrze, oraz godzinę zauważenia skutków ataku. To bardzo ważne. Ustalisz w ten sposób przedział czasowy kiedy mogło dojść do ataku a to nieocenione, kiedy trzeba będzie śledzić logi serwera. Natychmiast zalogowałem się do Direct Admin i pobrałem logi serwera. Ich przeglądanie nie należy do przyjemnych… Jest to żmudny proces kiedy nie wiesz czego szukać. Ten który ja miałem do przejrzenia miał o ile dobrze pamiętam ~ 10.000 do 20.000 wpisów. Każda godzina to kolejne tysiące wpisów w logach. Śledzenie pobranych logów odkładam na chwilę…
Trzecim krokiem było natychmiastowe przeskanowanie wszystkich plików newralgicznych dla szablonu. Strona bowiem powinna natychmiast wrócić online. Sprawdzenie nagłówka i stopki przed wpisami których tam być nie powinno – ręcznie – jeśli znamy się na rzeczy. Skanując za pomocą skanerów online jak np.: Sucuri SiteCheck da też w miarę konkretny obraz sytuacji ale nie do końca jest to wiarygodne, zwłaszcza kiedy wpis siedzi w bazie danych.
Kolejny krok – czwarty to daty modyfikacji plików. Choć wprawny włamywacz potrafi zatrzeć ślady i zmienić daty modyfikacji plików tak aby nic nie wskazywało na modyfikację, trzeba od tego zacząć. Logujesz się przez ftp i sprawdzasz daty modyfikacji plików. W moim przypadku – czysto. Wszystko pozornie nietknięte.
Na tym etapie ustaliłem, że atak objął tylko zastąpienie ostatniego wpisu bezeceństwami. Na stronę najpewniej nikt się nie włamał. Tak pliki jak i struktura strony nie wykazywały żadnych nieprawidłowości. Strona wróciła online, ale i tak była spalona. Wiedziałem że za moment przywrócę ją w całości z kopii bezpieczeństwa offline. Pozostało ustalić co się stało i ważne jest aby ustalić to szybko na miejscu zdarzenia, gdyż po przywróceniu strony z kopii mam mniejsze szanse na sensowne działania…