More Adventures in Second Life

9 03 2011

As followers of this blog know, on the 10th of February I wrote about my adventures with RedZone, revealing the ridiculously insecure way the spyware collects data. This elicited a furious coding effort by zFire who tried valiantly, to the best of his ability to plug the hole I had exposed here (but that had already been widely exploited it seems by people intent on poisoning his database). On Sunday 13th February zFire rolled out a new version of RedZone with some new improved encryption. It was another week before he fixed everything else he broke. As I said in a post on 13th February, it was extremely hard to find a RedZone to scan me with the new improved system. But I tried valiantly, and in fact I did manage to get scanned once.

As it turns out, once was enough. Within a couple of hours I had cracked the new encryption which was pretty much as clueless as the last one. I did not mention this at the time though, as I was enjoying watching all the RedZone updates, and in any case, why let the “enemy” know what we know?

However others have also posted on SLUniverse that they have cracked this encryption, and what it contains. (Waves to Walker. We really should find a way to chat sometime!) This being the case, and as RedZone is on its last legs, I thought now would be a good time to blog about my findings.

So here is how zFire used the best of his ability to fix his encryption. You will remember that the previous encryption was a straightforward monoalphabet substitution cipher – much like a ceasar cipher. It can be decrypted by hand rather easily. zFire decided he would fix this by replacing it with… another monoalphabet susbstitution cipher!

Here it is. The first line is plain text, the second line is the ciphertext alphabet:


=./&%0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWX-
tuQtlikJ0x&raL39qhM.%VW8eDNRU62P=XH5/vFKgBSYnG_bdjsAEfmw4Cp7O1Iyc-

Good job zFire!

Oh but he added an extra couple of features to make it really difficult! These were:

  1. He concatenated all variables together into a single ciphered string so that everything was now encrypted. He did not notice that this – if anything – makes the code easier to break.
  2. He wrote the string backwards. That was cool. That took me almost a minute to spot!
  3. He actually got a clue and inserted a transaction ID. He did not need to encrypt the transaction ID – its very existence is the single most important thing he could have done to help prevent false data being reported into his database. This was the piece of information I decided not to mention in my previous article.

I must say I was quite disappointed when I saw the transaction ID. Easy banning of theBoris Gothly as a copybotter was now not on the cards (and yes, we did spot that the ban had worked, zFire! Just in answer to your message in this forum that the previous code did nothing).

What must now be happening is that the RedZone device itself reports back Avatar scan information, which is given a transaction ID. This report contains stuff that was previously reported in the GET request fed to your client. Your client then confirms a couple of points of information and also supplies IP address and User Agent for the scan (if you open the parcel media URL).

So what can we do? We cannot intercept the scan information and change it, and having media off already ensures that the missing IP address is not sent back to the database.

The answer comes from silly redZone users themselves. Because they have requested the option to ban all those terrorists and malcontents who dare walk into a sim with their media off. How does RedZone know that the media is off? Because one half of the scan is sent back to base from the sim, and the other half from the client using the parcel media hack. Failure to receive the second half of the transaction from the parcel media hack indicates (not to reliably) that parcel media is off, or the client is blocking the request in some other way. After a while, these people get ejected from the sim for the audacity of not connecting to a content stream that provides them with no content!

But what would happen if you could fool the sensor into thinking someone else was on sim who was not really there? Then RedZone would record their names and information, and eventually ban them from a sim that uses the media-off ban. Now that could be fun.

And here we have to cue a techy friend who wishes to rename nameless. This friend had been observing RedZones for some time and had discovered how to listen in on the RedZone probe communications with the base unit. RedZone, like any script, can only scan in a 96 metre radius of its location, so those full sim scans are handled by flying probes that jump around the sim doing multiple 96 metre scans and then report back to the base unit with an llRegionSay() call on a secret channel.

As it turns out, that channel differs for different installations, but once chosen it is set. If you can find the channel of a RedZone device, you can listen in on the communication, and even send back your own communication to it.

Discovering channels is not a trivial thing to do as you have to create a lot of channel listeners listening (on a rotating basis) on all possible channels until you observe chatter. You can create a lot of listeners, but you still need scripts to close old ones and open new ones and a bit of patience. Fortunately RedZone probes chatter a lot, so one of the freely available channel scanners should find the chatter without too much difficulty.

Having found the chatter, my techy friend presented me with some data that looked like this:


[21:21] MystiTool HUD 1.3.1: (xx) [zF RedZone v4.1.7 - Ch.36411517]: Probe go to~
[21:21] MystiTool HUD 1.3.1: (xx) [Object - Ch.36411517]: ghJKhKk pmKlo aP.GGP.r-rLP0~q0Lq-MBMBrq0q-8xBBjjXah-sshowrGkjsIlswKS~dsjwUAksadlsLkKsahsjswsa-XZXs~q0lq-rrahHasea-JJ8xBah9X-sQqjhJk3Xr0JqsoiS~o=jqaDa=3483aB 0eBqawS 0MoMX9S

I looked at it and at first I was stumped. This looked like zFire’s normal clueless ciphered encryption, but the normal markers that made it easily crackable were missing. I knew there should be a UUID in there but nothing obviously fitted the pattern of a UUID.

Thus for the first time I actually had to ask for more data to crack the encryption. My friend (and his friend) collected me a whole load of additional data and then I took a good look at it, and spotted that some data did not change from one scanner to another. Eliminating the non changing information was the breakthrough. Once I removed the junk (every second letter), this was clearly just another of zFire’s backwards ciphered strings, and I already had the code to decrypt it.

Here is my rough and ready decryption script:

integer mychannel=2 ;
integer listen_handle ;
//
string clearText= "=./&%-0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWX " ;
string cipherText="tuQtl-ikJ0x&raL39qhM.%VW8eDNRU62P=XH5/vFKgBSYnG_bdjsAEfmw4Cp7O1Iyc " ;
// 
string substitute(string baseChar, string clearText, string cipherText) {
    string ss="" ;
    integer pos = llSubStringIndex(clearText,baseChar) ;
    ss=llGetSubString(cipherText,pos,pos) ;
    return ss ;
}
//
default
{
    state_entry()
    {
        listen_handle = llListen(mychannel, "", llGetOwner(), "");
        llOwnerSay("Type /"+(string) mychannel+" encryptedstring to see decryption") ;
    }
    listen( integer channel, string name, key id, string message )
    {
        string resultstr="";
        string unstegtext="" ;
        integer msglength=llStringLength(message) ;
        integer i ;
        for (i=msglength ; i>=0 ; i-=2) {
            unstegtext+=llGetSubString(message,i,i);
            resultstr+=substitute(llGetSubString(message,i,i),cipherText, clearText) ;
        }
        llOwnerSay("cleartext     : "+resultstr) ;
    }
}

It decrypted to something like this:


=add Obj Marker 1f15f287-e582-46d1-a212-ac5b0f0598f1 0a714cfa-c819-4cfb-bc7a-a66368918ed2

Notice the UUIDs. One is the UUID of the person detected and the other appears to be the RedZone device owner’s UUID.

So to add additional people to a sim is easy. Just write a script that uses llRegionSay() on the sim with the detected RedZone probes which inserts random UUIDs of people, or UUIDs of a hitlist of RedZone owners, and all these people appear to be sim visitors. As none of them are actually on sim, they clearly never send back the second GET request with their IP address, and after a while, RedZone bans them.

Well anyway it amused me.

zFire – would you like to go and fix your software again? Or do you think you are ready now to call time on your illegal collection of personal data?

A final word: there is an additional attack, and this one I believe has been used by someone (I really don’t know who) for some time to poison the RedZone database. RedZone stores the IP address from the scan from the client – but suppose a clever coder intercepted those scans on their computer and quickly constructed a URL and fed this to an inworld object that collected it using an llHTTPRequest() with a correct transaction ID? In that case the GET request would come from the sim IP address, and anyone doing this in the same sim would become alts of one another in the database. Nice! But flawed in a few ways (which I will not mention for reasons of space) so I did not pursue that myself.

Advertisements

Actions

Information

9 responses

10 03 2011
Adromaw

“or UUIDs of a hitlist of RedZone owners, and all these people appear to be sim visitors. As none of them are actually on sim, they clearly never send back the second GET request with their IP address, and after a while, RedZone bans them.”

Isn’t that part of what the safe list feature (presumably) prevents? Assuming the owner has set it up correctly that is.

10 03 2011
Serjourn Daxter

/100 MODE Sarcasm

I have had much fun over Zfire’s pathetic attempts at securing his product. He obviously knows zilch of even the most basic encryption principle, the Kerckhoff’s principle that simply states: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Are you listening, Zfire? You need a key management system and a secure algoritm! There are secure algorithms all over the place, Eliptic curve, Blowfish, DES, TripleDES, RSA. In light of the Kirkoff’s principle, all these algoritms are fully documented. So go get them. Get them all. That will keep you busy for a while.

