A user who joined recently has been causing a havoc in the cloud data history or cloud monitors of some popular cloud projects which is on the front page or in trending or is really popular. (I am not criticizing or against any scratchers on the community I am just reporting an issue which may be an exploit in scratch to resolve it) He/she has been setting the cloud variable to huge numbers using an exploit or by hacking idk and he/she is setting data name (which is not possible for a viewer or scratcher not owning the project) and naming them like to spam a certain studio or to advertise his/her youtube channel and to name the new data's . If this is an exploit or bug in scratch please fix it as soon as possible because the user or users' who are using it can set inappropriate words on the cloud data history's. Also the user who is setting the value is a New scratcher…

edit your post out and remove all instances of the username and images - then read this - https://scratch.mit.edu/discuss/post/5607340/

also remove links to the project and cloud log, since it would be naming and shaming the cloud variable exploit abuser

JSscratcher_2008 wrote:

Also the user who is setting the value is a New scratcher…

this is also part of the exploit that the Scratch Team has yet again, ignored to fix.

slgsan-encrypted wrote:

JSscratcher_2008 wrote:

A user who joined recently has been causing a havoc in the cloud data history or cloud monitors of some popular cloud projects which is on the front page or in trending or is really popular. (I am not criticizing or against any scratchers on the community I am just reporting an issue which may be an exploit in scratch to resolve it) He/she has been setting the cloud variable to huge numbers using an exploit or by hacking idk and he/she is setting data name (which is not possible for a viewer or scratcher not owning the project) and naming them like to spam a certain studio or to advertise his/her youtube channel and to name the new data's . If this is an exploit or bug in scratch please fix it as soon as possible because the user or users' who are using it can set inappropriate words on the cloud data history's. Also the user who is setting the value is a New scratcher…

It can't be fixed, it's the nature of cloud variables; anyone can change it, if you want, try this:

if <not <(☁ cloud variable) = [original value]>> then
set [☁ cloud variable] to [original value]
end

No that won't work in scratch, because if you “look inside” and it's not your project it disconnects you from the cloud server.

This “hacking” is being done using an external script and it is a big problem that I think the scratch team needs to address quite urgently.

colinmacc wrote:

slgsan-encrypted wrote:

JSscratcher_2008 wrote:

A user who joined recently has been causing a havoc in the cloud data history or cloud monitors of some popular cloud projects which is on the front page or in trending or is really popular. (I am not criticizing or against any scratchers on the community I am just reporting an issue which may be an exploit in scratch to resolve it) He/she has been setting the cloud variable to huge numbers using an exploit or by hacking idk and he/she is setting data name (which is not possible for a viewer or scratcher not owning the project) and naming them like to spam a certain studio or to advertise his/her youtube channel and to name the new data's . If this is an exploit or bug in scratch please fix it as soon as possible because the user or users' who are using it can set inappropriate words on the cloud data history's. Also the user who is setting the value is a New scratcher…

It can't be fixed, it's the nature of cloud variables; anyone can change it, if you want, try this:

if <not <(☁ cloud variable) = [original value]>> then
set [☁ cloud variable] to [original value]
end

No that won't work in scratch, because if you “look inside” and it's not your project it disconnects you from the cloud server.

This “hacking” is being done using an external script and it is a big problem that I think the scratch team needs to address quite urgently.

yes

slgsan-encrypted wrote:

colinmacc wrote:

slgsan-encrypted wrote:

JSscratcher_2008 wrote:

A user who joined recently has been causing a havoc in the cloud data history or cloud monitors of some popular cloud projects which is on the front page or in trending or is really popular. (I am not criticizing or against any scratchers on the community I am just reporting an issue which may be an exploit in scratch to resolve it) He/she has been setting the cloud variable to huge numbers using an exploit or by hacking idk and he/she is setting data name (which is not possible for a viewer or scratcher not owning the project) and naming them like to spam a certain studio or to advertise his/her youtube channel and to name the new data's . If this is an exploit or bug in scratch please fix it as soon as possible because the user or users' who are using it can set inappropriate words on the cloud data history's. Also the user who is setting the value is a New scratcher…

It can't be fixed, it's the nature of cloud variables; anyone can change it, if you want, try this:

