Twórcy wtyczek i motywów: tego można się dowiedzieć z luki w zabezpieczeniach naszego pakietu SDK

Ten tydzień był dość intensywny dla naszego zespołu, ponieważ musieliśmy poradzić sobie z luką w zabezpieczeniach. Bezpieczeństwo jest dla nas najwyższym priorytetem i jest to pierwsza poważna luka w naszym SDK od czterech lat. Niestety, jak w przypadku każdego oprogramowania – programiści to także ludzie, więc błędy się zdarzają, niezależnie od tego, czy jesteś niezależnym programistą, 20-osobowym sklepem z motywami, czy Google. Celem tego artykułu jest przede wszystkim przejrzystość, ale także pokazanie, jak poradziliśmy sobie z incydentem i czego możesz się z niego nauczyć.

W poniedziałek 25 lutego 2019 r. otrzymaliśmy wiadomość e-mail z pomocą techniczną od pomocnego programisty, który natknął się na problem z GitHub w repozytorium WooCommerce. Problem został stworzony przez przedstawiciela małej firmy hostingowej, który zauważył podejrzaną aktywność na swoich serwerach. Przedstawiciel zamieścił odpowiednie dzienniki aktywności, które wskazywały na dwa potencjalne ataki, a jeden z nich był wymierzony we wtyczkę z pakietem Freemius SDK.

Ponieważ bardzo poważnie traktujemy bezpieczeństwo, natychmiast przeprowadziliśmy dokładne dochodzenie i potwierdziliśmy, że luka rzeczywiście znajduje się w naszym SDK.

Ze względu na wagę luki od razu rozpoczęliśmy prace nad poprawką. Po zaledwie kilku godzinach opublikowaliśmy załatany tag i powiadomiliśmy wszystkich programistów, którzy korzystali z podatnej wersji SDK, aby jak najszybciej zaktualizować SDK we wszystkich swoich produktach. Zaktualizowaliśmy również oryginalny problem z GitHub, aby poinformować o nim zespół WooCommerce (problem GH, który usunęliśmy po kilku godzinach, aby zmniejszyć ekspozycję).

Aby złagodzić narażenie i dać wszystkim pewien czas na aktualizację do wersji poprawionej, poprosiliśmy programistów o dwie rzeczy:
(a) Jeśli ta aktualizacja bezpieczeństwa zostanie uwzględniona w twoim dzienniku zmian, używaj tylko ogólnych sformułowań, takich jak „Poprawka bezpieczeństwa”.
(b) Nawet po zaktualizowaniu i wydaniu zaktualizowanych wersji prosimy o nieujawnianie tego problemu w ciągu następnych 30 dni, dając wystarczająco dużo czasu wszystkim naszym partnerom i ich użytkownikom na aktualizację.

Zaledwie dzień później witryna, która opisuje luki w zabezpieczeniach wtyczek (celowo nie zawiera do nich linków ani nie podaje ich nazwy), opublikowała post na temat luki, w tym informacje o tym, jak ją wykorzystać, wymieniając kilka z wtyczek, których dotyczy problem. To nas zaskoczyło, ponieważ właśnie powiadomiliśmy twórców wtyczek i motywów o problemie mniej niż 24 godziny wcześniej. Nie kontaktowali się z nami ani nie stosowali praktyki rynkowej Responsible Disclosure , którą uważamy za dość nieodpowiedzialną i nieetyczną.

Skontaktowałem się z nimi, prosząc o tymczasowe wycofanie raportu, aby zmniejszyć narażenie i dać naszym programistom i ich użytkownikom szansę na aktualizację do poprawionych wersji, zanim przyciągnie niechcianą uwagę większej liczby hakerów. Ale osoba, z którą się komunikowałem, która nigdy nie ujawniła swojego nazwiska (prosiłem ich), ma swoją własną słuszną ideologię i wydaje się, że zdrowy rozsądek do niej nie przemawia. Próbowałem wyjaśnić problematyczną sytuację i zwiększone ryzyko, jakie narażają one wielu programistom i użytkownikom, ale moje wysiłki nie zostały wysłuchane i zdałem sobie sprawę, że moja wymiana e-maili była tylko stratą czasu.

