lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Jul 2015 08:45:00 +0100
From: Kevin Beaumont <kevin.beaumont@...il.com>
To: 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

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 <kevin.beaumont@...il.com> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