Scanning & Monitoring For SCTP

When Denial of Service Become Remote Code Execution

When vulnerabilities are discovered, they are classified by various organizations using different methods. For example, CVSS scoring uses an algorithm to determine a severity rating from 1 to 10. This rating has been adopted by the NVD (National Vulnerabilities Database) and is used by Tenable to provide scores within the Nessus plugins. Sometimes a vulnerability is announced and its original rating is set as moderate or low. This is frequently the case with Denial Of Service (DoS) vulnerabilities as they allow an attacker to disrupt services but not gain remote access to the system. However, sometimes an advisory describes a vulnerability that seems to only cause DoS conditions, but is really an indicator of a condition that may permit remote code execution. This discrepancy typically occurs because the researcher does not fully understand or does not diagnose the underlying problem.

This is the case with CVE-2009-0065, a buffer overflow in the Linux kernel code that handles the Stream Control Transmission Protocol (SCTP). It was originally published and treated as a DoS condition but, after additional investigation, a researcher published details on leveraging it for remote code execution. Several Linux distributions published advisories and originally used the following terminology to describe the vulnerability:

"...allows remote attackers to have an unknown impact"

"A remote attacker could send specially crafted SCTP traffic causing a system crash, leading to a denial of service."

"This could, potentially, lead to a denial of service."

"...a memory overflow in the SCTP implementation that can be triggered by remote users.”

At first glance, this may not seem like a problem that requires immediate attention. However, it’s difficult to determine the level of response when vague terms such as "unknown impact" and "potentially" are used in the various descriptions. The true nature of this vulnerability is not revealed until an exploit is posted that gives attackers the ability to execute remote code. The severity is then updated by NVD, and the field in the CVSSv2 scoring system for "Access Vector" is changed to "Network Exploitable". Given that this scenario will continue to happen with new vulnerabilities, how do we monitor for this in our environments, detect when it happens and respond accordingly? We can use a Nessus credentialed scan to determine if our systems are missing patches and running SCTP.

A Little About SCTP

Before we dive into how Nessus can be used to detect this particular vulnerability and similar vulnerabilities in your environment, it is beneficial to understand a little about SCTP. SCTP is a layer 4 protocol, similar to TCP and UDP, that incorporates features such as multihoming support (See "Introduction to Stream Control Transmission Protocol" for more information). It is the only general purpose transport protocol other than TCP and UDP to gain the blessing of the IETF. It is supported by most major operating systems including Linux, Solaris and Windows (Vista).

Using Nessus

Nessus provides several ways to check for vulnerabilities associated with SCTP, and offers a strategy for handling changing severity levels if a vulnerability is changed from a DoS to a remote exploit. The best method to check for this particular SCTP vulnerability is to perform credentialed scanning and enable the local security checks for your platform(s). The following plugins contain checks for the vulnerabilities described above:

• Fedora 10 2009-0816: kernel Fedora Local Security Checks
• RHSA-2009-0264: kernel Red Hat Local Security Checks
• RHSA-2009-0331: kernel Red Hat Local Security Checks
• [DSA1749] DSA-1749-1 linux-2.6 Debian Local Security Checks
• USN752-1 : linux-source-2.6.15 vulnerabilities Ubuntu Local Security Checks
• USN751-1 : linux, linux-source-2.6.22 vulnerabilities Ubuntu Local Security Checks
• Fedora 10 2009-0923: kernel Fedora Local Security Checks

If you continually scan your network, you will see this vulnerability appears on systems that are missing the patches. In addition, you can track if the plugin has a low or moderate rating when it is first published and then is upgraded to critical. Using Tenable's Security Center, you can schedule Nessus scans and produce reports based on several criteria, including plugin severity. If scans are running regularly, you will notice a change for any system that does not have the patch as it will not be listed as having a critical vulnerability associated with it.

Nessus will also detect the presence of the SCTP protocol (Protocol number 132) on target systems over the network and produce the following alert:

You must enable the above plugin (plugin ID 14788, "IP Protocols Scan" in the "Misc" plugin family) and be certain to check "Thorough tests (slow)" in the Advanced tab of the scan policy under "Global variable settings".

Nessus also contains network-based checks that will test the system for several SCTP related vulnerabilities. The plugins listed below are in the "Denial of Service" family:

• Malformed ICMP Packets May Cause a Denial of Service (SCTP) Denial of Service
• Linux SCTP Functionality Multiple Remote DoS Denial of Service
• Linux SCTP ECNE Chunk Handling Remote DoS Denial of Service
• Linux Kernel Netfilter *_conntrack_proto_sctp.c sctp_new Function Unknown Chunk Type Remote DoS Denial of Service

Users often disable the “Denial of Service" plugins family for a number of reasons, mostly to avoid crashing remote systems during a Nessus scan. This is a good reminder to schedule a maintenance window and run a Nessus scan with these plugins enabled to observe the behavior of your systems.

Conclusion

The SCTP vulnerability described here is particularly dangerous because it has a high likelihood of "flying under the radar". It relies on a protocol that is not as popular as its counterparts TCP or UDP. When a vulnerability uses a relatively obscure protocol, there is a good chance that detection mechanisms may not pick up on it, or that an analyst will dismiss alerts stating, "Oh, we don't use SCTP in our environment, so this is not a concern.” The fact is, many systems include support for this protocol by default in the operating system (for example, my Ubuntu Linux system had support in the kernel for SCTP). One of the most alarming facts is that a non-privileged user can start a service, enable SCTP services and then exploit it remotely to gain root access to a system. Finally, a vulnerability that starts out as a DoS issue, and then gets changed to a remote exploit has an even better chance of being missed in many environments. Be diligent in checking your systems for vulnerabilities, using both network-based checks and local checking, to be certain your systems are up-to-date with the latest patches and only running the services that you expect them to run. Tenable's Nessus and Security Center products can help you achieve this goal by providing the facilities to schedule vulnerability scans, report on changes in the results and monitor your network for suspicious behavior.

Resources

• CVSS Version 2 Scoring with Nessus and the Passive Vulnerability Scanner
• CVSS Scores in Nessus Plugins
• When a "potential D.o.S." means a one-shot remote kernel exploit: the SCTP story