Entre les 20:57 UTC del 28 d'agost del 2026 i les 06:10 UTC del 30, el trànsit dirigit a 256 adreces IP d'un proveïdor de panells d'allotjament se'n va anar a una altra banda. El navegador no va avisar de res, perquè l'atacant va aconseguir un certificat TLS legítim per a aquells dominis. Uns quants servidors van demanar una actualització, van rebre un paquet maliciós i el van instal·lar. I després hi ha la part que ens va fer obrir la consola: mentre va durar, la ruta segrestada era vàlida per a RPKI. No invàlida ni dubtosa: vàlida.
Som operador amb xarxa pròpia: anunciem les nostres adreces per BGP i tenim trànsit i peering. Quan vam llegir l'informe de l'incident hi vam trobar a faltar una paraula, així que la vam anar a buscar nosaltres. El que segueix és la reconstrucció, la dada que no és a l'informe i les comprovacions que pot fer avui qualsevol, tingui o no un sistema autònom propi.
El que va passar, amb hores
A les 20:57 UTC del 28 d'agost, el sistema autònom AS62390 (NexonHost) va començar a anunciar el prefix 162.55.80.0/24 a través del trànsit AS6204 (Zet.net), declarant com a origen l'AS24940 —que és Hetzner, el titular legítim d'aquell espai—. El bloc real s'anuncia com un /16.
I aquí hi ha la regla de BGP que decideix la resta de la història: guanya el prefix més específic. Un /24 guanya un /16 a qualsevol xarxa que accepti l'anunci, sense que importin preferències locals, comunitats ni longitud del camí. No hi ha empat a desfer: són dos destins diferents i el router tria el més concret.
La finestra de l'incident va ser d'unes 33 hores, però el desviament no va estar actiu tota l'estona: van ser dues onades que sumen al voltant de 22 hores, separades per un interval d'onze. I aquell interval no va ser casualitat. La cronologia del proveïdor ho explica així: després de reportar el segrest a Hetzner i escalar-ho diverses vegades, «Hetzner comença a anunciar 162.55.80.0/24 directament» i «el desviament cau a zero en minuts». La mitigació que va funcionar va ser desagregar: disputar el prefix més específic amb la mateixa arma. Apunta't aquesta frase, que torna dos apartats més avall.
Mesurat sobre els 368 peers del sistema de recol·lecció de rutes de RIPE, al seu pic la ruta falsa la veia prop del 72 %; la mitjana ponderada en el temps va ser d'al voltant d'un 28 % del total, o d'un 65 % comptant només els que portaven ruta cap a aquell destí. Els 368 la van portar en algun moment, amb unes 10.600 retirades registrades. Un camí d'exemple que recull l'informe: 20912 6204 62390 24940. Aquell darrer salt —l'origen— és l'única cosa que mira la validació d'origen, i és un número que l'atacant va escriure a mà.
El cadenat no diu qui ets: diu qui va contestar
Una autoritat de certificació comprova que controles un domini connectant-s'hi per la xarxa. Si la xarxa menteix, la comprovació menteix. L'informe ho diu sense embuts: la validació automatitzada de propietat del domini de l'autoritat de certificació també anava encaminada a través del segrest. Resultat: un certificat de Let's Encrypt tècnicament vàlid per als webs del proveïdor —l'annex de l'informe llista tots els noms de host coberts—, emès a qui no era. Ni avís al navegador, ni error al client que descarregava les actualitzacions.
Algú preguntarà per la validació des de diversos punts de la xarxa. Existeix: Let's Encrypt la va desplegar a escala el febrer del 2020 i diu haver estat la primera autoritat a fer-ho. Apuja el llistó i evita segrests locals o de curt abast. Però una ruta que veu la major part d'internet la veuen també els punts des dels quals es valida, i allà la multiplicitat deixa d'aportar. L'informe no explica com es va superar aquella comprovació i nosaltres no ens ho inventarem; el que sí que està mesurat és fins on va arribar la ruta. És la mateixa lliçó que vam escriure sobre el segrest de DNS al wifi d'un hotel: el xifratge protegeix el contingut del camí, no et diu si el camí és el correcte.
La dada que no és a l'informe
La paraula que faltava és RPKI. L'informe de l'incident no la menciona ni una vegada. RPKI és el sistema amb què el titular d'unes adreces signa un objecte —una ROA— que diu «aquest prefix el pot originar aquest sistema autònom, fins a aquesta longitud». Els routers que fan validació d'origen descarten el que no quadra. Així que vam anar a mirar què deia la ROA d'aquell bloc.
Consultat el 5 de setembre del 2026, RIPEstat respon que avui aquell /24 és invàlid per longitud: la ROA de 162.55.0.0/16 autoritza l'AS24940 amb maxLength 16. Ho pots reproduir en una línia:
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS24940&prefix=162.55.80.0/24" | jq .data.status
# retorna: "invalid_length"
curl -s "https://stat.ripe.net/data/rpki-history/data.json?resource=162.55.0.0/16" | jq -r '.data.timeseries[] | [.time, .max_length] | @tsv'
# 2026-08-28 24 <- el dia del segrest# 2026-09-01 24# 2026-09-02 16 <- dos dies despresL'historial és la part interessant. Des de la primera dada que guarda RIPEstat, el 17 de març del 2021, i fins a l'1 de setembre del 2026, aquella ROA tenia maxLength 24. El 2 de setembre va passar a 16. És a dir: el valor va canviar dos dies després que acabés el segrest, i durant les 33 hores que va durar va estar en 24.
Traducció operativa: mentre va durar l'atac, un router amb validació d'origen activada rebia el 162.55.80.0/24 fals, comprovava la signatura i li sortia vàlid. La ROA autoritzava l'AS24940 a originar qualsevol cosa fins a /24 dins d'aquell bloc, i l'atacant deia ser l'AS24940. No hi havia res a descartar.
Siguem honestos amb el que no sabem: ningú ha declarat per què es va estrènyer la ROA el 2 de setembre. La coincidència temporal hi és i qualsevol la pot veure; la causa no l'ha publicada el titular i no la publicarem nosaltres per ell.
RPKI valida l'origen, no el camí
La validació d'origen contesta una sola pregunta: el sistema autònom que apareix al final del camí està autoritzat a originar aquest prefix? Això resol l'error humà —l'anunci equivocat clàssic a les tres de la matinada— i els segrests maldestres. No resol qui falsifica l'origen, perquè l'AS d'origen és un camp de l'anunci, no una signatura: s'hi escriu el que es vulgui.
I si a més deixes una maxLength més ampla que el que anuncies de debò, li estàs regalant al falsificador un subprefix autoritzat: exactament la peça que guanya l'elecció de ruta. Això no és una intuïció nostra. Està escrit a l'RFC 9319 (BCP 185, octubre del 2022), titulat The Use of maxLength in the Resource Public Key Infrastructure (RPKI): «In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal». El mateix document recull un mesurament de juny del 2017: el 12 % dels prefixos autoritzats en ROAs portaven una maxLength més gran que la seva pròpia longitud i, d'aquests, el 84 % quedaven exposats a un segrest de subprefix amb origen falsificat.
La part incòmoda: aquella maxLength també va ser la cura
Torna la frase que vam demanar apuntar. El que va aturar el desviament va ser que el titular legítim anunciés ell mateix el /24. I aquell anunci d'emergència només era RPKI vàlid perquè la maxLength era 24. Amb una ROA mínima —maxLength 16, la que hi ha avui i la que recomana l'RFC— la contramesura de Hetzner hauria sortit invàlida per longitud i l'haurien descartat precisament les xarxes que millor fan els deures.
Aquella tensió és real i el mateix RFC 9319 la reconeix: qui emet ROAs mínimes ha de canviar-les per canviar el que anuncia, i tot i així conclou que la ROA mínima ofereix la millor protecció possible davant l'impacte immediat de l'atac. Hi estem d'acord, amb una condició operativa que gairebé ningú escriu: si estrenys la maxLength, necessites poder reemetre la ROA en calent —a les tres de la matinada, sense buscar qui té la contrasenya del portal del RIR—. La ROA mínima és la postura correcta; l'agilitat per canviar-la és el que la fa segura. Sense això segon, has canviat un risc per un altre.
La peça que tancaria del tot el forat del camí —validar que qui propaga l'anunci té dret a fer-ho, i no només qui diu originar-lo— continua en estandardització i el seu desplegament encara és marginal. Mentrestant, la defensa realista s'aguanta en dues coses: no deixar subprefixos autoritzats solts i no confiar en la xarxa per a res que importi de debò.
Què se n'emporta d'això una empresa sense AS propi
Si la teva empresa no parla BGP, no pots impedir que algú segresti el prefix del teu proveïdor. El que sí que controles és què passa a casa teva quan això succeeix. I el que va passar aquí és que uns servidors van demanar una actualització per un canal xifrat impecable i es van instal·lar un paquet que ningú havia signat. El xifratge autenticava el nom del servidor; res autenticava el contingut.
El proveïdor ha anunciat que implementarà signatura de codi per a tots els seus paquets. És la conclusió correcta, i és la pregunta que hauries de fer a qualsevol que tingui permís per instal·lar programari a les teves màquines sense que hi intervinguis —començant per l'agent de gestió remota, del qual ja hem escrit que és una superfície d'atac amb nom propi—.
L'indicador de compromís que va publicar el proveïdor és una unitat de systemd: /etc/systemd/system/java-jre-update.service. Un nom plausible, en un lloc normal, amb tota la pinta d'haver sortit d'un procés d'actualització legítim. Cap capa de xarxa veu això; ho veu la telemetria del mateix equip. Aquesta és la diferència pràctica entre un antivirus que mira fitxers i un servei d'EDR/MDR que mira el que es crea, s'executa i persisteix.
Sis comprovacions que pots fer avui
- 1Mira la teva ROA (o la del teu proveïdor) amb la consulta de dalt. Si la
maxLengthés més ampla que el prefix que anuncies de debò, estreny-la fins a igualar-la. És un canvi d'un minut al portal del RIR i tanca la porta exacta que es va fer servir aquí. En el mateix minut, escriu qui la pot reemetre de matinada si algun dia cal desagregar. - 2Pregunta per escrit als teus trànsits si descarten les rutes invàlides per RPKI. Un «sí» de paraula en una trucada comercial no és una resposta; el nom del router i la política aplicada, sí.
- 3Vigila els teus prefixos. Una alerta quan aparegui un anunci més específic que tu no has fet val més que qualsevol informe trimestral. Les dades de RIPE són públiques i gratuïtes.
- 4Cap actualització automàtica sense signatura verificada contra una clau que no arribi pel mateix canal. Si l'instal·lador es fia del TLS i prou, el TLS és la teva única defensa —i acabes de llegir el que val quan la ruta menteix—.
- 5Telemetria d'amfitrió amb memòria. El proveïdor va demanar revisar quatre coses: claus SSH desconegudes, comptes d'usuari nous, tasques programades o cron inesperats i connexions sortints inesperades. L'indicador de systemd el va publicar a part. D'aquella llista, només les connexions sortints les veu un tallafoc; les altres tres viuen dins de la màquina i només les veu qui mira a dins.
- 6Quan un proveïdor publiqui un indicador, busca'l a tot el parc, no només a la màquina sospitosa. Aquí el mateix fabricant reconeix que no pot donar una llista definitiva d'instal·lacions afectades: si esperes que t'avisin pel teu nom, no t'avisaran.
Què fem nosaltres amb això
A everyWAN operem xarxa pròpia: anuncis BGP, trànsit i peering, i el costum de mirar com es veuen les nostres rutes des de fora abans que ens ho expliqui un altre. Quan muntem adreçament propi per a un client —ho expliquem en detall a multihoming amb IP pròpia i dos operadors— la ROA entra al lliurable amb la longitud exacta que s'anuncia, i amb el nom de qui la pot canviar a les tres de la matinada.
I a la consultoria prèvia, la meitat de la feina consisteix a escriure la llista de dalt abans que faci falta: qui signa les teves rutes, qui pot instal·lar programari a les teves màquines sense preguntar-te, i qui mira l'equip quan l'avís arriba en anglès i en un blog d'un proveïdor que ni sabies que tenies.
Durant les vint-i-dues hores en què aquell anunci va estar actiu, qualsevol que fes les comprovacions obtenia una resposta correcta: l'origen estava autoritzat, el certificat era vàlid i l'actualització arribava servida. Les tres deien que sí, i cap de les tres comprovava el que calia comprovar.
Fonts: cronologia del segrest (28 d'agost del 2026 a les 20:57 UTC fins al 30 a les 06:10 UTC: finestra d'unes 33 hores, dues onades que sumen unes 22 de desviament actiu i un interval d'onze hores que comença quan Hetzner, després de l'avís i diversos escalats, comença a anunciar el /24 directament i el desviament cau a zero en minuts), prefix 162.55.80.0/24, AS62390 (NexonHost) anunciant amb trànsit d'AS6204 (Zet.net) i origen declarat AS24940, propagació mesurada sobre 368 peers de RIPE RIS (pic ~72 %, mitjana ponderada ~28 % del total i ~65 % dels que portaven ruta, ~10.600 retirades), certificat de Let's Encrypt vàlid per als noms de host del proveïdor que llista l'annex de l'informe, lliurament d'un paquet d'actualització maliciós a un nombre reduït d'instal·lacions, indicador /etc/systemd/system/java-jre-update.service i mesures recomanades (rotar claus d'API, restringir accés per IP, revisar claus SSH, comptes i tasques programades, restablir contrasenyes de l'àrea de clients, signatura de codi futura): informe públic d'incident publicat per Virtualizor/Softaculous. Estat i historial de la ROA de 162.55.0.0/16 (origen AS24940; maxLength 24 des del 17 de març del 2021 fins a l'1 de setembre del 2026 i 16 des del 2 de setembre; estat invalid_length del /24 avui): consultes a l'API pública de RIPEstat fetes el 5 de setembre del 2026, reproduïbles amb les ordres de l'article. Cita sobre maxLength («In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal»), mesurament de juny del 2017 (12 % dels prefixos autoritzats en ROAs amb maxLength més gran que la seva longitud; d'aquests, 84 % exposats) i reconeixement que emetre ROAs mínimes obliga a modificar-les per canviar el que s'anuncia: RFC 9319 / BCP 185, «The Use of maxLength in the Resource Public Key Infrastructure (RPKI)», octubre del 2022. El mateix RFC preveu excepcions, entre elles que s'anunciïn de debò tots els més específics que la maxLength permet. Desplegament de validació des de diversos punts de la xarxa el febrer del 2020: blog de Let's Encrypt. El que no afirmem: no sabem per què es va estrènyer la ROA el 2 de setembre —el titular no ho ha declarat—, i l'informe no explica com es va superar la validació de l'autoritat de certificació; la relació que plantegem entre la propagació de la ruta i aquella validació és un raonament nostre, no un fet publicat.
Qui signa les teves rutes i qui instal·la el teu programari?
Revisem el teu adreçament i les teves ROAs, et diem què veu internet dels teus prefixos i quins proveïdors poden instal·lar programari a les teves màquines sense passar per tu. T'ho lliurem per escrit.
Microsoft 365
ES 
CAT 
EN