Vulnerabilitate critică în pagina de login WordPress

Ce s-a întâmplat, pe înțelesul tuturor

Gândește-te la pagina de login a site-ului tău ca la recepția unei clinici: e prima încăpere în care intră oricine, fără programare și fără să spună cine e. Nu ai cum să o închizi, pentru că prin ea intri și tu.

Problema descoperită acum stă exact în acea recepție. Atunci când cineva greșește parola, WordPress afișează un mesaj de eroare. S-a dovedit că, în anumite condiții, textul care ajunge în acel mesaj nu era verificat suficient de strict — iar un atacator putea strecura acolo instrucțiuni pe care browserul le executa ca și cum ar fi venit de la site-ul tău.

În limbaj tehnic asta se numește cross-site scripting. În limbaj de zi cu zi: recepționera repetă cu voce tare orice i se dictează, iar cine e în cameră ascultă și execută.

De ce e considerată gravă

Problema a primit nota 8,9 din 10 la gravitate, iar motivele sunt trei:

• Nu e nevoie de cont sau parolă. Oricine de pe internet poate declanșa problema, fără să fie logat pe site-ul tău.
• Adresa e cunoscută de toată lumea. Pagina de login a WordPress e una dintre cele mai scanate adrese de pe internet. Roboții o caută automat, în masă, pe milioane de site-uri.
• Aproape toată lumea e afectată. Intervalul de versiuni acoperă practic tot ce s-a instalat din 2016 încoace și nu a fost actualizat.

La câteva zile după ce problema a fost făcută publică, scanările automate care o caută erau deja vizibile pe internet. Asta e tiparul obișnuit: între momentul în care apare reparația și momentul în care majoritatea site-urilor o instalează există o fereastră de câteva săptămâni. În fereastra aia se lucrează.

Cum se ajunge de la o pagină de login la controlul întregului site

Singură, problema pare limitată — „rulează niște cod în browser, și ce dacă?". Riscul real apare când victima e chiar administratorul site-ului.

Scenariul, la nivel de principiu, arată așa: ești logat în panoul de administrare (cum sunt majoritatea proprietarilor de site-uri, tot timpul, în același browser). Primești un link — pe e-mail, pe WhatsApp, într-un comentariu. Îl deschizi. Din acel moment, codul strecurat poate face în panou aceleași lucruri pe care le-ai putea face tu, pentru că browserul tău e deja autentificat.

Iar în panoul de administrare WordPress există, implicit, un editor de fișiere pentru teme și pluginuri. Acolo se poate adăuga cod care rămâne pe server și după ce închizi pagina. Așa se trece de la „o problemă în pagina de login" la „cineva are acces permanent la site".

Vestea bună: acest ultim pas nu se întâmplă singur. Cineva trebuie să te convingă să deschizi un link. Vestea proastă: e exact genul de lucru care funcționează, mai ales când linkul pare să vină de la site-ul tău.

Ești afectat?

Sunt afectate versiunile WordPress de la 4.7.0 până la 7.0.2 inclusiv. Reparația a apărut în 7.0.3, iar echipa WordPress a publicat versiuni de securitate și pentru ramurile mai vechi încă întreținute — deci nu ești obligat să faci un salt uriaș de versiune ca să fii în siguranță.

Ca să-ți vezi versiunea, intră în panoul de administrare și uită-te în Tablou de bord → Actualizări. Versiunea instalată scrie chiar în capul paginii.

Dacă ai actualizările automate de securitate pornite (setarea implicită la instalările noi), e foarte probabil să fii deja acoperit. Verifică totuși: multe site-uri au actualizările blocate de gazdă, de un plugin de „stabilizare" sau de fișierul de configurare, fără ca proprietarul să știe.

Ce ai de făcut, în ordine

1. Fă un backup complet — fișiere și bază de date. Înainte de orice intervenție, nu după.
2. Actualizează WordPress la 7.0.3 sau la versiunea de securitate corespunzătoare ramurii tale. E singura măsură care rezolvă cauza.
3. Verifică lista de utilizatori (Utilizatori → Toți utilizatorii) și șterge orice cont de administrator pe care nu-l recunoști.
4. Schimbă parolele conturilor de administrator și deconectează sesiunile active, ca să nu rămână cineva logat cu o sesiune veche.
5. Pornește autentificarea în doi pași pentru conturile cu drepturi de administrator. E cea mai ieftină măsură cu cel mai mare efect.
6. Dezactivează editorul de fișiere din panou. E pasul care rupe lanțul descris mai sus și, sincer, aproape nimeni nu are nevoie de el.
7. Pune un filtru în fața site-ului — un firewall la nivel de server sau un plugin de securitate care blochează tiparele de atac cunoscute înainte să ajungă la WordPress.

Dacă vreunul dintre pași sună complicat, nu improviza pe site-ul de producție. Scrie-ne și îl facem noi, fără să riscăm să pice ceva.

Cum îți dai seama dacă cineva a profitat deja

Actualizarea închide ușa, dar nu spune dacă a intrat cineva înainte. Semnele care merită verificate:

• Conturi de administrator apărute fără explicație.
• Fișiere de temă sau de plugin modificate recent, deși tu nu ai atins nimic.
• Pagini sau articole publicate în alte limbi, pe care nu le-ai scris.
• Vizitatorii sunt redirecționați spre alte site-uri, dar ție nu ți se întâmplă când ești logat.
• E-mailurile trimise de site ajung brusc în spam sau apar avertismente în Google.

Le-am detaliat pe toate, cu ce înseamnă fiecare, în ghidul 10 semne că site-ul tău WordPress este infectat. Dacă recunoști ceva de acolo, tratează-l ca pe o urgență: vezi ce faci, pas cu pas, când site-ul e virusat.

De ce actualizarea nu e toată povestea

Fiecare astfel de anunț urmează același traseu: apare reparația, apare descrierea publică, apar uneltele automate care caută site-urile nereparate. Diferența dintre un site care scapă și unul care nu scapă e, aproape întotdeauna, timpul de reacție.

De asta merită să ai și un strat de protecție care nu depinde de cât de repede actualizezi tu: un firewall care recunoaște tiparul de atac și îl oprește indiferent de versiunea instalată. Nu înlocuiește actualizarea — îți cumpără timp până când reușești să o faci.

Restul măsurilor care contează cu adevărat, în ordinea impactului, sunt în ghidul complet de securizare WordPress.