Yes, it can be stopped

I tried to post this on the official blog, but it was moderated and removed.

I agree 100% with LL long term, but I believe they are making a huge mistake short term.

People saying that this cannot be stopped are only partially correct. This is simply a packet injection attack, made trivially easy thanks to an open text protocol and a trusted client. This kind of stuff has existed since the time of the telegraph and the solution is simply to encrypt the channel and authenticate the peers. Doing so will render all the existing bots unusable and creating new ones not worth the trouble. Sure, textures will still be ripped, but only through the manual process that has always existed. They can minimize the performance impact by using a key length only strong enough to make it economically impractical to hack it.

In the long term, LL is completely correct on going the open source route. They know they’ll become irrelevant if they don’t. However, open source doesn’t mean unsecured or free-for-all and it is imperative that they maintain the incentives for content creation. If LL could solve this problem in a generic way, they would be worth orders of magnitude more as a DRM company than a virtual world. But they don’t need to, they control where the content it’s used.

What they need to do is to publish an open source API and to establish a certification process so that only certified applications are allowed to connect to the grid. And I believe this is exactly where there are going. Their goal should be to become the certification authority and central bank, leaving all the development to the open source community.

All in all, this is just a necessary step to what will become the metaverse.

DON’T PANIC

Thank you for posting this, it's exactly what was on my mind.

Can we ever be 100% free of this sort of thing? No.

Can we make it a hell of a lot harder, to the point of barely being worth the trouble? Of course. This is basic MMO technology, here, the kind that has been in place since the forefather of massive online gaming, Ultima Online, and seen in every other MMO in existence just about.

Client Authentication is nothing new. It is a cornerstone of client/server networking. Coupled with aggressive persecution of violators (which we won't see, of course, given Blue's position on this whole fiasco) this could be very easily curbed.

My solution in the meantime? Lock out any account without payment information on file out of your parcel. If people are willing to risk their real accounts, I'm willing to risk my rights as a content developer. I suggest everyone else follow suit. If Linden Labs won't remove free unverified accounts, take action as a community and block them yourself. If enough people follow suit we can create a relative safezone.

Thanks for posting this! It's hard to tell people this type of thing.

They think "OMG, world over, and we can't stop it" and trying to explain to them these exact two posts, they are always saying LL can't do that!

I'm glad someone else sees it the same way I do.

Well, there are two basic problems - first, the overwhelming majority of citizens uses unpaid accounts, so there goes basically all your traffic if you block those people. Further, because of the sheer number of landowners, most of whom aren't interested in this point-singularity exploits, you're unlikely to get any kind of a grass-roots movement going.

And secondly, certification schemes never work - look what happened to Microsoft and Verisign with their ActiveX controls. It was no barrier at all to the creation of malicious software interfacing with Internet Explorer.

Encrypting the stream will work, but only until that encryption is discovered, analyzed and duplicated. Given that the stream would have to be encrypted going in both directions, this places additional load on the data streams - possibly enough to render SL unusable on some systems where it was previously functioning. This is turn would remove access for thousands upon thousands of users.

There just isn't a practical solution for this that wouldn't result in a software arms race, so to speak, with Linden Labs perpetually making fixes to protect against yet another version of CopyBot.

Even the use of the CopyBot Removers is considered by the Lindens to be a breach of the ToS, because it has to spam every avatar in sensor range in order to work. So this is a real quagmyre.

You would only need a brief encypted handshake upon connection of the client to the Second Life servers to verify that it IS infact the real Second Life client trying to connect, and not a bot of some sort.

From there, you change the encyption check with each patch to keep yourself ahead of hackers. It's far, far from perfect, but it creates enough of a hinderance that the amount of people using this sort of thing (the real problem) would drop drastically. The rest can be culled via the good old fashioned community vigilance and the banhammer.

The problem would still exist. Blue Linden was VERY right when he said that this sort of thing can never be stopped -- He simply failed to acknowledge that it can be controlled and kept down to a level that is human-managable.

Yes, it means the Linden Labs development team would have to actually do scheduled, fervent work and keep alert. This is what we in the real world call a job.

All you'd have to do is make a packet sniffer which reads that handshake transaction and replicates it for the CopyBot to use. Once the algorithm was determined, it would be trivial to alter the CopyBot within hours each new release - perhaps even to automate its self-correction process. Encrypted handshaking could be done, but it's mostly futile. In the history of computing, there has never been a copy protection scheme of any kind which turned out not to be quickly circumvented, nor any that have been worth the effort of doing in the long run.

The problem with ActiveX is that end-users are given the option of trusting unsigned controls and accepting certificates not issued by a trusted authority. This wouldn't be the case here.

