G-SEC - Blog

A few new Advisories (Post will be updated regularly)

noreply@blogger.com (Thierry Zoller) — Sun, 16 Feb 2020 11:20:00 +0000

Subscribe to the RSS feed in case you are interested in updates

This is a living post, that will be updated as I release Advisories.

Updates:

02.01.2020 - Added Initial List of Advisories
09.01.2020 - Added Bitdefender and Kaspersky Advisories
12.01.2020 - Added Bitdefender Advisories
13.02.2020 - Added TZO-011/012 ESET and AVIRA Advisories
14.02.2020 - Added TZO-15 F-Secure Advisory

List of advisories:

[TZO-13-2020] - AVIRA Generic AV Bypass (ZIP GPFLAG)

[TZO-15-2020] - F-SECURE Generic Malformed Container bypass (RAR)

Where can I find more information about this bug class ?

I wrote a post about this bug class in 2009 and in essence, it still holds true. The threat landscape has shifted and so have the technical capabilities : https://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html

Why now ?

10 years ago I took a look at ways to evade AV/DLP Engine detection by using various techniques and released a metric ton of Advisories. 10 years later after multiple CISO type roles, I wanted to deep dive again and see how far (or not) the AV industry has reacted to this class of vulnerabilities. [1,2]

These types of evasions are now actively being used in offensive operations [3]. To my surprise with a few exceptions most AV Vendors haven't appropriately reacted and in some cases I even found the very same vulnerabilities that were patched and disclosed years ago.

Worse than that is the fact that some vendors that were very collaborative in 2008/2009 have now started to ignore submissions (until I threaten disclosure) or are trying to argue that generically evading AV detection is not a vulnerability although they patched and released advisories before. Go figure.

I had a lot of back and forth on this matter, for instance, one vendor argued that this could not be called a vulnerability because it would not impact Integrity, Availability or Confidentiality. Another Vendor argued that this cannot pose a "risk" to their customers because of XYZ (assumptions).

Well, I am reporting vulnerabilities within products, not risks. Furthermore, the impact on the customer is highly dependant on how the customer contextually uses the product. Something the vendor has rarely any insight into. Trying to calculate the expected loss for a hundred thousand customers is something we shouldn't be doing when handling vulnerability notifications, however, a shocking amount of vendors are unable to understand the difference between a vulnerability and a risk.

Even more bothersome to me is how the bug bounty platforms have created a distorted Reporter/Vendor relationship and mostly are executed to the detriment of the customers. I am collecting my experiences and plan to write a blog post about this phenomenon in the future.

I am hoping that I can finally help to eradicate this bug class and I don't have to come back to this 10 years from now.

[1] Our presentation at Hack.lu and CansecWest entitled "The Death of AV Defence in Depth?"

[2] It didn't go unnoticed - Past Press Coverage: Washington Post, Infoworld, Heise, Security Focus ... etc.

[3] https://www.bleepingcomputer.com/news/security/specially-crafted-zip-files-used-to-bypass-secure-email-gateways/ | https://www.techradar.com/news/zip-files-are-being-used-to-bypass-security-gateways

An Overview of the BEAST - TLS, CBC, countermeasures (Update 3)

noreply@blogger.com (Thierry Zoller) — Mon, 26 Sep 2011 14:38:00 +0000

Lots of good information floating on the internet on the Proof of Concept (dubbed 'BEAST) against TLS 1.0 by Juliano Rizzo and Thai Duong at the Ekoparty. This Post summaries the credible information available.

This blog post will be continuously updated as new items and possible mitigation emerge. Subscribe to the RSS feed in case you are interested in updates.

Updates

27.09.2011 : Added Thai blog post and POC Video
27.09.2011: Added CVE-2011-3389 , Bugzilla entry , Microsoft Advisory 2588513
Added BID, Secunia and Opera Advisory
28.09.2011: Added Whitepaper and Proof of Concept Code

TOC

Introduction to BEAST, TLS and CBC
Relevant Papers
Proposed countermeasures

Introduction to BEAST, TLS and CBC

Juliano and Thai presented a Proof of Concept of an attack against TLS 1.0 is first documented in 2001 and discussed in papers in 2005 and 2006. It was thought to be an impractical attack back then and solved by adding empty fragments into the IV.

This issue was addressed in TLS 1.1 (2005-6) and OpenSSL by inserting Empty Fragments into the message.

So why is this still and issue today ?

First and foremost, TLS 1.1 is not supported by many SSL stacks, server or client side. Although the protocol exists there was no real incentives to move over to TLS 1.1 (or 1.2). Attacks were documented, some countermeasures implemented in some SSL stacks, but deemed impractical and forgotten.

Secondly the OpenSSL option "SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS" is activated by default as it caused incompatibilities with certain SSL stacks. Activating here means removing the mitigation against this attack. It is known that Tomcat, Apache mod_ssl, and Exim disable this feature in OpenSSL by default. Note : The proposed NSS patch (see countermeasures) adds empty application data records, which appears to be more compatible.

To quote Nelson Bolyard on why TLS 1.1 was not introduced sooner in the NSS stack (Currently used by Chrome, Firefox and various servers) :

"There is no significant market demand for TLS 1.1, so we've been working on improvements in 
other areas,such as sharable DBs and full RFC 3280 compliance.  Once TLS 1.2 finally becomes 
an RFC, we will work on that some time thereafter. We believe there will be a demand for 
TLS 1.2 and some of the new cipher suites that require TLS 1.2 as a prerequisite." Source

What is TLS ? What is CBC ?

Putting it in layman terms, TLS is the new name for SSL. SSL was developed by Netscape and was renamed and reworked into TLS when handed over to the IETF.

More details are available on Wikipedia - The post by the TOR team does an excellent job of explaining TLS, CBC and the attack itself, I highly recommend reading it especially if you are interested in the details.

How does the Attack work ?
The attack has the CVE number CVE-2011-3389 - Thai himself explains the attack and how it was discovered in his blog post "Beast"

Proposed Countermeasures

Generic Server Recommendations :

Short-Term : Prioritize the RC4 Algorithm over CBC based ciphers (AES, DES). See the recommendations by PhoneFactor .
Short to Mid-Term : Enable and Offer TLS1.1 or TLS1.2 (Note: Firefox and chrome do not support TLS 1.1 and will fallback). For a compatibility overview look here

In the works :

The publication by Juliano and Thai should create the necessary incentive for Vendors to implement and use TLS1.1 and/or TLS 1.2. I will keep an eye on the usual suspects and collect all relevant support in the "TLS/SSL compatibility Report"
The Phone Factor (the guys behind the TLS session renegotiation vulnerability) propose prioritizing RC4 over AES or DES as a short term mitigation.
The chrome team has created patches to NSS fixing the issue client-side. (Empty Application Data Records) - it is currently pushes to Chromium Beta channels for testing
Various vendor discuss countermeasures in this Bugzilla entry

Literature

The BEAST Paper by Julian and Thai
Thais' blog post with a full recap
Attacks first documented in 2001 and discussed in papers in 2005 and 2006
Recap by the TOR Team
Recommendations by the PhoneFactor
Chrome Team has an interesting write up

Advisories

SSL/TLS Hardening and compatibility report 2011 (updated)

noreply@blogger.com (Thierry Zoller) — Tue, 20 Sep 2011 15:05:00 +0000

Subscribe to the RSS feed in case you are interested in updates

My professional and private commitments made it difficult to maintain a healthly blogging style, I am trying to get back to some blogging on a more regular basis.

Quick Update:

G-SEC does no longer operate on a commercial basis, for those that want to join the G-SEC Team and blogging platform drop me (Thierry) a mail.
I updated the "TLS/SSL hardening and compatibility Report" to 2011

TLS/SSL hardening and compatibility Report 2011

Notable Changes:

Chrome moved from SCHANNEL to NSS, this move enhances the ciphersuites available to XP systems considerably (compared to IE)
Added OPERA ciphersuites
Updated: Restructured Tables to reflect usage of NSS by Firefox and Chrome
Updated: Fixed typos

Note: I have not re-tested all browsers completely, if you find errors please let me know. The report is can be downloaded here

Signed - Thierry Zoller

New Paper: SSL/TLS Hardening and Compatibility report 2010

noreply@blogger.com (Thierry Zoller) — Thu, 18 Feb 2010 14:20:00 +0000

Subscribe to the RSS feed in case you are interested in updates

At last. What started as an "I need an overview of best practise in SSL/TLS configuration" type of idea, ended in a 3 month code, reverse engineer and writing effort. I really hope this comes in handy for you and was worth the effort. This is the "Release candidate" version of the paper, should no errors be found it will be the final version.

This paper aims at answering the following questions :

What SSL/TLS configuration is state of the art and considered secure (enough) for the next years?
What SSL/TLS ciphers do modern browsers support ?
What SSL/TLS settings do server and common SSL providers support ?
What are the cipher suites offering most compatibility and security ?
Should we really disable SSLv2 ? What about legacy browsers ?
How long does RSA still stand a chance ?
What are the recommended hashes,ciphers for the next years to come

The paper includes two tools :

SSL Audit (alpha) : SSL scanner scanning remote hosts for SSL/TLS support (Video)
Harden SSL/TLS (beta) : Windows server and client SSL/TLS hardening tool (Video)

Without further ado here is the complete package

PS: In order to know whether this type of publication is useful to some and whether I should spend time on such publications in the future, I would appreciate a heads-up if you find this to be interesting. Thierry

Harden SSL/TLS - Tool release

noreply@blogger.com (Thierry Zoller) — Tue, 16 Feb 2010 17:43:00 +0000

Subscribe to the RSS feed in case you are interested in updates

“Harden SSL/TLS” allows hardening the SSL/TLS settings of Windows 2000,2003,2008,2008R2, XP,Vista,7. It allows locally and remotely set SSL policies allowing or denying certain ciphers/hashes or complete ciphersuites.

^This tool specifically allows setting policies with regards to what ciphers and protocols are available to applications that use SCHANNEL crypto interface. A lot of windows applications do use this interface, for instance Google Chrome as well as Apple Safari are a few of these. By changing the settings you can indirectly control what ciphers these applications are allowed to use.

Advanced mode

· re-enable ECC P521 mode on Windows7 and 2008R2

· Set TLS Cache size and timeout

Known issues:
· none

Author :
Thierry ZOLLER for G-SEC
Download: Harden TLS/SSL (beta)

Download: Documentation

Video Preview

SSL/TLS Audit (alpha) - Tool Release

noreply@blogger.com (Thierry Zoller) — Wed, 10 Feb 2010 15:33:00 +0000

Subscribe to the RSS feed in case you are interested in updates

Developed as part of G-SEC's investigation into the "Secure SSL/TLS configuration Report 2010" (to be published) we developed this little tool called SSL Audit. (More to follow in the next days - stay tuned).

SSL Audit scans web servers for SSL support, unlike other tools it is not limited to ciphers supported by SSL engines such as OpenSSL or NSS and can detect all known cipher suites over all SSL and TLS versions.

Apart from scanning available ciphersuites it has an interesting tidbit : The Fingerprint mode (Experimental). Included is an experimental fingerprint engine that tries to determine the SSL Engine used server side. It does so by sending normal and malformed SSL packets that can be interpreted in different ways.

SSL Audit is able to fingerprint :

· IIS7.5 (Schannel)

· IIS7.0 (Schannel)

· IIS 6.0 (Schannel)

· Apache (Openssl)

· Apache (NSS)

· Certicom

· RSA BSAFE

Download available on the product page

TLS / SSLv3 renegotiation vulnerability explained (Update #2)(

noreply@blogger.com (Thierry Zoller) — Fri, 13 Nov 2009 11:52:00 +0000

Subscribe to the RSS feed in case you are interested in updates

This paper explains the vulnerability for a broader audience and summarizes the information that is currently available. The document is prone to updates and is believed to be accurate by the time of writing.

Updated 18.11.2009 : Added SMTP over TLS attack scenario, added s_client testcase
Updated 30.11.2009 : Added FTPS analysis, new attacks against HTTPS (injecting responses and downgrading to HTTP)
Updated 09.12.2009 : Proof of concept files for TRACE and 302 redirect using TLS rengotiation flaw

Download "TLS / SSLv3 renegotiation vulnerability explained"

posted by Thierry Zoller

SSLv3 / TLS Man in the Middle vulnerability - update #9

noreply@blogger.com (Thierry Zoller) — Thu, 05 Nov 2009 12:00:00 +0000

Subscribe to the RSS feed in case you are interested in updates

Updated 17:50 GMT+1 / 05.2009 - added Mitigation / Impact
Updated 16:40 GMT+1 / 06.2009 - added IETF draft
Updated 14:35 GMT+1 / 07.2009 - added SSLTLS Test Tool
Updated 16:34 GMT+1 / 07.2009 - added OpenSSL patch
Updated 13:00 GMT+1 / 09.2009 - added GNUTLS patch
Updated 19:40 GMT+1 / 09.2009 - added Mikestoolbox.net testing TLS renegotiation support
Updated 21:29 GMT+1 / 09.2009 - added Apache patch, Mozilla Bug ID, Redhat Bug ID, Mozilla patch disabling tls renegotiation, Tomcat mitigation
Updated 21:00 GMT+1 / 12.2009 - added a whitepaper trying to explain the vulnerability and it's implications to a broader audience

After some in-house tests, we can confirm that the vulnerability presented at http://www.extendedsubset.com/ indeed real and should pose a significant threat to most. The vulnerability has been discovered by Marsh Ray, Steve Dispensa and Martin Rex.

We are currently looking into possible mitigations and will update this blog post regularly with more information regarding said vulnerability.

Details

TLS/SSL vulnerability explained : G-SEC Whitepaper (DRAFT)
Protocol and attack flow graph (Author: Marsh Ray)
Original paper about the vulnerability (Author: Marsh Ray)
Network data captures (Author: Marsh Ray)
Explanation by Ivan Ristic
IETF TLS renegotiation extension Draft
SSLTLS Test tool (Leviathan Security)
Mikestoolbox.net - Test client implementation for TLS renegotiation extension

Patches

OpenSSL 0.9.81 ( Attention: OpenSSL removed the TLS/SSL renegotiation feature from this package - you need to test application before/after updating to this version ) (via ISC)
GnuTLS patch (implements a new TLS extension proposed in the IETF Draft) (via SID)
Apache patch (patches renegogtiation prefix attacks at the application layer, still need openssl fixes for other attacks)
Mozilla bug id 526689 | Proposed Mozilla patch
Redhat bug tracking 533125
Tomcat

Advisories

Cisco - cisco-sa-20091109-tls

Impacts :

Currently known to exist

In general an attacker positioned in the middle of a connection may inject arbritary content into the beginning of an authenticated stream it will be interesting to see what potential impact this vulnerability has within each of the applications / protocols supporting it. IMAPS, FTPSSL, POP3 etc
For web servers - Attackers (if in the middle) can inject data into a segment that is authenticated to the web server, the web server will merge those requests and process them. (GET requests are trivially exploitable, POST are not known to be)

Posted by Thierry Zoller

Solving the HACK.LU 2009 reversing challenge like it's 1998

noreply@blogger.com (Thierry Zoller) — Mon, 02 Nov 2009 20:15:00 +0000

Subscribe to the RSS feed in case you are interested in updates

Here is quick overview of one possible way to solve the Hack.lu 2009 crackme (reversing challenge) with the classical JZ/JNZ method (hence the 1998 reference).

Disclaimer : If you are used to reversing software, you can skip this post, there is nothing new for you to glimpse here. This is one way to solve this crackme, of course you could try to reverse engineer the serial generation algorithm. In reality, if you'd use a serial system like this in a shareware type of application nobody would bother to do so.

Target : http://2009.hack.lu/archive/2009/ReverseChallenge/crackme.exe

Although there are no classical packer signatures to be detected (PEid, ExeInfoPE), looking at the results of entropy tests it is clear that the sample is compressed/crypted in some way or another. Entropy being the measure for randomness/chaos.

Examples :

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA has an entropy of 0
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx has an entropy of 96,04%

Entropy measurement of crackme.exe

There are several ways to measure whether a binary (or parts of it) are compressed/encrypted, I happen to use gynvaels' excellent tool ENT (not to be confused by a similar entropy measurement tool) as it offers several advantages such as mapping to .code and .data section of a PE file. As we can see above the entropy of the code section (Green) is that of normal code, the data section is high on entropy at the very end of it.

Luckily for us it doesn't use stolen bytes or more advanced methods to hinder dumping from memory while the sample decrypted/decompressed itself.

So we proceed with

Loading the sample in Ollydbg - Wait until it hits OEP
Dump the process using Ollydump
fix import table
Search for "serial"
Look for branching code
Patch branching code from JZ to JNZ

Patching the Jump Zero to a Jump Not Zero instruction

This is it

Posted by Thierry Zoller

Advisory : Computer Associates multiple products - arbritary remote code execution

noreply@blogger.com (Thierry Zoller) — Tue, 13 Oct 2009 14:46:00 +0000

Subscribe to the RSS feed in case you are interested in updates

G-SEC released an advisory today that affects various Computer Associates products. The most interesting part is the multitude of ways this vulnerability can be triggered, if you skim through the list of affected products you can draw your own picture. Network, USB, Email, CD, DVD, OLE2 (DOC, XLS) and more.

Picture courtesy of Norton AV Gaming edition

You can find the advisory in our advisory section

List of affected products :

CA Anti-Virus for the Enterprise (formerly eTrust Antivirus) 7.1
CA Anti-Virus for the Enterprise (formerly eTrust Antivirus) r8
CA Anti-Virus for the Enterprise (formerly eTrust Antivirus) r8.1
CA Anti-Virus 2007 (v8)
CA Anti-Virus 2008
CA Anti-Virus 2009
CA Anti-Virus Plus 2009
eTrust EZ Antivirus r7.1
CA Internet Security Suite 2007 (v3)
CA Internet Security Suite 2008
CA Internet Security Suite Plus 2008
CA Internet Security Suite Plus 2009
CA Threat Manager for the Enterprise (formerly eTrust Integrated Threat Management) r8
CA Threat Manager for the Enterprise (formerly eTrust Integrated Threat Management) 8.1
CA Threat Manager Total Defense
CA Gateway Security r8.1
CA Protection Suites r2
CA Protection Suites r3
CA Protection Suites r3.1
CA Secure Content Manager (formerly eTrust Secure Content Manager) 1.1
CA Secure Content Manager (formerly eTrust Secure Content Manager) 8.0
CA Network and Systems Management (NSM) (formerly Unicenter Network and Systems Management) r3.0
CA Network and Systems Management (NSM) (formerly Unicenter Network and Systems Management) r3.1
CA Network and Systems Management (NSM) (formerly Unicenter Network and Systems Management) r11
CA Network and Systems Management (NSM) (formerly Unicenter Network and Systems Management) r11.1
CA ARCserve Backup r11.5 on Windows
CA ARCserve Backup r12 on Windows
CA ARCserve Backup r12.0 SP1 on Windows
CA ARCserve Backup r12.0 SP 2 on Windows
CA ARCserve Backup r12.5 on Windows
CA ARCserve Backup r11.1 Linux
CA ARCserve Backup r11.5 Linux
CA ARCserve for Windows Client Agent
CA ARCserve for Windows Server component
CA eTrust Intrusion Detection 2.0 SP1
CA eTrust Intrusion Detection 3.0
CA eTrust Intrusion Detection 3.0 SP1
CA Common Services (CCS) r3.1
CA Common Services (CCS) r11CA Common Services (CCS) r11.1
CA Anti-Virus SDK (formerly eTrust Anti-Virus SDK)
CA Anti-Virus Gateway (formerly eTrust Antivirus Gateway) 7.1

posted by Thierry Zoller on the 13/10/2009

IIS 5 & IIS 6 & IIS7 FTP vulnerability - information and tools (updated)

noreply@blogger.com (Thierry Zoller) — Tue, 01 Sep 2009 12:06:00 +0000

Subscribe to our RSS feed for regular updates

Renowed security researcher "Kingcope" published a recent zero day vulnerability (i.e no patch and unkown at the time of publication) affecting Microsoft IIS 5 and IIS 6. Functional exploit code exists for IIS 5 / 5.1 no functional code execution exploit code is known to exist for IIS 6.

Update: Kingcope released another exploit against IIS5/IIS6/IIS7 that performs a Denial of Service attack against IIS5/IIS6/IIS7 using unsecure globbing mechanism. This attacks works with standard user accounts (doesn't required write access). The second exploit is tracked under CVE-2009-2521

Updates :

Kingcope publishes a new attack against IIS5/IIS6/IIS7 - Denial of service only - CVE-2009-2521
Microsoft published KB975191 with more information
VDB IDS are : CVE-2009-3023 , VU#276653
To perform a DoS attack write access is not required - this is also the case for IIS6
Summary: Code execution possible on IIS5/5.1 if write access granted, DoS is possible on both IIS5 and IIS6. Note - there is a improbable condition that may allow code execution on IIS5/5.1 even if write access is not granted, the condition is that a directory is present that has certain characters in it. It's improbable but possible. Thanks to Guido Landi for the insight.

Fast facts IIS5/6 Code execution (CVE-2009-3023) :

Affects IIS5 /5.1 and IIS6 - currently only a functional code execution exploit for IIS 5/Win2k exists, DoS attacks is possible against all versions.
The attacker must use an FTP account that is allowed to create directories (anon or known user) for the exploit to work
The FTP service is not enabled by default
Anonymous access is not enabled by default

Current vulnerability requirements (code execution):

IIS 5 (5.1) or IIS 6 installed and
FTP service enabled and
Code exec only requirement : NTFS write permissions given to anonymous or known users
(IIS5 and IIS6 run on Windows XP, Windows 2000, Windows 2003)

Current mitigations :

Disable FTP service on IIS5 and IIS6 if not required or

If FTP is required, disable create directory permissions (see KB975191) or disable write access all together (pic) Note: this will not protect against Denial of Service attacks

1.	Browse to the root directory of your FTP site. By default this is in %systemroot%\inetpub\ftproot.
2.	Right-click on the directory and select Properties.
3.	Click the Security tab and click Advanced.
4.	Click Change Permissions.
5.	Select the Users group and click Edit.
6.	Deselect Create Folders/Append Data.

Comments :

Successfull code execution might be possible without the need to be able to create directories (more research required). Note: For a successful Denial of Service attack the creation of a directory is not required.
The reason there is no functional exploit against IIS6 (Windows 2003) is that the exploit mitigations that ship with Windows2003 make it harder to reliably exploit (if at all)
It's possible that the vulnerable part of the IIS code can be reached by other means, if other methods are known we will update this blog.

Tools :

Nmap script to scan network for IIS FTP with write permissions (Credit: Xavier Mertens)
OpenVas is able to scan for this flaw

Links :

US-CERT - http://www.kb.cert.org/vuls/id/276653
Microsoft - http://www.microsoft.com/technet/security/advisory/975191.mspx
Exploit code - http://milw0rm.com/exploits/9541
SNORT signature update - http://www.snort.org/vrt/docs/ruleset_changelogs/changes-2009-09-01.html

Posted by Thierry Zoller, Luxembourg

New advances in Office/Excel/Powerpoint Malware detection and analysis

noreply@blogger.com (Thierry Zoller) — Thu, 30 Jul 2009 22:20:00 +0000

Subscribe to the RSS feed in case you are interested in updates

As you may or may not know there is massive client-side exploitation movement going on since last year (there has been before but on a less massive scale). There seems to be an ongoing competition between different nations (government orgs.) , revolving around who is able to order chinese servers, deploy client side exploits and run with the false flag the fastest.

Those that had to look into client-side attacks surely feel the pain of doing so, apart from run-time analysis, it takes some in-depth knowledge of the format and common exploitation techniques (recognise shellcode patterns ) to spot and dissect them.

The office file format is a file format on steroids, has it's on MFT and own structure - hell the file format can even fragment - that kind of steroid. One can only imaging how this format came to live, did Microsoft launch an internal competition of who comes up with the most complicated and most difficult file format ever ? Compatibility was surely not the goal [1]. Anyway enough ramblings...

Luckily there has been good progress on the Office fileformat analysis front, there was Officecat [2] and STG Docfileviewer [3] but honestly in terms of supporting analysts, these didn't cut it.

This week Microsoft released "Offvis", basically DOC/XLS/PPT/OLE parser with added bonus of detecting existing attacks. It's main goal is to help researchers and vendors to facilitate the parsing and dissection of the awfully complicated office file format.

On another front, Frank Boldewin releases an awesome automatic and generic doc/ppt/xls dissection tool. The tool extracts macros and information about the structure of the file, and searches for common shellcode patterns, has it's own small disassembly logic and, as an added bonus, brute forces possible XOR and ADD obfuscation loops.

Offvis

As input Offvis takes Office file format files, such as DOC,XLS and so forth. On the left hand it displays raw content of the file, on the upper right it displays the result of the parsing attempt. The display is interactive allowing you to select a field and see the raw content displayed.

If the file exploits includes a commonly and known vulnerability, it will display and warn you. It does not detect any other attempts, including the commonly used method of dropping malicious code using macros.

There seems to be no generic detection of shellcode or malware. In essence Offviss' goal appears to be to help developers and vendors at better understanding the format itself and test the implementations of their parsers. The added CVE recognition of known exploits is a bonus at best, although it has one nifty feature that comes in handy during analysis - defragementation.

» Download Offviz : http://go.microsoft.com/fwlink/?LinkId=158791
» Download Fact sheet

Office Malscanner
Office Malscanner is a new suite of tools from Frank Boldewin

OfficeMalscanner - Scans, parses the format, searches for shellcode patterns, extracts macros, bruteforces all possible XOR and ADD obfuscation keys and searches for executable magic bytes.

Disview - Takes an offset as an argument and tries to disassemble the input

MalHost-Setup - Patches the shellcode as to halt on execution to allow debugging of the shellcode

The results we had with the tool were great, it is the first (to our knowledge) generic utility to detect malicious code within office file formats, by that we mean that it doesn't look for specific patterns of known exploits, but uses generic means to detect possible malicious code with the possibility of false positives (as in all generic methods).

OfficeMalScanner in action analysing a malicious PPT file

It detects the api hashing method commonly used in shellcode at offsets that are located nearby, it then brute forces all possibly XOR keys and matches MZ,PE signatures indicating binary executables, and extracts them to disk. Additionally it rates the different findings in a metric called "Malicious Index", one might imagine this index to be used to filter out malicious documents at the border setting a minimum "malicious index" to reach.

Video of the extraction and analysis of a macro based Word dropper

Click here to see the video in full screen

The video shows the extraction of a malicious VBA macro included in a Word document and the modifications done to the vba file to drop the exe without executing it.

Malhost-Setup - disassembling shellcode (here exploit targeting office)

Malhost-setup can be used to analyse malicious code that directly exploits office - Malhost-setup takes the malicious file as input and the address of the start of the shell code as hexadecimal offset. It then extracts the shellcode and embeds it into an executable allowing to proceed with analysis in your debugger of choice.

» Download : OfficeMalScanner
» Paper and malicious samples : Analyzing MSOffice malware with OfficeMalScanner

Posted by Thierry

Links:
[1] http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
[2] http://www.snort.org/vrt/vrt-resources/officecat
[3] http://support.microsoft.com/kb/139545/de