Questionable MP item ..

[Profaitchikenz Haiku]

21 hours ago, Rolig Loon said:

It's Sir Edmund Hillary's rationale for climbing Mt Everest: "Because it is there."

Um, he said "We knocked the bugger off"

If was George Mallory who made the quote you referenced

[Rolig Loon]

13 minutes ago, Profaitchikenz Haiku said:

21 hours ago, Rolig Loon said:

It's Sir Edmund Hillary's rationale for climbing Mt Everest: "Because it is there."

Um, he said "We knocked the bugger off"

If was George Mallory who made the quote you referenced

Drat.  Another perfectly good misattributed quotation down the drain. ( <<<  I said that. 6/8/2021 )  🚽

[Profaitchikenz Haiku]

1 minute ago, Rolig Loon said:

Another perfectly good misattributed quotation down the drain

Don't feed the alligators.

[Sid Nagy]

45 minutes ago, Rolig Loon said:

Drat.  Another perfectly good misattributed quotation down the drain. ( <<<  I said that. 6/8/2021 )  🚽

When in doubt, it must have been from Abraham Lincoln.

Edited June 8, 2021 by Sid Nagy

[Innula Zenovka]

26 minutes ago, Sid Nagy said:

When in doubt, it must have been from Abraham Lincoln.

As Voltaire was so fond of saying.

[Chaser Zaks]

Time to deep dive into this:

I just tested it on a testing account. This is exactly what occurs:

