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/UMBRELLAWEBV4/execdror5/execdror5-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/WsOpenFileJPU/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/UMBRELLAWEBV4/DblSlashForCache/DblSlashForCache-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/UMBRELLAWEBV4/DblSlashForCache/DblSlashForCache-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/1/343464/2003-11-02/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/1/343464/2003-11-02/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/UMBRELLAWEBV4/execdror5/execdror5-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/WsOpenFileJPU/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/UMBRELLAWEBV4/DblSlashForCache/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/UMBRELLAWEBV4/DblSlashForCache/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

[Florian Weimer]

Tyler Larson wrote:

> 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.

In some cases that's true. But if it's a remotely exploitable hole that
doesn't require prior authentication of the attacker and it affects
widespread software, I'd rather like to see a proof-of-concept exploit.

Why? Even if the admin in charge has applied a patch (or a
configuration change), there's a non-zero probability that something
goes wrong: the service is not restarted, the wrong version of the
package has been installed, the file system contains another copy of the
software which is the one that is actually running, the patch lacks a
hunk and is ineffective, the system compiler optimized away the new
security check, and so on.

If you look at the recent DCOM scanners, you'll notice that they work
without PoC code. Microsoft implemented some unrelated changes, and the
difference in behavior is externally observable. If you have got the
source code, you usually apply minimal patches which often don't even
change the version number (distributions such as Debian and SuSE have a
policy to backport just the isolated security fixes). That's why remote
probing almost always requires an exploit of some kind. Not a complete
exploit, with an extensive collection of offsets and shellcode for
various platforms, but some proof of concept, so that we are able to
check if we are in doubt.

> It's generally easier (and always more productive) to develop the fix
> than the POC anyway.

Sometimes this is true. A deterministic proof-of-concept exploit for
the recent ircd bug was quite hard to construct, fixing it was much
easier (I had applied a fix even before I fully understand the problem
and upstream agreed that there was in fact a problem 8-).

> 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.

I agree that exploit code is less helpful for threat assessment. After
all, you don't know if the exploit is representative for all methods of
attack, and if it demonstrates the maximum possible impact.

However, as outlined above, there are other uses for exploit code. Of
course, it doesn't really apply to passive attacks on clients such as
web browsers (but I presume that the discussion has slipped a bit 8-).

[Steven M. Christey]

Paul Schmehl said:

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

We need a little bit more than that, because our understanding of
"what's bad" increases with time, and that frequently reduces the set
of "what's good."

For example, I recently audited a web application that inherently
disallowed all but known good inputs, by design. Some of you know how
much of a rare pleasure it can be to audit well-designed software ;-)
It kept close track of "immutable" fields and would exit whenever any
tampering was detected. It did a pretty good job of using regular
expressions to restrict input.

Unfortunately, it was subject to a CRLF injection vulnerability, which
was not publicly known at the time the application had been developed.
And the CRLF injection attack normally would not have worked thanks to
the app's design, except the web application had a "feature" (perhaps
accidental) in which a customized control file could define new fields
that should have been labeled immutable, but were not.

As a different example, consider directory traversal issues in which
".." sequences are separated by illegal characters that are filtered
out only *after* the ".." check is performed. The process goes like:

1) Software checks for ".." sequences and generates an error if any
are found

2) Software cleanses and canonicalizes the input

Such software could be subject to directory traversal via a ".|."
sequence that isn't found in step 1, but the "|" gets removed in step
2; or maybe a "%2e%2e" URL encoding would work.

While this may be an example of an "allow all but known bad" approach,
there are also lessons to be learned about designing the software so
that security-sensitive operations are performed in the proper order.
In addition, there's a need to know and explicitly model which
vulnerabilities a piece of data may be exposed to at different points
in time. It's not just "known good," it's "known good under a
specific context at a specific time."

- Steve

[Byron Sonne]

> But wrongly rejecting good input has no security implications.
> But wrongly accepting bad input has.

Are you sure about that? It's arguable that it's the outcome of the
action that is more important than the content or value of the action
itself (i.e. By action or admission of action allow an offence to be
committed).

If I have backdoored a system, and I can have the system reject good
input (i.e. the sysadmin issuing a command to remove the backdoor), then
the system has continued to remain insecure as a result of rejecting
good input.

That may be a contrived example, but this is a topic that bears being
pedantic ;) so if a principle isn't true in all cases it isn't true at all.


--

For good, return good. For evil, return justice.

[Steven M. Christey]

"Goetz Babin-Ebell" <babin-ebell@trustcenter.de> said:

>> We need a little bit more than that, because our understanding of
>> "what's bad" increases with time, and that frequently reduces the set
>> of "what's good."
>
>Yes.
>But wrongly rejecting good input has no security implications.

Actually, I'm starting to see evidence that it can, if you think of
"susceptibility to denial of service" as a security issue.

