Czy utrzymane wtyczki powinny zostać zawieszone w repozytorium WordPressa, gdy wystąpi problem z bezpieczeństwem?

Opublikowany: 2020-03-12

27 lutego 2020 r. o godzinie 21:34 (CET) otrzymaliśmy wiadomość e-mail z powiadomieniem, że nasza wtyczka WP Activity Log została „ tymczasowo wycofana z katalogu wtyczek WordPress.org z powodu exploita” .

Zgłosiliśmy poprawkę w piątek, 28 lutego 2020 r., o 16:08. Wydanie poprawki zajęło nam tylko 16,5 godziny. Naprawilibyśmy ten problem znacznie wcześniej, gdyby stało się to w naszych normalnych godzinach pracy (mamy siedzibę w Europie), ponieważ mamy bardzo dobry czas reakcji pomocy technicznej (odniesienie).

Nasza wtyczka została przywrócona w poniedziałek 2 marca 2020 o godzinie 13:00. To jest 69 godzin po przesłaniu poprawki. Należy zauważyć, że przywrócenie wtyczki zajęło zespołowi tak dużo czasu z powodu weekendu.

Dziennik aktywności WP wycofany z repozytorium

Dlaczego to piszę?

Chciałbym zaznaczyć, że uważam, że nieobsługiwane wtyczki, które mają problemy z bezpieczeństwem, powinny zostać zawieszone w repozytorium WordPressa. Mam również ogromny szacunek do pracy, jaką wykonują wolontariusze z zespołu recenzji wtyczek, a także biorę pełną odpowiedzialność za zgłoszony problem z bezpieczeństwem.

Wierzę jednak, że zgłoszone problemy z bezpieczeństwem w utrzymanych wtyczkach mogą być lepiej rozwiązane. Ze względu na sposób, w jaki są one obecnie obsługiwane, reputacja wtyczki jest bardzo ujemna, a jej użytkownicy i ich strony internetowe są narażeni na ryzyko. Dlatego na końcu tego wpisu podkreślam kilka możliwych ulepszeń, które mogą pomóc i myślę, że należy je rozważyć. Chodzi o to, aby zawsze narażać mniej użytkowników na ryzyko i zmniejszać wpływ wtyczki i programistów.

W tym poście udokumentuję również wszystkie szczegóły tego, co się wydarzyło, i wyjaśnię zgłoszoną w naszej wtyczce podatność na krawędzie przypadków o niskim poziomie ważności.

Jak wygląda procedura zgłaszania problemu z bezpieczeństwem wtyczki WordPress?

Z oficjalnych wytycznych w Podręczniku wtyczek:

Każda próba bezpośredniego kontaktu z deweloperem powinna być podjęta przed zgłoszeniem nam wtyczki (choć rozumiemy, że może to być trudne – sprawdź najpierw kod źródłowy wtyczki, wielu deweloperów podaje swoje adresy e-mail). Jeśli nie możesz skontaktować się z nimi prywatnie, skontaktuj się z nami bezpośrednio, a my pomożemy.

Co się stało w naszym przypadku?

We wtyczce jest bardzo jasne, kto ją tworzy. Wystarczy spojrzeć na stronę wtyczki w repozytorium, a zrozumiesz! Ułatwiamy również kontakt z nami.

Jednak nikt nie zgłosił nam problemu z bezpieczeństwem przed tymczasowym wycofaniem wtyczki z repozytorium wtyczek. Więc ktoś zgłosił problem zespołowi ds. weryfikacji wtyczek WordPress i tymczasowo wycofał naszą wtyczkę z repozytorium bez wcześniejszego powiadomienia.

Zanim zagłębimy się w „dlaczego” i „co”, oraz co jest dobre, złe i co można poprawić, przyjrzyjmy się luce w zabezpieczeniach wtyczki i krótkiemu wyjaśnieniu, kim jesteśmy.

Jaka była luka w zabezpieczeniach wtyczki?

W WP Activity Log mamy kreatora instalacji, który pomaga użytkownikom skonfigurować wtyczkę. Jedno z ustawień kreatora pozwala użytkownikom niebędącym administratorami na odczytywanie dzienników aktywności.