Gdy społeczność naszych programistów aktualizowała swoje wtyczki i motywy do nowo załatanego pakietu SDK, który wydaliśmy, wykryliśmy dwa problemy:

1. Kilku programistów nie otrzymało naszego e-maila z ostrzeżeniem, ponieważ zarejestrowali się na Freemius za pomocą adresu e-mail, którego nie sprawdzają.
2. Celowo nie oznaczyliśmy poprawionego tagu GitHub jako oficjalnego wydania, aby uniknąć przyciągania uwagi. Jednak dowiedzieliśmy się, że programiści, którzy używali Composera do aktualizacji swoich bibliotek, nie otrzymywali najnowszej aktualizacji, ponieważ packgist pobiera tylko wydania, chyba że wyraźnie określili tag.

Aby rozwiązać te problemy:

1. Ponieważ luka została już opublikowana publicznie, dwa dni temu oznaczyliśmy łataną wersję jako oficjalną, aby programiści, którzy polegają na packgist, mogli dokonać aktualizacji.
2. Wcześniej tego ranka wysłaliśmy e-mailem kolejną partię wiadomości do programistów, którzy jeszcze nie zaktualizowali SDK we wszystkich swoich produktach. Tym razem wysłaliśmy wiadomości do ich oficjalnych kanałów wsparcia, aby zwiększyć szanse, że wszyscy otrzymają e-maile prawidłowo.

Mimo że chcieliśmy odroczyć publikację tej luki o co najmniej dwa tygodnie, otrzymaliśmy kolejne zapytanie od WP Tavern z prośbą o wkład, zanim opublikowali własny artykuł na ten temat, który był kroplą, która przebiła klawiaturę dewelopera.

Błędy, które popełniliśmy i czego można się z nich nauczyć

Patrząc wstecz na ten incydent, popełniliśmy kilka błędów, których mogliśmy łatwo uniknąć i które znacznie ułatwiłyby życie wszystkim.

Przejdź w tryb cichy i ostrzegaj tylko tych, którzy muszą wiedzieć

Ponieważ tak bardzo chcieliśmy jak najszybciej naprawić ten problem, osobiście popełniłem błąd „żółtodzioba”, który zbyt wcześnie przyciągnął niechcianą uwagę. Poszedłem dalej i zatwierdziłem poprawkę do repozytorium GitHub, którego używamy do zarządzania SDK. Repozytorium jest nie tylko publiczne, ale wyjaśniłem poprawkę i użyłem w nim słowa „bezpieczeństwo”.

Lepszym podejściem było stworzenie prywatnej/zamkniętej wersji repozytorium, załatanie tam problemu bezpieczeństwa i ujawnienie go tylko odpowiednim programistom, zamiast upubliczniania go. Nie zwróciłoby to uwagi „łowców luk”.

Nie marnuj energii na „trolle bezpieczeństwa”

Drugim błędem była próba interakcji z firmą stojącą za witryną, która opublikowała lukę. Była to całkowita strata czasu i energii, a tylko wywołała więcej antagonizmu, który zakończył się kolejnym postem o luce. Powiedziałbym, że dobrym wskaźnikiem, aby zdecydować, czy warto poświęcić czas na skontaktowanie się z autorem postu, który zagraża użytkownikom twojej wtyczki lub motywu, jest nazwa za postem/witryną/firmą. Jeśli chowają się za pełnomocnikami i działają irracjonalnie, szansa, że ​​przemówisz do nich z sensem, jest praktycznie zerowa.

Oto moja rada – wejdź w tryb cichy i powiadom tylko osoby, które muszą wiedzieć o luce. W przypadku wtyczki/motywu są to Twoi użytkownicy. To także dobra okazja, by podkreślić, jak ważne jest zbieranie e-maili użytkowników. Jeśli nie masz możliwości prywatnej komunikacji ze swoimi użytkownikami, nie masz skutecznego sposobu na prywatne powiadamianie ich o problemach z bezpieczeństwem.

