Jeśli korzystacie z Drupala, to upewnijcie się, że zaktualizowaliście go do najnowszej wersji. Od dwóch dni znany jest błąd umożliwiający zdalne wykonanie kodu bez uwierzytelniania. Niestety tysiące polskich stron nie dokonało jeszcze aktualizacji.
Ale o co chodzi?
Drupal jest popularnym rozwiązaniem do zarządzania treścią, które posiada otwarty kod źródłowy. Pod koniec zeszłego tygodnia zapowiedziano publikację nowej wersji oprogramowania z powodu poważnego błędu i poproszono administratorów o bycie w gotowości do przeprowadzenia aktualizacji 28 marca. Zapowiedź tego typu nie jest częstym rozwiązaniem, zdecydowano się na nie, ponieważ podatność pozwala na zdalne wykonanie kodu bez uwierzytelniania, jest stosunkowo prosta do wykorzystania i dodatkowo kod Drupala jest otwarty, co ułatwia analizę wprowadzanych poprawek i przyśpiesza tworzenie exploitów. Co prawda według naszych informacji nie ma jeszcze publicznych exploitów, ale to nie znaczy, że lada chwila się nie pojawią. W dodatku dochodzą nas słuchy, że odnotowywane są już pierwsze ataki z wykorzystaniem tego błędu.
Drupalgeddon
O szczegółach podatności wiele serwisów już się szeroko rozpisywało, my natomiast chcieliśmy się skupić na analizie polskich stron wykorzystujących Drupala, aby ocenić skalę problemu, gdyby dziś pojawił się publiczny exploit.
Na początek wyszukaliśmy jak najwięcej stron w domenie .pl zawierających ciąg „/sites/all/themes/” w kodzie źródłowym, który jest charakterystyczny dla Drupala. Dało nam to bazę 6612 adresów. Następnie przy użyciu prostego skryptu odpytaliśmy te strony o plik CHANGELOG.txt, z którego możemy dowiedzieć się, z jakiej wersji oprogramowania dana strona korzysta. Na tej podstawie określimy, czy dana wersja posiada łatkę czy nie. Oczywiście jest to metoda niedoskonała, bo administratorzy często usuwają lub ograniczają dostęp do tego pliku (co jest dobrą praktyką), administrator mógł celowo zmanipulować jego zawartość lub mimo że domyślnie dana wersja Drupala powinna być podatna, administrator mógł zmienić ustawienia w taki sposób, że nie będzie. Jednak aby mieć ogólny rozkład wykorzystywanych wersji i udział podatnych, ta metoda powinna być wystarczająca.
Po odfiltrowaniu tylko stron posiadających wspominany plik pozostało 3583 serwisów. Dodatkowo jedna ze stron miała wpisaną wersję Drupala jako „Drupal 2227.42” – celowa manipulacja czy jakaś własna przeróbka? Ponieważ taka wersja nie istnieje, ta strona została przez nas usunięta ze zbioru do analizy.
Efekty analizy pozostałych 3582 stron widoczne są poniżej:
Udział podatnych wersji Drupala na polskich stronach
Rozkład wersji Drupala na polskich stronach (większy obrazek po kliknięciu)
Jak widać aż 91% (3266) stron, które przeanalizowaliśmy, było niezaktualizowanych! Co prawda błąd został opublikowany dopiero kilka dni temu, ale biorąc pod uwagę, jak proste może być jego wykorzystanie, skutki dla tysięcy podatnych Drupali mogą być katastrofalne.
Wśród podatnych stron zidentyfikowaliśmy 23 strony w domenie gov.pl, w tym stronę ważnego ministerstwa, które posiada wersję Drupala z 2011 roku! Sprawę zgłosiliśmy do odpowiedniego CERT-u i opublikujemy szczegóły, gdy zostanie dokonana aktualizacja (choć nadal liczymy, że to tylko błędny plik changelog). Przy okazji odkryliśmy, że wiele polskich stron (381) korzysta z Drupala w wersji 6, który nie jest już oficjalnie wspierany, a 378, w tym jedna rządowa, z Drupala 7 w wersji niższych niż 7.32, czyli takich, które są podatne na SQL Injection.
Co robić?
Po pierwsze, jeśli jesteś administratorem Drupala i jeszcze tego nie zrobiłeś, jak najszybciej zaktualizuj go do najnowszej wersji (7.58 lub 8.5.1). Dla wersji 6, co prawda, wyjątkowo została wydana poprawka, ale nie jest ona już wspierana przez główną grupę deweloperów i zaleca się migrację na wersję wyższą. Publiczny exploit na tę podatność może pojawić się lada dzień i tysiące przejętych Drupali to ostatnia rzecz, którą chcemy oglądać jako bezpiecznicy :). Za jakiś czas przeprowadzimy ponowny przegląd i ocenimy, w jakim tempie przeprowadzane są aktualizacje.
Komentarze
O wow. Jakby zostało 10% podatnych, to też bym uznał, że to spory problem. A tu patrzę i oczom nie wierzę. A pamiętam komentarze pod newsami o tym, że będzie patch typu „to nie problem, większość instalacji Drupala jest pod opieką profesjonalnych adminów” :)))
A potem płacz że zamiast strony poważnej firmy pojawił się jeden wielki „kaktus”, bibliotek nie można aktualizować bo skrypt nie będzie działać na nowej wersji. A nowa wersja skryptu nie będzie kompatybilna z brandem więc jak raz prezio zapłacił 3k za zrobienie strony to ma działać aż mu się znudzi i zamówi nową…
Mam fuksa bo ummie w firmie odpowiadam za kilka stron ale tylko do poziomu OS, a skrypty CMS, skórki wtyczki plus aktualizacja treści to już nie moja działka (efekt są dwie agencje mające podpisane umowy z nami i oni zajmują się pisaniem i przerabianiem oraz poprawianiem po aktualizacji)…
Pfff… Widzialem strony sporych (czytaj: niebiednych) firm dzialajace na drupalu z 2013 roku, wiec czym tu sie przejmowac? :D :P
Zła metodologia badania… została opublikowana łatka, która umożliwia szybki fix bez upgradu wersji… Na wielu stronach najpierw zrobiłem łatkę dopiero później aktualizacje całości …
Oczywiście masz rację i będą takie przypadki, ale zakładam (być może błędnie), że część administratorów która tak robi nadal jest mniejszością.
Dodatkowo jeśli ktoś jest na tyle świadomy, że najpierw wgrywa łatkę, to raczej w niedługim czasie też podnosi wersję (tak jak piszesz, że Ty zrobiłeś).
Zaliczam to do opisywanego przypadku gdy: „mimo, że domyślnie dana wersja Drupala powinna być podatna, administrator mógł zmienić ustawienia w taki sposób, że nie będzie.”
Wiem, że nie chodzi o ustawienia a łatkę która zmienia kod, ale to uogólnienie gdy mimo, że z metodologii by wychodziło, że jest podatny, to nie jest.
Jeżeli ktoś nie potrafi samodzielnie wdrożyć łatki bezpieczeństwa, w sieci można już znaleźć oferty z pomocą w całkiem dobrej cenie jak na powagę sytuacji, np. tutaj: […]
WordPress to zło i rak sieci… A nie, zaraz… :P
A mozesz napisac dlaczego zlo i rak ?
Mysle ze w w/w wypowiedzi jest wiecej sarkazmu niz powagi.
Na następnym spotkaniu W3 zaproponuję nowy RFC wprowadzający oficjalny międzynarodowy znacznik do oznaczania treści sarkastycznych i ironicznych w sieci :P
To był złośliwiec w kierunku Drupalowców, przekonanych że WordPress to zło :P Ich się trzeba zapytać czemu tak sądzą. To że są nieaktualizowane instalacje w sieci to wina użytkowników a nie systemu, zresztą widać że Drupal ma to samo i dobrym dorkiem można wszystkich załatwić :)
Najlepiej robić strony w czystym HTML :P
No i jak dużo tych stron były atakowane?
Wystarczy usunąć „R” i każdy będzie wiedział do czego jest ten system.
https://www.drupal.org/psa-2018-002
„The security team is now aware of automated attacks attempting to compromise Drupal 7 and 8 websites using the vulnerability reported in SA-CORE-2018-002. Due to this, the security team is increasing the security risk score of that issue to 24/25
Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts. It is possible targeted attacks occurred before that.
Simply updating Drupal will not remove backdoors or fix compromised sites.”
U nas z pewnością zakończy się na patchowaniu i „z głowy”! I bedzie znowu Z3S miała do opisu wodopoje…