Malicious Application Hides Behind CLSID Extensions

Windows Class IDs Create Serious Vulnerability Remember the scene in "Mission Impossible 2" where the guy in the plane rips off the mask and exposes Ethan Hunt's nemesis? So too are Windows users also having problems distinguishing between good and bad applications. As security analyst Georgi Guninski has recently shown, malicious users can play a devastating trick on Windows systems using a CLSID extension, and thereby disguise a potentially dangerous COM object as a lowly .TXT file.? Microsoft's Component Object Model (COM) architecture has been built into all Windows systems since the debut of Window NT 3.5 and Windows 95. It ties disparate desktop tasks together by providing programmers with a library of standardized functions not dependent on any one programming language. Most Windows users experience

COM as OLE automation, as when you embed an Excel spreadsheet in a Word document, and as ActiveX controls that add interface enhancements (such as 3-D toolbars) to programs, and animate ActiveX-compliant Web pages. Like books in a library, COM objects require the equivalent of a Library of Congress or Dewey Decimal classification to refer to each object separately. This is the purpose of the CLSID, or CLasS ID, a 128-bit number that uniquely identifies a COM object and instructs the operating system how to execute it. What makes this especially dangerous is that a COM object can easily be crafted to rewrite the Windows Registry, delete files, wipe out the hard drive, and wreak all sorts of other havoc. Not What It Seems What Georgi Guninski discovered was that a CLSID appended to an otherwise innocuous .TXT extension doesn't show up in Windows Explorer, even with "Hide file extensions for known file types" turned off. Guninski provides a proof-of-concept file on his site called TESTHTA.TXT. The file is actually an HTML Application (HTA) file, with a full file name TESTHTA.TXT.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}. The number in brackets is the CLSID, but it is not displayed in Windows Explorer under normal circumstances. Double-click on it and it will execute, not as a text file, but in whatever way the CLSID tells it to. Windows still knows what it is though. List the file in Windows Explorer using the View > Details option, and Windows Explorer will report the file in the Type column as an "HTML Application." When set to Details mode, Windows Explorer knows that testhta.txt is not an ordinary .TXT file.] Right-clicking on the file and selecting Properties yields the same results. And when unzipping the test file we found that WinZip reported the entire file name, including the CLSID extension. BugNet has expanded on Guninski's demonstration exploit, and has created a myriad of similar exploits in an attempt to ascertain the seriousness of this vulnerability. With relative ease we were able to create an Excel spreadsheet with built-in startup macro that erases files off of the hard disk. We created a registry merge file that granted us Administrative rights on a Windows 2000 domain server. We even found a way to trash the entire registry, making it unusable. Despite the menacing nature of these files, they each hide innocently behind a harmless file name like README.TXT. Download a vulnerability .WAV demonstration file off our web site. The way someone might exploit this vulnerability is to create a gaffed file and place it in a shared network folder. People browsing to the folder would only see the innocuous filename. However, double-clicking on the file would unleash the ravages contained therein. The only protection is for the user to vigilantly look at the file icon to make sure that it matches the file type. For example, a README.TXT file should have the icon of the application that is associated with text files. On most systems, this would be Notepad. Any deviation from this should alert the user of a potential problem. Given the eagerness of e-mail users around the world to open a JPEG file of Anna Kournikova, even with the .VBS extension, doesn't inspire much hope that CLSID laden Trojan files will become a thing of the past. The only viable solution would be for Microsoft to create a patch. Given their response to our request, it appears they are looking into it. User Beware In response to our inquires, a Microsoft spokesperson stated that Microsoft was "thoroughly investigating this issue" just as they do with "every report [Microsoft] receives of security vulnerabilities affecting [its] products." However, the company believes at this point that any further speculation on the issue "would be irresponsible and counterproductive" to its goal of "protecting customers' information." The solution, of course, is not to let COM objects hide behind otherwise harmless-looking file extensions. But this is an old game really. E-mail worms have often spread by baldly disguising Visual Basic scripts as image files. The giveaway is the .VBS appended to the .JPG extension. The CLSID is a bit trickier because at first glance it doesn't show up as part of the filename. But look closer and it can't hide its true nature. E-mail attachments reveal the entire CLSID filename, so it is likely that future authors of viruses and worms will append files as .ZIP or self-extracting .EXE files. In any case, beware of any file with an extension followed by a long number in brackets. The shepherd knows his sheep, the old saying goes, and it is up to you to ferret out the fakes. Don't double-click it until you double-check it.