Monitoraggio e aggiornamento di Catalyst SD-WAN Security Advisory - Febbraio 2026

Introduzione

Questo documento descrive i passaggi per identificare e correggere le vulnerabilità critiche della sicurezza in SD-WAN in base agli advisory PSIRT del 25 febbraio 2026.

---

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Componenti di controllo e architettura SD-WAN Cisco Catalyst (vManage, vSmart, vBond)
• Procedura di aggiornamento di Cisco Catalyst SD-WAN
• Procedure di gestione dei casi TAC e raccolta di dati admin-tech Cisco

Componenti usati

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

---

Premesse

Per informazioni dettagliate e gli ultimi aggiornamenti, consultare la pagina ufficiale di consulenza PSIRT.

Queste avvertenze sono disponibili ai seguenti link:

• Vulnerabilità di Cisco Catalyst SD-WAN
• Vulnerabilità del bypass dell'autenticazione del controller SD-WAN Cisco Catalyst
  
  

I seguenti problemi sono risolti dai consigli PSIRT:

• ID bug Cisco CSCws5272
• ID bug Cisco CSCws3583
• ID bug Cisco CSCws3584
• ID bug Cisco CSCws3585
• ID bug Cisco CSCws3586
• ID bug Cisco CSCws3587
• ID bug Cisco CSCws93470

---

Panoramica sul flusso di lavoro di risoluzione

Azione richiesta: Apri una richiesta Cisco TAC per risolvere questo avviso di sicurezza.

Il TAC è disponibile per:

• Valutare l'ambiente per individuare eventuali indicatori di compromissione
• Guida l'utente attraverso il percorso di correzione appropriato in base alla valutazione
• Collaborare con il team PSIRT se vengono individuati indicatori di compromissione
• Fornire assistenza e supporto per l'aggiornamento se non vengono rilevati indicatori di compromissione

1. Collect Admin-Techs - Eseguire admin-tech su tutti i componenti di controllo (vSmart, vManage, vBond). Gli admin-tech vSmart non devono essere eseguiti simultaneamente, ovvero eseguiti uno alla volta. Tutti gli altri possono essere raccolti in qualsiasi ordine. Selezionare le opzioni Log and Tech.  Core non è richiesto.
2. Apri una richiesta TAC - Contatta Cisco TAC e fornisci tutti i pacchetti di log Admin-tech per i componenti di controllo
3. Valutazione TAC - TAC valuta l'ambiente del cliente per rilevare eventuali indicatori di compromesso
4. Execute Remediation - Completa il processo specifico fornito da TAC

---

---

Passaggio 1: Raccolta dei file Admin-Tech da tutti i componenti di controllo

Obbligatorio: Raccogliere i file admin-tech da tutti i componenti di controllo prima di aprire la richiesta TAC. Questa operazione è essenziale per consentire a TAC di valutare l'ambiente.

Raccolta:

1. Esecuzione di admin-tech su TUTTI i controller (vSmarts) - non eseguirli simultaneamente; raccogli uno alla volta
2. Esegui admin-tech su TUTTI i manager (vManage)
3. Esegui admin-tech su TUTTE le convalide (vBonds)

Raccolta di informazioni su Admin-Tech in un ambiente SD-WAN e caricamento nella richiesta TAC

