Matt Mullenweg odpowiada na pytanie dotyczące bezpieczeństwa: Podpisy cyfrowe dla aktualizacji WordPress są ważne, ale nie priorytetowe

Scott Arciszewski, Chief Development Officer w Paragon Initiative Enterprises, najbardziej znany ze swojej pracy w zakresie inżynierii kryptograficznej, opublikował post na Medium krytykujący Matta Mullenwega, współtwórcę projektu oprogramowania open source WordPress, za to, że nie dba wystarczająco o bezpieczeństwo. Arciszewski od tego czasu wycofał post, ale możesz go przeczytać za pomocą Wayback Machine.

Arciszewski pracuje nad projektem znanym jako libsodium, głównym rozszerzeniem PHP 7.2, które pozwala na szyfrowanie, deszyfrowanie, podpisy, haszowanie haseł i nie tylko. Jego celem jest umożliwienie programistom budowania narzędzi kryptograficznych wyższego poziomu.

System automatycznej aktualizacji WordPress jest obsługiwany przez api.wordpress.org. Ponieważ aktualizacje nie mają podpisu cyfrowego, w przypadku przejęcia api.wordpress.org osoby atakujące mogą wysyłać złośliwe aktualizacje do tysięcy lub milionów witryn. Ten scenariusz znalazł się na czele umysłów ludzi pod koniec zeszłego roku, po tym, jak Wordfence opublikował szczegóły złożonej luki w zabezpieczeniach, która mogła naruszyć serwery aktualizacji.

Arciszewski sugeruje jako rozwiązania podpisywanie kodu offline i kryptografię krzywych eliptycznych: „Klucz, który może wygenerować prawidłowy podpis dla pliku, nie jest przechowywany na serwerze (tylko sam plik i prawidłowy podpis są), więc nawet jeśli serwer zostanie zhakowany , osoby atakujące nie mogą po prostu dodać do pliku złośliwego oprogramowania konia trojańskiego” — powiedział.

OpenSSL jest rozszerzeniem PHP i jest powszechnie używany jako kryptografia z kluczem publicznym, ale obsługuje tylko RSA, co Arciszewski uważa za niewystarczające. Ponieważ WordPress jest napisany w PHP i obsługuje wersje 5.2-7+, Arciszewski musiał stworzyć rozwiązanie, które byłoby równie kompatybilne. To zainspirowało go do stworzenia sodium_compat, który dodaje weryfikację podpisu Ed25519 do automatycznego aktualizatora WordPressa.

Arciszewski przesłał szereg poprawek do WordPressa, ale został poinformowany przez Dion Hulse, programistę rdzenia WordPressa, że ​​biblioteki sodium_compat nie można połączyć z rdzeniem, dopóki nie przejdzie audytu bezpieczeństwa przeprowadzonego przez stronę trzecią. Audyty mogą kosztować dużo pieniędzy, więc plan Arciszewskiego polegał na sprawdzeniu, czy Automattic może przejąć część kosztów lub pozyskać fundusze. Jednak jego projekt został wstrzymany po tym, jak Mullenweg poinformował Hulse, aby przestał pracować nad tą funkcją, ponieważ nie jest ona powiązana z trzema głównymi obszarami działania Edytora, Customizer i REST API.

Arciszewski opisał tę decyzję jako nieodpowiedzialną i że każdy użytkownik ma powody do niepokoju: „Zespół WordPressa wykazał, że nie jest wystarczająco odpowiedzialny, aby zarządzać swoją imponującą własnością Internetu (z wyjątkiem niektórych osób, które nie są w stanie poprawić kursu organizacji )," powiedział. „Ten akt zaniedbania narazi resztę sieci na niebezpieczeństwo”.

Podpisywanie aktualizacji jest ważne, ale nie priorytetowe

Mullenweg odpowiedział na post na Medium.com swoim własnym i powtórzył zaangażowanie zespołu programistów WordPressa w bezpieczeństwo.

„Wszyscy zaangażowani bardzo poważnie podchodzą do swojej odpowiedzialności, a rozwój WordPressa oznacza, że ​​wielu rozważnych, ciężko pracujących ludzi zaangażowało się i myśli o bezpieczeństwie witryn WP holistycznie, pod każdym kątem” – powiedział.

Mullenweg wyjaśnił również, jakie ataki zostałyby powstrzymane przez wdrożenie podpisów cyfrowych do aktualizacji WordPressa.

