Weryfikowanie, czy w pełni usunąłem hack WordPress?

105

Mój fajny blog WordPress na http://fakeplasticrock.com (z WordPress 3.1.1) został zhakowany - wyświetlał się <iframe>na każdej stronie tak:

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Zrobiłem następujące

  1. Aktualizacja do wersji 3.1.3 poprzez wbudowany system aktualizacji WordPress
  2. Zainstalowałem skaner Exploit (wiele krytycznych ostrzeżeń o nietypowych plikach) i program antywirusowy (wszystkie były czyste i zielone, więc odinstalowałem je i usunąłem po uruchomieniu)
  3. Zmieniono hasło MySQL.
  4. Zmieniono wszystkie hasła użytkowników WordPress.
  5. Połączony przez FTP i pobrany cały system plików (niezbyt duży, jest to współdzielony host systemu Linux tylko na WordPress)
  6. Zróżnicował system plików względem oficjalnej ZIP WordPress 3.1.3 i usunął lub zastąpił wszystko, co nie pasowało.

Jestem tego całkiem pewien

  • wszystkie pliki na dysku są oficjalnymi plikami WordPress 3.1.3
  • na dysku nie ma żadnych „dodatkowych” plików oprócz mojego /theme, wtyczki Exploit Scanner (którą właśnie pobrałem), /uploadsfolderu i kilku innych oczekiwanych plików. Moja inna wtyczka, wp-recaptcha, pasuje do bieżącej oficjalnej pobranej wersji.
  • Sprawdziłem również .htaccessplik i nic tam nie wygląda źle

porównanie plików wordpress 3.1.3 w Beyond Compare

Nie dotknąłem bazy danych , ale staram się myśleć, jak coś w bazie danych może być złośliwe bez specjalnego kodu PHP, aby działało?

Mój blog WordPress jest teraz w porządku i nie zawiera hacków (myślę), ale czy jest jeszcze coś, co powinienem sprawdzić?

security hacked Jeff Atwood
źródło
1
Należy zachować bloga na bieżąco. :)
fuxia

Odpowiedzi:

80

Czy zidentyfikowałeś wektor wykorzystujący lukę? Jeśli nie, możesz pozostać otwarty na przyszłe wykorzystanie.

Inne rzeczy do rozważenia:

  1. Zmień hasła administratora WordPress - gotowe
  2. Zmień hasło użytkownika konta hostingowego
  3. Zmień hasła FTP
  4. Zmień hasło użytkownika bazy danych MySQL - gotowe
  5. Zmień prefiks tabeli db
  6. Zaktualizuj swoje wp-config nonces / salt
  7. Sprawdź uprawnienia do katalogu / pliku
  8. Zablokuj dostęp do przeglądania katalogów przez .htaccess
  9. Przejrzyj wszystko we wpisie Kod Hartujący WordPress
  10. Przejrzyj wszystko w dziale FAQ Wpis do mojej witryny został zhakowany
Chip Bennett
źródło
1
przepraszam, nie wspomniałem o tym - oczywiście zmieniłem hasła WordPress. Zaktualizowałem post i sprawdziłem na liście tutaj! Nie mogę wymyślić żadnego sposobu, w jaki mogliby mieć moje hasło hostingowe lub hasło FTP, po prostu wchodząc do WordPress; tych informacji nie ma w systemie plików ani bazie danych.
Jeff Atwood,
9
Masz prawdopodobny wektor wykorzystania do tyłu; prawdopodobnie nie jest to WordPress -> konto hostingowe , ale raczej konto hostingowe (przez serwer lub FTP) -> WordPress .
Chip Bennett
2
@Jeff niektóre exploity na poziomie serwera, nad którymi nie masz kontroli (oprócz znalezienia lepszego hosta). Ale to , że nie użyłeś poświadczeń hosta / FTP, nie oznacza, że ​​ktoś ich nie ukradł , uzyskując dostęp do konta hostingowego.
Chip Bennett
7
Istnieje bardzo powszechny exploit, który obchodzi rundy, w których złośliwe oprogramowanie infekuje twoją stację roboczą (lub stację roboczą kontrahenta), wykopuje zapisane hasła w twoim ulubionym programie FTP (lub obsługującym FTP) i wysyła je do atakującego, który następnie kompromituje witryny i używa go do rozprzestrzeniania tego samego złośliwego oprogramowania wśród innych webmasterów. Jest to jeden z typowych sposobów kradzieży hasła FTP. Szczególnie podstępne jest to, że rozprzestrzenia się za pośrednictwem zwykłych witryn, takich jak Twoja, a nie podejrzanych, na których prawdopodobnie będziesz ostrożny.
tylerl
3
Do Twojej wiadomości, jeśli masz dostęp do wiersza poleceń, WP-CLI ma polecenie weryfikacji sum kontrolnych , które sprawdzi każdy plik przed wordpress.org
William Turrell
26