Alternativa: Verifica manuale (solo se non è possibile raccogliere dati relativi all'amministrazione tecnica)

Per coloro che non possono condividere i file admin-tech, sono disponibili procedure di verifica manuali. Queste fasi forniscono indicatori preliminari che devono essere documentati e condivisi con il TAC.

Per le procedure dettagliate, vedere la sezione "Fasi della verifica manuale" alla fine di questo documento. Documentare tutti i risultati e fornirli a TAC nella richiesta di assistenza.

---

Passaggio 2: Apri una richiesta TAC e carica i file Admin-Tech

Dopo aver raccolto tutti i file admin-tech dal passaggio 1, aprire una richiesta di assistenza in Cisco TAC.

Azioni richieste:

1. Apri una richiesta TAC con un livello di gravità appropriato all'impatto aziendale
2. Caricare TUTTI i bundle di log admin-tech raccolti nel Passo 1 (Controller, Manager e Convalide)
3. Fare riferimento agli avvisi PSIRT
4. Attendere la valutazione e le indicazioni relative al TAC

---

Passaggio 3: Valutazione TAC

TAC analizza i file admin-tech caricati e determina lo stato del sistema.

Durante questo periodo:

• Attendere una valutazione ufficiale del TAC prima di intraprendere qualsiasi azione
• TAC contatta l'utente con i risultati e le fasi successive

---

Passaggio 4: Esegui monitoraggio e aggiornamento (guidato da TAC)

TAC assiste l'utente nel processo di correzione appropriato in base alla valutazione effettuata. Completare tutte le istruzioni fornite da TAC.

Percorso A: Nessun indicatore di compromesso trovato - Aggiornamento

Se TAC conferma l'assenza di compromessi, eseguire l'aggiornamento alla versione software fissa. Selezionare la versione appropriata dalla tabella Versioni software fisso di questo documento e fare riferimento alla guida all'aggiornamento collegata in questa sezione.

Aggiornamento dei controller SD-WAN con l'utilizzo di vManage GUI o CLI

Percorso B: Indicatori di compromesso individuati - Guida PSIRT

Se il TAC conferma la presenza di indicatori di compromesso, completare tutte le linee guida fornite dal TAC.

---

Versioni software fisse

Queste versioni software contengono correzioni per le vulnerabilità identificate:

Si applica alle versioni correnti	Versione corretta	Software disponibile
20,3, 20,6, 20,9	20.9.8.2 *	20.9.8.2 aggiornamento delle immagini per vManage, vSmart e vBond
20.10, 20.11, 20.12.5 e precedenti nella 20.12	20.12.5.3	20.12.5.3 aggiornamento delle immagini per vManage, vSmart e vBond
20.12.6	20.12.6.1	20.12.6.1 aggiornamento delle immagini per vManage, vSmart e vBond
20.13, 20.14, 20.15.x	20.15.4.2	20.15.4.2 aggiornamento delle immagini per vManage, vSmart e vBond
20.16, 20.17, 20.18.x	20.18.2.1	20.18.2.1 aggiornamento delle immagini per vManage, vSmart e vBond

* Se si utilizza la release 20.9 o precedente: Il software fisso per la versione in uso (20.9.8.2) è disponibile a partire dal 2/27. Cisco consiglia di rimanere nella versione principale corrente e di attendere la versione 20.9.8.2 invece di effettuare l'aggiornamento a una versione principale più recente (20.12, 20.15, 20.18). Se la versione corrente è precedente alla 20.9, attendere la versione 20.9.8.2 per eseguire l'aggiornamento. Continuare a lavorare con TAC e verificare nuovamente il 27/20 per il collegamento software disponibile.

Riferimenti importanti:

• Matrice di aggiornamento
• Matrice di compatibilità dei controller

---

Appendice: Fasi di verifica manuale (solo se la raccolta di dati Admin-Tech non è possibile)

Requisiti: Queste operazioni devono essere eseguite su tutti i componenti di controllo.

Verifica 1: Verifica della presenza di account di accesso SSH non autorizzati nei log di autenticazione

Passaggio 1: Identificazione di IP di sistema vManage validi

Accedere a ciascun controller vSmart ed eseguire:

west-vsmart# show control connections | inc "vmanage|PEER|IP"

Output di esempio:

                                                    PEER                                                                                    PEER
      PEER  PEER  PEER            SITE       DOMAIN  PRIV    PEER                              PUB     PEER
INDEX TYPE  PROT  SYSTEM IP       ID         ID      PRIVATE IP                        PORT    PUBLIC IP                         PORT    ORGANIZATION        REMOTE COLOR  STATE  UPTIME
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0     vmanage dtls 10.1.0.18     101018     0       10.1.10.18                        12346   10.1.10.18                        12346   calo-auto-lab       default       up     5:17:27:22

Passaggio 2: Genera stringa espressione regolare (solo vBond e vSmart)

Combinare tutti gli IP di sistema della Fase 1 in un modello regex OR:

system-ip1|system-ip2|...|system-ipn

Fase 2b: Passaggio aggiuntivo per i sistemi vManage

Se si eseguono questi comandi su vManage stesso, aggiungere al regex l'indirizzo IP dell'host locale (127.0.0.1), l'indirizzo IP del sistema locale, tutti gli indirizzi IP del cluster e l'indirizzo IP dell'interfaccia di trasporto VPN 0:

system-ip1|system-ip2|...|system-ipn|127.0.0.1|

Per trovare l'indirizzo IP del sistema vManage locale, utilizzare:

show control local-properties

Per trovare l'IP dell'interfaccia di trasporto VPN 0 e l'IP del cluster, utilizzare:

show interface | tab

Passaggio 3: Esegui comando di verifica

Eseguire questo comando, sostituendo REGEX con la stringa regex del passaggio 2:

west-vsmart# vs
west-vsmart:~$ zgrep "Accepted publickey for vmanage-admin from " /var/log/auth.log* | grep -vE "\s(REGEX)\s"

Passaggio 4: Interpreta risultati e documento per TAC

Se non viene visualizzato alcun output:

• Nessun indicatore di compromissione rilevato nel dispositivo
• Documentare questo risultato per la richiesta TAC
• Continuare la valutazione dei controller rimanenti

Se vengono stampate le righe del log:

• Esaminare attentamente tutti gli indirizzi IP visualizzati
• Verificare che l'indirizzo IP non sia correlato all'infrastruttura vManage (IP cluster, IP sistema precedente o simile)
• Se non si riesce a identificare l'IP di origine come legittimo, ciò può indicare potenziali indicatori di compromissione
• La voce registrata nel log mostra un timestamp e un indirizzo IP di origine
• Documentazione di tutti i risultati e apertura immediata di una richiesta TAC
• Includere le voci di log, i timestamp e gli IP di origine nel caso
• Il TAC determina la valutazione ufficiale

Verifica 2: Verifica la presenza di connessioni peer non autorizzate nei syslog dei controller

Questo comando estrae tutte le coppie peer-type e peer-system-ip dai file syslog del controller e li invia come elenco da rivedere. Non contrassegna automaticamente le voci sospette: è necessario ispezionare l'output e determinare se ogni IP del sistema peer è una parte nota e legittima dell'infrastruttura SD-WAN. Eseguire questa operazione su tutti i componenti di controllo (Controller, Manager e Convalide).

Passaggio 1: Eseguire il comando su ciascun componente di controllo:

Accedere innanzitutto a vshell e quindi alla directory di log:

vs
cd /var/log

Eseguire quindi questo comando:

awk '{
  match($0, /peer-type:([a-zA-Z0-9]+)[^ ]* peer-system-ip:([0-9.:]+)/, arr);
  if(arr[1] && arr[2]) print "(" arr[1] ", " arr[2] ")";
}' vsyslog* | sort | uniq

