New exploitation technique uses improper protocol specifications

This technique requires a “complete change in the thought process” of security researchers while performing a vulnerability analysis, Abhishek Singh and Johnathan Norman wrote in a recent issue of Virus Bulletin.

Even though improper implementation of protocol specifications has lead to traditional exploitation vectors such as remote code execution, the authors argue that exploitations arising from this technique can be classified as a new trend for three reasons.

First, “rather than analyzing the vulnerable source code to derive the conditions that can be used to create a signature for NIS [network intrusion prevention/detection] devices, the proprietary protocol specification document must be consulted. This document states the values for the arguments of a command as well as when and how the values can be used. The NIS signature is created based on the information provided in the documentation.”

Second, “in the case of vulnerabilities that arise due to the improper implementation of proprietary protocol specifications, test cases must be constructed according to values set by the protocol specifications and not by the exploitation techniques.”

Third, “there have been repeated occurrences of exploitations taking advantage of the improper implementation of protocol specifications.”

In an interview with Infosecurity, Norman explained that the exploitation of protocols usually takes place through injecting malicious data. “What we have seen more recently is protocols that are vendor specific…are being exploited directly,” he said.

“Microsoft will make their own internal protocol specification, which often has very limited documentation. Some of the documentation is public because they have APIs and allow developers to access it….We find that there is a lot of functionality that is not public and is intended for internal use within the corporation. People are exploiting functionalities in that code. What is happening is the developers are not properly implementing their own internal protocols….That is becoming more prominent today than it was historically”, Norman commented.

“Without a lot of information about how these protocols work, without them being very well documented, people in the security community are sort of blind about how to protect against them and how to identify them, unless the vendor makes an effort to work with the community....So writing detection for them becomes much harder”, he said.

Norman encouraged vendors to open up these protocols so that the security community can develop solutions to protect companies from these attacks. “I think the lack of information is what perpetuates this problem.”

What’s hot on Infosecurity Magazine?