Geoff Chappell - Software Analyst
Just when I had resigned myself to the notion that the computer security industry doesn’t care to invest in reverse engineering, along comes the Stuxnet worm and numerous investigations in which investment by each of any number of security companies is apparently to be measured in man-months. Of course, reports that have taken man-months would want to be detailed, and though I’m not shaken in my belief that the greatest competition about reverse engineering in computer security is not for the quality of the work but for the unsupported use of terms such as “in-depth” and “comprehensive”, I must admit that a quick look at Stuxnet confirmed that most of it surely had been mined at least well enough that I would not find much to add except by committing to a full study. I’m biased, unsurprisingly, but I think a substantial opportunity was missed by not having me on hand to have got started on that in June or July.
I can’t now catch up on others’ man-months, but within the constraints of what I will do for free, I did find one perspective that seemed novel enough to justify spending a little time to write up most of what I know about one Stuxnet component. I think that although the kernel-mode driver MRXCLS.SYS seems only to have been seen in Stuxnet, it was developed independently. Its code knows nothing of the rest of Stuxnet. Indeed, MRXCLS is a kernel-mode loader of essentially arbitrary user-mode malware. We should expect to see it again. It might be prudent to look at whether early versions of it were used elsewhere, and to look at what Stuxnet shows of an increasing specialisation in malware development.
Before moving on, it occurred to me that although everyone surely has realised that to talk of Stuxnet exploiting a vulnerability in .LNK files is to shoot the messenger, someone ought to note it explicitly. The coding oversight that’s depended on is actually that the Control Panel may execute CPL modules that aren’t currently installed. Shortcut files just present the best vector for exploitation. You may think this is nit-picking, but if we make a habit of not differentiating defects and vectors, then defects may not be properly fixed and alternative vectors may go unexamined. The suggestion is bad enough from Stuxnet that lax handling of PIDLs by shell folders makes for a category of possible exploits that have mostly gone unnoticed or been neglected. To get deflected by an inaccurate description of the exploited defect is to invite a turn from bad to worse.
By the way, there is something that’s natural for me but which I ought perhaps make a point of telling you. Both the above articles about Stuxnet are derived entirely from what reverse engineers in the security industry apparently refer to as static analysis. I do not run malware any more than needed for getting it unpacked. Everything you read here about Stuxnet is a wholly intellectual exercise, with no experimental observation of Stuxnet executing, not even in any sort of controlled environment. Though I’m pretty confident that what I read in the code I read correctly, I’m not perfect and you should know that I have made no attempt at all to verify by experiment anything that I have deduced.