Remote Exploit of Vulnerabilities

I was reading an article over on ThreatPost.com about this week’s ICS-CERT advisory for the Advantech WebAccess buffer overflow vulnerability and I was struck by the following statement that Dennis Fisher made:

“The vulnerability is mitigated by the fact that it cannot be triggered remotely.”

Now Dennis was clearly reading the ICS-CERT advisory that clearly said: “This vulnerability is not exploitable remotely”. Normally, I take the same approach when I write up my blog posts on ICS-CERT advisories, but this time I cheated and ignored the whole issue of remote exploitability. The reason was that Core Security labeled this vulnerability (at least in one place in their advisory) as remotely exploitable in their report on the vulnerability and I wanted to think about the whole issue of what is and isn’t remotely exploitable.

Remote: Yes and No

Let’s go back to that Core Security Advisory. In Section 2 they clearly state: “Remotely Exploitable: NO”. Down in Section 4, however, they clearly state:

“Advantech WebAccess is vulnerable to a Stack-based buffer overflow attack, which can be exploited by remote attackers to execute arbitrary code, by providing a malicious html file with specific parameters for an ActiveX component.”

Why the difference? Well the successful attack starts with an operator (or anyone with authorized access to the WebAccess application) opening a specifically designed html file. An attacker can only do this if they have system access. Thus: remotely exploitable; no.

It becomes remotely exploitable, however, when the attacker causes an authorized user to open that html. If that html code included providing remote access to the attacker, then it becomes remotely exploitable.

CAVEAT: Please remember, I have not coded in over a decade (fast approaching two) and I have never written code for anything as complicated as an HMI. So I cannot craft the exploit code described above and make no claim to be able to do so.

So what we have here is an attack that must be locally executed and may be remotely exploitable. Am I just playing with semantics or is this a real difference?

Remotely Executable

A remotely executable vulnerability would be one that an attacker could initiate and be in complete control of from a remote location. It requires some sort of remote access to the system; via a backdoor, stolen credentials or exploit of some other vulnerability. But once given that access the initiation of the actions necessary to exploit the vulnerability are completely under the control of the attacker.

In this case an authorized user has to be the one to initiate the sequence of events that starts the exploit of the vulnerability. Depending on the general level of vulnerability of a particular system this distinction may be a matter of terminology only. Some systems are so holely that anyone with a modicum of skill can become an authorized user, but that does not change the significance of this definition.

Systems that have reasonable degrees of access control would seem to have a reasonable level of protection against exploits of vulnerabilities that are not remotely executable. Having said that any number of studies on phishing or spear phishing attacks have shown that it is almost ridiculously easy to get someone to open a corrupted html file. And there are well known and well-practiced methods of convincing or coercing an insider to deliberately open such a file. These social engineering exploit tools make the ‘not remotely executable’ attack that much easier to remotely initiate.

I suppose that it is theoretically possible that a system could be constructed that a reasonable systems engineer would claim (while keeping a straight face) is immune to social engineering attacks. The people responsible for our nation’s various information systems protecting classified information would certainly like to be able to make that claim. Realistically though, I can’t think of anyone that would make such a claim for an industrial control system.

Make the Distinction

It would be nice if ICS-CERT and other vulnerability reporting agencies would make the distinction between remotely executable and remotely exploitable. Claiming that a vulnerability is not remotely exploitable when it clearly is misleads many people into thinking that their system is immune to a successful attack via that vulnerability.

For my blog, I will attempt to differentiate between the two levels of vulnerability whenever the data available to me allows me to make the differentiation.