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。
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.
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.
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
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.
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.
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.
Here is a simple example:
from scapy.contrib import cdp
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:
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:
power_req = cdp.CDPMsgUnknown19(val="aaaa"+"bbbb"*21)
First look at the protection of the binary program:
$ checksec cdpd_9.2.3
This is a 32-bit program, and only enabled NX and PIE.
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.
*(_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_tlvsfunction, many branches will go to the
cdpd_send_pwr_req_to_poedfunction, and there is a
__memcpy_to_buffunction in this function. This function limits the length of the
Power Requestedto less than 40 bytes. Such a short length is not enough for stack overflow. So we cannot go to the branch that will call
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:
/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
Finally, put a demo video:
CVE-2020-3119 Cisco CDP Stack Overflow Analysis