Patrząc na komunikat „Bezpiecznego przeglądania” w Google Chrome, pojawia się „hack .cc iFrame”, który wydaje się ostatnio dużo krążyć. Myślę, że 3.1.3 to naprawi, ale sprawdź swój plik index.php w katalogu głównym, jeśli witryna, to tam mnie uderzyło, dopóki nie zaktualizowałem WSZYSTKIEGO i zmieniono hasła.

Jest kilka BARDZO trudnych rzeczy, które ludzie mogą zrobić z zastrzykami postów i komentarzy. Możesz uruchomić następujące zapytania w swojej bazie danych, aby znaleźć niektóre z nich. Blogowałem resztę mojego „śledzenia” tutaj .

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'
SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

Mam nadzieję że to pomoże!

Dillie-O
źródło
4
Dodałbym SELECT * FROM wp_* WHERE comment_content LIKE '%<?%'i SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%'dla pewności ...
SeanJA
4
Och, ostatnia uwaga. Zakładam, że masz narzędzia Google dla webmasterów powiązane z tą domeną. Gdy wszystko zostanie wyczyszczone, możesz przesłać prośbę ze swojego konta narzędzi dla webmasterów, aby Google ponownie przeskanował witrynę i usunął komunikat ostrzegawczy. Przetwarzają żądania z narzędzi dla webmasterów zwykle w ciągu jednego dnia. W przeciwnym razie dostaniesz się na „niegrzeczną listę” przez dobre 90 dni.
Dillie-O
Znaleziono wiele wyników, ale wynika to z osadzonych ramek iframe dla Vimeo.
tooshel
20

Baza danych może również zawierać złośliwy kod: ukryte konta użytkowników lub wartości, które są drukowane gdzieś bez zmian. Sprawdź także w katalogu przesyłania pliki, które tam nie należą.

Aha, i spróbuj zrozumieć, w jaki sposób atakujący znalazł drogę do Twojej witryny. Na kontach współdzielonych często jest to cały serwer. Sprawdź inne witryny na serwerze pod kątem zhakowanych blogów lub innych stron. Przeczytaj swój dziennik FTP. Jeśli nie wiesz, jak to się stało, nie możesz zapobiec kolejnej przerwie.

fuxia
źródło
czy skaner Exploit nie znalazłby żadnych ukrytych kont użytkowników?
Jeff Atwood,
@Jeff Atwood Nie polegałbym na tym. Twoja tabela użytkowników nie jest tak duża. Możesz go łatwo odczytać bez żadnej wtyczki.
fuxia
Sprawdziłem wp_userstabelę i tylko 2 rzędy, oba oczekiwane ... nic w /uploadfolderze nietypowe (tylko gify i PNG i JPEG)
Jeff Atwood
@Jeff Atwood Czy przejrzałeś pliki, czy tylko rozszerzenia? Czy wszystkie te pliki są wymienione w bibliotece multimediów?
fuxia
4
Pliki graficzne są dość powszechną metodą dostarczania ładunku. Zobacz tutaj , a Zespół Przeglądu Tematów również wpadł na Motywy przy użyciu podobnego exploita TIFF.) Tak, tak: sprawdziłbym każdy z nich, aby upewnić się, że jest on częścią Biblioteki multimediów. (Łatwe skanowanie na wysokim poziomie: sprawdź obrazy, które nie mają zdefiniowanych rozmiarów miniatur).
Chip Bennett
13

Przykro nam, że zostałeś zhakowany - wygląda jednak na to, że wykonałeś dobrą operację odzyskiwania!

Twój system plików brzmi złocisto, nie powiedziałbym, że możesz zrobić coś jeszcze.

