Jump to content

Questionable MP item ..


You are about to reply to a thread that has been inactive for 129 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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 )  🚽

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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 by Sid Nagy
  • Like 2
  • Haha 1
Link to comment
Share on other sites

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.

 

  • Like 2
  • Thanks 8
Link to comment
Share on other sites

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.
O.o
Note: Translator English, not native.

Link to comment
Share on other sites

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.

  • Like 6
Link to comment
Share on other sites

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.
O.o
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?

  • Like 4
Link to comment
Share on other sites

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!  :D

  • Like 4
  • Haha 1
  • Sad 1
Link to comment
Share on other sites

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).

  • Like 2
Link to comment
Share on other sites

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.  

 

Link to comment
Share on other sites

Posted (edited)
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 by Innula Zenovka
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

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.)

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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 by Chaser Zaks
  • Like 3
  • Thanks 2
Link to comment
Share on other sites

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.

 

 

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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 by Phil Deakins
  • Thanks 1
Link to comment
Share on other sites

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.)

  • Like 3
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 129 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...