Monitoring Telnet Security

With the advent of the current Solaris Telnet Worm, Tenable has had many requests and comments about not only finding the specific associated vulnerability, but how to monitor Telnet in general. This blog entry discusses the worm, how to scan for the Solaris 10 in.telnetd vulnerability and how to monitor your network for Telnet activity.

Scanning for the Solaris in.telnetd Vulnerability

Tenable has released three checks to discover this vulnerability on Solaris systems:

• Plugin #24323 Solaris 10 Telnet Authentication Bypass
• Plugin #24343 Solaris 10 (sparc) : 120068-02
• Plugin #24342 Solaris 10 (i386) : 120069-02

Like most of Nessus's active scans, plugin #24323 confirms the presence of the vulnerability by actually attempting to interact with it. In this case, the NASL script tries to obtain the /etc/passwd file. Plugins #23434 and #24342 are both patch audits which require SSH credentials to audit the presence of the related missing patch to secure in.telnetd.

Looking for Telnet Worm Compromised Hosts

There are several techniques available to look for any evidence of Solaris systems on your network that have been compromised by this worm.

A simple way would be to use a Nessus scan and the "Trojan horses" plugin (Nessus ID #11157). This plugin was recently updated with a common back door port associated with the Telnet worm. To effectively use this, make sure you either perform a full port scan or at least target TCP port 32982.

Using the Security Center, a dynamic asset list can be created of all Solaris devices based on either a TCP/IP OS fingerprint with Nessus, passive TCP/IP fingerprint with the Passive Vulnerability Scanner (PVS) or even based on known SSH keys. Once the list of "all Solaris" servers is known, several things can be accomplished:

• If a PVS is configured to detect outbound port scans or a source of networks IDS events is available, any Solaris assets performing port scans could be infected with the worm.
• If any of the Log Correlation Engine's NBAD TASL scripts are enabled, such as the Shell Proxy or Suspicious Shell Proxy scripts, these will fire when there is an inbound connection quickly followed by an outbound connection. Considering these events for just your "Solaris" assets is also a useful filter. Like many worms, this Telnet worm makes many connections.
  
• The Security Center can correlate attacks from many different network IDS devices with the vulnerabilities scanned for by Nessus. This includes the Solaris 10 Telnet vulnerability. Security Center customers had automatic coverage for this correlation with Snort VRT, Bleeding Snort, Tipping Point and many other NIDS.
• If an attack has compromised a Solaris device they will undoubtedly create new logs. The LCE has a TASL script named "Never Before Seen" which highlights new log events that haven't occurred before. It is very likely that an attacker will generate firewall logs, host logs or event IDS logs that have not been seen yet. Filtering these alerts for just the Solaris assets also can give a sense of how much is really "new" in the system logs.
• CERT advisory TA07-059A mentions several files and directories that are commonly created by users and worms that compromise Solaris systems. Nessus scanners subscribed to the Direct Feed or managed by the Security Center can perform an audit of the Solaris hosts to see if these files exist with permissions indicative of a hacker or worm.

One last example is a combination of the PVS's ability to generate alerts when it sees new activity, specifically a system that begins to browse on a new port for the first time. These events can be sent to the LCE and trended. Here is an image of new port browsing events for port 23 at a small university:

Each of these events indicates a single host that has never been previously observed to send any network traffic on port 23. This activity started a few weeks ago and is indicative of a worm. The graph clearly shows that hosts that have never ever browsed on port 23 started to about a week ago. We've previously blogged about using this technique to find evidence of Symantec worms.

Auditing Telnet Use In General

There are many techniques an enterprise can use to audit protocol or application usage. For Telnet, Tenable offers many different ways to perform one time audits or continuous monitoring.

• Nessus Scanning Simply scanning a local network and finding all of the Telnet daemons that are open can highlight where these hosts are at.
• Distributed Scanning If multiple Nessus scanners are being managed by the Security Center, a scanner on the "outside" of a network can be tasked to scan for open Telnet servers. By scanning from the outside on a regular basis, the entire security posture of firewalls, screening routers and the systems potentially running Telnet can be routinely monitored.
• Passive Scanning If a PVS is in use, then it will automatically log not only which servers are running Telnet servers, but which ones use Telnet clients to reach other servers. If the PVS is deployed at a network boundary, then this can also indicate Telnet activity in and outside of your network.
• Host Configuration Assessment If the Security Center or a Nessus Direct Feed is in use, UNIX configuration files and running processes can be checked. This can ensure that TCP Wrappers is/isn't installed and that the Telnet service is/isn't running.

Conclusion

Telnet on Solaris 10 is the current worm of interest, but many of the concepts discussed here can be applied for day-to-day monitoring of your network. Tenable products are very useful for looking for the needle in the haystack when you know what to look for, but they also can shed a lot of light on network activity before they become public knowledge.