Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

July, 2008

  • How to parse the .doc file format

    This past February, Microsoft publicly released the Office binary file formats specification.  These describe how to parse Word, Excel, and PowerPoint files to review or extract the content.  Because they describe the structure of these file formats in detail, we think the file format specification will be particularly interesting to ISVs who write detection logic for malware scanners (such as Anti-Virus software).  Let us start delving into these documents by examining the basics of parsing a Word Document created with this legacy binary file format.  This discussion will not cover the new OOXML format introduced in Word 2007.
     
    Compound Binary Format
    First things first, in order to parse these older formats you will need to have knowledge of the Compound Binary File Format.  The specification for this format is available online.  Upon examination, you can see that the format is like a file system, similar to FAT.  There are directories called storages, which contain data files named streams.  All of this data is potentially fragmented across the file in various sectors described by the internal FAT.  There are libraries available to parse this format so you don’t have to re-invent the wheel if you don’t want to.  Use the Windows COM API, starting with the StgOpenStorageEx function, or one of the several freely available parsers and viewers to extract the individual data streams.  Compound binary files are actually quite common, and the COM API is a good way to access the data stored in these files.

    High Level Structure of Word Data
    In valid Word documents, there exists a stream named WordDocument.  Go ahead and view this stream’s contents.  It begins with a structure named the File Information Block, or FIB, which is described on page 141 of the Word Binary File Format specification.  This massive structure both contains data and acts like a guide map for the rest of the document.  At offset 0x9A in the FIB you will find a placeholder value named Rgfclcb.  This marks the beginning of the offset/length pairs which describe structure locations for the rest of the document.  These are offsets into another stream, named 0Table or 1Table.  To find out which of these two streams is being referenced, examine the 16 bit value at FIB offset 0xA and look at bit number 10 (AND it with 0x200).  If that bit is 0, then the offsets are referring to the 0Table stream.  If it’s 1, then the 1Table stream.

    This xTable stream contains much of the formatting data that Word uses to construct the document on your screen.  Each offset points at a different structure, so check the Word Binary File specification for additional details about the data stored at a particular Table stream location.

    A Real Example
    Now, let’s combine this information with some details about a patched vulnerability to see how we can detect a possible exploit attempt.  MS06-060 fixed a vulnerability in the Print Merge State (PMS) structure, which is stored in one of the xTable streams. 

    First, use the method described above to determine if this document is using the 0Table or 1Table stream.

    Next we have to find out if there is a PMS structure in the document, and if so, what its offset is in the xTable stream.  There are two possible places in the FIB that might store the location of this structure, fcPms and fcPmsNew.  First check fcPms.  The corresponding length value for that offset value is called lcbPms, and it’s a DWORD located at FIB offset 0x1FE.  If that value is non-zero, then the fcPms DWORD at FIB offset 0x1FA contains the xTable offset we need.  If the length value is 0, then we need to check the second possible location, fcPmsNew at FIB offset 0x48A.  The length value for this one is called lcbPmsNew, and is at FIB offset 0x48E.  If this DWORD is 0, then the document contains no PMS structures.  If it is non-zero, then the DWORD fcPmsNew contains the offset in the xTable stream of the PMS structure.

    Finally, if the document does contain a PMS structure, examine it in the table stream you identified earlier at the offset you just read from the FIB.  The structure looks like:

    struct PrintMergeState {
       WORD Reserved1;
       BYTE One;
       BYTE Two;
       DWORD Reserved2;
       BYTE Three;
       BYTE Reserved3[7];
       BYTE Four;
    };
    

    Within this structure there are four bytes of interest named One, Two, Three, and Four within the definition above.  Verify that the values of One and Two are set to either 0 or 1.  For Three and Four, verify that those values are within the range 0 to 5 inclusive.  Any other values for these fields are invalid and the document should be flagged as potentially abusing the MS06-060 vulnerability. 

    In the following example, the WordDocument stream started at file offset 0x1C00, and the 1Table stream started at file offset 0xC00.  After finding lcbPms (at 0x1C00 + 0x1FE) to be non-zero, we look at the PMS structure at 0xC00 + 0x1A6, and see that the value named “Three” is > 5, so this document might be trying to exploit MS06-060.

    We hope that you’ve found this a helpful example of how you can use the Word Binary File Format specification to accurately describe and detect attempts to exploit specific security vulnerabilities.
  • MS08-040: How to spot MTF files crossing network boundary

    Today we released MS08-040 to patch several vulnerabilities in the SQL Server Database Engine; one of them involves the SQL Server backup file format.  The format is also known as MTF (Microsoft Tape Format).  The vulnerability requires an attacker to be able to force the SQL Server to load a malicious MTF file from the local drive or from the network.

    Under normal circumstances (and by default), only authenticated SQL Server users can load an MTF file.  In order to remotely exploit this vulnerability, the attacker could leverage a separate SQL injection vulnerability and then trigger the SQL Server to load a malicious MTF file from the Internet; the SQL Server will then try to access the file using the Server Message Block (SMB) protocol or WebDAV. Web-based Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.)  Consequently, you will see SQL Server make an outbound connection to the Internet on ports 80, 443, 139, or 445.  In most cases, the Database Engine (sqlservr.exe) should not talk to the Internet on these ports so you should block them both inbound and outbound at the firewall  unless they are needed by other components.  Therefore, if you see SQL Server loading MTF files from the Internet, it is probably bad news.  You can fingerprint an MTF file on the network by looking at its header which is a 94-byte structure defined as follows:

    typedef struct {
    0x00:  UINT32 dblktype;
    ...
    0x56:  UINT16 svid; 
    ...
    0x5D:  UINT8 mver; 
    } MTFHDR;
    

    dblktype” should always be 0x45504154 (“TAPE”).  The “svid” field indicates the vendor and it should be 0x1200 (Microsoft).  An example header with the two fields highlighted is shown below.

    You should always set up your SQL server with best security practices as outlined in http://technet.microsoft.com/en-us/library/ms144228.aspx and http://www.microsoft.com/technet/prodtechnol/sql/2005/sql2005secbestpract.mspx

    - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • MS08-039: Which users are vulnerable to the OWA XSS vulnerability?

    Today we released MS08-039 which addressed several XSS vulnerabilities in Microsoft Exchange’s Outlook Web Access component.  While this is an update to be applied to the Exchange server, the clients who use OWA are the computers potentially at risk.  We’d like to explain a little more about the vulnerability so that you can determine whether you or your organization are at risk.

    OWA has two modes: OWA Light (or OWA Basic for Exchange 2003), and OWA Premium. In short, if OWA Light/Basic is used, you are vulnerable to the XSS vulnerability. You can tell whether OWA Light is used via the “Use Outlook Web Access Light” check box in OWA’s logon screen.

    So which mode is the default mode in OWA?

    To use OWA Premium, the browser must include support for ActiveX and the restricted IFRAME features.  Therefore, if you use a browser without these features, you will only be able to use OWA Light.  The OWA login screen displays the mode to be used.  In the screenshot below, a browser that does not support ActiveX and/or the restricted IFRAME features can only use OWA Light – you can see that there is no option to un-check the “Use Outlook Web Access Light” box.

    If you are using Internet Explorer and have enabled ActiveX, OWA will default to Premium mode.  In the default case, in fact, Internet Explorer users will be forced to use Premium mode.  However, an Exchange administrator could choose to configure their Exchange servers to enable OWA Light for all  users or could even force OWA Light for all users.  However, Exchange cannot be configured to force all clients to OWA Premium mode.  OWA Premium users are not vulnerable to the XSS vulnerabilities addressed with this security update. 

    Here’s the login screen when a browser supports the features required of Premium Mode and the Exchange administrator has been configured to enable OWA light:

    - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • MS08-037 : More entropy for the DNS resolver

    We released security bulletin MS08-020 two months ago to improve the DNS transaction ID entropy.  You can read more about the MS08-020 algorithm change in this blog entry.  Increasing the entropy makes it more difficult for attackers to spoof DNS replies.  Today, we released MS08-037 to further increase the difficulty of spoofing DNS transactions.  We modified the DNS client and server resolvers to send requests from a random source port.  Previously, an attacker would need to only guess the correct transaction ID.  After applying MS08-037, an attacker will need to guess both the transaction ID and source port in order to successfully spoof a DNS reply.  In short, randomized source ports for DNS transactions adds another unique piece of information to DNS transactions, which makes spoofing more difficult.

    The default size of the randomized socket pool on Win2k3 and down-level platforms is 2500 ports which is configurable by modifying the registry value:

    HKLM\System\CurrentControlSet\Services\DNS\Parameters\SocketPoolSize
    Another notable registry value is
    HKLM\CurrentControlset\services\tcpip\parameters\MaxUserPort

    Refer to http://technet2.microsoft.com/windowsserver/en/library/730fb465-d402-4853-bacc-16ba78e9fcc01033.mspx?mfr=true for more information on MaxUserPort.  On Win2k3, MaxUserPort is defined as the maximum port up to which ports may be allocated for wildcard binds.  Basically, MaxUserPort, if set, defines the dynamic port range.  It should also be noted that the MaxUserPort value has a different meaning in Vista and Win2k3.  In Win2k3, MaxUserPort, if set, defines the dynamic port range (it starts from 1024 to MaxUserPort).  In Vista, MaxUserPort, if set, signifies the number of dynamic ports, so the range is from StartRange (whatever has been configured, default is 49k) to StartRange+MaxUserPort.  Refer to: http://support.microsoft.com/kb/929851

    To summarize, the fixed behavior on Win2k3 and down-level platforms after installing the patch are:

    -          If MaxUserPort is set, then allocate ports randomly from 1024-MaxUserPort
    -          If MaxUserPort is not set, then the ports will be allocated randomly from the 49152-65535 range.

    The default port pool was chosen to pull random ports within a range consistent with BSD heritage where many systems have safely allocated ports dynamically from that range.  Doing so outside of that range has a small chance of introducing network failure, but in most cases won’t cause problems.  If you would like to add more entropy, you can grow the port limit by modifying the MaxUserPort and related registry keys.

    - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*

  • The IE8 XSS Filter

    Hello, our team and IE have recently collaborated on a new IE8 feature that was announced today – the XSS Filter.  Check it out here: http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx

    This effort demonstrates our commitment to helping our product teams benefit from the knowledge we have gained while defending our products from attack.  Stay tuned to our blog for more stories like this in weeks to come... 

     - Security Vulnerability Research & Defense Bloggers

    *Postings are provided "AS IS" with no warranties, and confers no rights.*