Brevo: ClickFix trafił do stron przez legalne widgety

Incydent trwał łącznie od 15:01 do 20:30 UTC, czyli 5 godzin i 29 minut. Od 16:07 zmieniona treść była dołączana do trzech skryptów używanych także jako komponenty osadzane na zewnętrznych stronach. Wybrani użytkownicy mogli zobaczyć fałszywy ekran weryfikacji wykorzystujący technikę ClickFix.

Dla security awareness istotne jest to, że użytkownik nie musiał wejść na oczywiście fałszywą domenę. Niebezpieczna treść mogła pojawić się na legalnej stronie korzystającej z prawdziwego komponentu dostawcy. Znana domena i znajomy widget nie powinny więc przesłaniać oceny tego, o co dokładnie prosi strona.

Co Brevo potwierdziło po incydencie z 14 września

Brevo to platforma do komunikacji z klientami i automatyzacji marketingu. W oficjalnym opisie incydentu firma wskazała, że napastnik uzyskał dostęp do długo ważnego klucza Cloudflare o szerokich uprawnieniach.

Przejęty dostęp pozwolił zmieniać treść na warstwie CDN. Oznacza to, że pliki na serwerach źródłowych Brevo nie musiały zostać zmodyfikowane, aby użytkownik otrzymał inną odpowiedź.

Brevo podało, że ogólne oddziaływanie złośliwej zmiany trwało od 15:01 do 20:30 UTC. Od 16:07 zmodyfikowana treść była dołączana do trzech plików JavaScript związanych z formularzami, widgetem Brevo Conversations i loaderem SDK, czyli komponentami, które mogą być osadzane na stronach klientów.

Firma zaznaczyła również, czego incydent nie objął. Według post-mortem aplikacja app.brevo.com, API Brevo, wysyłanie wiadomości e-mail oraz dane kont klientów przechowywane w Brevo nie zostały naruszone w tym zdarzeniu. Nie ma więc podstaw, aby opisywać ten przypadek jako potwierdzony wyciek całej bazy klientów Brevo.

Jak legalny widget stał się kanałem ClickFix

Warstwa CDN pośredniczy w dostarczaniu treści do przeglądarki. Jeżeli zostanie naruszona, użytkownik może otrzymać inną odpowiedź niż ta, którą właściciel aplikacji widzi w plikach źródłowych.

To ma znaczenie dla stron korzystających z zewnętrznych komponentów. Witryna klienta mogła być poprawna, a mimo to pobierać zmienioną wersję skryptu Brevo. Użytkownik widział legalną domenę i zwykły element strony, ale treść dostarczona w danym momencie pochodziła z naruszonej ścieżki dostawy.

BleepingComputer, serwis informacyjny poświęcony cyberbezpieczeństwu, opisał zdarzenie jako atak na łańcuch dostaw: incydent po stronie dostawcy komponentu rozszerzył ryzyko na strony, które ten komponent osadzały.

Fałszywa weryfikacja wykorzystywała ClickFix. To technika socjotechniczna, w której technicznie wyglądający komunikat przekonuje użytkownika do wykonania nietypowej czynności pod pozorem potwierdzenia, naprawy problemu lub odblokowania strony. Mechanizm opisujemy szerzej w artykule ClickFix i fałszywe CAPTCHA.

Punkt decyzyjny dla użytkownika jest prosty: jeśli weryfikacja nagle wychodzi poza normalne zachowanie strony i żąda nietypowej czynności, należy ją przerwać i zgłosić.

Co oznacza „ponad 100 tys. stron” i czego ta liczba nie dowodzi

Sansec, zespół badawczy publikujący analizy zagrożeń związanych z witrynami internetowymi, oszacował, że komponenty objęte problemem były używane przez ponad 100 tys. stron.

Ta wartość nie jest równoznaczna z potwierdzoną liczbą zainfekowanych witryn, użytkowników, którym pokazano fałszywą weryfikację, ani urządzeń, na których doszło do dalszego naruszenia. Brevo nie podało oficjalnej liczby skutecznie zaatakowanych odwiedzających.

Dlatego liczba Sansec powinna pozostać przypisana temu źródłu. Opisuje możliwą skalę ekspozycji komponentu, a nie potwierdzony wynik kampanii.

Dlaczego zwykła kontrola plików mogła nie wystarczyć

Brevo poinformowało, że pliki na serwerach źródłowych nie zostały zmienione. Zmiana działała na warstwie CDN i wpływała na odpowiedź w drodze do odbiorcy. To wyjaśnia, dlaczego sama kontrola plików źródłowych nie musiała pokazać tego, co rzeczywiście otrzymywała przeglądarka.