The is no need to implement encryption by obfuscation, a well know algorithm such as RSA or DSA which only can be broken by brute force should be used. The point is to make it strong enough to make it not practical. Note that the point is not to prevent reverse-engineering, but man in the middle attacks.

Agree about the performance impact, but that can be minimized. You could use an encrypted channel for sensitive operations and an open channel for non-sensitive operations.

There’s no need to reinvent the wheel. This problem has been solved many times. Just look at SSL and SSH.

The strength depends on the length of the key. Sure, anything can be broken, but the computing power required quickly becomes cost prohibitive. Seriously, anybody hacking 128-bit keys or longer is living in some foreign country with no extradition treaties hacking financial transactions and not trying to steal prim skirts.

Actually, the problem with ActiveX was that the people giving out the certificates weren't up to the task.

There was an ActiveX control called "Internet Exploder". All it did was shut down the browser - it was a proof of concept to show how dangerous ActiveX could be. When Microsoft responded by making it so that you could elect not to run unsigned ActiveX controls, the fellow who wrote Internet Exploder responded by getting Verisign to certify it, which they did!

All it does is add a layer, create another hoop to jump through. It is not a deterrent.

Regarding encryption, considering that LibSecondLife is being used by LL as a resource for the enhancement of their own product, it is unlikely that they would cut themselves off from that resource by making it incompatible with their servers. If encryption is used, it's not outside the realm of possibility that they may even assist the people working on LibSecondLife to implement that encryption! Linden Labs' support, aid and participation in LibSecondLife has been substantial to date, and there's no reason to expect that to suddenly cease.

Man in the middle attacks would surely become much less of a problem, and I'm sure it's something they think about, but CopyBot doesn't fall into this category in any case. It does not use a packet injection attack - it is a standalone client! It has no graphical interface, but it's not a man-in-the-middle attack at all.

So in reply to the person who started this thread, no, I don't think there is any practical way of stopping it directly. LibSecondLife is an open source API, and certification will do little or nothing to stop people from using it to accomplish all sorts of interesting, clever, and sometimes questionable things.

There's only one flaw in your plan.

Sadly, it is a CRITICAL one, which invalidates its usefulness COMPLETELY:

The client is completely under the control and access of the user. Thus, any keys, protocols, cryptographic algorithms, methods, processes, whatever are a simple disassembly away from being discovered, translated, and replicated into a "bot" client.

Until you can secure the CLIENT code from the users (TCPA/DRM), ANYthing you do will ultimately FAIL to succeed in is purpose to thwart infringement.

LL has already said (and rightfully so) that they don't intend to enter into an expensive and fruitless "arms race" with their clients. Rather, focusing instead on EMPOWERING the residents to police and handle it ourselves.

A MUCH better solution than ANY technological one which offers little more than a minor speedbump to those who wish to infringe.

Yes, but that doesn't stop Apple or Microsoft from doing it... because they know they have a responsibility to their customers to try their best to secure the data transferred from their servers. Imagine if iTunes said to record companies, "We can't stop it, so we might as well give up changing our client authentication process and open up the protocol." The record companies might at first sue them, then remove all their products from Apple servers.

As much as the libSL people like to say "We can break it"... you all know LL could make it a complete pain in the ass if they didn't tell anyone about protocol changes and changed an authentication process every release. libSLers deserve that after the hysteria they've caused the SL community (first giant prims, then God-Mode, now CopyBot).

I see SL as a world with an economy similar to iTunes where buyers and sellers are connected to provide paid-for-products and services. If Second Life can't enforce their DRM, and won't even try to stay ahead of the crackers, then they shouldn't advertise SL as a perfect place to start a business.

Either try your best to make it secure, or don't try at all, and get rid of permissions completely. Don't throw your hands up in the air and say this was inevitable. I would have been fired immediately from my .NET Developer job if that's how I handled security.

While I see and agree with the logic in your points about the client and the futililty of a tech solution, I am interested in how you think the community can address this when a person can enter made up info on the account registration page and make as many alts as the day is long?

In my mind, rampant anonimity makes resident driven solutions just as futile as tech solutions. This is why I lean towards LL legitimising libSL by either partnering with them as a real company, or hiring some number of them to work at LL. In either case, NDAs would be in effect. Then I would urge that a clear policy be drafted and released which states that groups of residents (especially those open to just anyone) are not allowed to reverse engineer. Open groups like this are great if one is given to utopian daydreams, but in reality, it's a security nightmare.

