HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Jikto in the wild

It appears that the source code to Jikto is in the wild. I suppose it was only a matter of time, even though as you will see SPI to extreme steps to prevent this from happening.

As my Shmoocon presentation slides discuss, Jikto bypasses the "Same Origin Policy" by using a proxy website like the-cloak, proxydrop, Google Translate, etc. This allows Jikto's code and the content of 3rd party sites to be loaded into the same security domain (ie the proxy sites), and thus read the responses. I believe pdp of GNUCITIZEN first discussed this and I based much of Jikto off his work. The consequence of this means that Jikto's code had to exist somewhere on the public Internet when I did my demo. Worse, when I got to Shmoo I saw that I didn't have a hard connection to the Internet, only wireless. This means anyone in the audience sniffing traffic would see where Jikto was and get a copy. Obviously I couldn't let that happen.

Instead I VPNed into SPI. This created an encrypted tunnel. I then remotely connected to my Desktop machine at work and did the demo from there. This means no one in the audience could sniff traffic and see where Jikto was stored. The problem is if someone watched very closely they could see the URL of where Jikto's code was. I ran all my traffic on the work machine through a proxy to show all the requests Jikto was making. The first request would have been to grab Jikto's code. Someone could have seen the URL and grabbed it.

Which is exactly what happened! A guy named LogicX grabbed a copy this way and posted it on Digg just a day after Shmoocon. However I contacted LogicX and asked him to take it down. I'm thankful he did. However, it seems someone else grabbed either his copy before it was removed or grabbed the code themselves at Shmoocon just like LogicX did.

The long and short of all of this is Jikto's code is in the wild. Regardless what you might have heard, SPI didn't leak it. Even LogicX admitted he snatched it because he got lucky. I suppose it was only a matter of time.

Labels: Jikto| Shmoocon| XSS Ajax

XSS+Ajax worm attacking Yahoo mail users

At the beginning of the week, Yahoo was attacked by a worm that propagates
using nothing but JavaScript and Ajax.
I've been giving interviews to the press all day and talked with the FBI about the
worm, so let me take a moment to fill you all in.


Cross Site Scripting (XSS) is a really big problem that most
people don’t take seriously enough. In the past XSS was mainly used for cookie
theft, session hijacking, petty vandalism, or to just be annoying. But Ajax, with its ability to
make HTTP connection from JavaScript without user intervention makes XSS much
more dangerous. SPI has been in the forefront in researching the dangers of
spoke at the Toorcon security conference in September 2005 about the
dangers of this blended threat (see slides here) The MySpace worm, also
known as
the Samy worm of October 2005 was the first public use of XSS and Ajax.

Here is how the worm works:

A victim opens an email message inside of Yahoo’s web-based
email system. This email message contains an HTML IMG tag. This IMG tag
contains an onload attribute which
contains JavaScript that will execute when the image has finished loading. This
JavaScript does several things:

  • Uses
    XmlHttpRequest to fetch the victim’s address book

  • Scraps
    out all email addresses in the address book for yahoo.com addresses.

  • Uses
    XmlHttpRequest  to grab a “crumb”
    which is a token required to send email

  • Uses
    XmlHttpRequest to send a email infected with the worm to everyone in the
    victim’s addressbook who has a yahoo.com email address

  • Sends the
    harvested email addresses to a 3rd party,
    presumably for spamming purposes.

How did this happen? Well, Yahoo failed to perform proper input validation.They didn’t strip out all the different HTML attributes that allows
script to execute.

Since Yahoo has fixed the problem, I've
attached the source code for the worm to this post. It's quite a
learning experience to examine for yourselves. You can see it is quite small
and uses only 3 Ajax calls to send infected email to everyone in your
address book.

Update: The virus scanner running on out server keeps deleting the virus. I have encoded the virus with ROT13 to prevent the virus scanner from flagging it. You will need to use a site like this to decode the source code and read the virus.

Labels: worm| XSS Ajax
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.