Sądzę, że Exploit Scanner rzuci ostrzeżenie, jeśli znajdzie jakieś skrypty, iframe, PHP (choć niebezpieczne tylko, jeśli eval'd) lub inny nietypowy kod w bazie danych.

Nie jestem pewien, czy sprawdza tabele inne niż posty i komentarze, być może warto /wp-admin/options.phpzajrzeć do szybkiego spojrzenia i sprawdzić, czy zauważysz coś dziwnego.

Sprawdziłbym również tabelę użytkowników w kliencie MySQL (użytkownicy mogą znajdować się w bazie danych, ale nie są widoczni dla administratora).

TheDeadMedic
źródło
zdecydowanie dobrym pomysłem jest uruchomienie zapytania MySQL w tabeli użytkowników, aby upewnić się, że nie ma w nim nic nieoczekiwanego, i zrobiłem to. Dobra wskazówka!
Jeff Atwood,
8

Sprawdź narzędzia Google dla webmasterów pod kątem dwóch rzeczy:

  • sprawdź, czy Twoja witryna nie została oznaczona jako naruszona i poproś o ponowne rozpatrzenie, jeśli tak jest
  • sprawdź swoją witrynę jako Googlebot i sprawdź, czy nie wstawiono spamu, który jest widoczny tylko dla Googlebota - przykładem tego jest hack WP Pharma

Ponadto ponownie zaimplementuję motyw lub sprawdzę go bardzo uważnie. Kilka linii PHP może przedefiniować podstawowe funkcje PHP, aby wyodrębnić szkodliwy kod z bazy danych, zwłaszcza tabele kluczy / wartości magazynu wp_options

Jon Galloway
źródło
tak, zdecydowanie ponownie przesłałem witrynę za pośrednictwem Narzędzi Google dla webmasterów i wydaje się teraz „wyczyszczona”.
Jeff Atwood
6

Przeszukaj bazę danych za pomocą phpmyadmin pod kątem „iframe” lub zrzuć bazę danych i wyszukaj tekst.

I sprawdź niewidocznych użytkowników w tabeli użytkowników; Widziałem użytkowników w tabelach, które nie pojawiały się w WP Admin >> Użytkownicy.

Wyczyść opcje «Wtyczki WordPress pokażą, co śmieci ze starych i prawdopodobnie wrażliwych wtyczek pozostały w bazie danych.

W Twoim motywie brakuje również <head>znacznika, więc sprawdziłbym to w przypadku edytowania motywu w celu usunięcia złych linków.

I zwykle: i jak znaleźć backdoora w zhakowanym WordPressie i hartowaniu WordPressa «WordPress Codex

markratledge
źródło
5

„czy jest jeszcze coś, co powinienem sprawdzić?” Musisz zbadać swój proces i dowiedzieć się, w jaki sposób zostałeś zhakowany (prawie na pewno dlatego, że nie załatałeś się na czas lub poprawnie) i to naprawić, nie tylko objawy.

Tom Chiverton
źródło
5
Wątpię, by miało to związek z nieaktualizowaniem WordPressa (chociaż jest to możliwe , po prostu nie jest prawdopodobne ). Sam WordPress prawie nigdy nie jest wektorem wykorzystującym. Typowymi wektorami są niepewna konfiguracja hosta i skradzione poświadczenia FTP.
Chip Bennett
4

To mi się kiedyś zdarzyło przez wyciek na mediatemie. Musiałem napisać wtyczkę, aby sprawdzić bazę danych pod kątem wstrzykniętych łączy. Możesz go tutaj pobrać jako gadżet github .

Jest dość przyjazny dla użytkownika, ma kilka kroków, które dostarczają informacje zwrotne i ponownie sprawdza bazę danych po zakończeniu.

Powodzenia!

kajzer
źródło
4

Miałem bardzo podobny hack, który musiałem naprawić na jednej z moich stron klienckich.

W systemie plików były złośliwe skrypty (php base64_decode). Jednak tabele „posty” i „komentarze” w bazie danych zostały naruszone, a kod iframe został również rozproszony przez te dane.

Dla bezpieczeństwa przeprowadziłbym przynajmniej kilka wyszukiwań DB. :)

Eric Allison
źródło
3

Sprawdź swoje wtyczki !, jak dotąd w tym roku pojawiło się 60 wydań exploitów z wtyczek .org, podejrzewam, że rzeczywista liczba jest znacznie wyższa, ponieważ tak naprawdę nikt nie robi tego na pełny etat.

Podałeś, że masz tylko jedną wtyczkę, no cóż, miała dziurę w zabezpieczeniach (nie jestem pewien, jak długo była wyłączona i może to nie być wektor).

wp-recaptcha-plugin
Exploit został wydany: 2011-03-18
Wersja wykorzystująca: 2.9.8

Autor stwierdził, że przepisał wersję 3.0, ale nie ma wzmianki o łatce bezpieczeństwa.

http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

Dziennik zmian: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/

Wyck
źródło
2

Korzystam z serwera w chmurze i mam losowe numery portów SSH w ogóle bez ftp. Hasła są niezwykle trudne do zhakowania. Cały dostęp do katalogu głównego jest całkowicie zabroniony. Zgadzam się, że WordPress nie będzie twoim winowajcą. Kolejną rzeczą do sprawdzenia jest to, że sesje ftp się nie zamykają, wirus na twoim komputerze osobistym (pamiętaj, że możesz załadować plik do witryny i kto kiedykolwiek załaduje ten plik, może dostać tego samego wirusa), a także nie przechowuj haseł w witrynach publicznych lub prywatnych strony zawsze zapisują je na papierze, nigdy w dokumencie tekstowym lub notatniku.

Na koniec zapytaj hosta, czy ostatnio miał naruszenie, ponieważ powinien mieć konfigurację zapory ogniowej

xLRDxREVENGEx
źródło
2

Sprawdź datę swoich plików. Żaden plik nie powinien mieć danych zmiany nowszych niż ostatnia edycja / instalacja!

Ale można to również sfałszować. Jedynym sposobem upewnienia się byłoby porównanie (np. Porównanie skrótów) wszystkich plików z oryginalnymi plikami instalacyjnymi.

powtac
źródło