Case Study

This section looks at a basic session hijacking attack against a Telnet session using T-Sight. You can use the same scenario against any Cisco device systems that allow TCP session connections, such as Telnet.

This case study shows a poorly designed IDS network, where the command and control interface is accessible to hacker Evil Jimmy. To set the scene, the company named Little Company Network (also known as LCN) has had some recent security issues, and management has allowed the networking team to purchase and install an IDS. As expected, the team rushed right out and bought a new Cisco IDS and installed several inexpensive hubs to get the maximum viewing of their newfound toy. The team also purchased IEV to monitor and record alarms.

The team did not have enough computers or network equipment to place the command and control interface on a separate secure network, and time was of the essence to get it installed. It decided to connect the command and control interface to the standard LAN. It knew it should not do that, but it thought the risks were minimal and put forth efforts to make it more difficult to break into.

The team knew that the IEV and IDS communication was SSL, which is generally secure, so this was considered safe. Then the team gave the sensor a long 10-character password to help thwart password guessing to the command and control interface. Next, it enabled Telnet on the system for ease of access, just like it did on all other networking devices. LCN knows that Telnet is insecure somehow, so the team made sure that the IDS was configured to allow only the computer IP addresses of the networking teams to connect via Telnet to the command on control interface. Finally, the team could install the IEV collection software on an existing computer on the network and save hardware costs. With all this done, the team felt it was ready to launch into production and connect the command and control interface into the LAN. Figure 6-41 shows the LCN network and where Evil Jimmy will be hijacking the session.

Figure 6-41. LCN Network

It was here that things started to go wrong. The team never should have configured Telnet on the IDS. This weakness gave Evil Jimmy the patience to wait in the background for the LCN networking team to Telnet, at which point he could hijack the session and compromise the entire IDS. Evil Jimmy will probably not destroy the system, but just disable all the alarms he might trigger over the next few weeks. This allows Evil Jimmy free reign over the network because the LCN networking team will be blindly watching for alarms on a system that Evil Jimmy completely controls.

Note

This scenario of connecting the command and control interface to the standard LAN is not that far fetched. However, the configuration of Telnet on any Cisco system such as PIX Firewalls, routers, switches, and IDS should never be done at all costs.

Watch as Evil Jimmy goes to work:

Step 1.	Being cautious, Evil Jimmy packet sniffs the target network to discover continuous HTTPS (SSL) traffic between two computers. The traffic is moving all day long, and he suspects that IEV is pulling alarm data from a sensor. He dares not port scan, because it might lead to detection.
Step 2.	Evil Jimmy starts T-Sight and waits for a Telnet session to the IDS. (See Figure 6-42.) Figure 6-42. Starting T-Sight
Step 3.	Evil Jimmy calls the networking team and uses a little social engineering on the LCN team about some new Cisco IDS alarm graphing software that is a lot better than IEV. However, it works only with certain versions for IDS installation. Evil Jimmy convinces the networking guy to Telnet in and get the version information of the IDS and see if he can actually use this fictitious software. Note that this step is optional. Evil Jimmy could just sit back and wait for a normal ad-hoc Telnet connection to the IDS system.
Step 4.	Evil Jimmy picks up the Telnet connection to the IDS system after the LCN team member follows his instructions. (See Figure 6-43.) Figure 6-43. Picking Up a Telnet Session
Step 5.	Evil Jimmy double-clicks on the connection to bring up the dialog box shown in Figure 6-44. From here, Jimmy selects Realtime Playback. Figure 6-44. Viewing a Telnet Session in Real-Time Playback
Step 6.	Now Evil Jimmy can watch as the LCN administrator logs into the sensor and captures the password. At the bottom of Figure 6-45, you can see the username of cisco and the password of 13579"$^*)^M. (The ^M represents a carriage return.) This is all that Evil Jimmy needs usually; however, IP address restrictions have been put in place, so he will actually take over the session because it is so easy to do so. Figure 6-45. Watching the Session and Collecting Passwords
Step 7.	Evil Jimmy hijacks the session and starts to play with it, as Figures 6-46 and 6-47 show. As you can see, Evil Jimmy has complete control over the connection and can enter into any part of the system that the original LCN administrator could. Figure 6-46. Hijacking the Session Figure 6-47. System Compromised!
Step 8.	The system has been compromised. Now it is only a matter of time before all needed signatures are turned off, backdoor administrator accounts are created, and log files are compromised. Then Evil Jimmy can focus his efforts on the rest of the network, knowing he really is not being watched.

This type of attack demonstrates the dangers of session hijacking. To prevent against malicious hackers like Evil Jimmy, disable Telnet on all your devices and enable something better, such as SSH (which most Cisco devices support).

Tip

The authors of this book have seen and taken advantage of clients using this network design along with dozens of router and PIX installations where internal Telnet was enabled. This type of data makes great data for your Penetration Test Report! Even when you cannot successfully use session hijacking, there are other ways to hijack a session, which you will see in Chapter 9, "Cracking Passwords."