Specifically, the software not only has to recognize the bad input, it
has to generate an error condition, then properly respond to it.

A few types of vulnerabilities have been reported due to bad error
handling on security-relevant conditions:

- An application detects an input that's too long and returns a NULL
pointer, which then causes a crash when the pointer is dereferenced.

In fact, I suspect that some of the so-called "buffer overflows"
that get reported these days are really null pointer problems.
Researchers are encouraged to consider this in their diagnoses.

- An application detects a bad input and reports an error, but it
doesn't "exit" out of the code, and goes right on processing the bad
input.

>I don't think we should primarily look for vulnerabilities,
>but we all should spend more time on the definition of allowed input
>and reject all that is not in these limits.

I agree that more attention should be paid to identifying *exactly*
what "allowed input" means. For example, directory traversal issues
could probably be entirely eliminated as a class if the software's
design restricted file names to be alphanumeric with a single file
extension. The programmer may cry "but that limits flexibility in
file naming!" but it's in that flexibility where danger lies.

On the other hand, alphanumeric tests can be insufficient if you also
want to avoid MS-DOS device name problems...

- Steve

[Alun Jones]

> -----Original Message-----
> From: Goetz Babin-Ebell [mailto:babin-ebell@trustcenter.de]
> Sent: Monday, November 10, 2003 11:25 AM
>
> But wrongly rejecting good input has no security implications.
> But wrongly accepting bad input has.

Coding to satisfy only security implications, in a vacuum separated from the
rest of the world, all the security bugs in the world can be fixed simply by
removing all the features.

Wrongly rejecting good input has a very strong implication - your program
fails to do what it is tasked with. You can call that a security
implication, in that security's task is not just to prevent access by the
unwashed, but also to allow, provide and facilitate access to those that are
approved.

If all we are doing is trying to prevent unauthorised access, then all we
have to do is turn off, unplug, and shred, our computers. There - security
made easy.

Alun.
~~~~
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
1602 Harvest Moon Place | alun@texis.com.
Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

[Goetz Babin-Ebell]

--------------ms000204080601000904010104
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Alun,

Alun Jones wrote:
>>-----Original Message-----
>>From: Goetz Babin-Ebell [mailto:babin-ebell@trustcenter.de]
>>Sent: Monday, November 10, 2003 11:25 AM
>>
>>But wrongly rejecting good input has no security implications.
>>But wrongly accepting bad input has.
>
> Coding to satisfy only security implications, in a vacuum separated from the
> rest of the world, all the security bugs in the world can be fixed simply by
> removing all the features.

That is not what I have said:
You define a field of accepted inputs (your white list)
All inputs, that do not match the white list,
is rejected with an error.

Now you have to study the errors with the supplied input.
If there is some input that should be accepted,
you have to adapt your white list.
(After testing that this inpuut doesn't barf your program...)

> Wrongly rejecting good input has a very strong implication - your program
> fails to do what it is tasked with.

Only for those inputs you are not sure
that it really does what it should do.
And that is good.
An error message is always better than an wrong result.

> You can call that a security
> implication, in that security's task is not just to prevent access by the
> unwashed, but also to allow, provide and facilitate access to those that are
> approved.

Your program has a function.
If gets some inputs, does some operations and generates some outputs.

There are 3 differend kinds of inputs:
1. inputs you are sure it will generate correct output
2. inputs you are sure it will generate unwanted output
3. inputs you don't know what output it will will generate

You want only to generate error messages for inputs of kind 2.
I want to generate error messages for inputs of the kinds 2 & 3.

Lets have an example:
A program that gets a number and calculates the next number.

For some inputs it will generate correct outputs.
For other inputs you are either not sure or you know that
it will generate some wrong output.

The used data type is unsigned char.

The 1st version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
return FALSE;
}

This is OK until the first customer tries
the number 10 and gets an error message.

Reading (and testing) the code, we find:
there is no problem with 2 digit numbers.

So the 2nd version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' && !in[2])
return TRUE;
return FALSE;
}

This is OK until the first customer tries
the number 100 and gets an error message.

Reading (and testing) the code, we find:
there is a problem with numbers bigger than 255.

So the 3rd version of the input test function is:

BOOL CheckInput(const char*in)
{
if (!in)
return FALSE;
if (in[0] >= '0' && in[0] <= '9' && !in[1])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' && !in[2])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] >= '0' && in[2] <= '1' && !in[3])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] == '2' && in[1] >= '0' && && in[1] <= '4'
&& !in[3])
return TRUE;
if (in[0] >= '0' && in[0] <= '9' &&
in[1] >= '0' && in[1] <= '9' &&
in[2] == '2' && in[1] == '5' && in[0] >= '0' && in[0] <= '5'
&& !in[3])
return TRUE;
return FALSE;
}