Many of the participants in LibSecondLife are already working for LL, and it's already a legitimized project as it has the support of Linden Labs. Also, there is no way to contractually limit someone's right to reverse engineer an internet protocol. And since the entire LibSecondLife project is open source already under the BSD license, non-disclosure agreements seem a bit silly.

You won't get any argument from me about how stupid open registration is, and how it exacerbates the problem multi-fold. The fact of the matter is that LL has pretty much screwed the pooch, compounding one disaster with another. That said, them giving us the tools to easily identify infringed content, and a fast-tracked way to have the content and the offender's presence remedied would be the better solution for all concerned.

As a resident, I fully intend to report ANYone I see that has an unauthorized copy of ANY other person's work. I first will contact the creator to verify, then I will AR the offender. If it is MY work which is infringed, I will pursue every means necessary to eradicate said person from SL. Repeatedly, if necessary.



I disagree with the stance, principally because the success of LibSL is due to its openness, allowing new folks to come in as they please to help out in some way, furthering the knowledgebase of the project itself. Also, when companies tend to "overly-legitimize" independent efforts, they also tend to get watered down because lots of top-heavy management comes into play, crushing a lot of the lateral thinking which is what makes the independent project so valuable.

In fact, I would tend to argue that SL is much the better, security-wise, with the open LibSL group than if it had never existed, or was just a group of Lindens themselves. Further, forcing the "No Reverse Engineering" clause on them would only drive them underground (and back into the arms of the rest of the underground SL "development" projects that ARE out there...).

You mean the ones with Linden last names I'm hoping? If so, I am not referring to them.

Ahh but that's the crux here, I am of the mind that if they are a group of residents that is open to all comers, and they have LL's blessing to ignore TOS section 4.2, that it cannot be really legit.

4.2 tells me that *I* am not allowed to.

I am not talking about blanket NDAs. What I envision is one that simply forces any libSL devs who have discovered security holes to not reveal them to the general public, at least until LL has been informed and has time to digest it and formulate policy and procedure with respect to each case.

Hah... simple disassembly away? Well then let's make the libSL guys whip out their disassemblers. Maybe if they had to do that every release, they would think twice before posting potentially dangerous code on their website.



Expensive? Other than log-in, when I had a .NET client app connecting to my webservice, all I did was take information on the client I also knew on the server(like the date, username, last login info etc.) and took out pieces of each of those strings and md5 it in the code, then sent that to my webservice. Sure it can be broken, you just disassemble the code. But I want to see LL make the crackers do that with each release.

It is a pain in the ass to realize that "oh, now you are taking the 2nd and 3rd char of this string, 5th and 6th char of that string, and combining it with the end of the date, and encrypting it", and then rebuilding it.

The function I wrote took 10 minutes on the client, and 10 minutes on the server to change each release. It was good enough encryption for Time Warner, Comcast and other major corporations to use. Why can't LL at least do that to stop unauthorized clients? Expensive... well it wasn't for my crappy software that I don't even want to think about anymore.

Can't disagree with any of this.

I suppose only time will tell if SL is better off or not for it. I'm glad they are working towards a more secure SL, but at the same time I fear that more Pandora's boxes may be opened in the process, which will cause me to question their value further.

Do you have any metrics on how effective that was?

I'm going to guess that the reason it was good enough for those companies was that a) they didn't have any real idea of how much of a problem they had, assuming they had one, and b) they knew that any attempt to encrypt logins would be broken within hours if anybody cared to do it, and c) there are a great many more hackers out there with nothing better to do with their time than they can afford staff programmers to outwit.

But they had to make some sort of token gesture, so what you were doing was that token. They didn't actually expect it to make them secure, and frankly, it wasn't worth paying for more than 10 minutes of your time every month to do it, or they'd have done much more.

I suppose that for me the biggest question that comes to mind is..

Does open source have to mean all or nothing? Can it not be partially open? When a resident run economy and real life money is involved, I think that enacting some type of disclosure agreement in order to join the group really isn't too much to ask.

Of course, it is my opinion that SL will never be ready for full open source with people running their own local servers. You think we have security problems now, just allow Joe Blow to license the software and hook his server up to the grid. Yikes.

How do other MMO developers do it? You're basically saying there is no such thing as security, but the ongoing presence of other MMOs that haven't been overrun by hackers just doesn't jive with that. Somehow they manage to thwart it enough to deliver a viable product with a lifetime of many years in some cases.

On that note, where are the non slLib hackers in SL? Why aren't they running custom clients and wreaking havoc if it's just futile to even try to secure an MMO? I mean, youre saying things like, "there are a great many more hackers out there with nothing better to do with their time than they can afford staff programmers to outwit.", right? Where are they?

