Ed Reed wrote:
This article describes a Trojan horse attack introduced via MS Office
(Word) documents that provided remote access by adversaries to
compromised systems. It doesn't say if the exploit - design flaw -
was intentionally introduced (a product of deliberate subversion) or
Well, odds are not, given the source of the software in question (and,
no, I don't mean that I think MS has much better security screening of
its employees... 8-) ).
... While the article may provide comfort to the defense in depth
crowd (the State department THINKS the issue was discovered immediately
- but then again, after they were made aware of it - so they knew what
to watch for - they found numerous other compromised systems, so I
wonder how many haven't (yet) been caught).
This isn't terribly surprising, but it brings to mind a new insight (for
me, anyway) into the issue that government and commercial customers are
We've (Aesec) been saying that subversion (deliberately introduced
design and implementation defects into a customer's IT supply chain) is
the preferred avenue of attack of professional adversaries, and I agree
that it is.
We've (Aesec) also noted that the commercial security industry is
largely focused, instead, on discovering and patching software defects
that can be easily discovered (via fuzzing and testing) and exploited to
gain access to systems.
Both those two avenues can lead to serious security breeches.
But it's not necessary to plant an operative into a vendor's shop in a
position to introduce flaws into software to gain advantage. Simply
knowing enough about the internal design and implementation of the
system is likely to provide the adversary with the knowledge and
opportunity to discover paths of attack that can be researched at their
leisure, held until needed as what would be considered a private zero
So at one end of the spectrum of malicious attacks are pure opportunists
(including amateurs and script kiddies) using defects discovered through
fuzzing interfaces and related black box testing techniques. At the
other end of the scale are paid professional operatives infiltrating
vendor development and delivery supply chains to introduce defects
intentionally. And in the middle are those with gray box knowledge of
products involved, who are in a better position than the public to
identify attack vectors worth investigating.
This middle ground would seem to significantly increase the threat -
there are many more jobs in vendor organizations (and their supply and
support chains) that provide privileged insight to product design,
development, implementation and delivery than there are with direct code
modification roles in the product. So I think you'd have to assume that
the pool of unreported zero day exploits may be much larger than
I agree with all this, but...
You -- and all journalistic and other commentaries I've seen/heard on
the increasingly common use of these targetted Office exploits -- miss
one very important option, I think; the attacker has access to
(partial) source of the closed, supposedly closely-held, proprietary
software in question.
Recall the rumours and stories from a few years back of the MS source-
code thefts? From memory, reputedly (most of) Win2K, some of WinXP (?)
and (parts of) Office were stolen. Parts of these thefts were clearly
confirmed with (parts of) Windows OS source becoming downloadable from
various underground sources sometime later.
Further, and more speculative, was the suggestion that the reputed
(earlier) MS break-in (as opposed to the third-party licensee from
which the OS source code was reputedly clearly obtained) was a
Russian or Chinese hacker/hacking group.
Some say that there were multiple break-ins at MS around that time and
that both Russian and Chinese groups were involved.
Nowadays most of the publicly discussed/disclosed targetted Office
exploits have been attributed to Chinese-based attackers.
Also of some interest might be the fact that it seems (at least to me)
if there are version specificities in the exploits used in these
targetted attacks, these more commonly restrict the applicability of
the exploit to the older Office product versions. Now, this may be
indicative of overall improvements in MS code standards due to SDLC
(are newer versions of Office distilled through SDLC?) and compiler
security improvements, but it might also be indicative of the
attackers (or, at least those they buy their exploits from) having
access to the reputed/rumoured stolen Office source which, if it ever
was stolen, would be code of older versions of Office and thus be more
likely to have changed, and thus not exhibit the same vulnerabilities,
in newer versions.
Just a thought.