Unsurprisingly, worm authors find binary planting a great method for their digital monsters to propagate from infected systems to new ones. Symantec's analysis of Stuxnet provides a good insight into one of this worm's methods for propagating among users of a particular software product, in this case Siemens SIMATIC STEP 7. Like many other mission-critical and expensive software products, SIMATIC STEP 7 has a binary planting vulnerability that loads a DLL from a data folder; if the DLL is there, it gets executed. This is a typical binary planting attack vector, and in this case also reveals the user population the worm is targeting.
Using binary planting for malware propagation is not new: in 2001, the infamous Nimda worm was planting riched20.dll alongside various Microsoft Office documents in an attempt to get it executed by other users when they opened these documents.
At the time of this writing there are 102 published and unfixed binary planting issues available for all worm authors out there to use. Add to these the 500+ binary planting issues we've discovered during our research (only a handful are published) and extrapolate the ubiquity of these flaws to all Windows software, and you'll get a feeling of the threat we're facing today. Right now, a worm that simply sprays malicious dwmapi.dlls all over the place should be very successful in its propagation, let alone a slightly more intelligent one that can map DLLs to document extensions and update its knowledge as new binary planting holes are found.
So are we entering an era of binary planting worms? Who knows? There certainly is no shortage of binary planting bugs nor is there likely to be one soon, and it is unreasonable to expect most Windows computers to have any protection against binary planting in place. On the other hand, worms will probably prefer the "double-click-bang" binary planting bugs to maximize their success-to-detection ratio, and many of these happen to be the relatively easy to find (and therefore more likely to get fixed).
I say "many of these" because in contrast to the binary planting issues published these days where a vulnerable application always loads a malicious DLL upon startup, we found many cases where DLLs get loaded depending on various triggers, predominantly the content of data files. Worm authors may therefore decide to focus on such "triggered" binary planting issues which are more difficult to find but have a longer life expectancy. Undoubtedly, vulnerability black markets will be happy to accommodate such vulnerabilities for those who wish to focus on writing malware and leave vulnerability research to others.
Then again, worms don't particularly care about the types of vulnerabilities they use for propagation, as long as they get the job done quietly and efficiently. Perhaps, therefore, it is most likely that tomorrow's worms will simply add unpublished binary planting issues to their arsenal, along with buffer overflows and other types of remote execution methods.
As always, it is again up to software vendors to decide how much ammunition they want to make available to the malware authors. As it is again up to users to tolerate it or not.
Posts
