Stealing Your Private YouTube Videos, One Frame at a Time
bugs.xdavidhu.me
bugs.xdavidhu.me
DSC001.mp4
And then filtering that by recently uploaded always yields interesting results. For those that don't know, `DSC-XXX` is a standard naming scheme for digital cameras. More on the default naming scheme in the following link[1][0] https://www.urbandictionary.com/define.php?term=fat-fingerin...
[1] https://en.wikipedia.org/wiki/Digital_camera#Digital_Still_C...
[2] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...
(6 views at time of posting it here)
Thank you.
EDIT: Wow I kindly say something is disturbing to me and y'all respond with down votes. Thanks for the compassion.
For late readers who are deciding on whether to watch it: the video shows somebody butchering some deer meat, and the deer carcass is shortly seen hanging in the background.
Those words may technically be accurate, but I don't think that's a very fair representation of what's going on in the video.
It may be worth considering how ordinary and unremarkable such a sight is to all the world's humans. Even in the first world, a stroll down Chinatown of any major city is bound to result in seeing some "carcasses" hanging upside down from the ceiling.
Some may object to the idea of labeling the customs of such a huge swath of the global population as something which demands a warning.
Walking down the street in Chinatown I may not be too surprised to see a hanging animal carcass, but this is Hacker News not a street market.
> unremarkable such a sight is to all the world's humans
Vegetarianism is pretty common in the world, with for example 30% of India being vegetarian[1]. So be careful not to project your own thoughts on to "all the worlds humans".
[1] https://www.hinduamerican.org/blog/4-things-about-hinduism-a...
Cows eat grass, turn into huge balloons of meat, and feed lots of people. They take almost no maintenance.
I can't think of a more efficient way to feed people.
https://iopscience.iop.org/article/10.1088/1748-9326/aad401#....
https://iopscience.iop.org/article/10.1088/1748-9326/11/10/1...
[0] https://www.sbnation.com/2015/7/17/8990773/accidental-upload...
Monitoring network traffic (http requests) and logs is similar to any other logged data or reading disassembled code. Patching in a different video ID is sort of like patching ASM to implement some hack. The automation created at the end to extract and assemble the video was basically creation of cracking software for this particular exploit.
What one person calls arcane knowledge is another's everyday tools. This is a case where I see obscure technical stuff, but web devs see regular stuff ;-)
Point taken. If this had been something about Android I'd be staring at my screen drooling like a dog looking at a TV.
> With my first account, I started using YouTube, trying every feature, pressing every button I could find, and whenever I saw an HTTP request with a video ID in it, I changed it to the target Private video
Was this done with some tooling or scripts, or purely by eyeing devtools? I could see that step for example being very similar to "parse WireShark logs", for example.
I agree that the level of detail included makes it fairly readable without being to scary to non-experts.
Pretty much every single web vulnerability researcher uses it, to the point of absurdity. Squint hard enough and screwdrivers have a familiar shape, so you of course you look for a big enough hammer.
When user agent (UA) makes authenticated call to service A, which in turn makes call to service B:
UA -[user auth]-> A -[????]-> B
how to pass authentication information from A, when making a call to B? Options I can think of:
- pass UA token as is. This has a problem that token becomes too powerful and can be made to call any service.
- pass own token and pass user auth info as an additional field. This doesn't solve confused deputy problem, since own token can be used with any user auth and service B can be tricked to make request for data in B not belonging to user
- Mint new unique token derived from tuple (A own token, UA token, B service name). B then extracts user information from the token presented by A and authorizes request. This seems to solve confused deputy problem, because A has no access to other UA tokens, so it can't mint a new token for a wrong user. Downside is that token minting should probably be done in another service and it requires making a call to it for almost every request between two microservices, making it a bottleneck pretty quickly.
I've never seen last one in real life, maybe it has some critical flaws I am failing to see?
Not sure what you mean by "token becomes too powerful and can be made to call any service." Each sub-service can have in token what is required to access it, and that can be managed by main frontend service.
There is a limit to token size but you can easily optimize claims and stuff to not go overboard in majority of cases.
If UA token is passed as is down the chain of microservices, then every service starts to accept it. Intercepting this single token allows attacked to craws whole internal system. It wont grant access to other users data, but nevertheless it doesn't seem like a secure solution to me.
> Each sub-service can have in token what is required to access it, and that can be managed by main frontend service.
This would require UA token to contain audience claim of every single internal service, this is unlikely to pass security review.
It can intercept it, but can not change it. It can replay it eventually (even that shortly, depending on timeframe of your access token which is usually minutes) but you can protect against it.
> This would require UA token to contain audience claim of every single internal service, this is unlikely to pass security review.
I have penetration tests on my main service. Sub-services are not accessible and can be secured to desired level on the internal network. I never had security inspections on internal services (I work on highly critical gov systems). Maybe in some domains its like you say but I believe its generally not a problem. Furthermore, we need to have some perspective on this - there are multiple easier ways to hack a service and there probably exists big number of other exploits that are easier to achieve.
Service B then uses A token for authentication, but UA token for authorization.
That way account A couldn’t access account B’s decryption key to get to their private video data
Bonus: When using a mesh service like this, you can also ban/rate-limit/load-balance/canary calls between any two microservices if necessary.
The way Google does mutual authentication between services (which, I reiterate, does not address this problem) is described in great detail at https://cloud.google.com/security/encryption-in-transit/appl...
Doesn't Kerberos solve this with s4u2self and s4u2proxy and other delegated credentials?
I'll admit it isn't quite the exact same, but the general idea is the same.
UB has a list of allowed intermediates (in this case, A) so user agent doesn't send it to every service.
In my implementation there were various kinds of tokens, so UB couldn't be used by itself to invoke B directly.
For our situation all this complexity turned out to be not worth it. :-/
This reminds me more of the Facebook bug where www.facebook.com had access control but mobile.facebook.com didn't. I don't really consider every endpoint to be a "deputy".
> A confused deputy is a legitimate, more privileged computer program that is tricked by another program into misusing its authority on the system.[0]
In this case, we know we don't have access to open the safe, but we were able to convince the deputy, who does have access to the safe, to give us what's inside one small piece at a time. The deputy didn't intend to empty the safe- he was only showing little bits of what's inside! That's all he's allowed to do with his access!
I see where the OP is coming from in calling it that.
The second option is indeed bad.
The third option is used heavily in production for both cost savings and latency reduction.
There's a 4th option which is to go back to your auth server with the UA token and get a new one representing all the data you discuss in your tuple, but still signed and valid representing (a, user, b). This is the on behalf of flow, and is standardized in oauth2 under the name Token Exchange, roughly.
(E - actually, my 4th and your 3rd are the same. My 3rd is an improvement to not require minting a new token)
Youtube video ID's were generated by taking an internal integer, and encrypting it with a fixed key. That key has been leaked in the early days of youtube (pre google buying it).
That means there are a bunch of early video id's that are predictable. That makes this bug much worse.
I feel like this article should demonstrate why private should be both things whenever possible.
> you could set a public video to private, or vice versa
You could, but if you don't leak the ID all over then it should provide an extra step of security.
> security by obscurity
Hiding an ID like this isn't all that different from hiding a key.
So this big created a method for continued albeit silent and low res access to private but known videos of note.
I think videos after being made private can be edited by the owner. So it would be possible for new “private” data from a known video id to leak this way.
For context, this is approximately what Google has to pay for an entry level engineer employee to work for ~40 hours.
Finding a bug of this severity level in a publicly accessible service with a bug bounty program every 40 hours of work is... a stretch of the imagination for an entry level person.
The author should "charge" based on a percentage of the value that this bug fix gives to google. I'd argue that for such a huge platform this bug is worth tens if not hundreds of thousands. Certainly would cause way more reputational damage than that of there was a large-scale data leak based on this.
As the music industry learned the hard way, if you make it too hard to be a good guy, everyone will become a bad guy.
I certainly don't see room for adding regulatory requirements here. And, about public pressure, this type of work is in its infancy, relatively speaking. Going straight for the throat is too much.
I don't mean that the US would chase you in Russia but you are digging yourself a hole and limiting options as you go.
Most companies are exploiting security researchers and pay them bounties that could be compared to the discounts found on Fiverr for different services.
5000 dollars is akin to to a very healthy contractor rate of $200 an hour at 25 hours of work, which is a conservative estimate of how much time OP spent discovering this. That to me feels pretty fair pay, based on things in reality, not some future value of potential costs savings that require some pretty hand-wavy maths to quantify.
* experts are paid for applying their knowledge, not their time[1][2]
* A “fair” time based system should also pay for unsuccessful searches e.g. the previous month unsuccessfully searching for a bug in Chrome.
* if person A spends 1 hour finding bug X, and person B spends 1000 hours finding exactly the same bug X, then it is a fallacy that you could pick a fair hourly rate.
Also I’ll mention that you don’t get paid according to how much damage a bug can cause. 1: usually the damages occur to a third party (e.g. users of Microsoft Windows, not Microsoft). 2: imagine you find ten bugs that could wipe out the business Acme - you can’t get paid 10x Acme’s value (not even just 1x Acme’s profits.)
The fact that a company has undervalued this work and failed to identify it as important, and someone external has identified it, makes it worth even more.
A ransom demand on YouTube might be unbounded in value, e.g.: https://www.lexology.com/library/detail.aspx?g=e4d1be15-18db...
For brilliant hackers in other parts of the world, then this might be a nice job. But I don't know if these bug bounties are available everywhere.
Microsoft used to pay 20k for exploit primitives that could potentially lead privilege escalation. These days the bounty program seem to require a demonstration (read: working exploit).
Zerodium offers up to 80k for a working local privilege escalation exploit. Depending on the workings, if that exploit can be used to break out of a browser sandbox you might earn a bonus.
The whitehat bounties are not market rate, if you only look at the monetary rewards.
Maybe that's mitigated because people with the know-how to find exploits like that are usually well-educated and not desperately in need of money, but people can be greedy.
Though if as a corp you cover the black market rate fully then there's really no reason for a researcher to ever sell on the black market.
But this problem is not there with all avenues for grey market transactions.
But I do wonder if it would be possible to set up a legal alternative. I suspect if you did you would find law makers lobbied to make it illegal and it would already be decided as unethical by the corporate designed ethics systems.
Last month on HN someone got £7500 from FB, but, everyone thought he should have got more: https://news.ycombinator.com/item?id=25401294
There is also a darknet diaries episode (can't remember which) but the guy who found a bug had got into instagram s3 buckets and source code, he felt he should have got the $1M bug bounty but instead facebook claimed he did it without permission to go further and got fuck all.
By the same logic, blind SQLi will typically be valued 'less' (hence pay out less) than SQLi with output.
Must say a quick thinker, and he's just 17 or 18.
This is absolutely one of the biggest issues I also have seen in several companies.
for the experienced hackers in the room - what would your reasonable next step be if you wanted to get audio or higher resolution video?
just wondering because i often see these researchers not stop after finding the first exploit, and its often the subsequent exploits built up from their knowledge of the system that uncover the really damning security holes
Imagine your business is built on Youtube. You want to be able to test things in your videos internally, and upload them prior to a scheduled release date.
Personally I'd bet on driving general engagement with the platform in some way, but the particular manner is not clear to me.
Well in that case the answer is super simple: The same reason Google provides any other free service, whether it be Maps, Gmail, Photos, Search, Hangouts, Meet, Pay, whatever. The more Google services you use and the more time you spend using them, the more you can be monetized.
Also, the versitility of youtube as a tool leads me to buy youtube premium for $10/mo.
Also, the most professional content creators upload private, then schedule the video public at a time that will get the most exposure by the youtube algorithm. They also pre-prepare multiple thumbnails and swap them out for the first few hours of public exposure. it's a calculus.
There are a lot of product announcements that are handled by uploading private videos that are made public at a given time, so there'd be quite a lot of attacker interest in this exploit if it hadn't been fixed. Worth the bounty.
I think HN is getting brigaded pretty badly for anyone who's said that Parler's security was garbage, so maybe that?
Chained with another exploit to actually be able to discover someone's private video IDs, it would have been worth a much higher bounty.
I honestly can't think of a week that goes by without the discovery of a private video ID in the videogame space tbh for some unannounced title or feature.
In practice, you're not finding a bug like this every week.
The bug bounty programs were originally intended to give a white hat market alternative to the black hat and gray hat markets. They don't do that. If I find a bug, and I want profit, I'm much better off selling to my government than to Google.
One can only imagine the number of exploits the US, China, Russia, North Korea, etc. have in their cyber-warfare vaults.
Exploits compound. Often, two minor exploits make a major exploit.
I got a 5k payout from google for serious OAuth bypass bug. I'm not a security researcher so I wouldn't have any idea or really desire to sell something like this to a Government.
But I'd have to agree that if I had publicly revealed the bug Goog would have lost magnitudes of business or possible fines from governments far above and beyond 5k.Some points to consider are that there's risk involved dealing with the black market, including getting the payout in a way that doesn't trace back to you and legal liability if you're caught, a company has no reason to pay >=$x for an exploit that will cost them $x, and beyond that I suspect a lot of people simply feel better about telling the company about an exploit than selling it to criminals who will use it for extortion and theft.
I don't think companies owe it to researchers to exclusively supply their income, but I think theres room for improvement on the payout when most of the point is to deter selling on the black/gray market.
For putting their ad at the point most relevant, maybe, or better still, putting their ad at the point to which their audience will skim to.
It definitely made me rethink each of interactions on my services.
The video is kind of incriminating due to what the person was discussing and the fact that he deleted it.
It's 2020, not 2021. The issue was reported in december 2019.
AFAIK this is against YouTube's EULA, so owning a resource is irrelevant. He doesn't own the accounts, Google does.
And Google prohibits any attempt at tampering with their systems.
So, they probably think it's okay.