„Może to powstrzymać atak typu man in the middle, w którym ktoś modyfikuje pliki aktualizacji w sieci między Twoim blogiem a WordPress.org, lub może powstrzymać sytuację, w której część domeny .org obsługująca aktualizację zostanie naruszona, ale podpis część nie jest, a ktoś zdecydował się wysłać aktualizacje, mimo że wie, że zostaną odrzucone” – powiedział.

Zespół nie wie o żadnych witrynach WordPress, które zostały zaatakowane w ten sposób. Chociaż istnieje taka możliwość, zakres szkód byłby prawdopodobnie ograniczony. Serwery aktualizacji są monitorowane przez całą dobę, a ponieważ wiele dużych firm hostingowych automatycznie skanuje witryny swoich klientów w poszukiwaniu złośliwego oprogramowania, złośliwa aktualizacja prawdopodobnie zostanie szybko wykryta.

Mullenweg opisuje, co by się stało, gdyby serwer aktualizacji został naruszony.

„Wyłączylibyśmy to naprawdę szybko, powiadomilibyśmy świat o problemie, naprawiliśmy problem, włączyliśmy go ponownie i powiadomiliśmy określone witryny lub hosty, jeśli to możliwe” – powiedział. Chociaż WordPress obsługuje 27,5% z 10 milionów najlepszych witryn śledzonych przez Alexę, jest bardzo mało prawdopodobne, że liczba witryn zostanie naruszona.

Dodaje, że istnieją prostsze sposoby na złamanie zabezpieczeń witryny WordPress i wymienił największe problemy z bezpieczeństwem WordPress na podstawie wpływu.

1. Witryny nie aktualizują rdzenia.
2. Witryny nie aktualizują wtyczek.
3. Witryny nie aktualizują motywów.
4. Słabe hasła, bez ochrony przed brute-force lub uwierzytelniania dwuskładnikowego.
5. Hosty (profesjonalne lub ad-hoc) nie skanują i nie naprawiają witryn.
6. Hipotetyczne kwestie niespotykane w praktyce, które odwracają uwagę od dotychczasowych priorytetów.

Mullenweg potwierdza, że ​​zaproponował darowiznę na audyt sodu_compat dzień przed opublikowaniem przez Arciszewskiego swojego posta. Nawet jeśli biblioteka przeszła audyt, kod nie mógł zostać od razu dodany do rdzenia. „Musiałbyś również wykonać pewną znaczącą pracę po stronie serwera, aby odizolować podpisywanie od serwera aktualizacji, więc w pierwszej kolejności warto ," powiedział.

A gdyby kod został dodany do rdzenia, skorzystałyby z niego tylko te witryny, które zaktualizowały się do wersji, która posiada bibliotekę kryptograficzną i sprawdzanie aktualizacji. WordPress.org nadal będzie musiał wysyłać aktualizacje do starszych wersji, które nie mają funkcji sprawdzania aktualizacji. Witryny te nadal byłyby narażone na otrzymanie złośliwej aktualizacji.

Mullenweg mówi, że podpisy cyfrowe i podpisywanie aktualizacji w końcu trafią do WordPressa, ale nie jest to priorytetem, ponieważ są przed nim inne problemy z bezpieczeństwem. " powiedział.

„Dobrym podejściem byłoby zbudowanie najpierw po stronie serwera, ponieważ prawidłowe wykonanie tego, powiedzmy z HSM, jest trudną i ważną częścią; następnie zdobądź podpisane paczki; następnie przetestuj weryfikację we wtyczce, ponieważ nie chcemy przerywać automatycznych aktualizacji; a następnie w końcu połączyć się z rdzeniem i ustawić klienta, aby odrzucał niepodpisane aktualizacje. Po stronie klienta musimy wybrać bibliotekę kryptograficzną i poddać ją audytowi”.

Mullenweg zakończył swój post, wyjaśniając, dlaczego opublikował swoją odpowiedź na Medium zamiast na swojej osobistej stronie. „Wydaje się, że to najpopularniejsze miejsce na takie tyrady. Chciałem też wypróbować słynnego edytora Medium” – powiedział.

Co dalej z sodem_compat

Chociaż perspektywy dodania jego biblioteki do WordPressa w 2017 roku nie wyglądają dobrze, Arciszewski mówi, że istnieje wiele innych projektów PHP, które mogłyby na tym skorzystać. audyt kryptografii partii i próba sfinansowania kosztów” – powiedział.