Vulnerabilities in Blocklive

[PPPDUD]

Just an FYI, @GarboMuffin has uncovered vulnerabilities in this project, which are currently public information. I haven't tested any of these yet.

Edit: As pointed out by @GarboMuffin, these vulnerabilities may no longer exist.

[GarboMuffin]

Everything described in that post is from 2024, as is clarified in the title and the first sentence of the body. It's not making any claims about the state of blocklive today. I don't know anything about the state of the project today.

[GarboMuffin]

Although, there are many very obvious and very critical vulnerabilities in the current version of the code on GitHub

For example, basically all auth checks are completely broken. Everything in here passes in undefined for bypassBypass (????) so every auth check just passes instantly

There's also still XSS

[GarboMuffin]

These are the same symptoms that I talked about in 2024. They were never properly fixed.

For the XSS, a possible attack would be:

• Enumerate all Blocklive/Livescratch users (via cloud variable auth logs?)
• Create a new livescratch project for each user using one of the unauthenticated endpoints to create a new project, which will make that new project show up in the my stuff page
• Anyone who clicks the my stuff page will see the project, probably try to leave it because they wouldn't recognize it, but clicking that leave button triggers XSS

Luckily, livescratchapi.waakul.com seemed to only have ~270 projects on it as of last night, so it seems this thing is not widely used anymore. Unfortunately, even people who just passively have the extension installed are susceptible to this because the XSS is on the my stuff page, not when actively editing a project

The overall security posture of this project - backend and extension - is quite bad.

[GarboMuffin]

It's worth noting that any frontier language model today can develop that attack end-to-end with a copy of the source code and not much more prompting.

[PPPDUD]

Just in case Blocklive deletes this issue, this is an archived version.

[GarboMuffin]

A few more issues with the auth on livescratchapi.waakul.com:

Even setting aside all the issues inside authenticate(), the authentication exchange flow before this point is unsound. Because an attacker can view public cloud variable logs, they can see every username/code pair that has been used. Once an attacker observes one of these, they can then start a bunch of auth attempts for that user until the attacker gets a server-generated login code that matches what already exists in the server logs. There is no rate limiting and the verification code is only 6 digits, so it's perfectly feasible to do this. They can then complete the auth flow on behalf of the victim at to obtain the victim's token.

The API also uses Math.random() extensively for things that would ideally be cryptographically secure. There should be various ways to observe the internal state of this to be able to predict future verification codes, since V8 Math.random() is not intended to be very secure.

The authentication system uses non-timing-safe comparisons to check if the token matches what it should be. There could theoretically be a way to gradually send a lot of requests and observe how long it takes to slowly deduce a user's token (very theoretical - doubtful this is practical in real-world setting)