Odwirusowywanie strony w praktyce

Nie ka偶dy zdaje sobie z tego spraw臋, ale podobnie jak komputery, tak i strony internetowe mog膮 艂apa膰 wirusy. Niedawno zg艂osi艂 si臋 do nas po pomoc nowy klient. Temat bardzo pal膮cy i trudny, bowiem jego istniej膮ca witryna na WordPressie zosta艂a zaatakowana, atakuj膮cy uzyskali dost臋p do plik贸w i umie艣cili na stronie wirusy.

 

W toku szybkiej rozmowy uda艂o si臋 ustali膰, 偶e:

– Pierwszy atak nast膮pi艂 jaki艣 czas temu

– Dostawca hostingu za op艂at膮 mia艂 usun膮膰 problem

– W trakcie tego usuwania cz臋艣膰 funkcjonalno艣ci strony (np. edycja slidera) znikn臋艂a

– Po nieca艂ych 2 tygodniach wirusy wr贸ci艂y

 

Najpierw przyjrzeli艣my si臋 objawom. Wirus najbardziej widoczny by艂 oczywi艣cie w nag艂贸wku strony:

 

 

Dla osoby postronnej mo偶e to wygl膮da膰 jak losowy ci膮g liczb, w rzeczywisto艣ci jest to zakamuflowany kod. Cz臋艣膰 z niego z jakiego艣 powodu by艂a ewidentnie widoczna dla u偶ytkownik贸w (czy to z winy b艂臋du atakuj膮cego, czy te偶 nieudanej operacji usuwania dostawcy hostingu).

 

Innym objawem, ci臋偶szym do pokazania na obrazku, by艂y losowe przekierowania do stron niebezpiecznych (klasyczny spam). Konsola przegl膮darki drukowa艂a 艂adowanie dziwnych zasob贸w (domeny .xyz, adonline).

 

W katalogach strony znalaz艂a si臋 ca艂a masa dziwnych plik贸w, nie pochodz膮cych ani od WordPressa, ani u偶ywanego szablonu. Zawiera艂y przedziwne tre艣ci, cz臋sto zaszyfrowane, a czasem z pozoru bezsensowne:

 

 

 

Przyst膮pili艣my do operacji odwirusowywania, kolejno:

– Usuwaj膮c wszystkie istniej膮ce konta u偶ytkownik贸w i tworz膮c je na nowo, z trudniejszymi loginami i has艂ami

– Usuwaj膮c wszystkie pliki wirusa z serwera

– Blokuj膮c publiczne REST API instancji WordPressa

– Wycinaj膮c domyslny mechanizm xmlrpc

– Zmieniaj膮c dane logowania do hostingu i zamykaj膮c luki po stronie dostawcy

– Wprowadzaj膮c dwuetapowe uwierzytelnianie przy logowaniu, z blokad膮 po 3 nieudanych pr贸bach

– Blokuj膮c mo偶liwo艣膰 automatycznego listowania login贸w autor贸w artyku艂贸w

– Usuwaj膮c widoczny na stronie kod wirusa

 

Po takiej operacji problem faktycznie znikn膮艂, strona przyspieszy艂a i wszystko wydawa艂o si臋 i艣膰 ku dobremu. Przyst膮pili艣my do etapu drugiego, czyli naprawiania brakuj膮cych funkcjonalno艣ci, kiedy spotka艂a nas niespodzianka: wirus wr贸ci艂. Niemal偶e w czasie rzeczywistym mo偶na by艂o zoabserwowa膰, jak si臋 powoli odbudowywuje i generuje wszystkie pousuwane pliki nale偶膮ce do niego.

 

Takie przypadki wymagaj膮 zawsze odrobiny logiki.

 

Wiedzieli艣my, 偶e nie jest to r臋czna operacja – w tym okresie definitywnie nikt inny nie mia艂 dost臋pu do instancji. W trakcie prac nad sliderem co艣 musia艂o uaktywni膰 na nowo mechanizm wirusa.

 

Okaza艂o si臋, 偶e mamy do czynienia z atakiem typu Hydra – wirus wstrzykuje sw贸j zaszyfrowany kod w losowe pliki JS oraz PHP. Wywo艂anie dowolnej jednej kopii odpala go na nowo, a pierwsza procedura to sprawdzenie kt贸rych jego cz臋艣ci ju偶 nie ma i stworzenie ich na nowo.

 

 

Jak poradzi膰 sobie z takim problemem? Przede wszystkim trzeba zapobiec odrastaniu g艂贸w potwora, w przeciwnym razie mo偶na walczy膰 z nim w niesko艅czono艣膰. Za pomoc膮 FTP na czas prac zablokowali艣my mo偶liwo艣膰 zapisu do wszystkich plik贸w i katalog贸w. Nast臋pnie r臋cznie weryfikowali艣my pliki szablonu, ka偶dej wtyczki oraz samego WordPressa, wycinaj膮c podejrzane elementy i nadpisuj膮c pliki.

 

Kiedy kt贸ry艣 plik lub linia kodu by艂y niejasne (wygl膮da艂y dziwnie, ale nie musia艂y pochodzi膰 od wirusa), por贸wnywali艣my je z pobranymi czystymi kopiami szablonu oraz wtyczek. Je艣li oficjalne wersje si臋 r贸偶ni艂y, wiedzieli艣my 偶e sporne fragmenty strony by艂y modyfikowane. W teorii mogli艣my po prostu z marszu nadpisywa膰 wszystko czystymi kopiami, ale chcieli艣my wiedzie膰 gdzie i jak dok艂adnie wirus dzia艂a艂.

 

艁膮cznie wirus doklei艂 sw贸j zaszyfrowany kod w ponad 70 plikach, a my mieli艣my ju偶 jasno艣膰, co dok艂adnie mia艂o miejsce 2 tygodnie wcze艣niej.

 

Dostawca hostingu procedur臋 usuwania wykona艂 automatycznym narz臋dziem (clamav), kt贸re po prostu usuwa艂o wszystkie zainfekowane pliki. Jako 偶e wirus dokleja艂 sw贸j kod do bogu ducha winnych wtyczek, cz臋艣膰 z nich przesta艂a dzia艂a膰, gdy偶 skaner wyci膮艂 pliki tych wtyczek w ca艂o艣ci. Jednocze艣nie pomin膮艂 co najmniej jedn膮 instancj臋 wirusa, przez co ten wr贸ci艂. Czemu po 2 tygodniach, a nie wcze艣niej? Bardzo proste – dok艂adnie wtedy klient w panelu administratora WordPressa odpali艂 jak膮艣 opcj臋, kt贸ra wywo艂a艂a zainfekowany kod.

 

Pozostaje pytanie, czemu skaner nie usun膮艂 wirusa na dobre. Kasuj膮c ca艂e pliki powinien w teorii wy艂apa膰 ka偶de jego wyst膮pienie. I tak rzeczywi艣cie by艂o – skaner znakomicie poradzi艂 sobie z szybk膮 analiz膮 PLIK脫W. Jednak wirus dokleja艂 si臋 te偶 w miejscach, kt贸re nie s膮 w WordPressie faktycznymi plikami, jak np. w tre艣ci ka偶dego wpisu i innych miejscach bazy danych (widoczne w widoku HTML):

Prawdopodobnie to w艂a艣nie edycja, przez klienta, kt贸rego艣 ze starszych wpis贸w wywo艂a艂a infekcj臋 na nowo po 2 tygodniach.

 

Po r臋cznej weryfikacji ka偶dego pliku WordPressa (w tym panelu administratora), szablonu i wtyczki jeszcze raz wykonali艣my gruntowne procedury, w tym ponowne stworzenie nowych u偶ytkownik贸w i usuni臋cie starych – na wypadek, gdyby cz臋艣膰 kodu wirusa zapisywa艂a lub wysy艂a艂a gdzie艣 has艂a. Jako 偶e Hydra wywo艂a艂a si臋 na nowo przed r臋cznym przegl膮danie plik贸w, za艂o偶yli艣my po jego zako艅czeniu 偶e stron臋 traktujemy jak 艣wie偶o zaatakowan膮 a偶 do ko艅ca ponownej procedury zabezpieczaj膮cej.

 

Na wszelki wypadek prawa zapisu plik贸w odblokowali艣my jedynie dla katalogu /wp-content/. Pozwala to klientowi instalowa膰 wtyczki, motywy i wgrywa膰 obrazki, a przy tym gwarantuje 偶e nic, nigdy i w 偶aden spos贸b nie wyedytuje ju偶 plik贸w samej instalacji WordPressa.

 

Od czasu interwencji min臋艂y ju偶 kolejne 2 tygodnie, a strona klienta dzia艂a bez zarzutu. Po wirusach nie ma 艣ladu, 艂aduje si臋 szybciej ni偶 kiedykolwiek, jest bezpieczna jak ska艂a na przysz艂o艣膰 i odzyska艂a pe艂n膮 funckjonalno艣膰.