if <not <(☁ cloud variable) = [original value]>> then
set [☁ cloud variable] to [original value]
end

No that won't work in scratch, because if you “look inside” and it's not your project it disconnects you from the cloud server.

This “hacking” is being done using an external script and it is a big problem that I think the scratch team needs to address quite urgently.

No, ANYBODY can change the cloud variables, if not then how do cloud high scores work?

Did you even read what I wrote? As soon as you look inside the project at the code, you are disconnected from the cloud system and you aren't reconnected until you refresh the entire page. So you can't do what you describe from within Scratch. (Except on your own projects)

Really wish the ST would fix this exploit already. There's not much you can do about these users abusing the exploit other than reporting them.

side note: From what I've seen, these users are also setting the values of cloud variables that aren't even in the project. That just goes to show how flawed the cloud system is.

Epicness123 wrote:

Really wish the ST would fix this exploit already. There's not much you can do about these users abusing the exploit other than reporting them.

side note: From what I've seen, these users are also setting the values of cloud variables that aren't even in the project. That just goes to show how flawed the cloud system is.

tbh this is kinda soooo ez to fix if you think about it…

Chiroyce wrote:
How do cloud variables work?

When a person with a Scratch Account loads a project, there is a websocket connection made to the websocket server with the URL of wss/clouddata.scratch.mit.edu, once that is done, and the Scratch Interpreter sees blocks that change a cloud variable, it sends a request via the websocket to change it, this is fast, and easy to do.

What's the problem, then?

Well you see - currently there is no way of finding out if a block in a project changed a cloud variable or if a human being with a programming language did this.

How does the server verify that you are who you claim to be?
The websocket server authenticates you in a few ways -

1. If you have a Scratch account and are logged in to it, your browser automatically sends your session ID along with the request for a websocket connection, this way if you have a valid scratch session, the server creates the connection with the browser, otherwise, it simply doesn't.
Key data for this step - A scratch username & password, which can be used to start a scratch session, which in turn gives you a sessionID

2. Next, the scratch interpreter checks for blocks that changes cloud variables, if there is such a block, and that block has been executed, the code tells the browser to send a packet of data via the websocket, the browser does so, and the server updates the variable, and then sends the current value to everyone else who is having a websocket session for the same project.

Where this goes wrong …
You see, servers in general should NEVER trust what the client sends to them, as it can be modified by them. If you have a shopping website and you calculate the money for the checkout based off of what the client sends you (i.e, what they want to buy + the price of it), then they can simply modify the request to be 0$ and get a 100% discount. A better way would be for the server to check if the value sent by them is the same value as whatever is stored on the server.

“Well then we could use this for cloud data …, right?“

Nope, you see, cloud variables are very dependent on whatever happens on the client side, if you beat a high score in a game, you're the one who is submitting your score to the server, and the server may think that an if block which checked if (yourScore) > (highScore), but it can even be a person who is using Python or JavaScript, to establish a websocket connection with a valid session id, and pretending to be a project who is sending the data.

So in short, never trust client side data.

”But then what do we do now?”

That's the problem! So at this point I have absolutely no clue what the Scratch Team can do about this, the best solution I can think of is to have cloud projects running on the server, just like popular multiplayer games, but that seems like wayy too much work and server load. Any ideas to fix this?

In this topic: https://scratch.mit.edu/discuss/post/5607340/

slgsan-encrypted wrote:

Even though that guy was banned, he still executed that loop from his alt, i didn't wanna specify the username, but that account is too blocked…

But I know of a python API called scratch2Py made by @TheCloudDev and it can be used to change turbowarp vars…

I could make a bot to monitor the cloud monitor with python if anyone wants to help… Can someone please give me the hackers username so I can make something to stop them?

slgsan-encrypted wrote:

Everebydoy missed the fact that the user is a NEW SCRATCHER and a new scratcher can't change cloud variables, cloud variables use SecureWebSockets, so they are encrypted using TLS(Transport Layer Security) and intercepting them is SO tough why would anybody intercept a cloud variable to just change the value? Probably he/she has an alt, @JSscratcher can you pls give the link to the project in my profile, i can monitor it for a few days and i would love to…

You're overcomplicating things wayy to much - why do you need to intercept when you can make the request yourself?
Read this —

Chiroyce wrote:

How do cloud variables work?

