It is interesting watching the system work from the researcher perspective and see the responses and time line. This was one of the first vulnerabilities that we processed through our vulnerability disclosure policy. Matt identified this in late February and it went to US-CERT and CERT/CC in early March. While nine months may seem like a long time, it is not unusual. There is little interest in a responsible party (researcher, vendor, asset owner, coordination center) in disclosing vulnerabilities prior to solutions being available, although there are times when it is necessary.
Read US-CERT’s Vulnerability Note
Matt’s S4 presentation and paper will discuss this vulnerability and others so I won’t steal his thunder.
Matt did not develop any unique approach to assessing the implementation. Rather he took the same approach that researchers, and attackers, take to assess any protocol implementation. The vulnerability caused the server to crash when a set of specially crafted packets were sent. We did not attempt to write any code to further exploit this vulnerability because a DoS condition is a serious enough issue. If it makes you feel any better, an attacker would need access to an ICCP server, a fair amount of time to learn the complex protocol stack, and to be a skilled programmer to craft the attack. Still it is reasonable to expect that a motivated adversary has access to money and at least one skilled individual – – SO UPGRADE YOUR SERVER!
My only quibble with the Vulnerability Note is in the systems affected section. The Sisco stack is the most widely used stack in ICCP servers, and it is a good bet that your ICCP server has the Sisco stack. In fact we identified the vulnerability in two non-Sisco branded ICCP servers that used the Sisco protocol stack.
One way to determine if you are running a vulnerable version of the Sisco stack is to run the SCADA Nessus plugins and compare the results with the information on Sisco’s site.