Archive for January, 2008

Ginko Financial Collapse Ultimately Yields Real Virtual Risk (Huh?)

January 15th, 2008 5 comments

I’m feeling old lately.  First it was my visceral reaction to the paranormal super-poking goings-on on Facebook and now it’s this news regarding Linden Lab’s Second Life that has my head spinning. 

It seems that the intersection between the virtual and physical worlds is continuing to inch ever closer.

In fact, it’s hitting people where it really counts, their (virtual) wallets. 

We first saw something like this bubble up with in-world gambling issues and now Linden announced in their blog today that any virtual "in-world banks" must be registered with real-world financial/banking regulatory agencies:

As of January 22, 2008, it will be prohibited to offer interest or
any direct return on an investment (whether in L$ or other currency)
from any object, such as an ATM, located in Second Life, without proof
of an applicable government registration statement or financial
institution charter. We’re implementing this policy after reviewing
Resident complaints, banking activities, and the law, and we’re doing
it to protect our Residents and the integrity of our economy.

Why?  It seems there’s more bad juju brewin’.  A virtual bank shuts down and defaults.  What’s next?  A virtual sub-prime loan scandal?

Since the collapse of Ginko Financial in August 2007, Linden Lab has
received complaints about several in-world “banks” defaulting on their
promises. These banks often promise unusually high rates of L$ return,
reaching 20, 40, or even 60 percent annualized.

Usually, we don’t step in the middle of Resident-to-Resident conduct
– letting Residents decide how to act, live, or play in Second Life.

But these “banks” have brought unique and substantial risks to
Second Life, and we feel it’s our duty to step in. Offering
unsustainably high interest rates, they are in most cases doomed to
collapse – leaving upset “depositors” with nothing to show for their
investments. As these activities grow, they become more likely to lead
to destabilization of the virtual economy. At least as important, the
legal and regulatory framework of these non-chartered, unregistered
banks is unclear, i.e., what their duties are when they offer
“interest” or “investments.”

There is no workable alternative. The so-called banks are not
operated, overseen or insured by Linden Lab, nor can we predict which
will fail or when. And Linden Lab isn’t, and can’t start acting as, a
banking regulator.

Some may argue that Residents who deposit L$ with these “banks” must
know they’re assuming a big risk – the high interest rates promised
aren’t guaranteed, and the banks aren’t overseen by Linden Lab or
anyone else. That may be true. But for all of the other reasons we’ve
set out above, we can’t let this activity continue.

Thus, as we did in the past with gambling, as of January 22, 2008 we will begin removing
any virtual ATMs or other objects that facilitate the operation or
facilitation of in-world “banking,” i.e., the offering of interest or a
rate of return on L$ invested or deposited. We ask that between now and
then, those who operate these “banks” settle up on any promises they
have made to other Residents and, of course, honor valid withdrawals.
After that date, we may sanction those who continue to offer these
services with suspension, termination of accounts, and loss of land.

Wow.  Loss of land!  I thought overdraft fees were harsh!?

Ed Felten from Freedom to Tinker summed it up nicely:

This was inevitable, given the ever-growing connections between the
virtual economy of Second Life and the real-world economy. In-world
Linden Dollars are exchangeable for real-world dollars, so financial
crime in Second Life can make you rich in the real world. Linden
doesn’t have the processes in place to license “banks” or investigate
problems. Nor does it have the enforcement muscle to put bad guys in

Expect this trend to continue. As virtual world “games” are played for
higher and higher stakes, the regulatory power of national governments
will look more and more necessary.

So far I’ve stayed away from Second Life; I’ve got enough to manage in my First one.  Perhaps it’s time to take a peek and see what all the fuss is about?


On Patch Tuesdays for Virtualization Platforms…

January 14th, 2008 2 comments

In December I made note of an interesting post on the blog titled "Patch Tuesday for VMware."  This issue popped up today in conversation with a customer and I thought to bubble it back up for discussion.

The post focused on some work done by Ronald Oglesby and Dan Pianfetti from GlassHouse
Technologies regarding the volume, frequency and distribution of patches across VMware’s ESX platform. 

