API keys per ongeluk op Github, na delete nog zichtbaar!

[Jazco2nd]

*Paniek*
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).
Ik heb dit bestand volledig verwijderd, de historie alles is weg online. Nu krijg ik bericht van Sendgrid dat mijn account suspended is omdat de API key op github staat.
In de mail zit een rechtstreekse link naar een github blob binnen mijn repository en inderdaad, het gewraakte .env bestand met alle gevoelige info.


Ik kan niks met dit bestand doen! Wissen kan niet, bewerken kan niet "You must be on a branch to make or propose changes to this file."

Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.

git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.

Hoe kan je zoiets compleet wissen?

[GlowMouse]

https://docs.github.com/e...ve-data-from-a-repository

[Yukkie]

Kun je niet de hele repo op private zetten of weg gooien?

[Jazco2nd]

GlowMouse schreef op woensdag 10 maart 2021 @ 14:54:
https://docs.github.com/e...ve-data-from-a-repository

Ik heb juist dat gebruikt, de BFG cleaner vorige week. Ik kan dus zelf ook niet het bestand vinden online, alleen met de rechtstreekse link die ik van Sendgrid kreeg.

edit: ik ga gewoon nog een keer die stappen volgen, maar ik heb het vorige week dus ook 2x geprobeerd om zeker te zijn dat het weg was.

[ Voor 15% gewijzigd door Jazco2nd op 10-03-2021 14:56 ]

[bwerg]

Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.

Even voor de zekerheid: je bedoelt niet "het bestand staat niet in de laatste revision" neem ik aan?

("de historie alles is weg" impliceert dat je het goed hebt gedaan, maar toch)

[Jazco2nd]

bwerg schreef op woensdag 10 maart 2021 @ 15:06:
[...]

Even voor de zekerheid: je bedoelt niet "het bestand staat niet in de laatste revision" neem ik aan?

("de historie alles is weg" impliceert dat je het goed hebt gedaan, maar toch)

Klopt, het staat in geen enkele revisie als ik hier kijk waar het bestand was:

code:

https://github.com/username/repositoryname/blob/master/foldername/(filename)

Er is dus geen file, in geen enkele revisie.

Maar met de rechtstreekse link van sendgrid zie je gewoon nog steeds het bestand:

code:

https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename

Ik heb zojuist weer de stappen uitgevoerd zoals die hier staan, dit keer niet BFG-Cleaner gebruikt en de stappen voor beide url paden uitgevoerd:

code:

git clone
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch PATHTOFILE" --prune-empty --tag-name-filter cat -- --all
git push origin --force --all
git push origin --force --tags

en ook stap 10..

Niks veranderd. De file staat nog steeds beschikbaar via de link van Sendgrid

[ Voor 3% gewijzigd door Jazco2nd op 10-03-2021 15:19 ]

[GlowMouse]

Helpt dit?
https://stackoverflow.com...ed-blobs-from-my-git-repo

[Jazco2nd]

als ik via de Sendgrid link "1 stap hoger ga" staat er duidelijk "tree" in de url. Ik gebruikte helemaal geen trees, werkte altijd in de master branch. Dus er is een tree ontstaan en binnen die tree bestaat het bestand nog.. Maar als ik

code:

git worktree list

doe, zie ik alleen de master tree.

[Jazco2nd]

GlowMouse schreef op woensdag 10 maart 2021 @ 15:22:
Helpt dit?
https://stackoverflow.com...ed-blobs-from-my-git-repo

Nope, heb het antwoord met de meeste stemmen (231) geprobeerd. De antwoorden daaronder komen overeen met de Github documentatie.

[Luc45]

Als zulke geheime data op het internet heeft gestaan is het er bijna niet meer af te krijgen. Tuurlijk is het handig om het alsnog weg te halen, maar het is sowieso ook verstandig deze API keys te revoken en nieuwe aan te vragen. Mocht iemand ze nog ergens op het internet vinden, dan zijn ze in ieder geval ook niet meer geldig.

[DataGhost]

Umm, dit soort data weghalen uit een version control-repo is op zichzelf al tricky, maar het weghalen uit zoekmachines, andere archivers, repo-clones en persoonlijke opslag van mensen die het al gezien hebben is zo goed als onmogelijk. Ik mis een beetje waarom je niet voor de makkelijkste optie bent gegaan, namelijk het wijzigen van je wachtwoorden en API-keys bij de betreffende services? Je moet ze sowieso als compromised beschouwen.

[Woy]

