How To Access Private and Deleted Github Repositories Data

preview_player
Показать описание
In this video I discuss a GitHub attack vector that can let anyone access data from deleted or private Github Repos.

Read the blog post about this Cross Fork Object Reference bug on truffle security

My merch is available at

₿💰💵💲Help Support the Channel by Donating Crypto💲💵💰₿

Monero
45F2bNHVcRzXVBsvZ5giyvKGAgm6LFhMsjUUVPTEtdgJJ5SNyxzSNUmFSBR5qCCWLpjiUjYMkmZoX9b3cChNjvxR7kvh436

Bitcoin
3MMKHXPQrGHEsmdHaAGD59FWhKFGeUsAxV

Ethereum
0xeA4DA3F9BAb091Eb86921CA6E41712438f4E5079

Litecoin
MBfrxLJMuw26hbVi2MjCVDFkkExz8rYvUF
Рекомендации по теме
Комментарии
Автор

The title seems to be a bit overexaggaerated, it is not ANY private/deleted repo but it must be a private/deleted fork of a still existing public repo

tmbnes
Автор

Basically, forks are not clones. Forks are like some kind of top-level branches above each repo branch.

davidt
Автор

Microsoft be like “we brought recall to GitHub to enhance the user experience” or some variation of Julian Smith’s “I made this for you!”

gwky
Автор

This is just Git. If you push your API key to a repository, it's on the Internet forever.

James
Автор

It's not a bug. It's normal behavior, as expected. All hashes are public, even if your repo is private.

leofun
Автор

So does that mean I can get into the yuzu repo?

piked
Автор

Isn't this well-known? I thought everyone knew that forks had the same visibility as the parent repo.

MithicSpirit
Автор

Mental ur the goat. Have a great weekend. Watched all the way through

jabrowski_
Автор

Quite a few bots in this comment section, why though? Doesn’t sound like any Mental Outlaw viewer would fall for them and I haven’t seen them around previously…😊

papakamirneron
Автор

Secrets are usually not commits in the repo (and never should be) but a setting on organization level.
Devs using Github do not need access to the key but the name of the key that somebody set as secret in the organization to reference it in the build and integration process. And for their local use they can use another development only key, which if committed can be easily revoked.
I understand that this feature loads the gun with which dumb devs can shoot themselves in the foot, but I don't think Microsoft is to blame if that happens.

marsovac
Автор

6:30 it doesnt work for private commits, right?

dandyddz
Автор

You can alternatively mirror your github repos on gitlab, codeberg, gitea, or even self-hosted instances. So you don't have to ditch all of the cool github CI/CD features

unixmind
Автор

Nobody pushes anything of value to github anymore since they used all that code to train copilot

trailblazingfive
Автор

Copy and paste is such an advanced black hat hacking tool

FreedomEver
Автор

If you commit any sensitive data like keys you should create new ones and make sure existing ones no longer work. That is just industry best practice. Is this "never delete" policy good? Maybe not, but you still have a way to protect yourself from this particular issue.

DankoStojanovic
Автор

I think this really actually is by design not just for gh.. I once tried uploading all my backups of videos on facebook on a burner account so I can watch them anytime, including some of the anime I wanted to watch just to see what would happen. Though the anime would be taken down eventually due to copyright, I made a copy of the autogenerated URLs beforehand on a spreadsheet (I also intended to share them with friends lol) and I found I could still watch them only on that burner account. I think big companies never really delete anything on their servers for any potential lawsuits they might encounter in the future, and so they just make it inaccessible but all the data is still there on their servers. However the content should not be accessible to just anyone with the hash. They need to patch that lol

louieestonanto
Автор

If the repo was created as private and remains private how this "bug" will occur?

blackpiller
Автор

in git, where you are the only party who has access to you repo, this is indeed a feature and works as intended (until the commit gets gc'd), but on github, this is an issue.
this is why i told my old company they will need to change their secret api key if they ever make the repo public, not just delete it,

SArthur
Автор

that's no github bug, it about git and it's still not a bug. i don't know git internals well but there are a few things about commits.
first, under no circumstances should anyone commit secrets like API keys or passwords. that's no different whatever source control you use maybe except an internal one.
i've read that once you push a commit to github it's not possible to delete it. you can delete commits but they will still be in github servers. or so i've read. (turns out that is false. check replies)
think 5 times very carefully when you are working with git and secrets.

ardnys
Автор

Huh, I thought I noticed this on enterprise a few months ago where I could see commits of deleted branches. I figured it’s just zombie commits hanging out server side, but the fact this is an issue with privacy and not considered a bug is worrisome.

jonb