wydanie systemu zarządzania treścią stron internetowych . Wydanie wyróżnia się zakończeniem na wdrażaniu sprawdzanie aktualizacji i uzupełnień za pomocą podpisu cyfrowego.
Do tej pory przy instalowaniu aktualizacji w WordPressie głównym czynnikiem bezpieczeństwa było zaufanie do infrastruktury i serwerów WordPress (po pobraniu sprawdzany był hash bez weryfikacji źródła). Jeśli serwery projektu zostały naruszone, napastnicy byli w stanie sfałszować aktualizację i rozesłać złośliwy kod pomiędzy witrynami opartymi na WordPressie, które korzystają z systemu automatycznej instalacji aktualizacji. Zgodnie z wcześniej stosowanym modelem zaufania, taka zamiana pozostałaby niezauważona po stronie użytkowników.
Biorąc pod uwagę fakt, że projektu w3techs, platforma WordPress jest używana w 33.8% witryn w sieci, incydent miałby skalę katastrofy. Jednocześnie niebezpieczeństwo naruszenia infrastruktury nie było hipotetyczne, ale całkiem realne. Na przykład kilka lat temu jeden z badaczy bezpieczeństwa luka, która umożliwiła atakującemu wykonanie swojego kodu po stronie serwera api.wordpress.org.
W przypadku podpisów cyfrowych przejęcie kontroli nad serwerem dystrybucji aktualizacji nie doprowadzi do naruszenia bezpieczeństwa systemów użytkowników, ponieważ w celu przeprowadzenia ataku konieczne będzie dodatkowo uzyskanie oddzielnie przechowywanego klucza prywatnego, którym podpisywane są aktualizacje.
Wdrożenie sprawdzania źródła aktualizacji za pomocą podpisu cyfrowego utrudniał fakt, że stosunkowo niedawno w standardowym pakiecie PHP pojawiła się obsługa niezbędnych algorytmów kryptograficznych. Niezbędne algorytmy kryptograficzne pojawiły się dzięki integracji biblioteki do głównego zespołu . Ale jako minimalna obsługiwana wersja PHP w WordPress wydanie 5.2.4 (z WordPress 5.2 - 5.6.20). Włączenie obsługi podpisów cyfrowych doprowadziłoby do znacznego zwiększenia wymagań dotyczących minimalnej obsługiwanej wersji PHP lub dodania zewnętrznej zależności, czego programiści nie mogliby zrobić ze względu na powszechność wersji PHP w systemach hostingowych.
Rozwiązaniem było oraz włączenie kompaktowej wersji Libsodium do WordPress 5.2 - , w którym zaimplementowano w PHP minimalny zestaw algorytmów weryfikacji podpisów cyfrowych. Implementacja pozostawia wiele do życzenia pod względem wydajności, ale całkowicie rozwiązuje problem kompatybilności, a także pozwala twórcom wtyczek rozpocząć wdrażanie nowoczesnych algorytmów kryptograficznych.
Do generowania podpisów cyfrowych wykorzystywany jest algorytm , opracowany przy udziale Daniela J. Bernsteina. Podpis cyfrowy jest generowany dla wartości skrótu SHA384 obliczonej na podstawie zawartości archiwum aktualizacji. Ed25519 charakteryzuje się wyższym poziomem bezpieczeństwa niż ECDSA i DSA oraz charakteryzuje się bardzo dużą szybkością weryfikacji i tworzenia podpisu. Odporność na hacking dla Ed25519 wynosi około 2^128 (średnio atak na Ed25519 będzie wymagał 2^140 bitów operacji), co odpowiada odporności algorytmów takich jak NIST P-256 i RSA z kluczem o rozmiarze 3000 bitów lub 128-bitowy szyfr blokowy. Ed25519 nie jest również podatny na problemy z kolizjami skrótów i nie jest podatny na ataki związane z synchronizacją pamięci podręcznej ani ataki z kanałem bocznym.
W wersji WordPress 5.2 weryfikacja podpisu cyfrowego obejmuje obecnie tylko główne aktualizacje platformy i domyślnie nie blokuje aktualizacji, a jedynie informuje użytkownika o problemie. Zdecydowano się nie włączać od razu domyślnego blokowania ze względu na konieczność pełnego sprawdzenia i obejścia . W przyszłości planowane jest także dodanie weryfikacji podpisu cyfrowego w celu weryfikacji źródła instalacji motywów i wtyczek (producenci będą mogli podpisywać wydania swoim kluczem).
Oprócz obsługi podpisów cyfrowych w WordPress 5.2 można zauważyć następujące zmiany:
- Do sekcji „Stan witryny” dodano dwie nowe strony służące do debugowania typowych problemów z konfiguracją, a także udostępniono formularz, za pomocą którego programiści mogą pozostawić informacje dotyczące debugowania administratorom witryny;
- Dodano implementację „białego ekranu śmierci”, wyświetlanego w przypadku krytycznych problemów i pomagającego administratorowi samodzielnie rozwiązywać problemy związane z wtyczkami lub motywami poprzez przejście do specjalnego trybu odzyskiwania po awarii;
- Zaimplementowano system sprawdzania kompatybilności z wtyczkami, który automatycznie sprawdza możliwość wykorzystania wtyczki w aktualnej konfiguracji, z uwzględnieniem używanej wersji PHP. Jeżeli wtyczka wymaga do działania nowszej wersji PHP, system automatycznie zablokuje włączenie tej wtyczki;
- Dodano obsługę włączania modułów za pomocą kodu JavaScript и ;
- Dodano nowy szablon Privacy-policy.php, który umożliwia dostosowanie zawartości strony polityki prywatności;
- W przypadku motywów dodano funkcję obsługi haków wp_body_open, która umożliwia wstawienie kodu bezpośrednio po tagu body;
- Wymagania minimalnej wersji PHP zostały podniesione do 5.6.20, wtyczki i motywy mają teraz możliwość korzystania z przestrzeni nazw i funkcji anonimowych;
- Dodano 13 nowych ikon.
Dodatkowo możesz wspomnieć Krytyczna luka we wtyczce WordPress (CVE-2019-11185). Luka umożliwia wykonanie dowolnego kodu PHP na serwerze. Wtyczka jest używana w ponad 27 tysiącach witryn w celu zorganizowania interaktywnego czatu z odwiedzającym, w tym na stronach takich firm jak IKEA, Adobe, Huawei, PayPal, Tele2 i McDonald's (Czat na żywo jest często używany do implementacji irytujących wyskakujących okienek czaty na stronach firmowych z ofertami czat z pracownikiem).
Problem objawia się w kodzie służącym do przesyłania plików na serwer i umożliwia ominięcie sprawdzania poprawnych typów plików i przesłanie skryptu PHP na serwer, a następnie wykonanie go bezpośrednio przez Internet. Co ciekawe, w zeszłym roku podobną lukę wykryto już w Live Chat (CVE-2018-12426), która umożliwiała załadowanie kodu PHP pod przykrywką obrazu, określając inny typ treści w polu Content-type. W ramach poprawki dodano dodatkowe kontrole białych list i typu zawartości MIME. Jak się okazuje, kontrole te są realizowane nieprawidłowo i można je łatwo ominąć.
W szczególności zabronione jest bezpośrednie przesyłanie plików z rozszerzeniem „.php”, ale rozszerzenie „.phtml”, które na wielu serwerach jest powiązane z interpreterem PHP, nie zostało dodane do czarnej listy. Biała lista umożliwia jedynie przesyłanie obrazów, ale można to ominąć, podając podwójne rozszerzenie, na przykład „.gif.phtml”. Aby ominąć sprawdzanie typu MIME na początku pliku, przed otwarciem znacznika z kodem PHP wystarczyło podać linię „GIF89a”.
Źródło: opennet.ru