When a person with a Scratch Account loads a project, there is a websocket connection made to the websocket server with the URL of wss://clouddata.scratch.mit.edu, once that is done, and the Scratch Interpreter sees blocks that change a cloud variable, it sends a request via the websocket to change it, this is fast, and easy to do.

What's the problem, then?

Well you see - currently there is no way of finding out if a block in a project changed a cloud variable or if a human being with a programming language did this.

How does the server verify that you are who you claim to be?
The websocket server authenticates you in a few ways -

1. If you have a Scratch account and are logged in to it, your browser automatically sends your session ID along with the request for a websocket connection, this way if you have a valid scratch session, the server creates the connection with the browser, otherwise, it simply doesn't.
Key data for this step - A scratch username & password, which can be used to start a scratch session, which in turn gives you a sessionID

2. Next, the scratch interpreter checks for blocks that changes cloud variables, if there is such a block, and that block has been executed, the code tells the browser to send a packet of data via the websocket, the browser does so, and the server updates the variable, and then sends the current value to everyone else who is having a websocket session for the same project.

Where this goes wrong …
You see, servers in general should NEVER trust what the client sends to them, as it can be modified by them. If you have a shopping website and you calculate the money for the checkout based off of what the client sends you (i.e, what they want to buy + the price of it), then they can simply modify the request to be 0$ and get a 100% discount. A better way would be for the server to check if the value sent by them is the same value as whatever is stored on the server.

"Well then we could use this for cloud data …, right?“

Nope, you see, cloud variables are very dependent on whatever happens on the client side, if you beat a high score in a game, you're the one who is submitting your score to the server, and the server may think that an if block which checked if (yourScore) > (highScore), but it can even be a person who is using Python or JavaScript, to establish a websocket connection with a valid session id, and pretending to be a project who is sending the data.

So in short, never trust client side data.

”But then what do we do now?"

That's the problem! So at this point I have absolutely no clue what the Scratch Team can do about this, the best solution I can think of is to have cloud projects running on the server, just like popular multiplayer games, but that seems like wayy too much work and server load. Any ideas to fix this?

— https://scratch.mit.edu/discuss/post/5607340/

On my project https://scratch.mit.edu/projects/1026678264/ A unidentified user named sdfdsgfxg is setting my cloud variables to 890858479, I believe it might be some sort of cloud variable exploit Cloud Monitor…

Seems to be, it is really easy to do in Python. Like 5-10 lines of code. Just shows how little Scratch cares about the advanced community.

JSscratcher_2008 wrote:

colinmacc wrote:

slgsan-encrypted wrote:

JSscratcher_2008 wrote:

A user who joined recently has been causing a havoc in the cloud data history or cloud monitors of some popular cloud projects which is on the front page or in trending or is really popular. (I am not criticizing or against any scratchers on the community I am just reporting an issue which may be an exploit in scratch to resolve it) He/she has been setting the cloud variable to huge numbers using an exploit or by hacking idk and he/she is setting data name (which is not possible for a viewer or scratcher not owning the project) and naming them like to spam a certain studio or to advertise his/her youtube channel and to name the new data's . If this is an exploit or bug in scratch please fix it as soon as possible because the user or users' who are using it can set inappropriate words on the cloud data history's. Also the user who is setting the value is a New scratcher…

It can't be fixed, it's the nature of cloud variables; anyone can change it, if you want, try this:

if <not <(☁ cloud variable) = [original value]>> then
set [☁ cloud variable] to [original value]
end

No that won't work in scratch, because if you “look inside” and it's not your project it disconnects you from the cloud server.

This “hacking” is being done using an external script and it is a big problem that I think the scratch team needs to address quite urgently.

yes

i tried it and it wasnt my project and it worked once

popsiclej31 wrote:

On my project https://scratch.mit.edu/projects/1026678264/ A unidentified user named sdfdsgfxg is setting my cloud variables to 890858479, I believe it might be some sort of cloud variable exploit Cloud Monitor…

yup that same user ID messed up my friend's high scores, yet the actual username is nonexistant. someone is hacking the servers via something like scratchattach maybe, and the servers currently do not have protection against these kinds of things.

A shame they they're forcing the ST to break ScratchAttach to fix this for all us good users who use it to do cool things…