1. The user is told to add a experience to their land
2. The user is then told to deed the object if it is group owned
3. Then upon entry of any resident(Checked every 10 seconds), they are told to visit a LSL HTTP URL with a query string matching their UUID(EG: http://simhost-#.agni.secondlife.io:12046/cap/<cap>/?<VISITOR UUID HERE>) with the following message:

   Quote

   ATTENTION - We need to check for alts.
   To stay here you'll need to open this url so we can do a quick test.

   This is also sent in chat:

   Quote

   [10:34] Alt Blocker (v1.25): By clicking through to the url you consent (and agree that it's okay in your country) to be tested to prove that you're not using alts.  Your IP Address will never be recorded, the only data used is a mathematical hash.  And nobody is ever told who the alts are, everyones privacy is respected.

4. A "mathematical hash" occurs and detects the alt.
5. The user sees the following message in their web browser:

   Quote

   Thank you, that's all we needed!
   You can now close this browser window.

6. Any alts on the land at the same time and you are kicked with this:

   Quote

   [10:34] Alt Blocker (v1.25): Your alts have been detected and they will now be temporarily blocked from this area.  Please visit again later (one avatar at a time).
   [10:34] Second Life: You have been banned for 1440 minutes

    

So what can I figure out from this? Does it work, yes! (This is both good and bad, bad because it works, good because I get to go all analysis on it, figure out how it works, and figure out how I can use this knowledge to break it)

Inspecting the request headers and response headers, cookies are not used. In fact, nothing identifiable is stored on the browser, so that leaves either the user agent, or IP address. Let's rule out the user agent because that's easy to test by simply doing this:

felix@crocuta:~$ wget -O- "http://simhost-093042474281521d7.agni.secondlife.io:12046/cap/f2140c12-6696-325b-9e97-a545e8e39ae9/?796b1537-70d8-497d-934e-0abcc2a60050"

Still detects me, so that means the IP address has to be used, lets try that in tor. After trying it in tor, IT DOESN'T DETECT ME AS A ALT!

So that means it is indeed using the IP address, but it says that it doesn't record it, but it uses a mathematical hash, so what is really going on under the hood?

Well, thankfully dataserver is sent to the prim, not specifically a script. So I put in a little bug to watch the dataserver responses and I get this:

Quote

[10:25] Alt Blocker (v1.25): DATASERVER:
1,1623172887~796b1537-70d8-497d-934e-0abcc2a60050

This is a response from the llReadKeyValue function, which means it follows this format: <status>,<data>

With that knowledge in mind, we know that the "1," is part of the LSL function, which leaves us with the data after that: 1623172887~796b1537-70d8-497d-934e-0abcc2a60050

Clearly it is seperated by a ~, so we see a number, and a UUID. The UUID is me. The number is the current unix timestamp(EG: https://www.unixtimestamp.com/index.php). But no information regarding on what the "key" of the value is.

Since they mentioned a "mathematical" function, I guarantee you their "mathematical" function is just:

llMD5String(llGetHTTPHeader(request_id, "x-remote-ip"),0);

Or maybe it is just sugar coated and just stores the raw IP address without MD5 hashing it. Even if it is MD5 stored, because you can easily iterate over all the experience database keys and figure out what what the keys are, you can simply have a rainbow table of every IP address(4,228,250,625 different hashes to index, but this includes reserved IP addresses which can easily reduce the number a lot). My GPU can do around a million hashes per second, if not more. So it'd only take me about 70.46667 minutes or less to figure out someone's hashed IP address.

 

---

So what does all the techno jarble I just posted mean?:

1. Your IP address gets stored by this, either by hash or just plain text. Either way is bad and I would be able to reverse the hash in less than 70 minutes.
2. Your alts are detected by this, but it is easily foolable by just using a proxy(such as tor) to visit the URL, or by using LSL to llHTTPRequest the URL and make the request from the simulator it's self.
3. You can abuse this to get other people banned from the land by changing the last part of the URL you are given. To ban for example Dan Linden(Sorry Dan!), provided he is on the land as well, but he wouldn't be too happy about alt detectors: /?3de548e1-57be-cfea-2b78-83ae3ad95998.
4. It most certainly violates the Terms of Service.

 

[Axel Naxos]

I have Money Chairs that have the same function of detecting ALT accounts and then blocking them, allowing only the use of one account, ie, the first one that used the chairs.
It also asks for confirmation, supposedly IP, by sending a link to be clicked.

Note: Translator English, not native.

[MoiraKathleen]

I rarely ever play those games or contests or whatever where you win $L's, so if I and my alt decided to go dancing at the same club at the same time, that should benefit the club owner becuase it'd be more traffic to the location.   It's also rare that both myself and my alt are even logged in at the same time. 

However, if I ever landed someplace and got greeted with this message about clicking a URL for alt checking, I'd immediately TP out  and never return to that location,  even if I never intended to log on my alt as well when visiting that location.

[Sid Nagy]

45 minutes ago, Axel Naxos said:

I have Money Chairs that have the same function of detecting ALT accounts and then blocking them, allowing only the use of one account, ie, the first one that used the chairs.
It also asks for confirmation, supposedly IP, by sending a link to be clicked.

Note: Translator English, not native.

I thought money chairs where put up to generate traffic.
Who cares if there are alts among them?
Or am I missing something?

[Whirly Fizzle]

2 hours ago, Chaser Zaks said:

You can abuse this to get other people banned from the land by changing the last part of the URL you are given. To ban for example Dan Linden(Sorry Dan!), provided he is on the land as well, but he wouldn't be too happy about alt detectors: /?3de548e1-57be-cfea-2b78-83ae3ad95998.

So basically you can go to any parcel using one of these devices & get everyone on the parcel banned by this system very easily.

Sounds like a fun game! 

[Coffee Pancake]

[Whirly Fizzle]

So I mean, err..  Does anyone know a parcel where this thing is rezzed?

Asking for a friend....

😜

[Innula Zenovka]

2 hours ago, Chaser Zaks said:

It most certainly violates the Terms of Service.

Which one, though?   I've re-read http://wiki.secondlife.com/wiki/Linden_Lab_Official:Residents'_privacy_rights and it's not clear to me how this item breaks any of the rules, assuming it works as you think it must (for what it's worth, it's how I would reconstruct it, too).

[Rowan Amore]

On 6/7/2021 at 5:18 PM, Innula Zenovka said:

I think it's something that works well on a parcel level but doesn't necessarily scale.    The obvious solution would be to release the script full perms, with a note that you'll have to own an experience (or be an experience contributor) and set the land to your own experience to make it work, but whoever made the thing hasn't done that, for whatever reason (maybe they didn't consider it).    I don't know how how many KVP keys a database can hold by default -- a great many, I do know that.     

In practice, though, I think local memory would be quite adequate unless you had a really high traffic parcel.

 

I posted the relevant section of the privacy policy on page one.  This is from the GDPR and concerns privacy in the EU.  I imagine it's why the object asks legality in your country.

https://gdpr.eu/compliance/

https://gdpr.eu/gdpr-consent-requirements/

From a quick read, the object doesn't seem to meet the requirements for "need to know" nor the consent definition.  

 

[Innula Zenovka]

12 minutes ago, Rowan Amore said:

I posted the relevant section of the privacy policy on page one.  This is from the GDPR and concerns privacy in the EU.  I imagine it's why the object asks legality in your country.

https://gdpr.eu/compliance/

https://gdpr.eu/gdpr-consent-requirements/

From a quick read, the object doesn't seem to meet the requirements for "need to know" nor the consent definition.  

 

Then that's a matter for the Information Commissioner, and anyone in the EU who thinks they have a case should take it up with their local Information Commission Office.

I mean, it may well be in contravention of EU data law -- not being a specialist in EU data protection law, I have no way of knowing, and neither do LL, but the ICO do, and they're the people whose views count, so best ask them, I'd have thought.

Edited June 8, 2021 by Innula Zenovka

[Rowan Amore]

Seems to me the creator would be in more trouble in RL than in SL and LL is covering their behind.  They don't seem to technically be disallowing the obtaining of personal information even if they would be aware of someone doing so.   Could be a slippery slope for LL since the creator is using their platform to do something, IMO, that is against the spirit of the GDPR and LL is allowing it.

[Innula Zenovka]

8 minutes ago, Rowan Amore said:

Seems to me the creator would be in more trouble in RL than in SL and LL is covering their behind.  They don't seem to technically be disallowing the obtaining of personal information even if they would be aware of someone doing so.   Could be a slippery slope for LL since the creator is using their platform to do something, IMO, that is against the spirit of the GDPR and LL is allowing it.

At the time,  I complained about RedZone to the ICO and was told that, while they would have investigated had the data controller been in the EEA or EU, it was outside their jurisdiction.    That's now changed, of course, but it seems to me that this particular application lacks the features that made RedZone problematic under EU data protection law.

I may well be mistaken, of course, but as it is, I won't be making a complaint, at least not on the basis of what I know or can reasonably surmise.   However,  anyone who doesn't share my view and is concerned that this kind of application contravenes European data protection law (as quite possibly it does, for all I know) has an appropriate remedy readily to hand.

[Axel Naxos]

3 hours ago, Sid Nagy said:

Pensei que cadeiras de dinheiro eram colocadas para gerar tráfego.
Quem se importa se há alts entre eles?
Ou eu estou esquecendo de alguma coisa?

Those who like to donate money, like to donate to multiple users, not just ONE user.
It's not always just wanting to get traffic.
This is a parallel universe to the SL pattern, of lust and selfishness.

[Mollymews]

2 hours ago, Innula Zenovka said:

Which one, though?   I've re-read http://wiki.secondlife.com/wiki/Linden_Lab_Official:Residents'_privacy_rights and it's not clear to me how this item breaks any of the rules, assuming it works as you think it must (for what it's worth, it's how I would reconstruct it, too).

i agree

this system is asking the visitor to opt-in.  That the visitor gets ejected when they don't opt in is not a ToS violation according to the my land - my rules

nor is it against the sharing rule as far as I can tell.  The visitor is asked to opt-in to sharing, if they decline to share then they get ejected. My land - my rules

[Qie Niangao]

6 hours ago, Chaser Zaks said:

You can abuse this to get other people banned from the land by changing the last part of the URL you are given. To ban for example Dan Linden(Sorry Dan!), provided he is on the land as well, but he wouldn't be too happy about alt detectors: /?3de548e1-57be-cfea-2b78-83ae3ad95998.

I'm not sure I follow how this would work. The device must be querying KVP for a key matching the (hash of) the incoming IP address, but with a different "alt" avatar UUID. It shouldn't notice if there are different IP addresses used by the same avatar. So unless I spoof Dan Linden's IP address, I don't see how he gets banned. What am I missing?

(Not crucial to this logic, but also: there's nothing to prevent the script from keeping track of which avatar UUIDs it has prompted with llLoadURL. In fact, it's already got a little queue of them waiting to get booted if they don't appear with a timely request. It can just drop spoofed requests apparently "from" avatars not currently in that load-or-die queue.)

[Chaser Zaks]

9 hours ago, Qie Niangao said:

I'm not sure I follow how this would work. The device must be querying KVP for a key matching the (hash of) the incoming IP address, but with a different "alt" avatar UUID. It shouldn't notice if there are different IP addresses used by the same avatar. So unless I spoof Dan Linden's IP address, I don't see how he gets banned. What am I missing?

(Not crucial to this logic, but also: there's nothing to prevent the script from keeping track of which avatar UUIDs it has prompted with llLoadURL. In fact, it's already got a little queue of them waiting to get booted if they don't appear with a timely request. It can just drop spoofed requests apparently "from" avatars not currently in that load-or-die queue.)

All accounts used below in the example are mine and IP addresses are internal addresses.

Here is a example table:

KEY	VALUE
altdetector_127.0.0.1	1623172887~796b1537-70d8-497d-934e-0abcc2a60050
altdetector_192.168.0.127	1623173421~835096de-9f7e-42d2-b92d-6dc6677f7d8f

In this example, Chaser Zaks(796b1537-70d8-497d-934e-0abcc2a60050) and Saltyalt(835096de-9f7e-42d2-b92d-6dc6677f7d8f) are already in the area and have clicked the URL already.

When Parker Oh(918ff3eb-e8fe-4cfe-8bff-5963a461962e) with the IP of 192.168.0.192 enters the area, they are prompted to visit the URL. They do and this is added to the table:

KEY	VALUE
altdetector_192.168.0.192	1623172926~918ff3eb-e8fe-4cfe-8bff-5963a461962e

Now, Parker Oh still has the URL. They can simply change it to /?796b1537-70d8-497d-934e-0abcc2a60050 and it will look up the the key "altdetector_192.168.0.192" and see that a entry exists and that the UUID assigned to that address is "918ff3eb-e8fe-4cfe-8bff-5963a461962e", which since the time is very recent(I presume it is a past 24 hour check because it bans for 24 hours), it will consider "796b1537-70d8-497d-934e-0abcc2a60050" as a alt of "918ff3eb-e8fe-4cfe-8bff-5963a461962e", and eject both Parker Oh and Chaser Zaks. This can be repeated for /?835096de-9f7e-42d2-b92d-6dc6677f7d8f and eject Saltyalt.

I should note that script is using a "trust the client" approach and not storing any request history. I have checked this and confirmed it myself. It is the same URL for every person, there is no salt/hashing inside the URL, and it doesn't check if the person is even in the area before it ejects them.

Edited June 9, 2021 by Chaser Zaks

[Innula Zenovka]

19 minutes ago, Chaser Zaks said:

All accounts used below in the example are mine and IP addresses are internal addresses.

Here is a example table:

KEY	VALUE
altdetector_127.0.0.1	1623172887~796b1537-70d8-497d-934e-0abcc2a60050
altdetector_192.168.0.127	1623173421~835096de-9f7e-42d2-b92d-6dc6677f7d8f

In this example, Chaser Zaks(796b1537-70d8-497d-934e-0abcc2a60050) and Saltyalt(835096de-9f7e-42d2-b92d-6dc6677f7d8f) are already in the area and have clicked the URL already.

When Parker Oh(918ff3eb-e8fe-4cfe-8bff-5963a461962e) with the IP of 192.168.0.192 enters the area, they are prompted to visit the URL. They do and this is added to the table:

KEY	VALUE
altdetector_192.168.0.192	1623172926~918ff3eb-e8fe-4cfe-8bff-5963a461962e

Now, Parker Oh still has the URL. They can simply change it to /?796b1537-70d8-497d-934e-0abcc2a60050 and it will look up the the key "altdetector_192.168.0.192" and see that a entry exists and that the UUID assigned to that address is "918ff3eb-e8fe-4cfe-8bff-5963a461962e", which since the time is very recent(I presume it is a past 24 hour check because it bans for 24 hours), it will consider "796b1537-70d8-497d-934e-0abcc2a60050" as a alt of "918ff3eb-e8fe-4cfe-8bff-5963a461962e", and eject both Parker Oh and Chaser Zaks. This can be repeated for /?835096de-9f7e-42d2-b92d-6dc6677f7d8f and eject Saltyalt.

I should note that script is using a "trust the client" approach and not storing any request history. I have checked this and confirmed it myself. It is the same URL for every person, there is no salt/hashing inside the URL, and it doesn't check if the person is even in the area before it ejects them.

How about using the (hashed) IP address as the key?

That way, when someone opens the webpage, thus exposing their IP address,  the script tries to read the KVP value for which the hashed IP address is the key.   

If llReadKeyValue(strHashedAddress) returns a key not found error, it's a new visitor (or, at least, a visitor who has not used this IP address here in the past) so admit the visitor and call llCreateKeyValue(strHashedAddress, (string)llGetUnixTime()+"~"+(string)kAvUUID);

If, however, it does return a value, then compare the avatar UUID associated with the IP address with that of the avatar currently using it.    If they match, then welcome back.  If not, then assume (possibly mistakenly) they're someone's alt, and ban them either permanently or temporarily using llAddToLandBanList.

 

 

[Phil Deakins]

16 hours ago, Sid Nagy said:

I thought money chairs where put up to generate traffic.
Who cares if there are alts among them?
Or am I missing something?

Not all money/camping chairs are there for the traffic. For a while I had 8 of them on their own little parcel. It was just a small way of giving something to users. In such circumstances, multiple avatars from the same person are definitely not wanted. If they are there just for the traffic, then yes, alts don't matter.

Edited June 9, 2021 by Phil Deakins

[Krystina Ferraris]

19 hours ago, Sid Nagy said:

When in doubt, it must have been from Abraham Lincoln.

Or Marylin Monroe 👠😅

[Qie Niangao]

1 hour ago, Chaser Zaks said:

I should note that script is using a "trust the client" approach and not storing any request history. I have checked this and confirmed it myself. It is the same URL for every person, there is no salt/hashing inside the URL, and it doesn't check if the person is even in the area before it ejects them.

First, thanks for the very clear explanation. I was somehow ignoring the case of sacrificing as "alt" an already-present confederate, making our luckless Dan appear to share that confederate's IP address. (Now I can't imagine what I was thinking you could have meant, other than that!)

And yeah, an easy solution is for the script to be a little less trusting of the client. As I mentioned, there's no reason for it to pay any attention to http requests "from" avatar keys that aren't among those currently being probed with llLoadURL. Your suggestion of simply encoding the avatar key would be even easier. (And here we are, giving product improvement ideas for a device we both find, uh, unfortunate.)