Czy utrzymane wtyczki powinny zostać zawieszone w repozytorium WordPressa, gdy wystąpi problem z bezpieczeństwem?
Opublikowany: 2020-03-1227 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.
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.
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¤t-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¤t-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;
- Kiedy w przeszłości mieliśmy problemy, zawsze rozwiązywaliśmy je w ciągu kilku godzin. Tym razem zrobiliśmy to samo.
- Zawsze odpowiadaliśmy na czas, gdy kontaktował się zespół ds. wtyczek.
- Problem z bezpieczeństwem dotyczył tylko naszej wtyczki (niski poziom ważności) i był to przypadek skrajny.
- Problemu bezpieczeństwa nie można było wykorzystać automatycznie.
- 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:
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;
- 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ć.
- 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.
- 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.