Friday, August 19, 2005 6:47 AM bart

Demo of "Attachment Execution Service internals" in Windows XP SP2 and Windows Server 2003 SP1

The introduction

Oh my god, I couldn't stop to work the night before I leave for a short one-week holiday :o. But hey, there are holidays for, isn't it? :d Let's turn serious now. Last week I've been spending my free time on writing some security-related demo scripts, including the XP SP2 and W2K3 SP1 security boost features. One of these is the Attachment Execution Service (AES). The idea is to isolate potentially unsafe attachments in order to prevent these to harm your computer. Attachments stand for mail attachment but also for files that were sent using instant messaging.

 

The API

First, let's point to the API on MSDN: IAttachmentExecute. The sample which is included with the API documentation shows the basic workings of this interface. The idea is that a browser, mailclient or IM tool calls the various methods of this interface in order to execute operations such as saving the attachment (method Save) or executing the attachment (method Execute, pass in the "action" to be taken, e.g. open or print or edit or ..., depending on the file type registration parameters in the registry). I'm currently writing a piece of sample code on how to use this interface which I'll try to post later on.

How does this help to enhance security you might wonder? The answer can actually be found in the API. For instance, take a look at the method Execute. You should find the following remark:

IAttachmentExecute::Execute may run virus scanners or other trust services to validate the file before executing it. Note that these services can delete or alter the file.

IAttachmentExecute::Execute may attach evidence to the local path in its NTFS alternate data stream (ADS).

Look for similar remarks on the method Save:

IAttachmentExecute::Save may run virus scanners or other trust services to validate the file before saving it. Note that these services can delete or alter the file.

IAttachmentExecute::Save may attach evidence to the local path in its NTFS alternate data stream (ADS).

 

The demo

What's interesting is the NTFS alternate data streams (ADS; KB article 105763) part. Here's a demo walkthrough scenario:

  1. Download the LADS tool from Frank Heyne to display NTFS alternate data streams. You might find the following resource interesting if you're not familiar with the alternate data streams feature of NTFS (which was originally added to NTFS because of Macintosh compatibility reasons): http://lists.gpick.com/pages/NTFS_Alternate_Data_Streams.htm. Extract the lads.exe executable in some folder, say c:\temp

  2. Start, Run, cmd, OK

    >cd %userprofile%\My Documents\My Received Files
    >c:\temp\lads.exe

    Note: This assumes you're using MSN Messenger and you've already received a file from one of your contacts. Alternatively, you can download a file using Internet Explorer 6 (XP SP2, W2K3 SP1) and perform the operations above on the directory where the file was saved.

  3. In the output of the lads.exe run you should find stuff like this:

    \My Documents\My Received Files\1.pdf:Zone.Identifier

  4. The Zone.Identifier is the alternate data stream associated with the file during the attachment saving through IAttachmentExecute. Let's view this ADS using Notepad (replace 1.pdf by one of the files you've found):

    >notepad 1.pdf:Zone.Identifier

    You should find something like this:

    [ZoneTransfer]
    ZoneId=4


    Which is indicating the file comes from zone 4 (somewhere on the internet that is).

  5. Now find some executable somewhere on your system which was not downloaded from the internet. To boost our level of geekiness during the demo we'll go to a Visual Studio .NET 2003 Command Prompt, open up Notepad (optional, see further ;-)), write a "Hello World" console application in C# and invoke csc.exe.

    Setting environment for using Microsoft Visual Studio .NET 2003 tools.
    (If you have another version of Visual Studio or Visual C++ installed and wish
    to use its tools from the command line, run vcvars32.bat for that version.)

    C:\Documents and Settings\bartds>cd \temp

    C:\temp>C:\temp>echo class Hello { public static void Main() { System.Console.WriteLine("Hello World"); } } > hello.cs

    C:\temp>csc hello.cs
    Microsoft (R) Visual C# .NET Compiler version 7.10.6310.4
    for Microsoft (R) .NET Framework version 1.1.4322
    Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.

    C:\temp>

  6. Open up Windows Explorer and go to the temporary folder used in the previous step (say c:\temp). Locate the hello.exe executable and run it. It should work fine without a single warning.

  7. Switch back to the command prompt window and do the following:

    C:\temp>notepad hello.exe:Zone.Identifier

    Notepad will scream "Cannot find the hello.exe:Zone.Identifier file. Do you want to create a new file?" which you'll answer by clicking Yes. Enter the following two lines

    [ZoneTransfer]
    ZoneId=4


    hit File, Save and close Notepad.

  8. Switch back to Windows Explorer and run hello.exe again. It should still not issue a warning. Ough! However, when you close down Windows Explorer and open a new Windows Explorer instance for c:\temp you should not be able to execute the hello.exe file:



  9. Open the file properties for hello.exe and you'll notice the Security warning at the bottom of the dialog. Click Unblock. Now the file will execute correctly.



  10. Switch back to the command prompt window and try the following (again):

    C:\temp>notepad hello.exe:Zone.Identifier

    Again, Notepad will scream "Cannot find the hello.exe:Zone.Identifier file. Do you want to create a new file?" which indicates that the Unblock operation in Windows Explorer has removed the :Zone.Identifier ADS on the file. Answer Notepad's warning message with Yes and enter the following:

    [ZoneTransfer]
    ZoneId=3


    Hit File, Save and close Notepad.

  11. Close the existing Windows Explorer instance and open a new one, pointing to c:\temp. Now try to open the hello.exe file. Instead of blocking the execution as with ZoneId=4 in step 7-8, you'll now get a warning:



  12. Uncheck the "Always ask before opening this file" checkbox and click Run. The executable will run fine. Switch back to the command prompt window and try the following (once again):

    C:\temp>notepad hello.exe:Zone.Identifier

    Once again, Notepad will scream "Cannot find the hello.exe:Zone.Identifier file. Do you want to create a new file?" which indicates that clearing the "Always ask before opening this file" checkbox in the Security Warning dialog has removed the :Zone.Identifier ADS on the file. End of demo.

