Skipping over most of this (the vulnerability is not really investigated at all in the stream). But the gist of it is that "access devin's machine" links are tough-to-guess but unauthenticated URLs, so anyone who has that URL has all the same access Devin does to your account.
When you select "access Devin's machine" it opens up a online version of vscode, but there was no auth gating on the URL. So if the URL gets leaked for whatever reason (the unique part of which was the subdomain) then anyone with that URL can everything being worked on.
They have since added an auth gate to the online version of vscode that gets spawned.
I took that to be a "joke" by one of his viewers (his viewers are a joking crowd) or a guess, because why wouldn't you just issue a handful of wildcard certs instead of spamming subdomain cert issuance, so I thought nothing more of that comment. (heck both LE and AWS (The two cert issuers I have the most recent experience with) both rate-limit certs, either how many certs you can request in a period of time (le) or have active at any one time (aws), unless you manually request an exemption. IMO it's more work to issue a freshly minted cert for each instance you create then just slapping a wildcard cert on them all)
But as you brought it up I went and checked [0], There are only 3 subdomains on the devinapps.com domain in the cert logs with those kind of subdomains, all dated from May 21st to May 26th 2024 issued by Let's Encrypt, so prob just test/dev instances, also those certs have since expired and the URLs appear are not longer "active".
Today the devinapp.com subdopmains are indeed behind on a wildcard domain issued by AWS. (you can query DNS for {anything}.devinapps.com and dns will reply with the same set of IP's hosted on AWS, and if you visit {anything}.devinapps.com you will (most likely) get a 404 from an nginx server using a wildcard cert)
Thanks for doing that work. I had actually looked at this and spotted the two subdomains, which I erroneously took as evidence in support of the comment, as I'm largely unfamiliar with what crt.sh is actually showing.
I don't know what Devin is but it sounds like this is just a case of using a high entropy uuid as a workspace address, it's not that different than password auth if, say, your password was in the query string. Not great, but basically it's "anyone with a link" method of sharing access.
Did Google Photos ever change their auth scheme? I know I was surprised once when I found out the direct URL of my jpegs was "public"
It’s very common for CDN URLs to be public, but to be signed and only work for a limited amount of time. This is because it’s very hard to scale authorisation to edge CDN scale while keeping the performance benefits. This is a security tradeoff, sure, but a very common one.
I tried to watch this, but a young man’s silly antics are not educational for me. Maybe people who stream have to ham it up to get likes, but I’d rather see serious people at work.