Packets and Logs Found on the Shmoocon Network

Tenable staff had a great time at Schoocon this year and picked up some interesting data in the process. As we did in 2008 [http://blog.tenablesecurity.com/2008/02/shmoocon---dont.html] we ran our Security Center, Passive Vulnerability Scanner and Log Correlation Engine on the production Shmoocon 2009 network. This blog entry discusses the type of data that was obtained and also shows many different examples of log analysis and passive traffic analysis.

Initial Passive Vulnerability and Application Detection

Conference attendees stopped by the Tenable Shmoocon booth to play some poker and ask about our findings on the Shmoocon network. We found that there were not a lot of services being offered on the network. Most of the traffic we were profiling came from the attendees themselves. Having said that, the PVS was able to sniff the following vulnerabilities and services:

Since the PVS is usually deployed on the network perimeter, it flags any detected SQL databases as a potentially high severity level. Overall, nothing too startling was detected. 

The above screen shot was a sort based on severity level. Sometimes on a network like Shmoocon, the basic application data can be more interesting as shown below: 

Notice PVS vulnerability ID 3930 which identifies a Qualys vulnerability scanner appliance. The PVS includes rules to passively identify a variety of security tools such as Metasploit to see if they are installed on your network.

Another interesting set of data collected by the PVS was a profile all of the SSH daemons observed on the network. This table shows the type of SSH banners that PVS was able to observe on both the production network and the attendee traffic:

Obviously, Ubuntu seems to be the choice of OS for many of the attendees.

Profiling Interactive and Encrypted TCP Sessions

A neat feature of the PVS is to identify any server that hosts an interactive or encrypted TCP service. This automatically picks up on traffic such as Telnet sessions and SSL web services. Many backdoors and rootkit applications try to obscure network sessions by using non-standard ports and custom protocols. For example, consider the following “full detail” vulnerabilities detected by the PVS for hosts that had encrypted sessions:

172.16.10.18 -> 10.10.0.10:80|PVS detected a port used for one or more internal encrypted sessions. The data in this session had a high degree of randomness. Most likely, this is normal legitimate network traffic, but a variety of backdoors and compromised tools will also utilize encryption

172.16.10.20 -> 172.16.10.254:4343|PVS detected a port used for one or more internal encrypted sessions. The data in this session had a high degree of randomness. Most likely, this is normal legitimate network traffic, but a variety of backdoors and compromised tools will also utilize encryption

PVS detects encryption by testing for a sufficient amount of randomness in the data traffic. This technique also identifies compressed traffic on some protocols. For example, in the above screen shot, the host 172.16.10.18 has had at least one encrypted session with 10.10.0.10 on port 80. This is likely a web server offering content which has been compressed.

What is more interesting is port 4343 on 172.16.10.254. The PVS identified this traffic as some sort of TLSv1 traffic. This is likely a high-port SSL server of some sort as shown below:

Looking at each one of these ports one at a time can get tedious, so we used the Security Center to summarize all of the ports that were discovered which hosted some sort of encrypted session. This is shown below:

As the above screen shows,  there were hits on some interesting ports such as 9099 and 4343 and a few hits on some other ports.

If we wanted to, we could analyze this data further by considering each unique host, all of their sniffed application data and use the LCE to see how much traffic was passed over these ports.

As previously noted, the PVS can also sniff TCP sessions to look for interactive sessions. By “interactive” we mean that the latency between packets is likely to indicate that a human is typing away at the keyboard.

Below is an example PVS data record from the Shmoocon network:

172.16.10.226 -> 172.16.17.13:23|PVS has detected a port used for one or more internal interactive sessions: there were a large number of small packets relative to the number of packets in the session and the timing characteristics of the packets match user keystroke frequencies

172.16.12.123 -> 172.16.12.2:3050|PVS has detected a port used for one or more internal interactive sessions: there were a large number of small packets relative to the number of packets in the session and the timing characteristics of the packets match user keystroke frequencies

The first record is very straight forward. The PVS has detected an interactive shell on port 23. However, the second host has an interactive shell on port 3050.  If we wanted to investigate this further we could consider what other ports and applications were detected on host 172.16.12.123 or look at the realtime network and log activity collected by the LCE.

Realtime Log and Event Analysis

For the conference duration, the overall log profile can be summed up with this screen shot (click for a full screen):

Every system log, firewall record, network flow and other data gets normalized into a high-level type. These types are showed in the “Type” column above and have names such as “connection”, “firewall” and “router”.  

For example, one of the types is “errors”. Drilling into this type in the Security Center shows us this set of data:

In this screen shot, none of the errors seem too extreme. The FreeBSD syslog crash might be worth investigating, but the other logs seem fairly innocuous.

Let’s consider the firewall logs:

In this case, the firewall in use was a Cisco ASA firewall. It was configured to log “deny” events. Using the Security Center to summarize all of these logs by port displays the following data:

The main ports being denied were 80 and 443.

The LCE was also able to obtain Cisco logs for the routes and switches. Consider the following events from the “router” type:

There was an early spike of “Cisco-Configured_From_Console” events towards the beginning of the conference, but then only a few odd port up/down events that were balanced.

Any of the logs obtained by the LCE are fully searchable. For example, here is a list of “sudo” log events that are part of the “login” type:

Conclusion

Overall, these logs and traces were very typical of a security conference. A lot of the servers were not directly accessible to conference attendees, so there was not much suspicious activity to analyze.

We appreciate being able to gather logs and traffic on a live network. During the show, we were able to show various attendees about different aspects of log analysis and passive network monitoring.
If this sort of analysis was interesting, the following previous blog entries discuss similar types of data:

• Shmoocon 2008 Network Monitoring Notes
• There are many different posts in this blog's Event Analysis Training section