Wykorzystywane luki w zabezpieczeniach WordPress REST API Kontynuuj

Minęły prawie dwa tygodnie, odkąd zespół ds. bezpieczeństwa WordPressa ujawnił usterkę dotyczącą nieuwierzytelnionej eskalacji uprawnień w punkcie końcowym REST API w wersjach 4.7 i 4.7.1. Luka została po cichu załatana, a ujawnienie zostało opóźnione o tydzień, aby umożliwić właścicielom witryn WordPress rozpoczęcie aktualizacji do wersji 4.7.2. W zeszłym tygodniu setki tysięcy podatnych na ataki witryn zostało już zniszczonych, a raporty o szkodach wciąż napływają.

W ciągu weekendu ataki wzrosły, a firmy zajmujące się bezpieczeństwem WordPressa odnotowały więcej prób zablokowanych przez ich zapory. Sucuri, firma zajmująca się bezpieczeństwem witryn internetowych, która zgłosiła lukę w zabezpieczeniach WordPress, śledziła kampanię „Hacked by w4l3XzY3” w zeszłym tygodniu i oszacowała 66 000 błędów. Ta konkretna kampania przeszła już 260 000 stron zindeksowanych przez Google. Jest to jedna z prawie dwudziestu kampanii oczerniających wymierzonych w tę lukę.

„W ciągu ostatnich 24 godzin zaobserwowaliśmy średni wzrost uszkodzonych stron na kampanię o 44%” – powiedział w piątek dyrektor generalny Wordfence, Mark Maunder. „Całkowita liczba zniszczonych stron we wszystkich tych kampaniach, zgodnie z indeksem Google, wzrosła z 1 496 020 do 1 893 690. To 26% wzrost całkowitej liczby uszkodzonych stron w ciągu zaledwie 24 godzin”.

Maunder odniósł się do wykresu Google Trends, który, jak powiedział, pokazuje sukces kampanii oszpecających w ciągu ostatniego tygodnia. Gwałtowny wzrost rozpoczął się w dniu, w którym WordPress ujawnił lukę w zabezpieczeniach.

Jednak White Fir Design, inna firma oferująca usługi bezpieczeństwa, kwestionuje twierdzenia Wordfence, że włamano się na 1,8 miliona stron. Liczba około 2 milionów stron jest cytowana w raportach BBC, The Enquirer, Ars Technica, CIO.com i innych publikacjach. White Fir Design twierdzi, że zhakowane strony, które zostały zindeksowane przez Google, nie są wierną reprezentacją.

CTO Sucuri Daniel Cid również nie w pełni zgadza się z oceną sytuacji dokonaną przez Wordfence. Po przeprowadzeniu pewnych badań w weekend, Sucuri szacuje, że ponad 50 000 witryn zostało zhakowanych z 20-30 stronami na każdą z nich. Byłoby to mniej więcej milion na dolnym końcu szacunku i waha się do 1,5 miliona.

Sucuri zaczyna również dostrzegać poważniejsze próby wykorzystania luki w REST API w postaci ataków na zdalne wykonanie kodu (RCE) na witryny korzystające z wtyczek, które pozwalają na wykonanie PHP z poziomu postów i stron. Jedna z takich kampanii próbujących wstrzyknąć PHP obejmuje dodanie treści z zaatakowanej witryny, a następnie wstrzyknięcie backdoora ukrytego w /wp-content/uploads.

„Zniekształcenia nie zapewniają korzyści ekonomicznych, więc prawdopodobnie wkrótce umrą” – powiedział Cid. „To, co pozostanie, to próby wykonywania poleceń (RCE), ponieważ daje to atakującym pełną kontrolę nad witryną – i oferuje wiele sposobów na zarabianie – oraz SPAM SEO / linki partnerskie / zastrzyki reklam. Zaczynamy dostrzegać próby ich użycia w kilku witrynach i prawdopodobnie będzie to kierunek, w którym ta luka będzie nadużywana w nadchodzących dniach, tygodniach, a być może miesiącach”.

Hakerzy atakują strony, które nie zostały zaktualizowane do wersji 4.7.2 – wydaje się, że nie ma między nimi żadnego wzorca. Szybkie spojrzenie na wyniki Google dotyczące najaktywniejszych kampanii pokazuje, że zhakowane witryny obejmują blogi, media, witryny rządowe, edukacyjne, sportowe, medyczne i technologiczne.

Dlaczego interfejs API REST jest domyślnie włączony

Interfejs API REST WordPressa jest domyślnie włączony, ponieważ w przyszłości planuje się zwiększenie funkcjonalności administratora i wtyczek na interfejsie API REST. Po ostatnich atakach kilku użytkowników skomentowało ujawnienie luki w zabezpieczeniach, pytając, dlaczego jest ona domyślnie włączona.

„Problem z bezpieczeństwem dotyczy funkcji, której nie używam na żadnej z moich witryn (REST API), a mimo to ta funkcja jest po raz pierwszy włączona domyślnie, a po drugie od WordPress 4.7 potrzebujesz nawet wtyczki – co może wprowadzić dalsze problemy z bezpieczeństwem – wyłączyć tę funkcję?” jeden użytkownik (@helios2121) skomentował post. „Proszę przemyśleć swoje podejście do bezpieczeństwa. Twórz funkcje, na które nie wszyscy muszą się zgodzić. A przynajmniej daj możliwość rezygnacji bez konieczności stosowania dodatkowych wtyczek”.

Morten Rand-Hendriksen otworzył zgłoszenie trac, aby omówić domyślne wyłączenie interfejsu API REST i włączenie go tylko wtedy, gdy zażąda tego administrator witryny lub motyw lub wtyczka są od niego zależne.

Główny Committer Sergey Biryukov potwierdził, że w planach jest wprowadzenie większej liczby podstawowych funkcji, które opierają się na REST API. „Wyłączenie interfejsu API REST jest jak wyłączenie admin-ajax.php — oba spowodują uszkodzenie witryny” — powiedział Biryukov.

Rand-Hendriksen zapytał, dlaczego punkty końcowe treści nie mogą być domyślnie chronione, podczas gdy REST API jest domyślnie włączone do celów administracyjnych. Inny użytkownik zapytał, dlaczego punkt końcowy Użytkownicy nie jest domyślnie chroniony (np. https://news.microsoft.com/wp-json/wp/v2/users lub https://www.obama.org/wp-json/wp /v2/users), co „ułatwia uzyskanie wszystkich nazw użytkowników” w dowolnej witrynie korzystającej z wersji 4.7+.

„Jeśli naprawdę chcesz wyłączyć interfejs API REST w swojej witrynie (witrynach), to jest nasza obecna rekomendacja: ogranicz go do uwierzytelnionych użytkowników” – powiedział główny komisarz James Nylen. „Chcemy jednak nadal zwiększać adopcję i wykorzystanie interfejsu API REST i spodziewam się, że nawet ta modyfikacja będzie przerywać coraz więcej funkcji WP w miarę upływu czasu, takich jak motywy i osadzania oparte na interfejsie API”.

Nylen poleca wtyczkę Disable JSON API dla tych, którzy chcą zastosować się do tej rekomendacji w witrynach korzystających z WordPress 4.7+. Wtyczka ma obecnie ponad 10 000 aktywnych instalacji.

Zespół ds. bezpieczeństwa WordPressa pracował pilnie, aby złagodzić ataki, pomagając hostom i firmom zajmującym się bezpieczeństwem we wdrażaniu zabezpieczeń, zanim problem został upubliczniony. Jednak pełne ujawnienie luki zostało ukryte na blogu Make/Core, witrynie, która nie jest powszechnie czytana wśród zwykłych właścicieli witryn WordPress. Link do ujawnienia został opublikowany tydzień później jako dodatek do poprzedniego wpisu na blogu WordPress.

„Chociaż doceniam odpowiedzialne ujawnienie tego problemu i starania, aby go rozwiązać, mam nadzieję, że rozważysz ogłaszanie przyszłych ogłoszeń za pośrednictwem nowego posta w witrynie WordPress News, a nie tylko dołączanie aktualizacji do poprzedniego posta” – skomentował użytkownik @johnrork w sprawie oficjalnego ujawnienia. „Prawdopodobnie nie jestem jedyną osobą, która mogłaby uniknąć skompromitowania, gdyby w środę pojawiło się to jako nowy element w moim czytniku RSS”.

Ci, którzy czytali blogi Make, mieli przewagę nad naprawianiem własnych witryn i/lub witryn swoich klientów. Ci, którzy polegają na blogu WordPress w celu uzyskania informacji o aktualizacjach zabezpieczeń, prawdopodobnie przeczytali post, gdy został pierwotnie opublikowany i nigdy nie wrócił, aby zobaczyć aktualizację tydzień później. Ten poważny problem gwarantował przejrzystość WordPressa w nowym poście na swoim blogu informacyjnym. Spowodowałoby to również automatyczne wysłanie tweeta do ponad pół miliona obserwujących na oficjalnym koncie WordPress i koncie na Facebooku, które ma ponad milion polubień.

Na szczęście liczba podatnych witryn, które mają również wtyczki, które mogą pozwolić atakującym na wykorzystanie tej luki, jest znacznie mniejsza. Zniekształcone witryny są kłopotliwe, ale łatwe do naprawienia. W większości przypadków administratorzy potrzebują jedynie aktualizacji do wersji 4.7.2 i przywrócenia zniszczonych postów do najnowszej wersji. Większość właścicieli witryn nie ma pojęcia, jak szybko exploity zaczynają pojawiać się po publicznym ujawnieniu, ale ta sytuacja delikatnie przypomniała, jak ważna jest aktualizacja WordPressa i korzyści płynące z pozostawienia automatycznych aktualizacji włączonych.