Scriptul de marketing de pe site-ul tău a atacat vizitatorii: ce arată incidentul Brevo

• 14 septembrie, 15:01 UTC: potrivit Brevo, începe impactul pe propriile pagini; de la 16:07, worker-ul modifică și trei fișiere JavaScript încorporate de clienți, precum și sibforms.com.
• 20:30 UTC: Brevo elimină worker-ul și rutele sale și revocă cheia compromisă; la 20:42, verificarea confirmă că paginile și scripturile afectate servesc din nou conținut curat.
• Sansec a observat fereastra scripturilor încorporate între aproximativ 16:05 și 20:13 UTC, diferență compatibilă cu suprafața și metoda sa de observare.
• Pe 10 septembrie fusese anunțat separat un incident SAML SSO. Sursele publice nu confirmă că acesta și compromiterea Cloudflare au avut același autor sau aceeași cauză.
• Sansec estimează că peste 100.000 de site-uri foloseau componentele afectate. Este o estimare a expunerii potențiale, nu un număr confirmat de site-uri compromise ori de vizitatori infectați.

Vizitatorilor li se afișa o pagină falsă de tipul „Cloudflare, verify you are human” — tehnica de inginerie socială pe care am descris-o pe larg într-o analiză anterioară. Ideea este simplă și eficientă: utilizatorul crede că trece o verificare de rutină și execută el însuși pașii ceruți.

Pe site-urile WordPress, atunci când vizitatorul era un administrator autentificat, codul încerca să instaleze și să ruleze plugin-uri malițioase. Aici escaladarea devine serioasă: nu mai vorbim despre păcălirea unui vizitator oarecare, ci despre preluarea site-ului prin sesiunea celui care îl administrează.

• Confirmat de Brevo: cheia API compromisă fusese păstrată în codul aplicației, avea permisiuni complete asupra contului Cloudflare și a permis modificarea conținutului la marginea CDN fără schimbarea fișierelor-sursă.
• Documentat independent de Sansec: componentele afectate erau folosite de peste 100.000 de site-uri și codul încerca să instaleze un plugin pe site-urile WordPress când vizitatorul era administrator autentificat.
• Necunoscut public: câți vizitatori au interacționat efectiv cu pagina falsă, câte site-uri WordPress au ajuns să ruleze un plugin malițios și cine se află în spatele atacului.
• De reținut pentru proporție: fereastra de câteva ore limitează expunerea, dar nu o elimină. Un site cu trafic mare poate servi mii de vizitatori în patru ore.

Fiecare etichetă de marketing, widget de chat, instrument de analiză sau formular încorporat rulează în pagina ta, în browserul vizitatorului. Din perspectiva lui și a răspunsului operațional, diferența dintre codul scris intern și codul încorporat dispare atunci când pagina livrează comportamentul malițios.

Ceea ce face incidentul instructiv este că problema nu a fost o vulnerabilitate a funcției Brevo folosite de client, ci pierderea controlului asupra unei chei de acces la infrastructura de livrare. Pentru client, rezultatul practic rămâne grav: pagina sa a putut servi cod ostil fără ca propriile fișiere să fie modificate.

Aceasta este, în esență, o problemă de furnizori, nu de securitate a aplicației tale. Și se gestionează ca atare: inventar, limitare și capacitate de reacție.

• Fă lista scripturilor terțe încărcate pe paginile publice. Deschide o pagină reprezentativă, uită-te la ce domenii externe se încarcă și compară cu ce crede echipa de marketing că este instalat. Diferența dintre cele două liste este constatarea.
• Pentru fiecare script, notează cine l-a cerut, ce face și dacă mai este necesar. Etichetele rămase de la campanii încheiate acum doi ani sunt cod activ pe care nu îl mai revizuiește nimeni.
• Verifică dacă folosești Subresource Integrity sau o politică de securitate a conținutului. Niciuna nu este gratuită ca efort și SRI nu funcționează cu scripturi care se actualizează singure, dar merită discutate cu echipa tehnică pentru cele care pot fi fixate.
• Stabilește cine primește o alertă dacă un furnizor de scripturi anunță un incident, și în cât timp puteți scoate o etichetă de pe site. Dacă răspunsul este „deschidem un tichet și așteptăm”, fereastra ta de expunere este mult mai mare de patru ore.
• Întreabă furnizorii cu scripturi pe site-ul tău două lucruri concrete: cum sunt protejate cheile de acces la infrastructura lor de livrare și în cât timp te anunță în caz de incident. Cazul Brevo arată exact de ce contează prima întrebare.

Un raport util arată câte scripturi terțe rulează pe proprietățile publice, cine deține fiecare, care au fost eliminate ca nefolosite și ce s-a convenit contractual privind notificarea în caz de incident. Chiar și constatarea „avem unsprezece etichete și nimeni nu știe cine a cerut trei dintre ele” este un rezultat, dacă e documentată.

Pentru o organizație aflată în sfera NIS2, această trasabilitate susține securitatea lanțului de aprovizionare, fără a echivala automat cu conformitatea legală, care rămâne evaluarea proprie a organizației. Awarely Monitor poate lega furnizorii, activele expuse și dovada închiderii; decizia de a păstra sau elimina un script rămâne a echipei.