Now you need a key management system. Nonononono, you can’t use the same key in all instances of your product. It is hard enough to maintain a secret that just two persons know about. What about a secret that 17000 people know? And hiding the key inside your code (obscurification) violates the Kirkoff Principle, making the key very likely to be compromized.

So you need asymetric encryption utilizing keypairs of public and private keys. At this point, you will have to chunk out a fair share of the algoritms that you have obtained, simply because they are NOT asymetric.

So your product fires up, grabs your public key from the network, encrypts the message contents with the public key and sends it to you – who can now decrypt it. Great. But anyone can grab your public key and insert false messages. The lookup of your private key can also be blocked. So anyone can prevent messages from going out or inserting false messages. Not quite what you wanted, is it?

To secure this, the users (device owner) must be issued with a private/public key set and use their private key to encrypt messages they send to you. So you need key management – for each instance of the scanner. Happy programming, I’d say.

Now if someone BUYS a RedZone scanner from you, they need a key pair issued. So to insert false messages, all you have to do is buy the scanner – oops – almost forgot – that is a bit hard these days, isn’t it?

Come to think of it – you COULD implement a Diffie–Hellman key exchange scheme… exchanging a session key for each each session, with a digitally signed…. oh never mind.

Or you could go write something else – something usefull – if you have the skills for that.

/100 MODE no sarcasm

11 03 2011
skills

o.o

12 03 2011
Jenni Darkwatch

There are at least 3 people who insert(ed) bogus info into his DB as well as doing the same with a few other systems out there. Altering the IP address is trivial, always has been trivial, and the same goes for all the other info his system gathers.

zFire and security makes as much sense as calling Myanmar a democracy. His mySQL DB runs with root account active, and the PHP script doesn’t (well, didn’t) properly filter input data, nor does it use proper permissions on the user inserting the data. That’s also not a secret, there’s a few people who are/were aware of that. I could go on, but why bother.

Yet there’s people still thinking he’s the greatest thing since sliced bread. Figures.

12 03 2011
no2redzone

Jenni, yes indeed. The number of people that knew about the SQL insertion problem was actually frighteningly large. I thought Crackerjack gave the game away a while back when he started whittering on about it, but zFire never noticed.

But using an SQL insertion to attack a database is Sith magic. We Jedi do not do such things. 🙂

Sadly the script kiddie who attacked him last night (or this afternoon if you are in the USA) did not realise the power of SQL insertion on an SQL database running as root. I may have to blog an article about what we could have done if we were Sith!

On the other hand it has been good fun poisoning the database using perfectly legal GET requests – the extent of the bad data in there must be truly staggering.

12 03 2011
Serjourn Daxter

Oww. I may be a bit misinformed here? Do you mean to say that nobody have really used that blatantly obvious possibility existing as root user to reshuffle random avatar names versus IP addresses? Because that could really make his database totally worthless and would also be rather hard to detect without knowing when it happened – and rolling back a backup… which requires knowing when it happened… which actually require professional database management.

But as you say – that is Sith powers. No Jedi would ever do such eviiil things. Never!

14 03 2011
zf Redzone User Passwords Hacked « Herk's Lab

[…] for months. For example, detailed instructions on cracking his database are here and here. Anyone with a background in networking, security, or even web development would find it amazing […]

15 03 2011
Serjourn Daxter

Just heard that HybridZ has stopped using RedZone over news that the database has been hacked.

If you are to sell a security product, your personal integrity, security of the product and data integrity are key assets. If either are lacking, your product is worthless. Let us evaluate RedZone on these criteria:

Personal integrity of zFire – I will NOT be the judge of that because that could be called harassment.

Security of the product – Well, read this blog. Make up your own mind.

Data integrity – again – read this blog. Make up your own mind. But also consider this long lived data processing principle: Garbage in = garbage out. RedZone is based on an IP address as an identifier. That is pure garbage. Proxies blow up this scheme (like in hotells, at airports, at Starbucks and at some ISP’s). Dynamic IP also blows IP as reliable identification. So as RedZone’s input is based on garbage, what will its output be?

I think it is high time all that ever bought RedZone realize it is one big scam and they have been subject to a great con game. “Money” and “refund” are two words that come to my mind here.

16 03 2011
Serjourn Daxter

RedZone – Goodbye and Good Riddance. Now other products remain, so ladies and gentlemen, please reload your weapons and re-aim!




%d bloggers like this: