Tydzień temu deweloperzy odpowiedzialni za platformę do zarządzania treścią Wordpress udostępnili wersję 4.1.2, która naprawiała kilka luk w zabezpieczeniach. Najgroźniejsza z nich mogła doprowadzić do przeprowadzenia skutecznego ataku XSS na stronę internetową i w efekcie do osadzenia złośliwych skryptów, które mogłyby pomóc atakującemu w uzyskaniu uprzywilejowanych uprawnień. Kilka dni temu udostępniono kolejną wersję 4.2 i niestety jak się okazało, nowa wersja CMS-a (oraz starsze) zawierają niezałatany błąd typu „stored XSS”, który umożliwia atakującemu na wykonanie kodu z uprawnieniami administratora bez włamywania się do serwera.

Znalazcą błędu jest człowiek o imieniu Jouko Pynnönen pracujący dla finlandzkiej firmy Klikki Oy. Odkrył on, że luka w WordPress-ie w wersji 4.2, 4.1.2, 4.1.1, 3.9.3 może być wykorzystana przez nieuwierzytelnionego atakującego do wstrzyknięcia złośliwego kodu. Problem leży w systemie komentarzy, który do bazy danych zapisuje pierwsze 64-kilobajty znaków - jeśli treść komentarza jest wystarczająco długa, to będzie ona obcięta w bazie danych.

Jeśli użytkownik, zalogowany jako administrator otworzy stronę z pełnym komentarzem zawierającym odpowiednio spreparowany i otagowany w html-u kod, może nieświadomie wywołać go z prawami administratora i tym samym wykonać dowolny kod na serwerze, włącznie z dopisaniem skryptów PHP do szablonu graficznego. W ten sposób atakujący może przeprowadzać różne zadania, takie jak zmiany hasła administratora oraz tworzenie nowych kont z najwyższymi uprawnieniami.

Mam stronę na Wordpressie, co zrobić?

Przede wszystkim zachowaj spokój. Błąd typu stored XSS działa w najpopularniejszych i najnowszych wersjach Wordpressa, jednak by udało się go poprawnie użyć, administrator musi otworzyć stronę z komentarzem. Wykonanie kodu nie zadziała, jeśli komentarze są zatwierdzane po ówczesnej moderacji, lub jeśli komentarz zostanie zatwierdzony z Kokpitu Wordpressa. 

Błąd ten jest znany już od co najmniej 14 miesięcy. Od tego czasu deweloperzy Wordpressa nie zrobili nic w tym kierunku, dopiero ostatni incydent związany z stored XSS doprowadził do tego, że udostępniono wersję 4.2.1, która naprawia wyżej opisywany błąd naruszający bezpieczeństwo. Zalecana aktualizacja jest pod adresem: https://wordpress.org/news/2015/04/wordpress-4-2-1/

Już załatana luka w domyślnej instalacji WordPress

(08/05/2015) Może już czas, aby założyć nowy specjalny serwis informujący wyłącznie o podatnościach WordPressa? Oczywiście to taka niepoprawna dygresja, jednak do śmiechu na pewno nie jest administratorom tej najpopularniejszej platformy do zarządzania treścią. Potwierdzają to chociażby ostatnie tygodnie, kiedy to ujawniono lukę w pluginie TheCartPress, gdzie podatnych było niemal 5 tysięcy instancji Wordpressa, oraz podatność XSS stored, która „dotykała” wszystkie wersje od 4.2 w „dół”. Tym razem odkryta przez badacza bezpieczeństwa Davida Dede z firmy Sucuri luka zagraża(ła) bezpieczeństwu niemal wszystkim stronom opartym o CMS WordPress. Na szczęście aktualizacja 4.2.2 naprawiła problem z podatnością.

Luka występowała w domyślnej instalacji WordPressa, więc nawet pobierając jego najnowszą wersję z oficjalnej strony producenta, już na starcie Twoja strona zawierała podatność, która mogła pozwolić atakującemu na przeprowadzenie ataku „DOM-based cross-site scripting (XSS)”. Błąd zawierał się w mechanizmie do generowania i pobierania czcionek Genericons Webfont Package, który jest integralną częścią domyślnego szablonu graficznego WordPress Twenty Fifteen Theme. Zidentyfikowana luka jako „DOM-based XSS” w modelu DOM (Document Object Model) odpowiedzialnym za wyświetlanie m.in. tekstu, obrazów, nagłówków i prezentacji ich w przeglądarce internetowej mogła być wykorzystana przez hakera do przeprowadzenia zaawansowanych ataków, w tym XSS, kradzieży lub przejęciu sesji użytkownika oraz administratora. Oznacza to tyle, że payload (ładunek) XSS nie jest wysyłany do serwera, ale jest wykonywany bezpośrednio w przeglądarce po stronie klienta.

Administratorzy powinni upewnić się, czy ich strona korzysta z webowych fontów, jeśli tak, eksperci z Suruci zalecają usunięcie pliku example.html lub zabronienie do niego dostępu.

źródło: ArcabitArcabit.pl