# 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.

1. Set GNS3 VM。

1. Create a New Template

1. Choose Switches -> Cisco NX-OSv 9000

Then Import the corresponding firmware into GNS3 VM。

After the import is completed, we can see the newly added device in the switches column.

1. 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.

1. 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.

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.

## 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.

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:

## 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:

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:

## How to exploit

First look at the protection of the binary program:

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:

1. After the stack overflow overwrites the return address, it will continue to overwrite the address of the function parameter.

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.

1. In the cdpd_poe_handle_pwr_tlvs function, many branches will go to the cdpd_send_pwr_req_to_poed function, and there is a __memcpy_to_buf function in this function. This function limits the length of the Power 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 call cdpd_send_pwr_req_to_poed function.

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.

1. 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:

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

CVE-2020-3119 Cisco CDP Stack Overflow Analysis

https://nobb.site/2020/03/19/0x59_EN/

Hcamael

2020-03-19

2021-06-04