Zoals al gezegd is, is het sowieso verstandig om de gegevens aan te passen, want het kwaad is al geschied.

Als je het toch weg wil halen zou je ook gewoon de volledige repo kunnen verwijderen, en een nieuwe aanmaken en daar de aangepaste repo zonder de gegevens naar toe pushen ( Wel zorgen dat het lokaal ook echt weg is )

[Kalentum]

Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.

Ik neem aan dat die keys al gewijzigd zijn.

Misschien dat GitHub ook nog ergens iets cached?

[Jazco2nd]

@Luc45 @DataGhost @Woy
Dat is sowieso gedaan, helaas vandaag pas, want vorige week na de commit heb ik onmiddelijk de documentatie gevolgd om het te verwijderen. Het stond geen minuut online (ik weet nu dat good practice is het onmiddelijk allemaal te wijzigen/revoken al stond het maar een seconde online).

Nu blijkt dus dat het in een aparte tree, die ik niet kan clonen blijkbaar, al een week online stond

Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen? Ik begrijp sowieso niet hoe de tree is ontstaan, daar ik nooit werk met trees, ik houd het simpel.

ik heb inmiddels een verzoek ingediend via Support om sensitive info te verwijderen.. https://docs.github.com/e...nformation-removal-policy

[ Voor 21% gewijzigd door Jazco2nd op 10-03-2021 15:47 ]

[Klippy]

Jazco2nd schreef op woensdag 10 maart 2021 @ 15:45:
[..]
Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen?
[..]

git, niet github. GitHub is gewoon een git host, zoals er velen meer zijn.
Het hele doel van git is natuurlijk versiebeheer en het opbouwen van historie zodat je niks perongeluk kan verwijderen of niet kan terugdraaien bij een fout (jij zelf, maar vooral iemand anders die in je code werkt).
Dus ja, als je dat wel wil doen is dat in theorie onmogelijk zonder commandos als `git-filter-branch` die je normaal niet snel zou gebruiken want dat vervangt je hele historie. Vandaar de vele warnings.

Ben dan ook benieuwd naar die "Private Information Removal", lijkt er op dat als ik nu een fork zou maken van je repo je alsnog pech hebt.
Maar er zijn zo veel git caches dat het zoals gezegd niet veel nut zal hebben. Keys roteren en klaar.

[Kalentum]

Jazco2nd schreef op woensdag 10 maart 2021 @ 15:45:
@Luc45 @DataGhost @Woy
Maar is github dan zo verschrikkelijk ingewikkeld dat er geen optie is om 1 enkele commit volledig te verwijderen? Ik begrijp sowieso niet hoe de tree is ontstaan, daar ik nooit werk met trees, ik houd het simpel.

Dat woordje 'tree' is een GitHub dingetje, geen git ding. Het betekent dat de GitHub website een bestandslijst (directory) gaat tonen. Dus bv tree/2342424 verwijst naar de directorystructuur in commit 2342424. Als GitHub de inhoudt van een bestand toont dan staat er 'blob'

Daar heb je verder geen invloed op.

https://git-scm.com/docs/git-worktree Git Worktree is een heel ander concept en heeft niets met wat GitHub een 'tree' noemt te maken.

dus

code:

 https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename

'eenlangestring' is een commit hash. Als jij die commit hebt verwijderd, dan lijkt het me dat Gitthub het niet meer zou moeten tonen en dat het dus een cache issue is.

[ Voor 14% gewijzigd door Kalentum op 10-03-2021 16:12 ]

[Freeaqingme]

Jazco2nd schreef op woensdag 10 maart 2021 @ 15:45:
@Luc45 @DataGhost @Woy
Het stond geen minuut online

Het gaat er niet om of/dat het online gestaan heeft, laat staan hoe lang. Het gaat er om dat het gedeeld is met een derde partij. Nou zal Github niet direct iets met jouw api-keys doen, maar voor hetzelfde geldt is er net in 'die ene minuut' een backup gemaakt van die server, en wordt Github over 6 maanden gehackt, waarbij men in die backup gaat speuren.

[Hydra]

Het heeft helemaal geen zin die key nog te verwijderen. Hij is al lang gescraped. De enige optie is de key blokkeren/verversen.

[Hydra]

Freeaqingme schreef op woensdag 10 maart 2021 @ 16:21:
Het gaat er niet om of/dat het online gestaan heeft, laat staan hoe lang. Het gaat er om dat het gedeeld is met een derde partij. Nou zal Github niet direct iets met jouw api-keys doen, maar voor hetzelfde geldt is er net in 'die ene minuut' een backup gemaakt van die server, en wordt Github over 6 maanden gehackt, waarbij men in die backup gaat speuren.

