FLAMING RETORT: Frankenstein Malware – the future of cyberwar, or just a catchy headline?

FLAMING RETORT: Frankenstein Malware - the future of cyberwar, or just a catchy headline?

A number of friends, acquaintances and readers have asked me recently about “the recent Frankenstein virus research paper thing.”

Bankrolled at least in part by the US Air Force, and openly touted by its authors as “a powerful tool for active defense (e.g., offensive cyber-operations),” this internet-era Modern Prometheus story has been widely covered in the technology media, often with a degree of admiration bordering on breathlessness.

When I first heard the full title of the paper, Frankenstein: Stitching Malware from Benign Binaries, and realised that its goal was to come up with a strategy for deliberately creating malware that is harder to detect, my gut reaction was, “We don’t need it, it won’t work anyway, but it’ll make catchy headlines.”

Just how reasonable were my visceral and unscientific conclusions?

Very briefly explained, the authors, Vishwath Mohan and Kevin W. Hamlen, describe a mechanism for constructing malicious programs entirely out of code sequences which already appear in legitimate software installed on the victim’s computer.

Of course, this raises the question, “Why bother?”

The authors offer an opinion on that matter, saying, “By creating new copies entirely from byte sequences obtained from benign files, we argue that it becomes significantly more difficult for defenders to infer adequate signatures that reliably distinguish malware from non-malware on victim systems.”

In less orotund words, “Because it makes the malware harder to detect.”

One problem I see with the Frankenstein approach – aside from my understandable objection to anything which makes harder malware easier – is that there is no reason to assume that this Frankenware will be harder to detect simply because it consists of byte sequences which already appear on the victim’s computer.

In fact, its inevitably synthetic construction – knitted together as it is from bits and pieces plundered from a completely different context – may paradoxically make it easier to spot.

The object code in Frankenware, you can reasonably assume, will inevitably be of an unnatural and unusual form. It may work, but it will be weird. On that basis alone, you can envisage a practical and effective way to detect it, even without knowing or caring what it does.

And this highlights the second problem I see with the the Frankenstein approach.

Frankenware presumes that anti-virus software relies almost entirely on the static recognition of known code sequences without regard for their order or the context in which they appear, and without considering the overall effects of that code. It assumes, simplistically, that some permutation of a known-good program will, ipso facto, itself look good.

That’s not correct, as far as I can see, any more than a statement which only uses words which from the Unanimous Declaration of the Thirteen United States of America will inescapably read like a unilateral assertion of political independence.

Mohan and Hamlen have based their work on the concept of gadgets, which form the basis of Return Oriented Programming (ROP).

In ROP, you rely on finding code sequences already in memory on your victim’s computer and knitting them into a meaningful whole. You don’t so much care what the gadgets are, but where they are – specifically, that they are already loaded into memory pages marked as executable.

You don’t use the gadgets as a means of looking normal, but as a way of behaving normally.

So, borrowing the overall concept of gadgets was an interesting idea for Frankenware, but in the end, a fruitless one, because gadgets are neither necessary nor sufficient for creating hard-to-find malware.

In summary:

  • Gadget-built code doesn’t look more natural just because it’s built from strings already on your hard disk.
  • Gadget-built code isn’t harder to detect simply because the strings it uses can be found in legitimate programs.
  • The world doesn’t need more malware, and it certainly doesn’t need more malware construction tools.

In short, is Frankenware which vaguely resembles existing legitimate software, in the same way that a patchwork quilt resembles a woven blanket, likely to be the basis of undetectable malware in a future cyberwar?

I doubt it.

Malware which, at first sight, is legitimate sofware (because it’s digitally signed by someone you trust, or delivered officially by your service provider, for example) is in my opinion a much more serious concern.

Then again, Mohan and Hamlen had a paper accepted at the USENIX 2012 Workshop on Offensive Technology, plus a trip to Washington to present it, and I did not.