Dla organizacji korzystającej z zewnętrznych skryptów ważne jest więc nie tylko pytanie, czy zmieniła się własna aplikacja, lecz również czy zewnętrzna zależność zachowuje się tak jak wcześniej.

Ten przypadek pasuje do szerszego wzorca nadużywania zaufania do przeglądarki: poprawny kontekst techniczny może zostać użyty do przedstawienia użytkownikowi niebezpiecznej instrukcji.

Co powinien zrobić użytkownik przy fałszywej weryfikacji

Jeżeli strona informuje o błędzie, CAPTCHA lub potrzebie potwierdzenia człowieka, ale instrukcja wymaga nietypowej czynności poza zwykłym procesem w przeglądarce, użytkownik powinien przerwać proces.

Nie należy zakładać, że prośba jest bezpieczna tylko dlatego, że pojawia się na znanej stronie. Przy incydencie u dostawcy właśnie ta normalność może zwiększać wiarygodność komunikatu. Bezpieczniejszą reakcją jest zamknięcie komunikatu, ponowne wejście na usługę niezależną drogą i zgłoszenie sytuacji do zespołu bezpieczeństwa lub pomocy technicznej.

Jeżeli podejrzana instrukcja została już wykonana, pracownik powinien szybko zgłosić zdarzenie zgodnie z procedurą organizacji, aby zespół techniczny mógł sprawdzić urządzenie, aktywne sesje i zakres zdarzenia.

Celem szkolenia nie jest uczenie użytkownika analizy kodu lub infrastruktury CDN. Punkt decyzji jest prostszy: nietypowa czynność żądana przez stronę powinna zatrzymać proces i uruchomić zgłoszenie.

Co powinna sprawdzić organizacja używająca zewnętrznych widgetów

Pierwszy krok to wiedzieć, które zewnętrzne skrypty, formularze, widgety i biblioteki działają na publicznych stronach. Bez takiej ewidencji trudno szybko odpowiedzieć na komunikat dostawcy o naruszeniu konkretnego komponentu.

Drugi krok to możliwość szybkiego wyłączenia zależności. Jeżeli dostawca informuje o aktywnym incydencie, organizacja powinna mieć sposób na tymczasowe usunięcie lub zablokowanie komponentu bez długiego cyklu zmian całej aplikacji.

Warto także obserwować zachowanie strony od strony użytkownika, a nie wyłącznie integralność własnych plików. Kontrola zewnętrznych zależności i jasna ścieżka reakcji na incydent dostawcy zmniejszają czas potrzebny do ograniczenia ekspozycji.

Po stronie dostawców przypadek Brevo pokazuje znaczenie ograniczania uprawnień oraz czasu ważności danych dostępowych. Oficjalny post-mortem wiąże możliwości napastnika z długo ważnym kluczem Cloudflare o szerokich uprawnieniach.

Jak ćwiczyć ten scenariusz w security awareness

Typowy test phishingowy zaczyna się od podejrzanej wiadomości. Incydent Brevo daje inny scenariusz: pracownik trafia na legalną stronę, ale w pewnym momencie widzi instrukcję, której nie powinien wykonywać.

Takie ćwiczenie może sprawdzać trzy zachowania. Po pierwsze, czy użytkownik rozpoznaje nietypowy krok. Po drugie, czy powstrzymuje się od wykonania instrukcji mimo zaufanego kontekstu. Po trzecie, czy szybko zgłasza sytuację.

PHISHLY może odtwarzać podobne punkty decyzyjne w bezpiecznych testach phishingowych dla firm. Szerszy program security awareness powinien łączyć takie ćwiczenia z jasną ścieżką zgłaszania oraz zasadą, że pracownik może przerwać proces, gdy instrukcja nie pasuje do normalnego sposobu działania usługi.

Co wynika z incydentu Brevo

Brevo nie opisuje klasycznego przypadku, w którym użytkownik dostał wiadomość z przypadkowej domeny i sam wszedł na fałszywą stronę. Problem powstał wyżej w łańcuchu: przejęty dostęp do warstwy CDN pozwolił zmieniać treść dostarczaną przez legalne komponenty.

To zmienia sposób, w jaki warto uczyć zaufania w przeglądarce. Znana domena i prawdziwy widget są pomocnymi sygnałami, ale nie są bezwarunkowym potwierdzeniem bezpieczeństwa każdej instrukcji wyświetlanej na stronie.

Najbardziej praktyczna reguła dla użytkownika jest prosta: jeśli strona żąda nietypowej czynności wykraczającej poza zwykły proces, trzeba przerwać działanie i zgłosić zdarzenie. Dla organizacji druga część tej samej zasady brzmi: zewnętrzny komponent jest częścią własnej powierzchni ryzyka, nawet jeśli jego kod i infrastruktura należą do dostawcy.