Aktualny status incydentu

Ponad 60% programistów korzystających z naszego SDK zaktualizowało już do wersji poprawionej. Dodatkowo SDK jest wyposażony w specjalny mechanizm, który pozwala wielu wtyczkom lub motywom wspieranym przez Freemius zainstalowanym na tej samej witrynie WordPress na korzystanie z najnowszej wersji SDK, jeśli jeden z produktów jest już zaktualizowany. Więc to dobrze.

To powiedziawszy, wciąż istnieje wiele witryn, które są podatne na ataki. Dlatego nie wspomniałem o żadnych szczegółach technicznych dotyczących samej luki ani produktów, których dotyczy problem. Nadal chcemy oferować naszym programistom możliwość łatania ich produktów i umożliwienia użytkownikom aktualizacji do bezpiecznych wersji.

Jak zmniejszyć zagrożenia bezpieczeństwa we wtyczce/motywie WordPress?

Jeśli nie masz żadnego doświadczenia w zakresie bezpieczeństwa, Google „najlepsze praktyki dotyczące bezpieczeństwa sieci”, a znajdziesz mnóstwo artykułów i praktyk. Przeczytaj kilka z nich, aby mieć świadomość współczesnych i typowych potencjalnych zagrożeń i błędów. Miej to na uwadze podczas procesu tworzenia i testowania. Inną dobrą praktyką jest przeprowadzanie okresowych audytów bezpieczeństwa poprzez zatrudnienie badacza bezpieczeństwa. Będzie to kosztować kilkaset dolarów, ale jeśli polegasz na swoim produkcie jako głównym źródle dochodu, to nie ma sensu.

Niestety, tak jak w naszym przypadku, wciąż mogą się zdarzyć złe rzeczy. Mimo że mamy bardzo dobre zaplecze w zakresie bezpieczeństwa, przeprowadzamy dokładne przeglądy kodu i współpracujemy z doświadczonym badaczem bezpieczeństwa ze społeczności HackerOne, ale ta luka wciąż prześlizgnęła się przez szczeliny.

Myślę, że jednym z powodów, dla których tak się stało, jest to, że podatny kod został faktycznie dodany do debugowania przypadków brzegowych i nie jest częścią podstawowej funkcjonalności SDK. Więc jeśli jest tutaj lekcja, traktuj dowolny fragment kodu w swoim produkcie w ten sam sposób, niezależnie od tego, czy jest on częścią rzeczywistej logiki biznesowej, czy cokolwiek innego.

podsumowanie

Problemy z bezpieczeństwem są nieuniknione w świecie oprogramowania. Niezależnie od tego, czy nam się to podoba, czy nie, pewnego dnia Twoja wtyczka lub motyw będą miały problem z bezpieczeństwem. Problem może dotyczyć Twojego kodu, używanej biblioteki/struktury, podstawowej metody WordPress, która zapewnia nieoczekiwane wyniki, i wielu innych scenariuszy.

Kiedy to się stanie (mam nadzieję, że tak się nie stanie), nie stresuj się (zdecydowanie to zrobiliśmy) i działaj impulsywnie — wyrządzi tylko więcej obrażeń. Opracuj metodologiczny plan naprawy, powiadom zainteresowane strony i bądź tam, aby pomóc swoim użytkownikom w zabezpieczeniu ich witryn. Wszyscy wiedzą, że zdarzają się problemy z bezpieczeństwem, ważniejsze jest to, jak radzisz sobie z sytuacją.

Mając to na uwadze, w imieniu całego zespołu Freemius, naprawdę przepraszamy za niedogodności i będziemy tu przez cały weekend, aby zaoferować wsparcie, porady lub jakąkolwiek inną pomoc związaną z problemem. A dla naszych nowych użytkowników wiem, jak ważne jest pierwsze wrażenie, a to zdecydowanie nie jest dobre. Mam nadzieję, że dasz Freemiusowi kolejną szansę i z czasem zobaczysz niesamowite funkcje, które oferujemy dla Twoich wtyczek i motywów WordPress.