Er zijn gewoon heel veel bots die die dingen scrapen om Bitcoin miners e.d. te starten op hosts. Heb het zelf zien gebeuren bij een klant; het was serieus een kwestie van minder dan een uur.

[Anoniem: 882605]

Vreemd dat niemand vraagt of dit een publieke of private repo was. https://tecadmin.net/delete-commit-history-in-github/

of source files kopieren en nieuwe repo maken.

[Hydra]

Anoniem: 882605 schreef op woensdag 10 maart 2021 @ 22:08:
Vreemd dat niemand vraagt of dit een publieke of private repo was. https://tecadmin.net/delete-commit-history-in-github/

of source files kopieren en nieuwe repo maken.

Afaik kan sendgrid dit alleen weten als het een public repo is.

[Vloris]

Jazco2nd schreef op woensdag 10 maart 2021 @ 15:16:
[...]


Klopt, het staat in geen enkele revisie als ik hier kijk waar het bestand was:

code:

https://github.com/username/repositoryname/blob/master/foldername/(filename)

Er is dus geen file, in geen enkele revisie.

Maar met de rechtstreekse link van sendgrid zie je gewoon nog steeds het bestand:

code:

https://github.com/username/repositoryname/blob/eenlangestring/foldername/filename

Je spreekt jezelf nu tegen.
In de huidige master is het bestand niet terug te vinden, in de revisie waar sendgrid naar linkt ("eenlangestring") nog wel.

Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.

[Kalentum]

Ik dacht dat hij de commit had verwijderd en een force push had gedaan... maar blijkbaar niet?

[Lethalis]

DataGhost schreef op woensdag 10 maart 2021 @ 15:38:
Umm, dit soort data weghalen uit een version control-repo is op zichzelf al tricky, maar het weghalen uit zoekmachines, andere archivers, repo-clones en persoonlijke opslag van mensen die het al gezien hebben is zo goed als onmogelijk. Ik mis een beetje waarom je niet voor de makkelijkste optie bent gegaan, namelijk het wijzigen van je wachtwoorden en API-keys bij de betreffende services? Je moet ze sowieso als compromised beschouwen.

Inderdaad. Zo snel mogelijk die API keys veranderen.

Er zijn namelijk mensen die speciale github crawlers hebben hiervoor en binnen notime die keys te pakken hebben. Dan krijg je van die leuke verhalen dat iemand ineens een heel virtueel server park heeft in zijn bezit bij AWS voor vele duizenden euro's per maand zonder dat zelf door te hebben (totdat de creditcard rekening binnenkomt).

@Jazco2nd Heb je github per se nodig trouwens? Ik zou gewoon lokaal een gitea server draaien en die lekker privé houden.

[ Voor 6% gewijzigd door Lethalis op 11-03-2021 09:58 ]

[Hydra]

Vloris schreef op donderdag 11 maart 2021 @ 09:12:
Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.

Idd. Zelfs als je een branche pushed en daarna die hele branch verwijdert heb je nog twee problemen. 1. Het is al lang gescraped door bots. 2. het staat altijd nog in de reflog en is dus terug te vinden.

[Hydra]

Lethalis schreef op donderdag 11 maart 2021 @ 09:55:
Er zijn namelijk mensen die speciale github crawlers hebben hiervoor en binnen notime die keys te pakken hebben. Dan krijg je van die leuke verhalen dat iemand ineens een heel virtueel server park heeft in zijn bezit bij AWS voor vele duizenden euro's per maand zonder dat zelf door te hebben (totdat de creditcard rekening binnenkomt).

Ik heb dit zelf bij een klant meegemaakt. Externe partij had deploy keys gepushed naar een publieke Git repo. In no time (echt binnen een uur) stonden er een hele berg bitcoin miners te draaien. AWS had dit zelf door en de account manager heeft het bedrijf gebeld om te melden dat dit aan de hand was. Erg netjes van ze; de klant zelf had het helemaal niet door.

[Hydra]

Lethalis schreef op donderdag 11 maart 2021 @ 09:55:
@Jazco2nd Heb je github per se nodig trouwens? Ik zou gewoon lokaal een gitea server draaien en die lekker privé houden.

Niks mis met github. Sterker nog; als je dit soort fouten maakt vooral NIET je spullen zelf gaan draaien. Github heeft gewoon prive repos.

[Lethalis]