Isn't this line of logic a bit like saying "Well, I can't stop theives from breaking the lock on my door, so I won't bother locking it."?

Yes, it was a token gesture. I was actively changing things to make it more difficult for people to use an unauthorized client for the webservice, even if it only resulted in them having to spend a small amount of time rebuilding their hacked client. I also didn't hand out the protocol for the webservice to everyone, it was considered proprietary. In the end, the masses who use the product don't care about the details.

People who texture things for a living were completely happy in their ignorance until LL came out and said they don't have security. Horrible public relations. If the marketing guys did that at my company, they would be fired, not me. I at least covered my ass by changing the encryption with each release.

What I'm saying is it's important to try. Apple does it with every release of iTunes. I want LL to try also... it's the only way they can regain the trust of the masses. Publicly state "We've changed the protocol, and haven't told anyone... the current version of CopyBot is dead." Let all the people who don't even understand the definition of a protocol have their day in the sun again. If LL doesn't at least do that, they don't care about their customers.

Ever heard of Asheron's Call? There was/is a thriving 3rd-party tools community which made a neat bot framework called DECAL. It allowed you to hook into the AC game client and do all kinds of neat things. Every update, the DECAL team had to disassemble and come up with a patch for DECAL for it to be able to work. They usually did this within hours to a day, after Turbine took a MONTH to make the changes. Now Turbine wasn't specifically trying to stop them, but the point is that 3rd party tool makers who rely on reverse engineering are more than capable of keeping up with any changes to the client software.



If it is that easy to change, then it will be that easy to crack. Just a law of programming versus reverse engineering. Unless you push out mass changes every time, they can simply use a special binary diff (one like many runtime patchers used to use) to find the code that was changed and update their own code accordingly to circumvent it.



LOL! You're joking, right? There's nothing mysterious about machine code; once you have read it enough times, just changing a few offsets won't throw ANYone off.



Heh. Well, there's a common razor in the security industry: Use as much security as needed to protect the value of what you are securing. Basically, if you are protecting your wallet, a large, bulky bank vault is PROBABLY a bit more than necessary.

As such, I would have to say if that is the kind of security you were using, either it wasn't protecting anything very important, or the risk of breach attempts wasn't very high. However, that's just my opinion.

Depends on the MMO. ALL MMOs have people who are creating all kinds of hacks and cheats. How each MMO development company approached the problem is different, but that's because the specific nature of the hacks is different and has different effects on each.

Most of the effort to thwart hackers/cheaters revolves around stopping them from doing things in the game world which give them an unfair advantage over the other players; IE, circumventing the game mechanics or rules.

As far as asset theft goes, though, no MMO even bothers preventing it. You can easily snap up ANY asset in any of the other games, as most of them are sitting right there on your HD in standard formats, readily accessible. The only thing that stops folks is Copyright, and the company's vigorous use of it against anyone who infringes their rights.



*shrug* That's one of my points.. the VAST MAJORITY of people have no desire to hack or cheat, even if you give them the tools to do it. However, the few that ARE out there are MORE than capable of reversing and analyzing the client software, looking for holes for themselves and their buddies. Some of them even SELL their knowledge for in-game assets or even RL currency/items. They RARELY give the MMO developer this info, though, and certainly don't like giving their discoveries out to the general public, because they want them to last as long as possible, so they can reap, utilize, and launder their ill-gotten gains long before the developer catches wise.



No, it's more like "Well, I can't stop thieves from breaking the lock on my door, but I sure as hell am not gonna move into a bank vault just to feel secure (which still is not foolproof)". Sure, lock the door, but don't expect it to provide bank-vault-level security. Be prepared to go after the crooks and have them put away for a while instead.

I’m not against LibSL at all. What I’m against is the exploit itself and how easy is to fool the servers. Short term, I'm not talking of making it impossible to do it again, but rather not worthwhile until a real solution is implemented.

Realistically, it would be a lot harder to disassemble the client and modifying it to do the packet injection as compared to a proxy implementation. The issue is not preventing reverse engineering of the protocol, but the insertion of unauthorized packets into the data stream.

Long term, everything should be open. No need to disassemble or reverse engineer anything. Security should not rely on secrecy, but rather on trusted code. Any person or group should be able to create their own SL-compatible application and have it certified and signed by LL or a third party organization managed by the community itself.

Short term question here:

Encryption tends to be a bit resource intensive. As each element in SL can be called for or not depending on the avatar's view, the time saving shortcuts for the encryption are few.

If LL were to omplement data encryption to halt packet interception and injection, how would that effect legit users? How much time would be added to downloads? How much more CPU horespower would be required on the server and client?