Most of the new IOS versions of Cisco routers and switches have implemented IOS scripting through TCL. TCL (Tool Command Language) is a scripting language commonly used for rapid prototyping and scripting applications. We can use TCL in various situations, from running a simple ping sweep, to creating complex network port scanning tools and even creating backdoors on devices. First, I will show you how to create and run a scripted Port/Network scanner that runs on a Cisco router called IOSmap. You can download the TCL script that will do this here. This tool can be used in a multi-layer attack; using a compromised router for pivoting. Pivoting is a method that uses a compromised system to attack other systems on the same network to avoid restrictions such as firewall configurations, which may prohibit direct access to all machines. In this scenario, we will pretend the attacker compromised an edge router and is using TCL to his advantage to pivot scans and attacks in the network. I am using using TFTP32 on a Windows machine on the same network to host the IOSmap script. You can download TFTP32 here.
Note: *Make sure you extract both files IOSmap.tcl and services.list in the same directory of TFTP32 or you will get a tclsh compilation error
First I will SSH to the router I compromised using PuTTY. After that, I will invoke my TCL script hosted on an external tftp-server with the help option to see what’s available.
For example: here I am checking for open tcp ports (135-139,443,445) on my tftp-server machine 192.168.0.198.
The script will also tell you if you run a command that requires resources that will exceed the available memory of the router.
We can see by running this script how powerful TCL scripting can be. In my next example, I will show you how TCL can be dangerous by creating a backdoor on a compromised router. In order to do that, we will run a TCL script on the router that acts as a backdoor. This backdoor script opens a persistent TCP socket connection listening to port 2455 and binds it to the Exec command at privilege level 15. Privilege level 15 is the equivalent to root access in cisco IOS permission levels. This script was developed by IRM Research and many other backdoor scripts are out there if you want to test them by yourself. This method has one obvious problem; the socket will only remain open as long as the router is online. So if the router restarts at any time, the connection will be lost. In order to fix that problem we will use an Embedded Event Manager command that will run the script each time the router turns on.
To download the backdoor.tcl script click here. Put it on your TFTP server and transfer it to the router.
Let’s try running the script and connecting to it.
Open a new terminal and make a connection to the backdoor:
Lets run a command to see if its working.
Very good, everything seems to work correctly. Now let’s reload the router and try to connect to it again.
Connection refused. Unfortunately, after the router restarted the socket connection was not re-initialized. That’s why we need to configure something like an EEM applet so the script runs on reload of the router. Lets log back in the router. Here’s an example EEM that runs disk0:/backdoor.tcl at start-up.
Lets reload the router and see if the Event Manager applet we configure works.
After the router started, the EM applet loaded backdoor.tcl. Everything is working as intended.
There is still one problem. Won’t the administrator notice the EEM or tcl script when going over the configuration file or the disk0:/ flash drive? Most probably, IF the administrator knows what he’s doing. In most cases, by using a very obscure name for the tcl script and the EEM applet, we can conceal the intrusion. For example, by using something like an Event Manager applet called Port_Auto_Failover in a big configuration file, we can confuse the network administrators in thinking this is something they shouldn’t touch. Most administrators adopt the mentality: “If it’s working then you shouldn’t touch it”. In this situation, we would be taking advantage of this type of thinking.
Hopefully, you now understand why you should constantly monitor your routers for any changes and hopefully implement a logging server or scripts that compare your configuration files. I will talk about this more in another blog.