Passaggio 2: Interpreta risultati e documento per TAC

Se l'output mostra solo gli IP di sistema vManage/vSmart/vBond noti:

• Nessun indicatore di compromissione rilevato da questo controllo
• Documentare questo risultato per la richiesta TAC
• Continuare la valutazione dei componenti di controllo rimanenti

Se l'output contiene indirizzi IP di sistemi peer non riconosciuti:

• Esaminare attentamente tutti gli indirizzi IP e i tipi di peer visualizzati
• Verificare che l'indirizzo IP non sia correlato all'infrastruttura del control plane SD-WAN
• Se non si riesce a identificare l'IP di origine come legittimo, ciò può indicare potenziali indicatori di compromissione
• Documentazione di tutti i risultati e apertura immediata di una richiesta TAC
• Includere l'output completo del comando con le coppie peer-type e peer-system-ip nel proprio caso
• Il TAC determina la valutazione ufficiale

Verifica 3: Lettura file DCA

Passaggio 1: Elementi da cercare

File di registro: /var/log/nms/containers/service-proxy/serviceproxy-access.log

Esempio di riga di registro:

[2026-03-04T01:45:06.239Z] "GET /reports/data/opt/data/containers/config/data-collection-agent/.dca HTTP/1.1" 200 - 0 32 1 - "" "python-requests/2.32.5" "ae076862-2244-45a6-844f-bc2af970e570" "192.168.2.3" "127.0.0.1:8080"

