Message-ID: <AEC742C5626B4858A80A2F716DFB7D0E@W340>
Date: Sat, 4 Jul 2015 08:11:59 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Kevin Beaumont" <kevin.beaumont@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Microsoft Office - OLE Packager allows code execution in
	all Office versions,
	with macros disabled and high security templates applied

Kevin Beaumont wrote:

> 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.

No, it fails when whitelisting is setup: the .JS payload is unpacked into
"%TEMP%" alias "%APPDATA%\Local\Temp" alias "%USERPROFILE%\AppData\Local\Temp"
where both SAFER alias Software Restriction Policies and AppLocker block its
execution.

JFTR: Windows Script Host is picky and runs scripts only if they have the
      extensions .JS, .JSE, .VBS, .VBE, .WSC, .WSF and .WSH.
      Windows Script Hosts also uses the SAFER API (which queries AppLocker
      resp. SRP rules, which declare the above extensions as executable),
      so ALL scripts the WSH may execute are blocked!
      The same holds for .PS1

But BEFORE SAFER blocks execution the user already has to

0. open the attachment,

1. double-click the embedded OLE object,

2. dismiss Windows standard dialog box
   "Opening content downloaded from the Internet may harm your computer"

3. double-click the *.JS

An exploit that requires FOUR user interactions is ... err ... ridiculous.

> 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.

But it does NOT execute if either SAFER or the "no execute" NTFS ACE is
used.

Conclusion: ALMOST HARMLESS!

Stefan Kanthak

> On 2 July 2015 at 10:31, Kevin Beaumont <kevin.beaumont-Re5JQEeQqe8AvxtiuMwx3w@...lic.gmane.org> 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/

Powered by blists - more mailing lists