Overview
A path traveral on confd_cli_grp allows to leak confd_ipc_secret. This leak gives the ability to connect with any uid and gid leading to a local privilege escalation to root.
Impact
This vulnerability allows any local user to escalate to an unconstrained root shell.
Details
vEdge routers propose a restricted shell access through vshell command. From this shell it is possible to launch confd_cli_grp which connects to confd in order to deliver a confd CLI session.
When connecting, confd_cli_grp provides session configurations (such as uid and gid and groups) once authenticated. The session authentication and configurations signature are based on a secret key stored in file confd_ipc_secret.
In order to find out the groups the current user belongs to, confd_cli_grp read a file with its name resulting of the concatenation of the directory /etc/viptela/aaa_auth_grp,the username and the extension .external.
Pseudo code:
snprintf(fname_buffer, 0x200, "%s/%s.external", "/etc/viptela/aaa_auth_grp", username);
Once opened, it loaded the file content:
Pseudo code:
fscanf(fd, "%s", aaa_groups_buffer);
It then parse the groups list (exemple: log,admin) and send it in a signed configuration message.
The problem is that the username is an attacker controlled variable.
It can be set through USER environment variable. For instance an attacker can define USER=/../../../../../tmp/foo environment variable.
A getpwnam_r() call is done to check the user validity. But the library libnss_viptela.so (called via getpwnam_r()) will consider this user as valid as long as the directory /tmp/vipnss. and the file /tmp/foo exist.
This is because the library libnss_viptela.so has a similar path traversal bug.
Then the groups will be loaded from file /etc/viptela/aaa_auth_grp/../../../../../tmp/foo.external which will be solved as /tmp/foo.external.
The ability to arbitrary read a file when loading group poses several issues:
- It is possible to set any
gid group to the user session.
- As the file content is controlled by the attacker,
fscanf() results in a potential stack buffer overflow.
- We can leak sensitive informations (as
confd_cli_grp is a S-UID binary) by making /tmp/foo.external point to any other file with a symlink. This will be detailed in next chapter.
Proof of Concept
For the exploitation demonstration we decided to leak confd_ipc_secret in order to be able to forge and resign the session configuration sent by confd_cli_grp to confd and thus establish a session with root privileges.
To better understand, you can find here our observations concerning the sessions establishment between confd_cli_grp and confd:
secret:
┌───────> confd_ipc_secret <────────┐
│ │
│ │
│ │
│ │
confd_cli_grp confd
│ challenge │
│<─────────────────────────────────────┤
│ │
├─────────────────────────────────────>│
│ resp:md5(chall + secret) │
│ │
│ │
│ nonce │
│<─────────────────────────────────────┤
│ │
├─────────────────────────────────────>│
│ conf + md5(nonce + secret + conf) │
│ │
│ │
│ CLI session is starting... │
│<────────────────────────────────────>│
│ │
The conf is a sequence of clear text and integers parameters separated by ; characters. This configuration is trusted by confd as it is signed with the IPC secret key.
Note: It is possible to proxify (Man-in-the-Middle) the communication by setting CONFD_IPC_PORT environment variable to a different port.
Our exploit strategy is to use the username USER=/../../../../tmp/pwn and symlink /tmp/pwn.external to point to confd_ipc_secret.
When establishing the connection with this user, confd_cli_grp will send the content confd_ipc_secret as a conf parameter.
Our exploit, in a Man-in-the-Middle situation, intercepts this secret in order to rebuild and sign a valid conf with uid=0 and gid=0.
You can find the exploit code in appendix.
vedge# vshell
vedge:~$ id
uid=1000(admin) gid=1000(admin) groups=1000(admin),302(log)
vedge:~$ python3 /tmp/exploit.py 1234
[.] PROXY: Connecting local 4565
[.] PROXY: Listenning 0.0.0.0 1234
[.] Launching confd_cli_grp
[.] PROXY: Connection received
[.] PROXY: Poll
[+] Received challenge: b'\xac_\xf7jc\xc6\x1c\xaaN\t\xaa\x97\xccw\x93\xb5'
[+] Leak succeed. Key: b'1550807544-98829'
[.] Signature: 734800704d6ddba3352dac126c8c36bd
Welcome to Viptela CLI
root connected from 127.0.0.1 using console on vedge
vedge# vshell
bash-4.4# id
uid=0(root) gid=0(root) groups=0(root),302(log),1000(admin)
bash-4.4#
Affected versions
This exploitation has been successfully tested on SD-WAN vEdge (x86 and mips64) platforms with 20.6.2 and 20.6.1 versions.
Solution
Security patch
Upgrade to fixed SD-WAN vEdge firmware release 20.6.3 (for other initial releases, please refer to Cisco Security Advisory)
References
https://nvd.nist.gov/vuln/detail/CVE-2022-20775
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sd-wan-priv-E6e8tEdF
Credits
Orange CERT-CC
Cyrille CHATRAS at Orange group
Timeline
Date reported: December 16, 2021
Date fixed: September 28, 2022
Overview
A path traveral on
confd_cli_grpallows to leakconfd_ipc_secret. This leak gives the ability to connect with anyuidandgidleading to a local privilege escalation to root.Impact
This vulnerability allows any local user to escalate to an unconstrained root shell.
Details
vEdge routers propose a restricted shell access through
vshellcommand. From this shell it is possible to launchconfd_cli_grpwhich connects to confd in order to deliver a confd CLI session.When connecting,
confd_cli_grpprovides session configurations (such asuidandgidandgroups) once authenticated. The session authentication and configurations signature are based on a secret key stored in fileconfd_ipc_secret.In order to find out the groups the current user belongs to,
confd_cli_grpread a file with its name resulting of the concatenation of the directory/etc/viptela/aaa_auth_grp,the username and the extension.external.Pseudo code:
Once opened, it loaded the file content:
Pseudo code:
It then parse the groups list (exemple:
log,admin) and send it in a signed configuration message.The problem is that the username is an attacker controlled variable.
It can be set through
USERenvironment variable. For instance an attacker can defineUSER=/../../../../../tmp/fooenvironment variable.A
getpwnam_r()call is done to check the user validity. But the librarylibnss_viptela.so(called viagetpwnam_r()) will consider this user as valid as long as the directory/tmp/vipnss.and the file/tmp/fooexist.This is because the library
libnss_viptela.sohas a similar path traversal bug.Then the groups will be loaded from file
/etc/viptela/aaa_auth_grp/../../../../../tmp/foo.externalwhich will be solved as/tmp/foo.external.The ability to arbitrary read a file when loading group poses several issues:
gidgroup to the user session.fscanf()results in a potential stack buffer overflow.confd_cli_grpis a S-UID binary) by making/tmp/foo.externalpoint to any other file with a symlink. This will be detailed in next chapter.Proof of Concept
For the exploitation demonstration we decided to leak
confd_ipc_secretin order to be able to forge and resign the session configuration sent byconfd_cli_grptoconfdand thus establish a session withrootprivileges.To better understand, you can find here our observations concerning the sessions establishment between
confd_cli_grpandconfd:The
confis a sequence of clear text and integers parameters separated by;characters. This configuration is trusted byconfdas it is signed with the IPC secret key.Note: It is possible to proxify (Man-in-the-Middle) the communication by setting
CONFD_IPC_PORTenvironment variable to a different port.Our exploit strategy is to use the username
USER=/../../../../tmp/pwnand symlink/tmp/pwn.externalto point toconfd_ipc_secret.When establishing the connection with this user,
confd_cli_grpwill send the contentconfd_ipc_secretas aconfparameter.Our exploit, in a Man-in-the-Middle situation, intercepts this secret in order to rebuild and sign a valid
confwithuid=0andgid=0.You can find the exploit code in appendix.
Affected versions
This exploitation has been successfully tested on SD-WAN vEdge (x86 and mips64) platforms with 20.6.2 and 20.6.1 versions.
Solution
Security patch
Upgrade to fixed SD-WAN vEdge firmware release 20.6.3 (for other initial releases, please refer to Cisco Security Advisory)
References
https://nvd.nist.gov/vuln/detail/CVE-2022-20775
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sd-wan-priv-E6e8tEdF
Credits
Orange CERT-CC
Cyrille CHATRAS at Orange group
Timeline
Date reported: December 16, 2021
Date fixed: September 28, 2022