Now we have found the real limits of the program.
But the importand fact is:
For all input the program ever accepted,
it calculated the correct output.


> If all we are doing is trying to prevent unauthorised access, then all we
> have to do is turn off, unplug, and shred, our computers. There - security
> made easy.

I did never say we should dump our computers.
I did say our programs should only accept
input we are sure they process correctly.


Bye

Goetz

--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126

--------------ms000204080601000904010104
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCS qGSIb3DQEHAQAAoIIIkDCC
BEQwggOtoAMCAQICDwCQHgAAAAJOQu0jEgf3pTANBgkqhkiG9w 0BAQUFADCBvDELMAkGA1UE
BhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbW J1cmcxOjA4BgNVBAoTMVRD
IFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE5ldH dvcmtzIEdtYkgxIjAgBgNV
BAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDMgQ0ExKTAnBgkqhk iG9w0BCQEWGmNlcnRpZmlj
YXRlQHRydXN0Y2VudGVyLmRlMB4XDTAzMDIxMDE0NDI1MFoXDT A0MDIxMDE0NDI1MFowgaox
CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQ QHEwdIYW1idXJnMRowGAYD
VQQKExFUQyBUcnVzdENlbnRlciBBRzEUMBIGA1UECxMLRW50d2 lja2x1bmcxGjAYBgNVBAMT
EUdvZXR6IEJhYmluLUViZWxsMSkwJwYJKoZIhvcNAQkBFhpiYW Jpbi1lYmVsbEB0cnVzdGNl
bnRlci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCgg EBALB6adN6EChrpAbT5KV1
ceRRIDAoGnz2gsBoFI2BwJLS+RpuIZfdJOepm4crg3X6LXrMKw SF/lshFeHrVPtLzabgLGyF
SujsJP0z3u7f4XNYCGHl4UbyPkYboIP9GC/DRtsknO1YfJUy/4yKBG4VjJ4AP6vZTEQey6jm
xelsK2ek4vwRfUjs/z9UcZmtj4ipiHP6IqFyydDTLarn1jWHUu2zFnJzryZ6mXdOUPi hCOFG
D+c1KFksZ1VscgDpKygTQcIg/VItmbeFkhOj9IkboOyiVKvvfhujlxmdm9ACt22MjMrB0RAb
9TR1DgXlyofwykKAK+GM8Cu8jcKaJjvfhaMCAwEAAaOB0zCB0D AMBgNVHRMBAf8EAjAAMA4G
A1UdDwEB/wQEAwIF4DA+BglghkgBhvhCAQgEMRYvaHR0cDovL3d3dy50cnV zdGNlbnRlci5k
ZS9ndWlkZWxpbmVzL2luZGV4Lmh0bWwwEQYJYIZIAYb4QgEBBA QDAgWgMF0GCWCGSAGG+EIB
AwRQFk5odHRwczovL3d3dy50cnVzdGNlbnRlci5kZS9jZ2ktYm luL2NoZWNrLXJldi5jZ2kv
OTAxRTAwMDAwMDAyNEU0MkVEMjMxMjA3RjdBNT8wDQYJKoZIhv cNAQEFBQADgYEAObOwuCFG
0HmVvCm8llpJ3qsBqtZgFyUT0wuz8JG6CZjHn5lwvOg+8m8huK rE5oGEQIo9EwLcFLDNVsxB
CiwjX2juU3JQl2Hs2smUyHkOqg+W0COetRp+PcDAk4hk0Mth5A 3bDy3FrzyhbjpYjAZTvnsY
9+QYmJm5cGWBJK9I7kIwggREMIIDraADAgECAg8AkB4AAAACTk LtIxIH96UwDQYJKoZIhvcN
AQEFBQAwgbwxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idX JnMRAwDgYDVQQHEwdIYW1i
dXJnMTowOAYDVQQKEzFUQyBUcnVzdENlbnRlciBmb3IgU2VjdX JpdHkgaW4gRGF0YSBOZXR3
b3JrcyBHbWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbG FzcyAzIENBMSkwJwYJKoZI
hvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw 0wMzAyMTAxNDQyNTBaFw0w
NDAyMTAxNDQyNTBaMIGqMQswCQYDVQQGEwJERTEQMA4GA1UECB MHSGFtYnVyZzEQMA4GA1UE
BxMHSGFtYnVyZzEaMBgGA1UEChMRVEMgVHJ1c3RDZW50ZXIgQU cxFDASBgNVBAsTC0VudHdp
Y2tsdW5nMRowGAYDVQQDExFHb2V0eiBCYWJpbi1FYmVsbDEpMC cGCSqGSIb3DQEJARYaYmFi
aW4tZWJlbGxAdHJ1c3RjZW50ZXIuZGUwggEiMA0GCSqGSIb3DQ EBAQUAA4IBDwAwggEKAoIB
AQCwemnTehAoa6QG0+SldXHkUSAwKBp89oLAaBSNgcCS0vkabi GX3STnqZuHK4N1+i16zCsE
hf5bIRXh61T7S82m4CxshUro7CT9M97u3+FzWAhh5eFG8j5GG6 CD/Rgvw0bbJJztWHyVMv+M
igRuFYyeAD+r2UxEHsuo5sXpbCtnpOL8EX1I7P8/VHGZrY+IqYhz+iKhcsnQ0y2q59Y1h1Lt
sxZyc68mepl3TlD4oQjhRg/nNShZLGdVbHIA6SsoE0HCIP1SLZm3hZITo/SJG6DsolSr734b
o5cZnZvQArdtjIzKwdEQG/U0dQ4F5cqH8MpCgCvhjPArvI3CmiY734WjAgMBAAGjgdMwgdAw
DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBeAwPgYJYIZIAYb4QgEIBDEWL2 h0dHA6Ly93
d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lcy9pbmRleC5odG 1sMBEGCWCGSAGG+EIBAQQE
AwIFoDBdBglghkgBhvhCAQMEUBZOaHR0cHM6Ly93d3cudHJ1c3 RjZW50ZXIuZGUvY2dpLWJp
bi9jaGVjay1yZXYuY2dpLzkwMUUwMDAwMDAwMjRFNDJFRDIzMT IwN0Y3QTU/MA0GCSqGSIb3
DQEBBQUAA4GBADmzsLghRtB5lbwpvJZaSd6rAarWYBclE9MLs/CRugmYx5+ZcLzoPvJvIbiq
xOaBhECKPRMC3BSwzVbMQQosI19o7lNyUJdh7NrJlMh5DqoPlt AjnrUafj3AwJOIZNDLYeQN
2w8txa88oW46WIwGU757GPfkGJiZuXBlgSSvSO5CMYIEdzCCBH MCAQEwgdAwgbwxCzAJBgNV
BAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW 1idXJnMTowOAYDVQQKEzFU
QyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZX R3b3JrcyBHbWJIMSIwIAYD
VQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAzIENBMSkwJwYJKo ZIhvcNAQkBFhpjZXJ0aWZp
Y2F0ZUB0cnVzdGNlbnRlci5kZQIPAJAeAAAAAk5C7SMSB/elMAkGBSsOAwIaBQCgggJ7MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ 8XDTAzMTExMTIwMjU0N1ow
IwYJKoZIhvcNAQkEMRYEFPVQThw0iPyeeiZIPfdvXNIRY01NMF IGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQ MCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHhBgkrBgEEAYI3EAQxgdMwgdAwgbwxCz AJBgNVBAYTAkRFMRAwDgYD
VQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQ QKEzFUQyBUcnVzdENlbnRl
ciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBHbWJIMS IwIAYDVQQLExlUQyBUcnVz
dENlbnRlciBDbGFzcyAzIENBMSkwJwYJKoZIhvcNAQkBFhpjZX J0aWZpY2F0ZUB0cnVzdGNl
bnRlci5kZQIPAJAeAAAAAk5C7SMSB/elMIHjBgsqhkiG9w0BCRACCzGB06CB0DCBvDELMAkG
A1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0 hhbWJ1cmcxOjA4BgNVBAoT
MVRDIFRydXN0Q2VudGVyIGZvciBTZWN1cml0eSBpbiBEYXRhIE 5ldHdvcmtzIEdtYkgxIjAg
BgNVBAsTGVRDIFRydXN0Q2VudGVyIENsYXNzIDMgQ0ExKTAnBg kqhkiG9w0BCQEWGmNlcnRp
ZmljYXRlQHRydXN0Y2VudGVyLmRlAg8AkB4AAAACTkLtIxIH96 UwDQYJKoZIhvcNAQEBBQAE
ggEAbWcYYx2avYsbqs+alli+CLPC9G41rWMI1M/YK+l2LY9pu9CFkZTIRTVRQ1DEecc7tpdi
hXMEaSD4NR6OxrIDiI5kYsIjYIaRY9jifjRHTDl870SCZG+OLf br/hZKGcz4tw2XGQTb0WDq
UDJXAqY3IFJ0hy0J7cwcCT53KKic2bBU1IJs59xtSISz/wwUyYFN9vZpLEGnTBc24x04g2gL
uCIQQ2vxCE2B9DTTPY5fZ2WYNBGSWa/9w1li/BfvGXvZAWW2dXheadZ6/EtLak4Wp6QN7l5I
+hbxUkSlFhb+Fi/k+2Fp/00IwC7q2kGLo8LYxeKQmgy7JddWPJqHl8AiFwAAAAAAAA==
--------------ms000204080601000904010104--