I'll try to post some code showing the IAttachmentExecute interface's functionality later on. If I find some time after my holidays, I'll blog about my adventures with DEP (see next screenshot) demo stuff too.

Going to bed now in order to be alive and kicking on my holidays :d.

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under:

Comments

# re: Demo of "Attachment Execution Service internals" in Windows XP SP2 and Windows Server 2003 SP1

Friday, August 19, 2005 10:01 PM by bart

Just some update. The following might be interesting: http://www.heise.de/security/artikel/print/50051

It describes two "issues" with the AES feature:
1. Caching in Windows Explorer (that's why I'm writing things such as "Close the existing Windows Explorer instance and open a new one" in my demo script).
2. The fact that only explorer.exe looks at the Zone Identifier and not cmd.exe.

Personally, I believe AES just functions as a first layer of defense, not as a full-blown protection mechanism. Therefore, these "attacks" are - in my opinion - less relevant. In order to protect against running executable content which was downloaded from the internet, the Windows loader for executables would need a change.

Cheers,
Bart

# re: Demo of "Attachment Execution Service internals" in Windows XP SP2 and Windows Server 2003 SP1

Thursday, May 11, 2006 2:19 PM by marc ochsenmeier

Hi,

I have been playing many hours with ADS and still find this issue very interesting. My slides about ADS is to be found a wwww.propagating.net

Regards,
marc ochsenmeier
HP, Germany

# Use Vista's DIR command to display alternate data streams

Thursday, July 13, 2006 1:58 PM by B# .NET Blog

People who have been playing around with Alternate Data Streams (ADS) - otherwise known as a fork - in...

# How does the RemoteSigned execution policy work?

Tuesday, March 06, 2007 9:32 PM by Windows PowerShell

You might have wondered how the "RemoteSigned" execution policy protects us from running unsigned PowerShell

# Removing Security from Downloaded PowerShell Scripts with Alternative Data Strea

Tuesday, April 24, 2007 11:35 PM by Scott Hanselman's Computer Zen

# Pragmatic Disillusionment

Sunday, February 24, 2008 2:14 AM by Unsanity.org

I wanted to talk about the issues we experienced while running the currently released versions of some of our software...

# Security Warning dialog box is displayed when you try to silently install a hotfix or an update

Friday, June 27, 2008 2:58 AM by Decrypt my World

Hi all, You may be trying to install a hotfix or update silently , but you keep getting a security warning