CVE-2020-3119 Cisco CDP Stack Overflow Analysis
Cisco Discovery Protocol (CDP) is a proprietary Data Link Layer protocol developed by Cisco Systems.
Recently, the Cisco Discovery protocol disclosed several vulnerabilities by Armis Labs, and I choose the CVE-2020-3119 for analysis,Armis Labs has published their Paper[1]。
Build the Environment
The vuln affects Cisco NX-OS system devices, we can find the device version affected by the vulnerability in Cisco Security Center[2]. We can get NX-OS 9.2.3 firmware from Cisco Download Center[3].
First, I tried to use binwalk
to decompress the firmware, but I encountered some problems. Too much xz compressed data in NX-OS firmware, binwalk
consumes a lot of time when dealing with firmware in this case.
I spent two days without decompressing the firmware. But I can’t find a substitute for binwalk.
So I decided to find a way to get the firmware up, and I found a software that can perform firmware emulation of Cisco devices – GNS3.
How To Use GNS3
After we download GNS3, we also need to download GNS3 VM. GNS3 VM as GNS3 server, can run directly using virtual machine, and we use GNS3 control server for firmware simulation.
- Set GNS3 VM。
- Create a New Template
- Choose Switches -> Cisco NX-OSv 9000
We find that GNS3 uses qemu to simulate NX-OS, so the firmware we downloaded from the Cisco Download Center requires qcow2 format.
Then Import the corresponding firmware into GNS3 VM。
After the import is completed, we can see the newly added device in the switches column.
- Connect the NX-OS and Cloud
In the above image, Toolbox-1
is my newly added ubuntu docker template. In the beginning of the research, I connected the Toolbox-1
directly to the NX-OS switch.
But then I found out that GNS3 has a template called Cloud(For example Cloud1 in the picture above). The Cloud can represent any NIC on the local device or any NIC on the GNS3 VM.
I have a frequently used ubuntu VM in my Mac. I let the NIC of this ubuntu VM directly connect with the NX-OS switch, this is convenient for my subsequent research.
In the process of research, we can right click on this straight line, use wireshark
capture the network traffic.
- Start all nodes
The last step is to click the start button on the upper toolbar to start all your devices.
NX-OS Switch Binary Research
However, The network is not working yet, and you need to log in the switch through the serial port to configure the Switch. GNS3 will forward the serial port of the Switch through telnet by default. We can see the telnet IP/Port through the upper right corner of the GNS3.
The first time you log in to the switch requires initial setup. After setup, you can log in to the Cisco management shell with the administrator account password you set.
After research found that qemu started one bootloader, and bootloader start nxos.9.2.3.bin(NX-OS firmware), this is a Linux System. Then the Linux start a Linux VM called guestshell
. Under default circumstances, we can only log into this guestshell
.
The terminal we use to log in through telnet and configuring Cisco Switch is not bash, this program called vsh.
The vulnerability in this research occurred in a cdpd
program, but we can’t find the cdpd in guestshell
. So we need to find a way to get the terminal of the outer system.
After subsequent research, it was found that there is a python command in vsh, and this python is an nxpython program that exists in the Cisco outer system. So we can use python to get the Linux shell of the Cisco outer system.
Then use the mac address to find the NIC you set up in GNS3, and set the IP address. Then we can directly access the terminal of the Cisco outer system through ssh.
1 | Cisco# python |
Use Scapy send CDP packet
Next we will research how to send cdp packets. You can see the cdp packet format in the analysis released by Armis Labs. Similarly, we can also open the cdp of Cisco Switch and view the cdp packets sent by Cisco Switch.
1 | Cisco#conf ter |
Then we can directly capture the packet of the NIC through wireshark or GNS3. Now, We can research the format of the CDP.
Because I am used to writing PoC using python, I started to study how to use python to send CDP protocol packets, and then I found that scapy
has some built-in CDP packet related content[4].
Here is a simple example:
1 | from scapy.contrib import cdp |
Triggering Vuln
The next step is to research how to trigger the vulnerability. First, scp the cdpd
from the switch, and then throw the binary into IDA
to find the vulnerability. According to the vulnerability analysis released by Armis Labs, it was found that the vulnerability exists in the cdpd_poe_handle_pwr_tlvs
function. The related vulnerability code is as follows:
1 | if ( (signed int)v28 > 0 ) |
The follow-up is still based on the contents of the Armis Labs vulnerability analysis article. As long as the Power Request and Power Level are added to the cdp package, the cdpd program crash can be triggered:
1 | power_req = cdp.CDPMsgUnknown19(val="aaaa"+"bbbb"*21) |
How to exploit
First look at the protection of the binary program:
1 | $ checksec cdpd_9.2.3 |
This is a 32-bit program, and only enabled NX and PIE.
Because the cdpd
program cannot interact, it can only send all the payloads at one time, so there is no way to leak the address. But because it is a 32-bit program, and the cdpd
program will restart automatically after each crash, so we can blast the cdpd
program address.
There are a few things to note before writing a exploitation script:
- After the stack overflow overwrites the return address, it will continue to overwrite the address of the function parameter.
1 | *(_DWORD *)(a1 + 4 * v9 + 1240) = *(&v40 + v9); |
And because of the above code, a value needs to be written to the address near the a1
address. If we only cover the return address, you cannot achieve the purpose of command execution by only jumping to an address. So our payload needs to overwrite a1
with a writable address.
- In the
cdpd_poe_handle_pwr_tlvs
function, many branches will go to thecdpd_send_pwr_req_to_poed
function, and there is a__memcpy_to_buf
function in this function. This function limits the length of thePower Requested
to less than 40 bytes. Such a short length is not enough for stack overflow. So we cannot go to the branch that will callcdpd_send_pwr_req_to_poed
function.
1 | v10 = *(_WORD *)(a1 + 1208); |
We need to make this condition evaluate to False
and not enter this branch. Therefore, the value of the a1 address to be covered needs to be constructed.
- The purpose of our use is not to execute
execve("/bin/bash")
, because there is no interaction, so even if this command is executed, it is useless. So what can we do? First, we can execute the code of the reverse shell. Second, we can add an Administrator account, such as executing the following command:
1 | /isan/bin/vsh -c "configure terminal ; username test password qweASD123 role network-admin" |
We can achieve these purpose by executing system (cmd)
. But how to pass the parameters? After research, we found that the contents of the DeviceID
related fields in the CDP protocol are stored on the heap, and the heap address is stored on the stack. We can adjust the stack address by ret
ROP. This will successfully pass arbitrary parameters to the system
function.
Finally, put a demo video:
Reference
- https://go.armis.com/hubfs/White-papers/Armis-CDPwn-WP.pdf
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200205-nxos-cdp-rce
- https://software.cisco.com/download/home/286312239/type/282088129/release/9.2(3)?i=!pp
- https://scapy.readthedocs.io/en/latest/api/scapy.contrib.cdp.html
CVE-2020-3119 Cisco CDP Stack Overflow Analysis