When you combine Ronald and Dan’s data with Kris Lamb’s from ISS that I wrote about a few months ago, it’s quite interesting.

The assertion that Ronald/Dan are making in their post is that platforms like VMware’s ESX have to date required just as much care and feeding from a patching/vulnerability management perspective as a common operating system such as a Windows Server:

So why make this chart and look at the time between patches? Let’s take a hypothetical
server built on July 2nd of 2007, 5 months ago almost exactly. Since
being built on that day and put into production that server would have
been put into maintenance mode and patched/updated eight times. That’s
right eight (8) times in 5 months. How did this happen? Let’s look at
the following timeline:

Maybe it’s time to slow down and look at this as a QA issue? Maybe it’s
time to stop thinking about these platforms as rock solid, few moving
parts systems? Maybe it’s better for us not to draw attention to it,
and instead let it play out and the markets decide whether all this
patching is a good thing or not. Obviously patching is a necessary
evil, and maybe because we are so used to it in the Windows world, we
have ignored this so far. But a patch every 18.75 days for our
"hypothetical" server is a bit much, don’t you think?

I think this may come as a shock to some who have long held the belief that bare-metal, Type 1 virtualization platforms require little or no patching and that because of this, the "security" and availability of virtualized hosts was greater than that of their non-virtualized counterparts.

The reality of the situation and the effort and potential downtime (despite tools that help) have led to unexpected service level deviance, hidden costs and latent insecurity in deployed virtualized environments.  I think Ronald/Dan said it best:

If a client is buying into the idea of server virtualization as a piece
of infrastructure (like a SAN or a switch) only to see the types of
patching we see in Windows, they are going to get smacked in the face
with the reality that these are SERVERS. The reality that the vendors
are sticking so much into the OS that patches are going to happen just
as often as with Windows Servers? Or, if the client believes the
stability/rock solidness and skips a majority of general
patches, they wind up with goofy time issues or other problems with iSCSI, until they catch up.

