Un XSS stocat ascuns la vedere

O vulnerabilitate recent dezvăluită în suita de colaborare Zimbra le oferă echipelor de securitate un motiv să își verifice jurnalele de actualizare cu atenție. Urmărită sub codul CVE-2025-66376, problema este o vulnerabilitate de tip cross-site scripting stocat (XSS) în Classic Web Client, interfața mai veche, bazată pe HTML, încă folosită de multe implementări Zimbra alături de aplicația web modernă.

Ceea ce face acest bug remarcabil este cât de puțin trebuie să facă victima pentru a-l declanșa. Conform dezvăluirii, simpla deschidere a unui e-mail malițios în interfața clasică este suficientă pentru a executa cod controlat de atacator în interiorul sesiunii autentificate de webmail a victimei. De acolo, atacatorul poate extrage tokenuri de sesiune, parole stocate în browser și chiar coduri de rezervă pentru autentificarea cu doi factori, acele coduri de backup pe care utilizatorii se bazează atunci când metoda principală 2FA nu este disponibilă.

Cum funcționează atacul

Vulnerabilitățile XSS stocat sunt deosebit de periculoase deoarece payload-ul malițios nu trebuie să fie accesat prin clic sau descărcat separat. Acesta este încorporat direct în conținutul pe care clientul de e-mail îl redă automat, în acest caz prin directive CSS (Cascading Style Sheets) inserate într-un e-mail. Classic Web Client Zimbra nu a reușit să igienizeze corespunzător acest conținut, permițând CSS-ului să execute JavaScript în contextul sesiunii de căsuță poștală a utilizatorului autentificat.

Odată executat acel cod, acesta moștenește tot ce are deja acces sesiunea victimei. Acest lucru îi permite să ajungă dincolo de inbox și să extragă tokenuri de autentificare, credențiale stocate în cache-ul browserului și coduri de rezervă 2FA păstrate pentru recuperarea contului. În practică, un singur e-mail deschis se poate transforma într-o preluare completă a contului, fără ca victima să introducă o parolă sau să dea clic pe un link suspect.

Nu este prima dată când gestionarea conținutului încorporat de către Classic Web Client a cauzat probleme. Zimbra a trebuit să corecteze anterior probleme similare de igienizare a HTML-ului și a fișierelor ICS în aceeași interfață, un tipar care subliniază de ce organizațiile care încă folosesc clientul legacy se confruntă cu expuneri recurente până când fie aplică patch-uri riguros, fie migrează complet de la acesta.

Cine trebuie să acționeze

Vulnerabilitatea afectează Zimbra Collaboration (ZCS) 10 înainte de versiunea 10.0.18 și 10.1 înainte de versiunea 10.1.13. Zimbra a lansat versiuni reparate, iar avizul de securitate al companiei descrie patch-ul ca adresând o problemă critică de XSS stocat în Classic Web Client. Organizațiile care rulează versiunile afectate ar trebui să trateze această actualizare ca pe o prioritate, nu ca pe ceva de programat în următoarea fereastră de mentenanță de rutină, având în vedere că exploatarea nu necesită nicio interacțiune din partea utilizatorului în afara deschiderii unui e-mail.

Deoarece problema rezidă la nivelul accesului la sesiune, aplicarea patch-ului poate să nu fie suficientă dacă un cont a fost deja compromis înainte de aplicarea actualizării. Administratorii ar trebui să ia în considerare și auditarea activității recente de autentificare, revocarea tokenurilor de sesiune și reemiterea codurilor de rezervă 2FA pentru conturile care au avut acces la interfața clasică în perioada în care vulnerabilitatea nu era corectată.

Ce înseamnă asta pentru tine

Dacă folosești webmail Zimbra, fie ca individ, mică afacere sau ca parte a infrastructurii de e-mail a unei organizații mai mari, această vulnerabilitate este un memento că tokenurile de autentificare și codurile de backup sunt doar la fel de sigure ca software-ul care îți redă inbox-ul. Autentificarea cu doi factori este o apărare solidă împotriva atacurilor bazate pe parole, dar un bug XSS stocat care poate fura codurile de rezervă direct din sesiunea browserului arată că 2FA nu este un glonț de argint dacă însuși clientul web de bază este compromis.

Pentru utilizatorii obișnuiți, riscul practic depinde de faptul dacă furnizorul tău de e-mail sau departamentul IT rulează Zimbra și, în mod specific, dacă Classic Web Client este încă folosit. Majoritatea oamenilor nu vor avea nevoie să facă altceva decât să aștepte ca administratorul lor să aplice patch-ul. Pentru administratori și echipele IT, însă, aceasta este o acțiune imediată.

Recomandări practice

  • Confirmă că implementarea ta Zimbra rulează ZCS 10.0.18, 10.1.13 sau o versiune ulterioară; orice versiune anterioară este expusă la CVE-2025-66376.
  • Dacă organizația ta se bazează încă pe Classic Web Client, prioritizează aplicarea patch-ului înaintea planului de migrare la interfața modernă pe care l-ai fi putut stabili.
  • După aplicarea patch-ului, analizează jurnalele recente de autentificare pentru anomalii și ia în considerare revocarea tokenurilor de sesiune pentru conturile care au fost active în fereastra de expunere.
  • Reemite codurile de rezervă 2FA pentru orice cont cu semne de activitate suspectă, deoarece codurile de backup furate pot ocoli complet protecțiile cu doi factori.
  • Tratează de acum înainte avizele de XSS stocat de la furnizorul tău de e-mail ca pe priorități ridicate, având în vedere că nu este prima dată când clientul legacy Zimbra a avut nevoie de remedieri urgente de igienizare.

A rămâne în fața vulnerabilităților ca aceasta se reduce la disciplina de rutină a aplicării patch-urilor și la cunoașterea exactă a clientului web pe care organizația ta îl folosește zi de zi. Câteva minute petrecute acum pentru a confirma versiunea Zimbra sunt mult mai puțin costisitoare decât recuperarea ulterioară a unei căsuțe poștale compromise.