Six Step IE Remote Compromise Cache Attack

[Liu Die Yu]

Six Step IE Remote Compromise Cache Attack


[tested]
OS:WinXp
Microsoft Internet Explorer v6.Sp1; up-to-date on 2003/10/30

[Overview]

A six step cache attack has been found which allows for remote
compromise of systems running Internet Explorer merely by viewing
a webpage.

This attack is possible partly because of the bugs in Internet
Explorer which remain unfixed. The oldest of these bugs is
almost two years old.

A little something old. A little something new.

Some Kung Fu.


[demo]

The below demo runs a harmless, demonstration exec

utable on your system.
http://www.safecenter.net/UMBRELLAWE...or5-MyPage.htm

Note: This demo has not been found to work on all systems. This seems
to be primarily because of the wide divergence in the placement of temp
folders. A more universal exploit is possible, but too time consuming.

[technical details]
a simple game - It goes a little something like this...


Liu Die Yu's file-protocol proxy bug to reach MYCOMPUTER zone
("file-protocol proxy" *http://safecenter.net/liudieyu/WsOpe...PU-Content.HTM)

then, in MYCOMPUTER zone:
A. use IFRAME to load MHT file which contains payload EXE, then the MHT
file is stored in IE cache.

B.1. use file:///::{450D8FBA-AD25-11D0-98A8-0800361B1103} to get %USERPROFILE%;
(the Pull's: http://www.derkeiler.com/Mailing-Lis...2-01/0013.html )

B.2. use "Redirection and Refresh in Iframe parses local file" to parse
cache index file:
%USERPROFILE%/Local Settings/Temporay Internet Files/CONTENT.IE5/INDEX.DAT
( Mindwarper of mlsecurity's: http://www.mlsecurity.com/ie/ie.htm)
double slash trick is also needed to make the parsed document accessible.
( Liu Die Yu's: http://www.safecenter.net/UMBRELLAWE...he-Content.htm)

C.1. and we get random directory names(like 9OKV91KH), and we get all possible URLs of our payload EXE.
C.2. and we check these URLs with "script src":
(Tom Micklovitch's: http://jscript.dk/Jumper/xploit/scriptsrc.html)

D. when we get a valid local URL pointing to the payload, launch it with
CODEBASE plus "double slash"
( Liu Die Yu's: http://www.safecenter.net/UMBRELLAWE...he-Content.htm)



A little complex. A little simple.

Kung Fu.

[Workaround]

Move your Temporary Internet Files from its' default location:
Tools -> Internet Options -> Temporary Internet Files -> Settings -> Move Folder



[credit]
Liu Die Yu - exploitation;
Dror Shalev developed ASP part of the code in the demo;
Liu Die Yu wrote the first version of this document;
the Pull improved the quality of this document;
All of the researchers named in "technical details";
Microsoft, for not fixing their bugs;

[Greetings]
greetings to:
Drew Copley, dror, guninski and mkill.

[Message]
"My only badge is my conscience. Guns back a badge, but
hellfire backs the conscience." -- Anonymous

-----
all mentioned resources can always be found at UMBRELLA.MX.TC

[people]
LiuDieyuinchina [N0-@-Sp2m] yahoo.com.cn
UMBRELLA.MX.TC ==> How to contact "Liu Die Yu"

[Employment]

I would like to work professionally as a security researcher/bug finder.

See my resume at my site. I am very eager to work, flexible, and
extremely productive. I have a top notch resume, with credentials
from leading bug finders. I am willing to work per contract, relocate,
or telecommute.

[Thor Larholm]

This post raises an interesting question. Is our goal to find new
vulnerabilities and attack vectors to help secure users and critical
infrastructures, or is our goal to ease exploitation of existing
vulnerabilities?

There are no new vulnerabilities or techniques highlighted in this
attack (which is what it is), just a combination of several already
known vulnerabilities. This is not a proof-of-concept designed to
highlight how a particular vulnerability works, but an exploit designed
specifically to compromise your machine. All a malicious viruswriter has
to do is exchange the EXE file.

Believe me, I am all in for full disclosure and detailing every aspect
of a vulnerability to prevent future occurances of similar threats, but
I don't particularly think that we should actively be trying to help
malicious persons.



Regards
Thor Larholm
Senior Security Researcher
PivX Solutions, LLC
Get our research, join our mailinglist - http://pivx.com/larholm/


-----Original Message-----
From: Liu Die Yu [mailto:liudieyuinchina@yahoo.com.cn]=20
Sent: Wednesday, November 05, 2003 2:35 AM
To: bugtraq@securityfocus.com
Subject: Six Step IE Remote Compromise Cache Attack

Snip
http://www.securityfocus.com/archive...2/2003-11-08/0

[Steve Hillier]

I see this more as a method to bring attention to the fact that even
though the individual flaws seem trivial, they can be combined to
perform a malicious act.

Vendors often do not act on an individual flaw as quickly if they feel
the exploit is trivial. This however shows that the individual flaws
pose a greater risk when combined, and that a 'trivial' flaw shouldn't
be ignored simply because it seems 'harmless'.

Why have these flaws not been patched even after almost two years of
knowing that they exist?



Steve Hillier, B.Sc.
Manager of Information Services
Mastermind Educational
www.mastermindtoys.com



> -----Original Message-----
> From: Thor Larholm [mailto:thor@pivx.com]
> Sent: Wednesday, November 05, 2003 5:23 p
> To: Liu Die Yu; bugtraq@securityfocus.com
> Subject: RE: Six Step IE Remote Compromise Cache Attack
>
>
> This post raises an interesting question. Is our goal to find
> new vulnerabilities and attack vectors to help secure users
> and critical infrastructures, or is our goal to ease
> exploitation of existing vulnerabilities?
>
> There are no new vulnerabilities or techniques highlighted in
> this attack (which is what it is), just a combination of
> several already known vulnerabilities. This is not a
> proof-of-concept designed to highlight how a particular
> vulnerability works, but an exploit designed specifically to
> compromise your machine. All a malicious viruswriter has to
> do is exchange the EXE file.
>
> Believe me, I am all in for full disclosure and detailing
> every aspect of a vulnerability to prevent future occurances
> of similar threats, but I don't particularly think that we
> should actively be trying to help malicious persons.
>
>
>
> Regards
> Thor Larholm
> Senior Security Researcher
> PivX Solutions, LLC
> Get our research, join our mailinglist - http://pivx.com/larholm/
>
>
> -----Original Message-----
> From: Liu Die Yu [mailto:liudieyuinchina@yahoo.com.cn]
> Sent: Wednesday, November 05, 2003 2:35 AM
> To: bugtraq@securityfocus.com
> Subject: Six Step IE Remote Compromise Cache Attack
>
> Snip
> http://www.securityfocus.com/archive/1/343464/2003->
11-02/2003-11-08/0
>

[Thor Larholm]

> From: white colin john [mailto:cjwhite1@ehlnx13.ews.uiuc.edu]=20
> If there's no proof-of-concept that shows current=20
> bugs can be combined into an exploit, is there=20
> any pressure on microsoft to patch the bugs?

There has already been several proof-of-concepts for each and every
vulnerability that was used to produce this exploit, and Microsoft are
patching those vulnerabilities. We already know and have demonstrated
that they can be abused, this exploit is just a refinement of those
POC's to ease exploitation - hence my concern.



Regards
Thor Larholm
Senior Security Researcher
PivX Solutions, LLC
Get our research, join our mailinglist - http://pivx.com/larholm/

[Benjamin Franz]

On Wed, 5 Nov 2003, Thor Larholm wrote:

> This post raises an interesting question. Is our goal to find new
> vulnerabilities and attack vectors to help secure users and critical
> infrastructures, or is our goal to ease exploitation of existing
> vulnerabilities?
>
> There are no new vulnerabilities or techniques highlighted in this
> attack (which is what it is), just a combination of several already
> known vulnerabilities. This is not a proof-of-concept designed to
> highlight how a particular vulnerability works, but an exploit designed
> specifically to compromise your machine. All a malicious viruswriter has
> to do is exchange the EXE file.
>
> Believe me, I am all in for full disclosure and detailing every aspect
> of a vulnerability to prevent future occurances of similar threats, but
> I don't particularly think that we should actively be trying to help
> malicious persons.

I have mixed emotions about this. On one side - why put millions of
systems at risk to script kiddies? On the other side, as noted by the
poster, one of these vulnerabilities has been known for more than _TWO
YEARS_. Surely far more than enough time for MS to have actually _fixed_
the problem if they intended to. MS seems (at least in some cases) to
ignore security problems until someone publically 'holds their feet to the
fire' over them. I suspect this happens when the problem 'runs deep' in
their code and will require more than fixing a boundary limit check and
recompiling.

--
Benjamin Franz

Gauss's law is always true, but it is not always useful.
-- David J. Griffiths, "Introduction to Electrodynamics"

[Seth Arnold]

--MW5yreqqjyrRcusr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 05, 2003 at 02:23:29PM -0800, Thor Larholm wrote:
> There are no new vulnerabilities or techniques highlighted in this
> attack (which is what it is), just a combination of several already
> known vulnerabilities.

I think that the engineering-for-security discipline is still in its
infancy. Part of the growth of the discipline is going beyond the simple
boring problems into complex chains of apparently harmless problems
combining to make real problems.

I think this is a valid claim in this case -- if some of the problems
really are known for more than two years without fixes, then I can only
draw the conclusion that either (a) they fell through the cracks or (b)
they were deemed apparently harmless.

I don't have much faith in (a), in large part because of your late,
lamented, and missed Unpatched IE Vulnerabilities page. That leads me
to conclude that the original poster has come up with a slick way of
exploiting the complexity of the software -- which should introduce
discussion about how to properly handle the complexity of the software.

Thanks

--=20
And for the love of God, would people PLEASE not use Lotus Notes or
Outlook/Exchange's "Out of Office Autoreply" on mail lists? Contact your
mail administrator for details how to do something more appropriate.
Thanks.

--MW5yreqqjyrRcusr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/qYbj+9nuM9mwoJkRApOgAKCJYwq2t5oM/J2OVr6NddVTPaRdsACdF4Rs
qyo/rMTq10lP+rjIop9lYv4=
=scLg
-----END PGP SIGNATURE-----

--MW5yreqqjyrRcusr--

[white colin john]

On Wed, 5 Nov 2003, Thor Larholm wrote:

> This post raises an interesting question. Is our goal to find new
> vulnerabilities and attack vectors to help secure users and critical
> infrastructures, or is our goal to ease exploitation of existing
> vulnerabilities?

If there's no proof-of-concept that shows current bugs can be combined
into an exploit, is there any pressure on microsoft to patch the bugs?

[Florian Weimer]

Thor Larholm wrote:

> This post raises an interesting question. Is our goal to find new
> vulnerabilities and attack vectors to help secure users and critical
> infrastructures, or is our goal to ease exploitation of existing
> vulnerabilities?

With Internet Explorer, Microsoft is exactly in the position that was
the original motivation for full disclosure -- force the vendor to fix
the bugs. The reasons are different (very risk-prone design; for
example, any ActiveX control can break the entire security policy), and
Microsoft isn't ignoring the problems altogether. But the end result is
nearly the same: lot's of unfixed, more-or-less well-known bugs.

You can deal with this situation in a few ways: ignore it, and hope for
the best; try to surpress information about vulnerability details;
choose safer settings (breaking many, many web pages); prevent users
from browsing the web using Internet Explorer (with or without disabling
plugins of questionable code quality, i.e. all of them); gamble with
virus scanners and special proxies; restrict Web access to separate
terminals, and so on.

However, none of these approaches makes the problem go away. I still
believe that the client is lost, and will remain lost for quite some
time. As far as I know, this view isn't shared by Microsoft engineers.
They reason that the company is pretty good at patch management, much
better than the competition. Maybe Microsoft has a true advantage over
the rest of the industry here (I wouldn't rule out that possibility),
but in the best case, your patch management is only as good as the
patches you can apply. If the developers have to deal with a
substantial backlog of unfixed security issues, both published and
unpublished, it's not very likely that the right patches are available
in time. So far, we have been rather lucky.

Note that this discussion completely ignores the poor, poor home users.
I have no idea how the situation can be improved for them, in particular
if they run illegal software copies and fear to download and apply any
vendor patches.

> Believe me, I am all in for full disclosure and detailing every aspect
> of a vulnerability to prevent future occurances of similar threats, but
> I don't particularly think that we should actively be trying to help
> malicious persons.

I understand your concern, and share it in some cases, especially if I
assume that most people are already sensitive to the threat. I don't
see that for Internet Explorer, so further education seems to be
necessary, even if it takes rather drastic forms.

[Paul Szabo]

Thor Larholm <thor@pivx.com> wrote:

> Is our goal to find new vulnerabilities and attack vectors to help secure
> users and critical infrastructures, or is our goal to ease exploitation
> of existing vulnerabilities?

The former is part of our goal, the latter is certainly not.

We actively look for vulnerabilities: to help users and vendors, and simply
because it is fun. We then try to advise users with workarounds, and try to
get vendors to develop fixes. Sadly, to convince vendors that there is a
problem worth fixing, sometimes we are forced to produce proof-of-concept
exploits.

> There are no new vulnerabilities ... in this attack ...

This demo may have been necessary to convince MS to fix those old
vulnerabilities.

[In another message you wrote:
> ... and Microsoft are patching those vulnerabilities.
Any concrete evidence to that?]

> Believe me, I am all in for full disclosure ...

We are judged by our actions. The vocal ones usually have something to hide.

Cheers,

Paul Szabo - psz@maths.usyd.edu.au http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics University of Sydney 2006 Australia

[Jelmer]

>This post raises an interesting question. Is our goal to find new
>vulnerabilities and attack vectors to help secure users and critical
>infrastructures, or is our goal to ease exploitation of existing
>vulnerabilities?

Interesting viewpoint from someone who willfully published code that caused
a worm to spread (and infact admitted to that he expected no less) and I
quote http://www.pcworld.com/news/article/0,aid,84324,00.asp

"The worm is a modified version of our example code. We never intended for
anybody to copy the code, although we kind of expected it would happen,"
said Thor Larholm, one of the two Europeans who demonstrated how specially
crafted code on a Web page could take over MSN Messenger. "We published the
example to put pressure on Microsoft to patch vulnerabilities that they are
fully aware of."


>There are no new vulnerabilities or techniques highlighted in this
>attack (which is what it is),
>just a combination of several already
>known vulnerabilities. This is not a proof-of-concept designed to
>highlight how a particular vulnerability works,

Untrue , normally content accessed in the temporary internet files folder is
in the restricted zone
Liu pointed out that this can be bypassed. this is the new and crucial
ingredient in the mix
without it, one would not be able to exploit this in this fashion

>but an exploit designed
>specifically to compromise your machine. All a malicious viruswriter has
>to do is exchange the EXE file.

>Believe me, I am all in for full disclosure and detailing every aspect
>of a vulnerability to prevent future occurances of similar threats, but
>I don't particularly think that we should actively be trying to help
>malicious persons.

There are many reasons imaginable why you want to do this

- It proofs the relevance of liu's cache exploit
- There are workarounds for some issues, many might not bother applying them
because they dismiss it as not being important enough to bother
- One vulnerability used in this is *OVER 2 YEARS OLD* microsoft bloody well
needs to wake up and smell the coffee, putting some pressure on them is just
what is needed
- If liu can do it theres a big chance that somewhere someone can do the
same, you could get hacked without knowing about it, I prefer to know whats
out there so I can take countermeasures
- He obviously takes great pride in his work, you can see he worked long and
hard at it, six steps thats quite a feat, working past every obstactle
there's a lot of stuff going on that researchers can look at and learn from
- It may give him the media attention to land a job much, which he seems to
be seeking, it's a proven concept, you did get your job over at pivx after
publishing the wormcode

-----Original Message-----
From: Liu Die Yu [mailto:liudieyuinchina@yahoo.com.cn]
Sent: Wednesday, November 05, 2003 2:35 AM
To: bugtraq@securityfocus.com
Subject: Six Step IE Remote Compromise Cache Attack

Snip
http://www.securityfocus.com/archive...2/2003-11-08/0

[Drew Copley]

> -----Original Message-----
> From: Benjamin Franz [mailto:snowhare@nihongo.org]=20
> Sent: Wednesday, November 05, 2003 2:50 PM
> To: Thor Larholm
> Cc: Liu Die Yu; bugtraq@securityfocus.com
> Subject: RE: Six Step IE Remote Compromise Cache Attack
>=20
>=20
> On Wed, 5 Nov 2003, Thor Larholm wrote:
>=20
> > This post raises an interesting question. Is our goal to find new=20
> > vulnerabilities and attack vectors to help secure users and=20
> critical=20
> > infrastructures, or is our goal to ease exploitation of existing=20
> > vulnerabilities?
> >=20
> > There are no new vulnerabilities or techniques highlighted in this=20
> > attack (which is what it is), just a combination of several already=20
> > known vulnerabilities. This is not a proof-of-concept designed to=20
> > highlight how a particular vulnerability works, but an exploit=20
> > designed specifically to compromise your machine. All a malicious=20
> > viruswriter has to do is exchange the EXE file.
> >=20
> > Believe me, I am all in for full disclosure and detailing=20
> every aspect=20
> > of a vulnerability to prevent future occurances of similar threats,=20
> > but I don't particularly think that we should actively be trying to=20
> > help malicious persons.
>=20
> I have mixed emotions about this. On one side - why put=20
> millions of systems at risk to script kiddies? On the other=20
> side, as noted by the poster, one of these vulnerabilities=20
> has been known for more than _TWO YEARS_. Surely far more=20
> than enough time for MS to have actually _fixed_ the problem=20
> if they intended to. MS seems (at least in some cases) to=20
> ignore security problems until someone publically 'holds=20
> their feet to the fire' over them. I suspect this happens=20
> when the problem 'runs deep' in their code and will require=20
> more than fixing a boundary limit check and recompiling.

Very well said.=20

I would note that I believe their strategy for securing code wants to be
inline with their strategy for pushing their products. The company is
full of strategies, and this is good. But, the primary stategy needs to
be to "put security first". Especially, post 9/11.=20

A few others things...

As with all security issues, the researcher is not bound to tell anyone
about them. Liu Die Yu could have just shared this with his friends, and
we all could have kept these to do as we will. Kind of like keeping your
own personal nuclear weapon. Who knows? Maybe there will be a rainy day.


My question then, to everybody, is "would you have preferred that he
keep this to himself and his friends, or would you have preferred for
him to have disclosed this, with a workaround?"

Because Liu Die Yu has worked with Microsoft (China) in the past, and he
has, unfortunately, found that he can not trust them. Maybe he talked to
the wrong person. Who knows? But, we can all see plainly that Microsoft
was without excuse to ignore these problems all of these years. What was
the thinking behind that?

Was somebody's job saved so this could happen? Was somebody able to make
a more successful career move because of this? Are researhers like Liu
Die Yu too intimidating to deal with, too challenging, too successful?

What would have happened if someone else put these flaws together and
discovered they could make them work? What would have been the case in
that situation? Why did Microsoft ignore the advice of all these
researchers and not do something about these issues? Why did they think
they could go it alone in this way? The advice was free for them.=20

They had almost two years to fix this, should Liu Die Yu even
conceivably be forced to wait another three to six months from a company
that has shown him bad dealings in the past?

This is using the system at its' best. It is an example of the best kind
of system. There is no bureaucracy, there is no limitation, no glass
ceilings, no prejudice... Anyone who is capable, come, find bugs.=20

Microsoft is putting out millions of dollars in bounties for worm
writers while people like Liu Die Yu are just trying to get into the
security field, so they can do what they are best at. What they love to
do. It isn't like he is incapable of doing this. He has found swarms of
bugs since starting to look for them.

Bounties work. We know they do. But, let's close the gap. Let's make
sure that tomorrow's bugs are not found outside of the Full Disclosure
community. Why would anybody be making these kinds of shortcuts? What
good is AV or Firewalls or anything if your OS let's the attacker
through?=20

We worry about script kiddies trying to figure out what Liu Die Yu did
here to make their own version? We should be worrying about rogue
nations and criminal organizations creating teams of bug finders so they
can penetrate any system they want to.

The computers themselves are worthless, compared to human lives, but the
information within them are invaluable. Blueprints. Military strategies.
Political strategies. Security strategies. Governmental secrets.
Corporate secrets. Identities. Weaknesses.=20

I have to wonder when people when begin to figure out that security bugs
mean... security holes mean: keys to the application, and generally,
keys to the system. We can ponder all we want about the NSA having a
backdoor, or merely Microsoft having a backdoor... But anytime someone
finds a security hole like this, they have a backdoor.
=20
If you want, ask the researcher to please alert the vendor. Be rude
about it, whatever. But, understand that if they were bad or interested
in doing evil... They would not report it to the world. They would use
it.=20

Lastly, just to be fair. Most researchers that find bugs in Microsoft's
products do so at least partly because everyone uses their software.
Microsoft actually has a code auditing team, they actually have made
moves towards securing their software. Most companies have not done
this. Their code is not even looked at. If the case were anything
different, Liu Die Yu would just put his resume on monster or dice, and
he wouldn't be speaking to us right now. He would be working in the
field he loves.

Drew Copley


Research Engineer, eEye Digital Security

Fun quote for the day:
"Who knows what evil lurks in the hearts of men? The Shadown knows!"


>=20
> --=20
> Benjamin Franz
>=20
> Gauss's law is always true, but it is not always useful.
> -- David J. Griffiths, "Introduction to Electrodynamics"
>=20
>=20
>=20

[Steven M. Christey]

Thor Larholm said:

>This post raises an interesting question. Is our goal to find new
>vulnerabilities and attack vectors to help secure users and critical
>infrastructures, or is our goal to ease exploitation of existing
>vulnerabilities?
>
>There are no new vulnerabilities or techniques highlighted in this
>attack (which is what it is), just a combination of several already
>known vulnerabilities.

Maybe I'm alone in this, but I find web browser bugs like these to be
among the most complex and difficult-to-understand vulnerabilities
that get reported. An aspect of that complexity often seems to
involve crossing several intended security "boundaries" in the
process, taking advantage of design choices that, by themselves, don't
seem to be that security-relevant. Example: one might think that
non-random locations for software components would be a good thing,
but it's a factor in a number of web client bugs. (Another aspect of
that complexity comes from advisories that simply include exploit code
using obscure components or elements but don't suggest where the issue
actually lies, but that's a different matter.)

I can only think of a handful of examples of "vulnerability chains"
within the same software package, but web clients seem to be a
consistent source of these chains (web servers too, probably, and
anything where a variety of components can be "glued" together). It
wouldn't surprise me if most "in-package vulnerability chains" have
one or more vulnerabilities that are very low risk in and of
themselves, but critical to exploiting the chains. (And back to the
subject of advisories, I've noticed that some researchers will treat
vulnerability chains as if they are entirely separate
vulnerabilities.)

Taking a long-term view with respect to vulnerability research in
general: understanding these attacks, and why they work, could provide
valuable lessons for any other software that attempts to define and
control access between different "security zones." This assumes that
these attacks can be classified in a way that clarifies the nature of
the underlying vulnerabilities and associated chains, but as Seth
Arnold pointed out, it could be beneficial for understanding how to
properly integrate security into engineering.

- Steve

[Tyler Larson]

Quoting white colin john <cjwhite1@ehlnx13.ews.uiuc.edu>:

> On Wed, 5 Nov 2003, Thor Larholm wrote:
>
> > This post raises an interesting question. Is our goal to find new
> > vulnerabilities and attack vectors to help secure users and critical
> > infrastructures, or is our goal to ease exploitation of existing
> > vulnerabilities?
>
> If there's no proof-of-concept that shows current bugs can be combined
> into an exploit, is there any pressure on microsoft to patch the bugs?
>
>

I'm surprised that nobody has taken issue with this statement. I think
that in this case Msft would continue to drag its feet for years to come, and
Liu was justified in posting the exploit. However, I think that in the
general case (expecially those dealing with entities other than Msft) the
statement is not always accurate.

When dealing with projects and organizations with security-minded developers--
take the OpenSSH project or vsftpd, for example--extremely little coersion is
necessary. Just email the developer and he'll fix it immediately.

In fact, I'd go as far as to say that in dealing with any open-source
software at all, development of a POC exploit is never necessary. It's
generally easier (and always more productive) to develop the fix than the POC
anyway. And if a vendor patch exists, POC code won't help anybody. Why?
Because the existance of a security patch already adequately demonstrates the
existance of a potential threat.

People who develop exploit code should think REAL HARD about why they're
doing it before they start. If you're writing it simply because nobody else
has yet, you should definately reconsider: there's probably reasons why no
one has written it before--do you really think you're the first one to know
how? If you're trying to impress you're peers (i.e. get a job) think again.
Attention you get by acting irresponsibly is not the attention you want. If
attention is a motive, it should be a secondary motive rather than a driving
one--otherwise it gets in the way of common sense. Attract attention while
doing the "right thing" (i.e. developing POC exploits only when they're
needed). It produces better results anyway.

As stated before by others, proof-of-concept exploit code serves one major
purpose: It lights a fire under a slow-moving organization to quickly develop
a fix. It's important to understand how, though. It does it by:

* Convincing the company that the threat is real. We like to think this is
all we're doing, but it's only a very small part of the process.

* Increasing the threat by aiding in the development of worms and viruses.
Sad but true, this is a major reason why exploit code speeds things up.

* Turning public opinion against the company. They clean it up only because
it would be a PR nightmare if they didn't.

Exploits, even POC exploits, do a LOT of damage, whether you like to belive
it or not. That's the whole reason why they work--they absolutely force the
company to fix the problem in order to stop the bleeding. That's why
Microsoft HATES the whole concept of full disclosure (a few choice Ballmer
quotes may come to mind). There's really nothing innocent or harmless about
it.

In certain situations, though, the general pubic (though probably not the
company) is better off because the exploits forces the company to fix its
mistakes. In those select few situations, I say the developer is justified in
writing the exploit. The rest of the time, though, I say he's just being a
public menace.

[http-equiv@excite.com]

I can confirm the below on a brand spanking new, 3 week old, top-of-
the-line machine with Windows XP Home edition, customised, with every
conceivable patch, security pack, gadget enabled updating twaddle it
comes with and installed to date.

I demand a refund from the vendor ! This is a disgrace. 2 year old
remnant bugs and holes unattended culminating in this full and
complete remote takeover via a web page [again !]. 5 Million dollar
bounties to chase ghosts in the closets wasting law inforcement's
valuable and over-worked time, when it can be better spent on
bounties for bugs and repairing of product I have been duped into
buying.

Pathetic !

"Liu Die Yu" <liudieyuinchina@yahoo.com.cn> wrote:

Six Step IE Remote Compromise Cache Attack


[tested]
OS:WinXp
Microsoft Internet Explorer v6.Sp1; up-to-date on 2003/10/30

[Overview]

A six step cache attack has been found which allows for remote
compromise of systems running Internet Explorer merely by viewing
a webpage.

This attack is possible partly because of the bugs in Internet
Explorer which remain unfixed. The oldest of these bugs is
almost two years old.

A little something old. A little something new.

Some Kung Fu.


[demo]

The below demo runs a harmless, demonstration executable on your
system.
http://www.safecenter.net/UMBRELLAWE...or5-MyPage.htm

Note: This demo has not been found to work on all systems. This seems
to be primarily because of the wide divergence in the placement of
temp
folders. A more universal exploit is possible, but too time consuming.

[technical details]
a simple game - It goes a little something like this...


Liu Die Yu's file-protocol proxy bug to reach MYCOMPUTER zone
("file-protocol proxy"
*http://safecenter.net/liudieyu/WsOpe...WsOpenFileJPU-
Content.HTM)

then, in MYCOMPUTER zone:
A. use IFRAME to load MHT file which contains payload EXE, then the
MHT
file is stored in IE cache.

B.1. use file:///::{450D8FBA-AD25-11D0-98A8-0800361B1103} to get %
USERPROFILE%;
(the Pull's: http://www.derkeiler.com/Mailing-
Lists/securityfocus/bugtraq/2002-01/0013.html
)

B.2. use "Redirection and Refresh in Iframe parses local file" to
parse
cache index file:
%USERPROFILE%/Local Settings/Temporay Internet
Files/CONTENT.IE5/INDEX.DAT
( Mindwarper of mlsecurity's: http://www.mlsecurity.com/ie/ie.htm)
double slash trick is also needed to make the parsed document
accessible.
( Liu Die Yu's:
http://www.safecenter.net/UMBRELLAWE.../DblSlashForCa
che-
Content.htm)

C.1. and we get random directory names(like 9OKV91KH), and we get all
possible URLs
of our payload EXE.
C.2. and we check these URLs with "script src":
(Tom Micklovitch's: http://jscript.dk/Jumper/xploit/scriptsrc.html)

D. when we get a valid local URL pointing to the payload, launch it
with
CODEBASE plus "double slash"
( Liu Die Yu's:
http://www.safecenter.net/UMBRELLAWE.../DblSlashForCa
che-
Content.htm)



A little complex. A little simple.

Kung Fu.

[Workaround]

Move your Temporary Internet Files from its' default location:
Tools -> Internet Options -> Temporary Internet Files -> Settings ->
Move Folder



[credit]
Liu Die Yu - exploitation;
Dror Shalev developed ASP part of the code in the demo;
Liu Die Yu wrote the first version of this document;
the Pull improved the quality of this document;
All of the researchers named in "technical details";
Microsoft, for not fixing their bugs;

[Greetings]
greetings to:
Drew Copley, dror, guninski and mkill.

[Message]
"My only badge is my conscience. Guns back a badge, but
hellfire backs the conscience." -- Anonymous

-----
all mentioned resources can always be found at UMBRELLA.MX.TC

[people]
LiuDieyuinchina [N0-@-Sp2m] yahoo.com.cn
UMBRELLA.MX.TC ==> How to contact "Liu Die Yu"

[Employment]

I would like to work professionally as a security researcher/bug
finder.

See my resume at my site. I am very eager to work, flexible, and
extremely productive. I have a top notch resume, with credentials
from leading bug finders. I am willing to work per contract,
relocate,
or telecommute.



--
http://www.malware.com

[Paul Schmehl]

--On Wednesday, November 05, 2003 8:27 PM -0500 "Steven M. Christey"
<coley@mitre.org> wrote:
>
> Maybe I'm alone in this, but I find web browser bugs like these to be
> among the most complex and difficult-to-understand vulnerabilities
> that get reported. An aspect of that complexity often seems to
> involve crossing several intended security "boundaries" in the
> process, taking advantage of design choices that, by themselves, don't
> seem to be that security-relevant. Example: one might think that
> non-random locations for software components would be a good thing,
> but it's a factor in a number of web client bugs. (Another aspect of
> that complexity comes from advisories that simply include exploit code
> using obscure components or elements but don't suggest where the issue
> actually lies, but that's a different matter.)
>
But isn't this crossing of security boundaries essentially caused by the
same mental error that buffer overflows are caused by? Trusting
untrustable input is at the foundation of each, isn't it?

If you create a boundary that says, "This is private space. Only trusted
data can enter.", yet you decide that, for whatever supposedly legitimate
reason you want to allow input from some other space, isn't it incumbent
upon you as the programmer to disallow all but "proper" input?

It appears to me that this chaining of weaknesses is nothing more than an
extension of the same problem that each weakness has individually, i.e. the
failure of the programmer to do "bounds" checking. Granted, it's more
complex to figure out how to exploit the weaknesses, but the reason the
exploit is possible is because of the same naive trust that fails us every
time.

We need a paradigm shift in programming from "allow all but the known bad"
to "disallow all but the known good", don't we?

Paul Schmehl (pauls@utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu