[Intrusions] obfuscated ms-its/.chm hostile web page attacks

[Nick FitzGerald]

James Affeld wrote:

> There are a few "reputable" websites that use the
> ms-its protocol, but not many.  ...

Can you list _any_ for us?

My position on web-borne .CHMs is (and has always been) that they are 
too dangerous to trust.  Their use depends far too heavily on the 
security zone model working.  Much history, and especially recent 
history, shows that you cannot trust IE's zone model -- any vaguely 
prudent user would consider it inherently dangerous and thus should 
disable support for the protocols specifically supplied to allow you to 
invite such security risks into the comfort of your browser.

> ...  The ones that
> obfuscate their invocation of this protocol are
> presumptively not reputable.  ...

Seems reasonable...

> ...  On the basis of the
> following captures, I suggest shunning 64.159.79.20,
> 38.113.1.157, 66.98.144.21, and 69.20.51.244

You don't get out much, do you??   8-)

There are many more sites than that hosting such crud and, worse, they 
change all the time (i.e. some go away, some move and new ones keep 
popping up).  Blacklisting is _NOT_ the way to address such threats as 
this.  As we seem to agree that ms-its: and its kin are undesirable in 
the extreme _regardless_ that there are sites trying to obfuscate their 
use of it, disabling the ability of your users to accept content 
supplied via this family of protocols is clearly the sensible approach. 
 Of course, that takes planning and intelligence and forethought to 
have rolled out your systems in such a way that, if you did not build 
them with ms-its: et al. disabled, you can simply and easily do so now 
via some form of system or policy management tool.

> Some of them are lifting obfuscation techniques
> directly from POC discussions along the lines of, "If
> I wanted to be evil, I could obfuscate this as
> follows..."  One uses more elaborate techniques as
> well.

You also clearly do not look at enough of these things.  Those examples 
are all simple compared to some of what is out there.

And, of course the "bad guys" have a leg up -- they only have to find 
_one_ way to get past the "defense", whereas the defenders have to find 
every way their adversaries can get past them.  When you do not build 
all the tools and all the system components you are trying to defend 
and do not have access to at least detailed design and implementation 
documentation, if not the source for them, you _CANNOT HOPE_ to know 
all the ways the code was designed and implemented to allow your feet 
to be blown off without you ever being aware _a priori_ that that 
avenue of attack even existed.  When it comes to web-based attacks such 
as this, note that if your users are allowed to browse with scripting 
enabled, you are all but guaranteed to lose against at least some 
attacks if your defense depends on blacklisting mechanisms because HTML-
embedded scripting means that you are trying to blacklist a 
(potentially) self-modifying target (I'll spare you the gory details of 
Halting problem issues and the like that also pop up...).  The "baby 
steps" obfuscation in your examples is nothing of what is possible, not 
even employing all the naive tricks the most complex (and even then 
they are trivial) "HTML protection" schemes use.


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854