Hydra schreef op donderdag 11 maart 2021 @ 09:59:
[...]
Niks mis met github. Sterker nog; als je dit soort fouten maakt vooral NIET je spullen zelf gaan draaien. Github heeft gewoon prive repos.

Jein (ja en nee).

Ik snap dat het slecht gedrag kan bevorderen, omdat je jezelf veilig waant met een eigen / lokale git server.

Maar je spullen liggen ook niet meteen op straat als je dan toch eens een fout maakt. Je moet dan minimaal toegang hebben tot het netwerk waar gitea op draait en gitea heeft ook gewoon private repos En onbeperkt, gratis en voor niets.

Je moet wel zelf je backups regelen uiteraard, maar goed... dat geldt voor alles.

PS
Wij exposen gitea niet naar het internet toe. Je moet minimaal met een VPN client verbinding maken eerst, voordat je er vanaf afstand bij kan.

[ Voor 9% gewijzigd door Lethalis op 11-03-2021 10:11 ]

[Hydra]

Lethalis schreef op donderdag 11 maart 2021 @ 10:09:
Maar je spullen liggen ook niet meteen op straat als je dan toch eens een fout maakt.

Waarom niet? Een private repo op public zetten op github is niet makkelijker dan een soortgelijke fout maken met je eigen spul. Daarbij komt dat 'een fout' bij self-hosting kan betekenen dat je alles kwijt bent.

Ik vind het geen goed advies, sorry.

[Lethalis]

Hydra schreef op donderdag 11 maart 2021 @ 10:11:
[...]
Waarom niet?

Omdat we het niet direct aan het internet hangen Dus als je geen VPN client hebt met de juiste certificaten, kom je er überhaupt niet bij.

Grootste risico van self-hosten vind ik het maken van goede back-ups (offsite + offline / immutable). Dat moet je dus absoluut wel goed op orde hebben, mocht die dag een keer komen dat je met ransomware of iets dergelijks te maken krijgt.

Maar ik ben het met je eens dat het:
1. Slecht gedrag zou kunnen bevorderen.
2. Het betekent dat je ineens ook systeembeheerder bent (en dat wil je niet altijd zijn).

Vandaar mijn jein. Op mijn werk draaien we sowieso veel op eigen servers en zijn de back-ups al geregeld enzovoorts, dus dan speelt punt 2 wat minder een rol. Ik heb overigens wel vaak geprobeerd management ervan te overtuigen clouddiensten te gebruiken - en privé wel degelijk met github, AWS en Azure gespeeld - maar dat willen ze simpelweg niet.

[Hydra]

@Lethalis voor mij is het simpel; tenzij je als bedrijf als core business hebt een Git host te zijn, kun je het beter niet zelf beheren.

[CodeCaster]

Vloris schreef op donderdag 11 maart 2021 @ 09:12:
[...]

Volgens mij snap je nog niet helemaal hoe git revisies en history werken. Het feit dat een bepaalde revisie niet in de history van master zit wil nog niet zeggen dat die revisie meteen helemaal verwijderd is.

Volgens mij jij ook niet, anders zou je wel vertellen wat hij eraan kan doen?

Een niet-gereferencede commit blijft nog even hangen in Git, om zo destructieve acties toch ongedaan te kunnen maken vanuit het reflog.

Dus, TS:

quote: https://rtyley.github.io/bfg-repo-cleaner/

The BFG will update your commits and all branches and tags so they are clean, but it doesn't physically delete the unwanted stuff. Examine the repo to make sure your history has been updated, and then use the standard git gc command to strip out the unwanted dirty data, which Git will now recognise as surplus to requirements:

$ git reflog expire --expire=now --all
$ git gc --prune=now --aggressive

Dit haalt de commit en de referenties ernaar lokaal weg, maar ... dit kun je niet pushen. Je moet wachten tot Github zelf ook een garbage collection heeft gedraaid. Dat gebeurt hooguit eens per 24 uur.

En in de tussentijd kan de hele wereld jouw API-keys lezen, dus zoals hierboven al herhaaldelijk gemeld: blokkeer ze (dat heeft Sendgrid blijkbaar al gedaan) en vraag nieuwe aan.

[ Voor 9% gewijzigd door CodeCaster op 11-03-2021 10:45 ]

[Voutloos]

Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).

Uit deze tekst kan ik niet helemaal opmaken welk bestand nou echt in git staat, maar voor deze zekerheid een good practice: Je wil doorgaans iets van een .env.example in git en de echte .env in je .gitignore.
Als dat de opzet is, heb je ook de extra drempel van het plakken van echte waardes richting een voorbeeldbestand. En dat moet je gewoon nooit doen.

