Només lectura a la consola de còpies no era només lectura

A l'avís que Veeam va publicar el 6 d'octubre, el permís que cal per executar codi al servidor de còpies és el de mirar. El rol es diu Backup Viewer, no toca res, no esborra res, no llança res, i és el que es concedeix sense convocar ningú perquè serveix per comprovar si les feines van sortir en verd.

L'avís és el KB4934, publicat el 6 d'octubre del 2026 juntament amb Veeam Backup & Replication 12.3.2 P4, build 12.3.2.4934. Porta tres vulnerabilitats. Afecten la build 12.3.2.4854 i totes les anteriors de la versió 12; la versió 13, diu el mateix avís, no està afectada. Sense mitigació provisional: no hi ha apartat de workaround.

Tres errors, i dos els dispara el mateix rol

Un apunt pràctic abans de continuar: dos dels tres identificadors pertanyen a la sèrie del 2025 i el tercer a la del 2026. Si els busques per any no et sortiran junts, i si el teu inventari de vulnerabilitats ordena per data de l'identificador, aquests tres no apareixeran a la mateixa pantalla encara que vinguin al mateix avís i es resolguin amb la mateixa build.

PR:L és la part que canvia la conversa

El vector del greu, tal com el publica Veeam:

CVE-2025-64393
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Llegeix-lo d'esquerra a dreta i és una llista d'obstacles que no existeixen. AV:N, per xarxa. AC:L, sense condicions de cursa ni configuracions rares. AT:N, sense requisits previs. UI:N, ningú no ha de clicar res. I PR:L: privilegis baixos, no pas cap. Aquest és l'únic peatge, i a les cases que veiem acostuma a estar pagat per avançat.

La cua del vector és la que normalment es passa per alt, i aquí diu alguna cosa. Els tres primers impactes, VC:H/VI:H/VA:H, són del sistema vulnerable: el servidor de còpies sencer. Els tres següents, SC:H/SI:H/SA:H, són la categoria que CVSS 4.0 reserva per als sistemes subsegüents, és a dir, per a l'impacte que cau fora del sistema vulnerable. Veeam marca aquestes tres en alt i s'hi atura: no diu quins són aquests sistemes. Qui són els hi posem nosaltres, perquè d'una consola de còpies pengen les credencials dels hipervisors, les dels repositoris i les de les cabines.

Qui té Backup Viewer a la teva consola?

Aquesta és la pregunta de l'avís, encara que l'avís no la faci. El rol de només lectura existeix per concedir-se sense reunió prèvia, i es dona a qui pregunta «puc veure jo si la còpia d'ahir a la nit va anar bé?». La resposta raonable a aquesta pregunta és que sí.

Els sospitosos habituals, per ordre de probabilitat que siguin a la teva llista i que ningú no se'n recordi: el compte amb què el sistema de monitoratge llegeix l'estat de les feines; el grup del service desk, perquè puguin contestar «sí, hi ha còpia» sense escalar; el consultor de l'última auditoria; el proveïdor a qui es va donar visibilitat durant una migració ja acabada; i el compte d'algú que ja no hi és, encara dins d'un grup del directori que té el rol assignat. Cap d'aquestes concessions no va ser un error quan es va fer. L'avís del 6 d'octubre és el que les reclassifica.

El 6,1 toca la clau de la caixa forta

El segon CVE està puntuat 6,1, mitjana, i és el que ens sembla pitjor explicat pel seu número. El que permet és modificar o esborrar la master key d'Enterprise Manager. La documentació de Veeam descriu aquest keyset com un parell de claus que encaixen: la pública xifra les storage keys als servidors de còpia connectats a Enterprise Manager, i la privada desxifra aquestes storage keys «in case a password for encrypted backup or tape is lost». És a dir, és el mecanisme documentat per quan algú perd la contrasenya d'una còpia xifrada.

No direm que esborrar aquesta clau et deixa sense còpies, perquè no ho sabem i depèn de quantes contrasenyes tinguis apuntades i on. El que sí que diem és més incòmode del que sembla: la via d'escapament documentada per al dia que falli la gestió de contrasenyes era a l'abast d'un compte de només lectura, i això es puntua 6,1 perquè l'impacte es mesura sobre el producte i no sobre la teva capacitat de recuperar-te. L'acció que en surt, a més de pedaçar, és exportar el keyset a fitxer i desar-lo fora del servidor de còpies. I això no és idea nostra: la mateixa documentació de Veeam ho demana amb totes les lletres, «It is important to regularly back up your Enterprise Manager keys or save their copies in a safe place».

No hi ha workaround. Hi ha una llista

El KB no ofereix mitigació temporal, i és honest: amb una deserialització en un servei intern no hi ha regla de tallafoc que et salvi a mitges. La build corregida és la 12.3.2.4934 i prou. Però entre que llegeixes això i aconsegueixes la finestra de canvi per tocar el servidor de còpies —que en moltes cases és el que menys es toca, perquè funciona i perquè ningú no vol ser qui trenqui les còpies— hi ha una feina que no necessita cap finestra: saber qui té el rol.

A la consola és a Users and Roles. Si prefereixes treure-ho a un fitxer i comparar la llista d'aquí a sis mesos, la referència de PowerShell de Veeam documenta Get-VBRUserRoleAssignment, que retorna RoleEntity, Role, Type, Name i Id. El resultat són unes quantes línies de text, i aquestes línies són l'inventari que no és al teu pla de recuperació.

Per què fa més mal aquí que en un altre servidor

Un RCE en un servidor d'aplicacions és un mal dia. Un RCE al servidor de còpies és un mal dia en què a més perds el pla B, perquè la màquina compromesa és la que desa les credencials amb què s'arriba a tota la resta i la que decideix què es reté i durant quant. Ho hem escrit aquí de diverses maneres: quan el servidor de còpies és al mateix domini que allò que protegeix, la dependència és circular i no es veu fins que cal; i la immutabilitat es queda curta si existeix un permís que esborra l'objecte abans que el cadenat compti. Aquest avís hi afegeix una tercera via al mateix lloc, i és la més barata de les tres: un compte de lectura.

Tampoc no és la primera vegada que la superfície de privilegi d'aquesta consola apareix en un avís: al setembre ja vam comentar un CVE on el que s'escapava era un tiquet d'administrador escrit en un log. Veeam té errors com tothom i els publica amb detall, amb vector i build corregida, que és com es fa. El que es repeteix és un pis més avall: el pla de recuperació acumula privilegi per capes i ningú no l'audita amb la freqüència amb què audita el directori.

L'ordre en què ho faríem

El que no afirmem

Amb una consola i quatre comptes, això és mig matí i no necessites ningú: mires la build, imprimeixes els rols i programes la pujada. Es complica quan el pla de recuperació fa anys que creix —un Enterprise Manager heretat, repositoris en tres llocs, un grup del directori que ningú no recorda haver creat— i la pregunta «qui pot entrar a la consola de còpies» no té resposta escrita enlloc. Aquest inventari, i el pla que es construeix a sobre, és exactament la feina d'un pla de recuperació davant de desastres, i és el que venem, així que agafa-ho amb el conflicte d'interès al davant. Si la teva gent ja ho té mapat, perfecte i no ens deus res. Si en llegir el punt 2 has pensat «uf», parlem-ne.

Fonts