Passaggio 2: Comando di ricerca manuale

Dal terminale: ricerca all'interno del bundle admin-tech estratto:

zgrep -r "data-collection-agent/.dca" var/log/nms/containers/service-proxy/serviceproxy-access.log*

Verifica 4: Attraversamento percorso / Sovrascrittura file arbitrari

Passaggio 1: Elementi da cercare

File di registro: /var/log/nms/vmanage-server.log

Esempio di righe di registro:

06-Mar-2026 02:16:34,029 UTC INFO  [285fcdc0-30fa-4ca0-8e06-6953a095a59a] [LAB-TEST-1] [SmartLicensingManager] (default task-11229) |57501bad-32a7-4f52-8f54-8547dcd7403e| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/cmd.gz.war = 2 ms to directory /opt/data/app-server/software/package/license/ack
04-Mar-2026 15:40:02,683 IST INFO  [ca0e641b-acc7-42a6-b39b-bf3d28be0bcb] [LAB-TEST-1] [SmartLicensingManager] (default task-1235) |default| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/sysv.gz.war = 0 ms to directory /opt/data/app-server/software/package/license/ack
27-Feb-2026 08:49:27,169 IST INFO  [d9976a9d-071e-4e07-a3ef-4e90019cae12] [LAB-TEST-1] [SmartLicensingManager] (default task-809) |default| Time taken to write file ../../../../../../../../../../../var/lib/wildfly/standalone/deployments/authscp.gz.war = 0 ms to directory /opt/data/app-server/software/package/license/ack

Attenzione: Il nome del file mostrato negli esempi (ad esempio, cmd.gz.war) è solo a scopo illustrativo. I casi effettivi possono utilizzare nomi di file diversi. Registrare tutti i nomi univoci dei file di attraversamento identificati, in quanto ognuno di essi rappresenta un payload eliminato separato.

Passaggio 2: Comando di ricerca manuale

Dal terminale: ricerca all'interno del bundle admin-tech estratto:

grep -rE "SmartLicensingManager.*Time taken to write file \.\.\/" var/log/nms/vmanage-server.log*

Compresi i registri ruotati/compressi:

zgrep -E "SmartLicensingManager.*Time taken to write file \.\.\/" var/log/nms/vmanage-server.log*

Per acquisire le righe di contesto correlate (elaborazione API di caricamento ed eventi di scrittura):

grep -rE "SmartLicensingManager.*(write file|is processing|stringUrl|Failed to download).*/wildfly" var/log/nms/vmanage-server.log*

Verifica 5: Distribuzione file 

Passaggio 1: Elementi da cercare

File di registro: /var/log/nms/containers/service-proxy/serviceproxy-access.log

Qualsiasi richiesta POST a un pattern URI *.gz/*.jsp è contrassegnata. Lo stato HTTP determina la gravità:

Stato HTTP	Significato	Compromesso confermato?
200	Il server ha eseguito la shell Web. payload attivo	Sì - compromesso confermato

Esempio di righe di registro:

[2026-03-04T08:03:33.295Z] "POST /cmd.gz/cmd.jsp HTTP/1.1" 200 - 6 63 78 - "" "python-requests/2.32.5" "9d842c1a-b96f-4d04-ac3d-542ec3dd734b" "192.168.2.3" "127.0.0.1:8080"

Passaggio 2: Comando di ricerca manuale

Dal terminale: ricerca all'interno del bundle admin-tech estratto:

grep -rE '"POST /[^"]+\.gz/[^"]+\.jsp HTTP' var/log/nms/containers/service-proxy/serviceproxy-access.log*

Compresi i registri ruotati/compressi:

zgrep -E '"POST /[^"]+\.gz/[^"]+\.jsp HTTP' var/log/nms/containers/service-proxy/serviceproxy-access.log*

Per separare l'esecuzione confermata (HTTP 200) da altri tentativi:

# HTTP 200 only - confirmed webshell execution:
grep -rE '"POST /[^"]+\.gz/[^"]+\.jsp HTTP[^"]*" 200' var/log/nms/containers/service-proxy/serviceproxy-access.log*

---

Domande frequenti

Q: Qual è il primo passo per affrontare questo advisory della sicurezza?

A: Raccogliere i file admin-tech da tutti i componenti di controllo e aprire una richiesta TAC per caricare i file. TAC valuta l'ambiente e fornisce indicazioni sulle fasi successive.

D. A quale versione devo effettuare l'aggiornamento? 

R. Eseguire l'aggiornamento alla versione fissa più vicina al più presto.

Q: È necessario raccogliere gli admin-tech da tutti i componenti di controllo?

A: Sì, TAC richiede file admin-tech da tutti i controller (vSmart, raccolti uno alla volta), da tutti i manager (vManage) e da tutti i validatori (vBond) per valutare correttamente l'ambiente.

Q: In che modo TAC determina se il sistema è stato compromesso?

A: TAC analizza i file admin-tech utilizzando strumenti specializzati per valutare l'ambiente del cliente alla ricerca di indicatori di compromesso.

Q: Cosa succede se vengono individuati indicatori di compromesso?

A: TAC ti contatta per discutere le fasi successive e le linee guida specifiche per il tuo ambiente. Cisco non esegue il monitoraggio e l'aggiornamento per conto dell'utente. TAC offre le linee guida necessarie per procedere.

Q: Come è possibile sapere quale versione software fissa utilizzare?

A: Fare riferimento alla tabella Versioni software fisso in questo documento. TAC conferma la versione appropriata per l'ambiente specifico.

Q: È possibile avviare l'aggiornamento prima che TAC analizzi gli esperti tecnici?

A: No, attendere il completamento della valutazione di TAC e fornire indicazioni prima di intraprendere qualsiasi azione correttiva.

Q: Durante il monitoraggio e l'aggiornamento è previsto il downtime?

A: L'impatto dipende dall'architettura di distribuzione e dal percorso di correzione. TAC fornisce indicazioni per ridurre al minimo l'impatto dei servizi durante il processo.

Q: Le correzioni PSIRT sono incluse nella prossima release 20.15.5 e in altre release future? 

A: Sì, le correzioni sono incluse nella versione 20.15.5 e in altre versioni future. Tuttavia, è necessario assegnare IMMEDIATAMENTE una priorità all'aggiornamento per ridurre le vulnerabilità descritte in questo documento. (Non attendere!)

Q: È necessario aggiornare tutti i controller se non vengono rilevati indicatori di compromissione?

A: Sì, tutti i componenti di controllo SD-WAN (vManage, vSmart e vBond) devono essere aggiornati a una versione software fissa. Non è sufficiente aggiornare solo un sottoinsieme di controller.

Q: Ho un overlay SD-WAN ospitato dal cloud. Quali sono le opzioni per l'aggiornamento?

A: Per le sovrapposizioni ospitate nel cloud, i clienti hanno due opzioni:

1. Verificare se l'ambiente è pianificato per un aggiornamento automatico passando a SSP > Dettagli sovrapposizione > Finestre di modifica.
2. Se non si desidera attendere l'aggiornamento pianificato, sono disponibili due opzioni:
   • Eseguire l'aggiornamento autonomamente utilizzando le guide all'aggiornamento disponibili in questo documento.

   • Aprire una richiesta TAC di standby per la finestra di manutenzione preferita. TAC è disponibile per l'assistenza in caso di problemi con l'aggiornamento.

Q: È necessario aggiornare anche i router perimetrali?

A: I dispositivi Cisco IOS XE non sono interessati da questo avviso.

D: Siamo un Cisco hosted overlay. È necessario correggere gli ACL o eseguire azioni sul provider di servizi condivisi?

A: Tutti i clienti ospitati da Cisco sono invitati a rivedere le proprie regole consentite per il traffico in entrata visualizzate sul provider di servizi condivisi e ad accertarsi che siano consentiti solo i prefissi necessari dal lato dell'utente. Queste regole sono valide solo per l'accesso alla gestione e non si applicano ai router perimetrali. Esaminarli in SSP > Sovrapponi dettagli > Consenti regole in entrata. La porta 22 e 830 è sempre stata bloccata per impostazione predefinita nel giorno 0 del provisioning da Cisco dall'esterno ai controller ospitati nel cloud.

Q: Siamo su CDCS / tenant condiviso. A quale versione verrà eseguito l'aggiornamento? 

A: In base alla versione corrente, il tenant condiviso o i cluster CDCS sono attualmente pianificati per essere aggiornati O già aggiornati alle versioni fisse. Di seguito sono riportati il tenant condiviso e le versioni fisse di CDCS:

1. Cluster Early Adopter => 20.18.2.1 (in realtà è la stessa versione standard)

2. Cluster release consigliati => 20.15.405 (versione specifica CDCS con correzioni PSIRT)

I clienti CDCS non devono intraprendere alcuna azione efficace per risolvere questo problema.

Q: Quali sono le best practice generali o i modi per ridurre le vulnerabilità per la mia sovrapposizione SD-WAN?

A: Per le best practice e i consigli per ridurre le vulnerabilità nella sovrapposizione SD-WAN, consultare la Cisco Catalyst SD-WAN Hardening Guide.

Q: Nel sistema vengono visualizzati i log di un utente "root".  Questo è preoccupante? 

A: Controllare che cosa altro sta succedendo nel sistema in quel momento.   Questi registri sono assolutamente prevedibili.  Ad esempio, i log delle modifiche all'accesso di sistema di un utente "root" vengono visualizzati quando vengono generati gli admin-tech.  I registri possono anche essere visualizzati da un utente "root" durante un riavvio.  

Feb 28 23:03:44 Manager01 SYSMGR[863]: %Viptela-Manager01-sysmgrd-6-INFO-1400002: Notification: system-login-change severity-level:minor host-name:"Manager01" system-ip: user-name:"root" user-id:245  generated-at:2-28-2026T23:3:44
Feb 28 23:03:47 Manager01 SYSMGR[863]: %Viptela-Manager01-sysmgrd-6-INFO-1400002: Notification: system-login-change severity-level:minor host-name:"Manager01" system-ip: user-name:"root" user-id:248  generated-at:2-28-2026T23:3:47

Q: Abbiamo già fatto un passo avanti senza indicatori di compromesso. Dopo che i nuovi CIO sono stati rilasciati il 17 marzo, cosa devo fare?

A: Il software elencato come fisso contiene la protezione da ulteriori tentativi di sfruttamento dei CVE elencati nei due avvisi descritti in questo articolo. Anche se l'aggiornamento protegge dagli attacchi futuri, potrebbero esserci degli attacchi esistenti che si sono verificati prima dell'aggiornamento. Per ripetere l'analisi degli admin-tech dei componenti di controllo, si consiglia di usare il servizio "Check Bug Applicability" integrato nella pagina Bug Search Tool per l'ID bug Cisco CSCws52722. Se necessario, i clienti possono aprire una richiesta TAC e ripetere la procedura descritta in questo articolo per ripetere l'analisi degli admin-tech basati sui nuovi COI. b

---

---