All - it is probably bad form to respond to my own post, but I've seen some folk dismiss this out of hand on social media so I wanted to provide two VERY QUICK proof of concept examples. These were just put together in 10 minutes.
http://owned.lab6.com/~gossi/research/public/packager/ There's an RTF and .docx version. You should be able to email these to colleagues. The "Sales Invoice" file is a .js file executed in Windows Scripting Host, which causes your PC to lock (as in, Ctrl+Alt+Delete lock - nothing malicious). It should work even if you have application whitelisting setup, by using Rundll32. Both examples have 0 out of 53 engine detection on Virustotal, and pass undetected through Cuckoo and Palo-Alto sandboxing, and endpoint security tools I've tried. The RTF should pass through most of the leading cloud mail gateways. On 2 July 2015 at 10:31, Kevin Beaumont <[email protected]> wrote: > All, > > OLE Packager is a feature introduced in Windows 3.1, which ran "up to" > Windows XP: https://en.wikipedia.org/wiki/Object_Linking_and_Embedding > > It is still present in every version of Microsoft Office, on every Windows > OS. > > It allows you to embed any file into Office documents. It is also very > dangerous and there is no way to disable it. > > To test, open Word 2010/2013 and select Insert -> Object -> Create from > File, and drop an executable into the document. Double clicking the > executable then spawns the executable. You can also right click the file > name, to change the name and use a custom icon. You can use the Draw > functions to draw a white box over the file extension. > > This isn't new (although I think most people aren't aware this function is > still active). > > There's all sorts of problems, though: > > - You can bypass many mail gateways and antivirus products by simply > saving the document as an .RTF file - these also support OLE Packager > objects. Most products I've tested fail to scan for Packager objects > inside RTF files, which are in turn then opened in Word by default. > > - A dll file called packager.dll is used to determine if the file > extension can execute code via a static list, and displays a warning for > the user to click through. There is no way to disable the Packager > functionality, so every Enterprise/Gov/Org/user has this functionality > enabled right now. > > - The DLL file hasn't been kept up to date. For example, you can use .PS1 > (PowerShell) embeds without any security warning. There's a lot of file > types now you can execute code with without warning, basically. > > - You can also embed executable code within ZIP files, to completely > bypass the warning. > > - The files are executed from your %appdata% folder, which is trusted for > things such as Windows Scripting Host. So for example, you can use > malicious .js files to execute full code, wrapped in a ZIP, with absolutely > no warning to the user nor ability to disable the functionality, even with > Group Policy/high security Office templates etc. > > I've tried this technique with most of the large cloud based email > filtering companies and it just sails past them. I've also tried two > anti-exploit products (Malwarebytes Anti-Exploit and a company I won't name > due to NDA) and it doesn't trigger their protection. No antivirus product > detected anything suspect during testing. > > I notified Microsoft of my research back in March, but from the dialogue > I've had it's a supported feature dating back to the early 90s. It also > appears to be supported going forward. I think it blows apart security > models and basically provides an easy way to detonate code on PCs far > behind firewalls - my belief is organisations should be able to disable > this feature, and it should probably be disabled by default in future > Office versions. > > As a mitigation, you can install Microsoft EMET and manually add > packager.dll to ASR. > > --Kevin > _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