Kreator instalacji dziennika aktywności WP

Jednak popełniliśmy błąd; nie sprawdziliśmy, czy użytkownik uruchamiający kreatora został uwierzytelniony. Dlatego nieuwierzytelnieni użytkownicy mogą uruchomić kreatora i zezwolić innemu użytkownikowi lub roli na dostęp do ustawień wtyczki. Jest to jednak skrajny problem o niskiej ważności.

Dlaczego jest to problem z zabezpieczeniami skrajnych przypadków o niskim poziomie ważności?

Osoby atakujące mogą to wykorzystać tylko wtedy, gdy:

  • kreator instalacji nigdy nie został ukończony przez instalatora,
  • atakujący mieli już użytkownika / mieli dostęp do użytkownika w serwisie,
  • Osoby atakujące mogą uzyskać jedynie dostęp do ustawień wtyczki i dziennika aktywności.

Wykorzystując te problemy z bezpieczeństwem, osoby atakujące nie uzyskują dostępu do innych uprawnień w witrynie WordPress. W związku z tym ten exploit nie ma żadnego negatywnego wpływu na zachowanie i funkcjonalność samego serwisu.

Dowód koncepcji

POC jest bardzo prosty. Odwiedź tę stronę jako nieuwierzytelniony użytkownik:

http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access

To jest krok kreatora, który pozwala określić, kto może zobaczyć logi. Wyszukaj wartość jednorazową „_wpnonce” w źródle strony HTML, skopiuj ją i wstaw w następującej komendzie curl:

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-TUTAJ&wsal-access=yes&editors%5B%5D= subskrybent&save_step=Dalej'

Po zalogowaniu się jako subskrybent będziesz miał pełny dostęp do ustawień wtyczki.

Dlaczego uważamy, że ta sprawa została niewłaściwie załatwiona?

W wysłanej do nas wiadomości e-mail znajdowały się:

Nie zamykamy wtyczek pochopnie, a jeśli chodzi o kwestie bezpieczeństwa, staramy się zrównoważyć liczbę użytkowników i historię programistów z powagą i możliwością uszkodzenia raportu.

Myślę jednak, że nasza wtyczka została wycofana zbyt wcześnie. Dotychczas;

  1. Kiedy w przeszłości mieliśmy problemy, zawsze rozwiązywaliśmy je w ciągu kilku godzin. Tym razem zrobiliśmy to samo.
  2. Zawsze odpowiadaliśmy na czas, gdy kontaktował się zespół ds. wtyczek.
  3. Problem z bezpieczeństwem dotyczył tylko naszej wtyczki (niski poziom ważności) i był to przypadek skrajny.
  4. Problemu bezpieczeństwa nie można było wykorzystać automatycznie.
  5. Jedyną szkodą , jaką mógł zrobić atakujący, była zmiana ustawień wtyczki, odczytanie dzienników aktywności lub ich wyczyszczenie.

Co inni programiści sądzą o takich sytuacjach?

Większość z nas przeczytała już artykuł, tweet lub wiadomość w mediach społecznościowych o podobnych sprawach. Chciałem jednak dowiedzieć się na własne oczy, co myślą o tym inni ludzie, zwłaszcza deweloperzy. Myślę, że to ważne, ponieważ mogą być rzeczy, których nie widzę.

Na początek wysłałem e-mail do osoby, która zidentyfikowała problem, dziękując jej za odpowiedzialne ujawnienie. Jego odpowiedź brzmiała:

„Cieszę się, że szybko naprawiłeś problem we wtyczce. BTW, zauważyłem, że ludzie z wordpress.org zamknęli go na kilka dni, co było trochę surowe i nie było tak naprawdę potrzebne.”- Jerome Bruandet.

Zrobiłem też małą ankietę w grupie na Facebooku Sprzedaż produktów WordPress. Chociaż ta grupa jest niewielka, większość jej członków to twórcy wtyczek i motywów. Z ankiety widać, że programiści jednogłośnie zgadzają się, że w przypadku problemów o niskim lub średnim stopniu należy się z nimi skontaktować i dać im szansę na dostarczenie poprawki, a nie wycofywanie wtyczki:

Ankieta deweloperów wtyczek WordPress na grupie na Facebooku

Jak można ulepszyć te procedury?

Zgodnie z moją najlepszą wiedzą, nie ma żadnych udokumentowanych procedur, gdy ktoś zgłasza problem z bezpieczeństwem we wtyczce. W takim przypadku procedury takie jak poniżej mogą pomóc programistom, a także narazić mniej ludzi na ryzyko.

Skontaktuj się z programistami i uzgodnij plan działania przed zamknięciem wtyczki

Zespół ds. przeglądu wtyczek może spróbować skontaktować się z twórcami i potwierdzić lukę przed zamknięciem wtyczki. Deweloperzy powinni odpowiedzieć z planem działania, w tym rozsądną datą poprawki.

W razie potrzeby zespół ds. recenzji wtyczek może ustalić termin. Na przykład programiści powinni mieć od 12 do 24 godzin na rozwiązanie problemu. Jednak w niektórych przypadkach mogą potrzebować więcej czasu, w zależności od strefy czasowej, w której się znajdują itp. Jeśli programiści nie odpowiedzą, wtyczka powinna zostać usunięta z repozytorium.

Określ wagę i rodzaj problemu dotyczącego bezpieczeństwa

To może być przedmiotem debaty. Jednak ktoś, kto ma trochę doświadczenia w zakresie bezpieczeństwa, może łatwo stwierdzić, czy zgłoszony problem z zabezpieczeniami może zostać automatycznie wykorzystany, czy jest to przypadek skrajny, czy nie, i jaki jest jego wpływ na zgłoszony dowód koncepcji (POC).

Sprawdź, czy programiści trzymają się planu działania

Powinien istnieć rodzaj kontroli, aby potwierdzić, że programiści przesłali poprawkę na czas i trzymają się wszelkich innych zadań zawartych w planie działania.

Wycofanie utrzymywanych wtyczek z repozytorium nie pomaga

W przypadku utrzymywanych wtyczek wycofanie ich z repozytorium wyrządza więcej szkody niż pożytku. Na przykład;

  1. Upubliczniasz, że wtyczka ma problem, najprawdopodobniej problem z bezpieczeństwem. Rodzi to wiele alarmów i zwraca uwagę na wtyczkę. Przypomina to również zapraszanie napastników, informowanie ich, że coś we wtyczce można wykorzystać.
  2. Ujawnia aktualną bazę użytkowników wtyczek, ponieważ nagle ich strony internetowe stały się celem. Większość użytkowników nie ma pojęcia, co powinni zrobić, zwłaszcza jeśli funkcjonalność wtyczki jest podstawą ich witryny i biznesu.
  3. Zwiększasz szanse na opóźnienie poprawki. Jest to zazwyczaj spowodowane brakiem komunikacji lub świętami i weekendami.

Można by argumentować, że wycofując wtyczkę z repozytorium, zatrzymujesz rozprzestrzenianie się infekcji . Jeśli jednak kwestia bezpieczeństwa ma niską wagę, wykorzystywanie nie może być zautomatyzowane, a ujawnienie jest odpowiedzialne, nie ma żadnych zagrożeń lub ryzyko jest bardzo niskie.

Zastrzeżenie: To nie jest atak

Chciałbym zaznaczyć, że nie jest to atak na zespół recenzentów wtyczek WordPress ani na kogokolwiek zaangażowanego w te procesy. Szczerze szanuję ich pracę i wiem, że robią to w dobrej wierze. Jednak z pewnością jest miejsce na poprawę, jak w każdym innym systemie i procesie.

Wielu zapewne powie mi, że jeśli chcę zmiany, to powinienem zgłosić się na ochotnika zamiast pisać ten post.

Próbuję dołączyć od dłuższego czasu; Rozmawiałem z kilkoma osobami z różnych WordCamps, aby się zaangażować, a także monitorowałem stronę wtyczek Make WordPress pod kątem wezwania wolontariuszy. Jednak w ciągu ostatnich kilku lat nie mieli żadnych wakatów. Gdy potrzebowali pomocy, dodawali nowych członków tylko przez zaproszenie.