wydanie systemu zarządzania treścią . Wydanie to jest znaczące z uwagi na zakończenie wdrożenia sprawdzania aktualizacji i dodatków za pomocą podpisu cyfrowego.
Dotychczas głównym czynnikiem zapewniającym bezpieczeństwo przy instalacji aktualizacji w WordPressie było zaufanie do infrastruktury i serwerów WordPressa (po załadowaniu następowała weryfikacja hasha bez weryfikacji źródła). W przypadku kompromitacji serwerów projektu, atakujący mieli możliwość podmiany aktualizacji i rozpowszechnienia złośliwego kodu wśród witryn opartych na WordPressie, które korzystały z automatycznej instalacji aktualizacji. zgodnie z wcześniej stosowanym modelem zaufania w dostarczaniu, po stronie użytkowników taka podmiana pozostałaby niezauważona.
Biorąc pod uwagę, że według projektu w3techs platforma WordPress jest używana na 33,8% stron w sieci, incydent miałby katastrofalne skutki. Przy tym niebezpieczeństwo kompromitacji infrastruktury było nie hipotetyczne, ale całkowicie realne. Na przykład kilka lat temu jeden z badaczy bezpieczeństwa odkrył lukę, która pozwalała atakującemu na wykonanie swojego kodu po stronie serwera api.wordpress.org.
W przypadku zastosowania podpisów cyfrowych, uzyskanie kontroli nad serwerem aktualizacji nie prowadziłoby do kompromitacji systemów użytkowników, ponieważ do przeprowadzenia ataku dodatkowo konieczne byłoby uzyskanie osobno przechowywanego klucza prywatnego, za pomocą którego dokonywane są podpisy aktualizacji.
Wdrożeniu weryfikacji źródła aktualizacji za pomocą podpisu cyfrowego przeszkadzało to, że wsparcie dla odpowiednich algorytmów kryptograficznych pojawiło się w standardowym pakiecie PHP stosunkowo niedawno. Potrzebne algorytmy kryptograficzne zostały wprowadzone dzięki integracji biblioteki do podstawowego składu . Jednak jako minimalnie wspierana w wersji WordPress wersja 5.2.4 (od WordPress 5.2 - 5.6.20). Włączenie wsparcia dla podpisów cyfrowych doprowadziłoby do znacznego zwiększenia wymagań dotyczących minimalnie wspieranej wersji PHP lub dodania zewnętrznej zależności, na co deweloperzy nie mogli się zgodzić, biorąc pod uwagę rozpowszechnienie wersji PHP w systemach hostingowych.
Rozwiązaniem było i włączenie w skład WordPress 5.2 kompaktowej wersji Libsodium — , w którym w języku PHP zaimplementowano minimalny zestaw algorytmów do weryfikacji podpisów cyfrowych. Wydajność realizacji pozostawia wiele do życzenia, ale w pełni rozwiązuje problem kompatybilności oraz umożliwia programistom wtyczek rozpoczęcie wdrażania nowoczesnych algorytmów kryptograficznych.
Do generowania podpisów cyfrowych wykorzystywany jest algorytm , opracowany przy współpracy z Daniem Bersteinem (Daniel J. Bernstein). Podpis cyfrowy tworzony jest dla wartości skrótu SHA384, obliczonego na podstawie zawartości archiwum z aktualizacją. Ed25519 oferuje wyższy poziom bezpieczeństwa niż ECDSA i DSA, a także wykazuje bardzo wysoką szybkość weryfikacji i generowania podpisów. Odporność na ataki dla Ed25519 wynosi około 2^128 (średnio, do przeprowadzenia ataku na Ed25519 potrzeba wykonać 2^140 operacji bitowych), co odpowiada odporności takich algorytmów jak NIST P-256 i RSA z kluczem o długości 3000 bitów lub 128-bitowemu szyfrowi blokowemu. Ed25519 nie jest również podatny na problemy z kolizjami w skrótach, nie jest wrażliwy na ataki związane z analizą czasu dostępu do pamięci podręcznej (cache-timing) oraz ataki kanałami bocznymi.
W wydaniu WordPress 5.2 weryfikacja podpisu cyfrowego obejmuje na razie tylko podstawowe aktualizacje platformy i domyślnie nie prowadzi do zablokowania aktualizacji, a jedynie informuje użytkownika o powstałym problemie. Zdecydowano się nie włączać blokady domyślnie ze względu na konieczność pełnej weryfikacji i obejścia . W przyszłości planowane jest dodanie weryfikacji podpisu cyfrowego również dla wersji źródłowych motywów i wtyczek (producenti będą mogli podpisywać wydania swoim kluczem).
Oprócz wsparcia dla podpisów cyfrowych w WordPress 5.2 można odnotować następujące zmiany:
- Do sekcji „Stan witryny” dodano dwie nowe strony do debugowania typowych problemów z konfiguracją, a także udostępniono formularz, przez który deweloperzy mogą pozostawiać informacje o debugowaniu administratorom witryny;
- Dodano implementację „białego ekranu śmierci”, wyświetlanego w przypadku krytycznych problemów i pomagającego administratorowi samodzielnie rozwiązać problemy związane z wtyczkami lub motywami, przechodząc w specjalny tryb odzyskiwania po awarii;
- Wprowadzono system sprawdzania zgodności z wtyczkami, który automatycznie weryfikuje możliwość użycia wtyczki w bieżącej konfiguracji z uwzględnieniem używanej wersji PHP. Jeśli do działania wtyczki potrzebna jest nowsza wersja PHP, system automatycznie zablokuje jej aktywację;
- Dodano wsparcie dla aktywacji modułów z kodem JavaScript przy użyciu i ;
- Dodano nowy szablon privacy-policy.php, który umożliwia dostosowanie zawartości strony dotyczącej warunków ochrony prywatności;
- Dla motywów graficznych dodano obsługę hooka wp_body_open, co pozwala na wstawienie kodu zaraz po tagu body;
- Wymagania dotyczące minimalnej wersji PHP podniesiono do 5.6.20, a w wtyczkach i motywach graficznych pojawiła się możliwość użycia przestrzeni nazw oraz funkcji anonimowych;
- Dodano 13 nowych ikon.
Dodatkowo można wspomnieć o krytycznej podatności w wtyczce WordPress (CVE-2019-11185). Luka ta umożliwia wykonanie dowolnego kodu PHP na serwerze. Wtyczka ta jest używana na ponad 27 tysiącach stron internetowych do organizacji interaktywnego czatu z odwiedzającymi, w tym na stronach takich firm jak IKEA, Adobe, Huawei, PayPal, Tele2 i McDonald's (Live Chat często wykorzystywany jest do realizacji wyskakujących, uciążliwych czatów na stronach firm z propozycją rozmowy z pracownikiem).
Problem ujawnia się w kodzie przesyłania plików na serwer i pozwala na obejście weryfikacji dozwolonych typów plików oraz przesłanie na serwer skryptu PHP, który następnie można wykonać bezpośrednim dostępem przez sieć. Interesujące jest to, że w zeszłym roku w Live Chat już wykryto podobną podatność (CVE-2018-12426), która umożliwiała przesłanie kodu PHP pod płaszczykiem obrazu, podając inny typ treści w polu Content-type. W ramach naprawy problemu dodano dodatkowe kontrole zgodnie z białymi listami i typem MIME zawartości. Okazało się, że te kontrole zostały zaimplementowane nieprawidłowo i można je łatwo obejść.
W szczególności bezpośrednie przesyłanie plików z rozszerzeniem „.php” jest zabronione, ale do czarnej listy nie dodano rozszerzenia „.phtml”, które na wielu serwerach jest związane z interpreterem PHP. Biała lista dopuszcza jedynie przesyłanie obrazów, ale można ją obejść, podając podwójne rozszerzenie, na przykład „.gif.phtml”. Aby obejść weryfikację typu MIME, wystarczyło w pliku, przed otwarciem tagu z kodem PHP, umieścić ciąg „GIF89a”.
Źródło: opennet.ru