As a counterpoint to this argument I had hoped to convince Kris Lamb to extend his patch analysis of VMware’s releases and see if he could tell how many patched vulnerabilities existed in the service console (the big ol’ fat Linux OS globbed onto the side of ESX) versus the actual VMM implementation itself.  For some reason, he’s busy with his day job. 😉 This is really an important data point.  I guess I’ll have to do that myself ;(

The reason why this is important is exactly the reason that you’re seeing VMware and other industry virtualization players moving to embedded hypervisors; skinnying down the VMM’s to yield less code, less attack surface and hopefully less vulnerabilities.  So, to be fair, the evolution of the virtualization platforms is really on-par with what one ought to expect with a technology that’s still fairly nascent.

In fact, that’s exactly Nand Mulchandani, VMware’s Sr. Director of Security Product Management & Marketing in response to Ronald/Dan’s post:

the article points out, "patching is a necessary evil" – and that the
existence of ESX patches should not come as a shock to anyone. So let’s
talk about the sinister plan behind the increase in ESX patches.
Fortunately, the answer is in the article itself. Our patches contain a
lot of different things, from hardware compatibility updates, feature
enhancements, security fixes, etc.

also want customers to view ESX as an appliance – or more accurately,
as a product that has appliance-like characteristics.

of appliances, another thing to consider is that we are now offering
ESX in a number of different form-factors, including the brand new ESX Server 3i.
3i will have a significantly different patch characteristics – it does
not have a Console OS and has a different patching mechanism than ESX
that will be very attractive to customers.

I see this as a reasonable and rational response to the issue, but it does point out that whether you use VMware or any other vendor’s virtualization platform, you should make sure to recognize that patching and vulnerability management of the underlying virtualization platforms is another — if not really critical — issue that will require operational attention and potential cost allocation.


P.S. Mike D. does a great job of stacking up other vendors against Microsoft in this vein such as Microsoft, Virtual Iron, and SWSoft.

BeanSec! Wednesday, January 16, 2008 – 6PM to ?

January 14th, 2008 No comments


Yo!  BeanSec! is once again upon us.  Wednesday, January 16th, 2008.

BeanSec! is an informal meetup of information security
professionals, researchers and academics in the Greater Boston area
that meets the third Wednesday of each month. 

I say again, BeanSec! is hosted the third Wednesday of every month.  Add it to your calendar.

Come get your grub on.  Lots of good people show up.  Really.

Unlike other meetings, you will not be expected to pay dues, “join
up”, present a zero-day exploit, or defend your dissertation to attend.
Map to the Enormous Room in Cambridge.

Enormous Room: 567 Mass Ave, Cambridge 02139.  Look for the Elephant
on the left door next to the Central Kitchen entrance.  Come upstairs.
We sit on the left hand side…

Don’t worry about being "late" because most people just show up when
they can.  6:30 is a good time to aim for.  We’ll try and save you a
seat.  There is a parking garage across the street and 1 block down or
you can try the streets (or take the T)

In case you’re wondering, we’re getting about 30-40 people on
average per BeanSec!  Weld, 0Day and I have been at this for just over
a year and without actually *doing* anything, it’s turned out swell.

We’ve had some really interesting people of note attend lately (I’m
not going to tell you who…you’ll just have to come and find out.)  At
around 9:00pm or so, the DJ shows up…as do the rather nice looking
people from the Cambridge area, so if that’s your scene, you can geek
out first and then get your thang on.

The food selection is basically high-end finger-food appetizers and
the drinks are really good; an attentive staff and eclectic clientèle
make the joint fun for people watching.  I’ll generally annoy you into
participating somehow, even if it’s just fetching napkins. 😉

See you there.


Categories: BeanSec! Tags:

Kid’s Software & The Evolution of SaaS

January 13th, 2008 7 comments

Something interesting just occurred to me as my (now) four year old and a couple of her friends were huddled around one of the computers in my office playing a Dragon Tales coloring game while my seven and eleven year old were in their respective rooms playing with the virtual pets in their virtual worlds of Webkinz.

Why is the fact that my kids are huddled around their Mac Mini’s on a cold day playing computer games in any way remarkable?  Because all of them were playing games which are hosted and presented via the Internet; no software except a browser required on this end.


Well, the really interesting thing was that my wife reminded me that we haven’t purchased ANY children’s software titles in the last two years because all of the games, learning applications and reference materials are all on-line.  Software as a, well, service.  And mostly free to boot!  The same usually can’t be said in the, um, "adult" realm.

This sounds like the kiddy version of GoogleApps.  How long until you don’t even have to buy a DVD for your XBox, PS3 or Wii…as high speed feeds continue to rise, it’s not that large of a stretch…

I think it’s a very interesting perspective on the more "mainstream" adoption of SaaS and a rather interesting way of monetizing it.  In the case of Webkinz, while the virtual world — replete with currency, domiciles, and social services — is free, one has to purchase a physical doll which has attached to it a "secret code" that one uses to register your pet in Webkinz World.  You then give it a name and choose a sex and start building rooms.

It’s basically second life for kids — without the job fairs (yet.)  My wife has now informed me that she’s going to get her own doll to play with the kids online.  I wonder if we’ll actually ever speak to one another in person any more!? 

Scratch that, she’s at this moment registering a bulldog named Waldo.

I’m hoping they start making 5’11 blonde Swedish nurse Webkinz soon…

…which reminds me, given the fact that since all this kid’s software is now on-line, how long until someone compromises it for unseemly reasons?   An interesting attack vector, no doubt.  I think I’ll call it SaaD – Software as a Disservice?


Categories: Software as a Service (SaaS) Tags:

Horrific Facebook Breach!

January 11th, 2008 5 comments

I don’t know what’s happening behind the scenes at Facebook.  Perhaps it’s the manifest evils of Beacon victimizing humanity coming back to haunt them, but there’s been a horrific breach over at Facebook.

I just don’t feel safe there any longer.

I joined FB as a number of groups to which I belong and enjoy monitoring decided to leverage the mass pandemonium that is social netgawking and make their information available only on this populist portal.

So I log on today, fully expecting to check my hatching eggs, play a round of scrabulous and explain to yet another aging filipino male "philanthropist" that I’m really not a 16 year old Catholic school girl trolling for a good time when I discovered the harrowing news:

I’d been SuperPoked!

That’s right. 

I was eFingered right after being attacked with a drive-by Vampire tea bagging knee-bar and an inverted trout slap…and some "friend" decided to curse me with a Thunder Pinch and send me a Pink Sock as a gift.

Seriously, what the hell!  When did we start talking like this?  I just mastered Snoop Dogg’s schizzle, yo!  I can’t keep up.

Most of the people that I am FB "friends" with are 30+ years old.  What possible reason would any self-respecting "old person" have for superpoking, trout-slapping or thunder-pinching me?  I’ve tried talking my wife into this stuff and it doesn’t work unless I liquor her up.  How do you think this is going to work on me?


If you can’t figure out how to revert to good old-fashioned email or IM, and speak ‘murican, I don’t want to talk to you.

No more hatching Jack-a-lopes.  No more Roman Candles.  No more Romanian Turtle Wedgies.

Screw this Web2.0 crap.

I’m going to play bowling on my Wii now.


Categories: Security Breaches Tags:

How To Say “Whoops! We Need To Rethink Our Train System’s Control Plane” In Polish…

January 11th, 2008 4 comments

TrainwreckMy dear friend Murray (sorry if that expression of warmth comes as a surprise, Murr…) sent me this story from the Register:

Polish teen derails tram after hacking train network

A Polish teenager allegedly turned the tram system in the city of
Lodz into his own personal train set, triggering chaos and derailing
four vehicles in the process. Twelve people were injured in one of the

The 14-year-old modified a TV remote control so that it could be used to change track points, The Telegraph
reports. Local police said the youngster trespassed in tram depots to
gather information needed to build the device. The teenager told police
that he modified track setting for a prank.

"He studied the trams and the tracks for a long time and then built
a device that looked like a TV remote control and used it to manoeuvre
the trams and the tracks," said Miroslaw Micor, a spokesman for Lodz

"He had converted the television control into a device capable of
controlling all the junctions on the line and wrote in the pages of a
school exercise book where the best junctions were to move trams around
and what signals to change.

"He treated it like any other schoolboy might a giant train set, but
it was lucky nobody was killed. Four trams were derailed, and others
had to make emergency stops that left passengers hurt. He clearly did
not think about the consequences of his actions," Micor added.

Transport command and control systems are commonly designed by
engineers with little exposure or knowledge about security using
commodity electronics and a little native wit. The apparent ease with
which Lodz’s tram network was hacked, even by these low standards, is
still a bit of an eye opener.

Problems with the signalling system on Lodz’s tram network became
apparent on Tuesday when a driver attempting to steer his vehicle to
the right was involuntarily taken to the left. As a result the rear
wagon of the train jumped the rails and collided with another passing
tram. Transport staff immediately suspected outside interference.

The youth, described by his teachers as an electronics buff and
exemplary student, faces charges at a special juvenile court of
endangering public safety. ®

Yes, yes.  I know, it’s not a SCADA system…as fun as that would be to bring up again, I don’t need any death threats, so I won’t mention it…directly.  But if you read about the recent security design debacle of the Boeing 787 Dreamliner and then look at this, it doesn’t take much of a logic jump to see why we should be worried about how command/control systems are implemented.

My next piece of chicanery is to steal one of Mogull’s Wii Guitar Hero controllers, hack it, and cause it to electrocute his cat every time he hits C# on Stairway to Heaven…


Categories: Hacking, Security Breaches Tags:

Thin Clients: Does This Laptop Make My Ass(ets) Look Fat?

January 10th, 2008 11 comments

Juicy Fat Assets, Ripe For the Picking…

So here’s an interesting spin on de/re-perimeterization…if people think we cannot achieve and cannot afford to wait for secure operating systems, secure protocols and self-defending information-centric environments but need to "secure" their environments today, I have a simple question supported by a simple equation for illustration:

For the majority of mobile and internal users in a typical corporation who use the basic set of applications:

  1. Assume a company that:
    …fits within the 90% of those who still have data centers, isn’t completely outsourced/off-shored for IT and supports a remote workforce that uses Microsoft OS and the usual suspect applications and doesn’t plan on utilizing distributed grid computing and widespread third-party SaaS
  2. Take the following:
    Data Breaches.  Lost Laptops.  Non-sanitized corporate hard drives on eBay.  Malware.  Non-compliant asset configurations.  Patching woes.  Hardware failures.  Device Failure.  Remote Backup issues.  Endpoint Security Software Sprawl.  Skyrocketing security/compliance costs.  Lost Customer Confidence.  Fines.  Lost Revenue.  Reduced budget.
  3. Combine With:
    Cheap Bandwidth.  Lots of types of bandwidth/access modalities.  Centralized Applications and Data. Any Web-enabled Computing Platform.  SSL VPN.  Virtualization.  Centralized Encryption at Rest.  IAM.  DLP/CMP.  Lots of choices to provide thin-client/streaming desktop capability.  Offline-capable Web Apps.
  4. Shake Well, Re-allocate Funding, Streamline Operations and "Security"…
  5. You Get:
    Less Risk.  Less Cost.  Better Control Over Data.  More "Secure" Operations.  Better Resilience.  Assurance of Information.  Simplified Operations. Easier Backup.  One Version of the Truth (data.)

I really just don’t get why we continue to deploy and are forced to support remote platforms we can’t protect, allow our data to inhabit islands we can’t control and at the same time admit the inevitability of disaster while continuing to spend our money on solutions that can’t possibly solve the problems.

If we’re going to be information centric, we should take the first rational and reasonable steps toward doing so. Until the operating systems are more secure, the data can self-describe and cause the compute and network stacks to "self-defend," why do we continue to focus on the endpoint which is a waste of time.

If we can isolate and reduce the number of avenues of access to data and leverage dumb presentation platforms to do it, why aren’t we?

…I mean besides the fact that an entire industry has been leeching off this mess for decades…

I’ll Gladly Pay You Tuesday For A Secure Solution Today…

The technology exists TODAY to centralize the bulk of our most important assets and allow our workforce to accomplish their goals and the business to function just as well (perhaps better) without the need for data to actually "leave" the data centers in whose security we have already invested so much money.

Many people are doing that with the servers already with the adoption of virtualization.  Now they need to do with their clients.

The only reason we’re now going absolutely stupid and spending money on securing endpoints in their current state is because we’re CAUSING (not just allowing) data to leave our enclaves.  In fact with all this blabla2.0 hype, we’ve convinced ourselves we must.

Hogwash.  I’ve posted on the consumerization of IT where companies are allowing their employees to use their own compute platforms.  How do you think many of them do this?

Relax, Dude…Keep Your Firewalls…

In the case of centralized computing and streamed desktops to dumb/thin clients, the "perimeter" still includes our data centers and security castles/moats, but also encapsulates a streamed, virtualized, encrypted, and authenticated thin-client session bubble.  Instead of worrying about the endpoint, it’s nothing more than a flickering display with a keyboard/mouse.

Let your kid use Limewire.  Let Uncle Bob surf pr0n.  Let wifey download spyware.  If my data and applications don’t live on the machine and all the clicks/mouseys are just screen updates, what do I care?

Yup, you can still use a screen scraper or a camera phone to use data inappropriately, but this is where balancing risk comes into play.  Let’s keep the discussion within the 80% of reasonable factored arguments.  We’ll never eliminate 100% and we don’t have to in order to be successful.

Sure, there are exceptions and corner cases where data *does* need to leave our embrace, but we can eliminate an entire class of problem if we take advantage of what we have today and stop this endpoint madness.

This goes for internal corporate users who are chained to their desks and not just mobile users.

What’s preventing you from doing this today?


Are Virtualization Laws That Are Immutable, Disputable?

January 8th, 2008 3 comments

A few months ago, Pete Lindstrom shot me over the draft of a Burton paper on virtualization security.  We sputtered back and forth at one another, I called him names, and then we had beer later.

The title of the paper was the "Five Immutable Laws of Virtualization Security."

I must admit, I reacted to what he sent me in a combinational fit of puzzlement and apathy.   I really couldn’t put my finger on why.  Was it the "not invented here syndrome?"  I didn’t think so.  So what was it that made me react the way I did?

I think that over time I’ve come to the conclusion that to me, these aren’t so much "immutable laws" but more so derivative abstractions of common sense that left me wondering what all the fuss was about.

Pete posted the five laws on his blog today.  A more detailed set of explanations can be found on the Burton blog here

I dare you to read through these without having to re-read each of them multiple times and then re-read them in cascading sequence since (hint) they are recursive:

Law 1: Attacks against the OS and applications of a physical system
have the exact same damage potential against a duplicate virtual system.

Law 2: A VM has higher risk than its counterpart physical system
that is running the exact same OS and applications and is configured

Law 3: VMs can be more secure than related physical systems
providing the same functional service to an organization when they
separate functionality and content that are combined on a physical

Law 4: A set of VMs aggregated on the same physical system can only
be made more secure than its physical, separate counterparts by
modifying the configurations of the VMs to offset the increased risk
introduced by the hypervisor.

Law 5: A system containing a “trusted” VM on an “untrusted” host has
a higher risk level than a system containing a “trusted” host with an
“untrusted” VM.

Ultimately, I’d suggest that for the most part, these "observations" are correct, if not oversimplified in a couple of spots.  But again, I’m left with the overall reaction of "so what?" 

Pete even mentions the various reactions he’s been getting:

I have been getting interesting reactions to these. Some say they
are wrong. Some say they are common sense. Some just don’t like the
word "immutable." I think they serve to clarify some of the confusion
that comes up when discussing virtualization by applying fairly
straightforward risk management principles.

I want to believe that somehow these "laws" will enable some sort sort of actionable epiphany that will magically allow me to make my virtualized systems more secure, but I’m left scratching my head regarding who the audience for this was?

I don’t think it clarifies any "confusion" regarding risk and virtualization and I’m puzzled that Burton suggests that these "laws" will enlighten anyone and dispel any confusion relating to whether or not deploying virtualization is more or less risky than not deploying virtualization:

In reality, we can apply traditional security practices to
virtualization to determine whether risk increases or decreases with
new virtualization architectures. It shouldn’t be surprising that the
increase or decrease in risk is predicated on the current architecture.
Here are five laws to live by when evaluating your virtualization

When combining the standard risk principles with an understanding of
the use cases of virtualization, a set of immutable laws can be derived
to assist in securing virtual environments

So, I’m with the "common sense" crowd since most of these "laws" have been discussed — and some practical advice to go along with them — for quite some time before the "Burton Tablets" came down from the mountain.

So I don’t disagree, but I’m reminded of a couple of good lines from a bad movie wherein the nasty knight says to the good knight "you’ve been weighed, measured and found wanting…"

So, there we are.  My $0.02.  I think I’ll add a slide or two about this at the virtualization forum next month…


Categories: Virtualization Tags:

Complimentary Admission to the InfoWord Virtualization Executive Forum, February 4th, San Francisco…

January 8th, 2008 3 comments


If any of my readers are interested in attending the InfoWorld Virtualization Executive Forum in San Francisco on February 4th, 2008, I have complimentary passes available (a $795 value)

You might remember that when InfoWorld first ran this forum in New York, I was grumpy because there were no topics/speakers focused on security.  I contacted them and expressed my concern.  Alan Shimel doubted anything would come of my kvetching, but lo and behold, the organizers invited me to come and present at this show in February.

So, if you believe in something strongly enough, good things *do* happen 😉

I am speaking (the last speaker of the day — all that stands between the audience and beer…is me!) so come on down and heckle me:

  Addressing Security Concerns in Virtual Environments

to create and easy to move, introducing a new software layer between
hardware and operating system, and operating over virtual networks as
well as physical ones, virtual servers present a new order of security
risks and challenges. This session will explore the impact of
virtualization on network and host security, how security solutions
providers are beginning to address them, and the best practices that
are emerging for securing virtual environments.

If you’re interested in attending free of charge, ping me via email and I’ll give you the details in order to register.

Hope to see you there!


{Edited for proper Yiddish…Thanks, Alan!}

Categories: Virtualization Tags:

Grab the Popcorn: It’s the First 2008 “Ethical Security Marketing” (Oxymoron) Dust-Up…

January 5th, 2008 15 comments

Robert Hansen (RSnake / / SecTheory) created a little challenge (pun intended) a couple of days ago titled "The Diminutive XSS worm replication contest":

The diminutive XSS worm replication contest
is a week long contest to get some good samples of the smallest amount
of code necessary for XSS worm propagation. I’m not interested in
payloads for this contest, but rather, the actual methods of
propagation themselves. We’ve seen the live worm code
and all of it is muddied by obfuscation, individual site issues, and
the payload itself. I’d rather think cleanly about the most efficient
method for propagation where every character matters.

Kurt Wismer (anti-virus rants blog) thinks this is a lousy idea:

yes, folks… robert hansen (aka rsnake), the founder and ceo of
sectheory, felt it would be a good idea to hold a contest to see who
could create the smallest xss worm
ok, so there’s no money changing hands this time, but that doesn’t mean
the winner isn’t getting rewarded – there are absolutely rewards to be
had for the winner of a contest like this and that’s a big problem
because lots of people want rewards and this kind of contest will make
people think about and create xss worms when they wouldn’t have

Here’s where Kurt diverges from simply highlighting nominal arguments of the potential for
misuse of the contest derivatives.  He suggests that RSnake is being
unethical and is encouraging this contest not for academic purposes, but rather to reap personal gain from it:

would you trust your security to a person who makes or made malware?
how about a person or company that intentionally motivates others to do
so? why do you suppose the anti-virus industry works so hard to fight
the conspiracy theories that suggest they are the cause of the viruses?
at the very least mr. hansen is playing fast and loose with the publics
trust and ultimately harming security in the process, but there’s a
more insidious angle too…

while the worms he’s soliciting from others are supposed to be merely
proof of concept, the fact of the matter is that proof of concept worms
can still cause problems (the recent orkut worm
was a proof of concept)… moreover, although the winner of the contest
doesn’t get any money, at the end of the day there will almost
certainly be a windfall for mr. hansen – after all, what do you suppose
happens when you’re one of the few experts on some relatively obscure
type of threat and that threat is artificially made more popular? well,
demand for your services goes up of course… this is precisely the
type of shady marketing model i described before
where the people who stand to gain the most out of a problem becoming
worse directly contribute to that problem becoming worse… it made
greg hoglund and jamie butler household names in security circles, and
it made john mcafee (pariah though he may be) a millionaire…

I think the following exchange in the comments section of the contest forum offers an interesting position from RSnake’s perspective:                   

Re: Diminutive XSS Worm Replication Contest


Posted by: Gareth Heyes (IP Logged)


Date: January 04, 2008 04:56PM



This contest is just asking for trouble 🙂

Are there any legal issues for creating such a worm in the uk?



Re: Diminutive XSS Worm Replication Contest



Posted by: rsnake (IP Logged)


Date: January 04, 2008 05:11PM


@Gareth Heyes – perhaps, but trouble is my middle name. So is danger.
Actually I have like 40 middle names it turns out. 😉 No, I’m not
worried, this is academic – it won’t work anywhere without modification
of variables, and has no payload. The goal is to understand worm
propagation and get to the underlying important pieces of code.

I’m not in the UK and am not a lawyer so I can’t comment on the
laws. I’m not suggesting anyone should try to weaponize the code (they
could already do that with the existing worm code if they wanted anyway).

So, we’ve got Wismer’s perspective and (indirectly) RSnake’s. 

What’s yours?  Do you think holding a contest to build a POC for a worm a good idea?  Do the benefits of research and understanding the potential attacks so one can defend against them outweigh the potential for malicious use?  Do you think there are, or will be, legal ramifications from these sorts of activities?