[Vloris]

CodeCaster schreef op donderdag 11 maart 2021 @ 10:43:
[...]

Volgens mij jij ook niet, anders zou je wel vertellen wat hij eraan kan doen?

Behalve zorgen dat de gelekte API keys nergens meer gebruikt worden zou ik adviseren er vooral niets meer mee te doen! Je kunt alleen maar meer stuk maken dan je wilt als je niet precies weet waar je mee bezig bent met dit soort trucjes met de inner-workings van git.

[Woy]

Sowieso is het natuurlijk al een goed idee om dit soort secrets uberhaubt niet in dergelijke config files op te slaan die uit de root van je git repo gelezen worden. Gebruik liever iets als Azure Vault, AWS Secrets Manager of Kubernetes Secrets.

Als deze gegevens niet uit dergelijke files gelezen worden kun je ze ook niet per ongeluk comitten.

[raptorix]

Woy schreef op donderdag 11 maart 2021 @ 14:06:
Sowieso is het natuurlijk al een goed idee om dit soort secrets uberhaubt niet in dergelijke config files op te slaan die uit de root van je git repo gelezen worden. Gebruik liever iets als Azure Vault, AWS Secrets Manager of Kubernetes Secrets.

Als deze gegevens niet uit dergelijke files gelezen worden kun je ze ook niet per ongeluk comitten.

Dit dus, en door dit soort gepruts is Sendgrid niet meer fatsoenlijk te gebruiken, vorig jaar massaal geblacklist op Spamhaus

[Woy]

raptorix schreef op zondag 14 maart 2021 @ 10:31:
[...]

Dit dus, en door dit soort gepruts is Sendgrid niet meer fatsoenlijk te gebruiken, vorig jaar massaal geblacklist op Spamhaus

Ja, ik ben er ook helemaal weg gemigreerd. De support van sendgrid was echt waardeloos. Het heeft meer dan een maand geduurd voordat er gedelist was, en binnen de kortste keren waren ze weer geblacklist. Enige reactie was dat dat blijkbaar is wat je van sendgrid mag verwachten. Daar ga ik niet voor betalen.

[raptorix]

Woy schreef op zondag 14 maart 2021 @ 11:36:
[...]

Ja, ik ben er ook helemaal weg gemigreerd. De support van sendgrid was echt waardeloos. Het heeft meer dan een maand geduurd voordat er gedelist was, en binnen de kortste keren waren ze weer geblacklist. Enige reactie was dat dat blijkbaar is wat je van sendgrid mag verwachten. Daar ga ik niet voor betalen.

Plus dat een betaald account vrij duur is als je maar 100 mails per maand ermee stuurt, ik had het aanvankelijk op een trial van een ander product gedaan maar dacht dat dat na trial stopte (bleek niet zo te zijn )

Uiteindelijk maar een apart outlook online account gebruikt.

[igmar]

Jazco2nd schreef op woensdag 10 maart 2021 @ 14:52:
*Paniek*
Mijn docker compose yml staat op github inclusief een voorbeeld .env bestand. Per ongeluk had ik dat laatste bestand vorige week geupdate met mijn eigen .env bestand, waar mijn persoonlijke variabelen in staat (wachtwoorden, API keys van mijn homeserver).
Ik heb dit bestand volledig verwijderd, de historie alles is weg online. Nu krijg ik bericht van Sendgrid dat mijn account suspended is omdat de API key op github staat.
In de mail zit een rechtstreekse link naar een github blob binnen mijn repository en inderdaad, het gewraakte .env bestand met alle gevoelige info.


Ik kan niks met dit bestand doen! Wissen kan niet, bewerken kan niet "You must be on a branch to make or propose changes to this file."

Ik ga nu als de donder al die gegevens veranderen natuurlijk, voor zover ik dat nog niet had gedaan. Maar ik wil dit bestand echt helemaal weg hebben.

git clone heeft geen nut: het bestand lijkt niet meer in mijn repository voor te komen dus wordt ook niet lokaal gedownload.

Hoe kan je zoiets compleet wissen?

Als de keys op github staan zijn ze compromised. Einde verhaal, dat is niet op te lossen. Ze zijn waarschijnlijk al gescraped, en worden actief gebruikt.

Ook een eventuele opschoonactie in git zal dit niet veranderen : Die keys zijn al gescraped. Advies : Roteer je API keys, en zorg dat dit niet meer gebeurd. Werk in een deploy pipeline met placeholders, en voor locale development met environment variables.