Hackers stelen 500GB aan data uit private GitHub-repo's van Microsoft

Hackers hebben ruim 500 gigabyte aan data van Microsoft gestolen uit private repositories op GitHub. De aanvallers zijn van plan de data online weg te geven. Het is niet duidelijk wat er precies in de datadump staat, maar het lijkt niet te gaan om heel belangrijke broncode.

De hacker, of hackers, zouden rond 28 maart van dit jaar zijn binnengedrongen op het officiële GitHub-account van Microsoft. Daar kregen ze toegang tot de private repo's van het bedrijf. De hackers noemen zichzelf Shiny Hunters, en stapten met de informatie naar Bleeping Computer. De hackers vertellen dat ze ruim 500GB aan data hebben buitgemaakt. Het aanvankelijke plan was om die te verkopen, maar nu zijn de hackers van plan het te lekken.

Op hackerfora hebben de aanvallers een sample van 1GB aan data laten zien. Daar twijfelen sommige forumgebruikers aan de authenticiteit van de data, onder andere omdat er Chinese teksten in de code staan.

De hackers hebben ook code gedeeld met Bleeping Computer. Daarin staan vooral samples van code en testprojecten. Ook staat er code in van een PowerShell-project genaamd PowerSweep. Volgens Bleeping Computer zijn er voorlopig geen aanwijzingen dat er data is gestolen van bijvoorbeeld Windows of Office. Microsoft heeft nog niet op het lek gereageerd.

Reacties (115)

[NoobishPro]

En daarom heb ik een eigen servertje staan met GIT. Mensen mij maar een amateur noemen dat ik geen Github gebruikte omdat ik niet wil dat de broncode van mijn producten makkelijk uit te lezen is...

[OMX2000]

Wat mensen vergeten is dat github geen git is. Dus belangrijkste toegevoegde waarde van Github is het sociale aspect rondom het delen van code. De Pull Request/Merge Request is geen onderdeel van git. Maar helpt wel enorm in het samenwerken aan code.

Mocht dat samenwerken niet zo belangrijk zijn. Dan zou ik een github/gitlab achterwege laten. Echter vind ik dat echt niet van deze tijd meer. Zeker als je met meerdere mensen aan code werkt. Die PR’s zijn echt goud waard!

Oh er is ook een github on premise variant: https://enterprise.github.com/faq

[Jogai]

Errrm, https://git-scm.com/docs/git-request-pull

[OMX2000]

Die snap ik. Maar dat komt nog uit de tijd dat je mails rondstuurt met patches, en je moet ook server hebben waar die “request pull” op staat. Toch wat spartaanser dan de huidige PR’s die ertoe hebben bijgedragen dat je makkelijk een steentje kunt bijdragen aan een project en erover discussieren.

[Jogai]

Rondmailen (waar ik zowieso op tegen ben) is een keuze, maar was vooral om aan te geven dat git met het concept PR is gekomen, en github een mooie interface eromheen heeft gemaakt. Dus dit statement klopt niet:

De Pull Request/Merge Request is geen onderdeel van git.

[NoobishPro]

Github is tegenwoordig ook gratis voor private repo's. Daardoor is het hierin ook relatief populair geworden.

Ik ben het in principe wel met je eens, maar vind het een wat 'outdated' gedachtegang omdat ik veel bedrijven Github zie gebruiken als private repository.

[Oon]

Wij hebben op het werk ook een git server draaien, maar ik mis toch echt wel de web-ui van GitLab of Gitea. GitHub vind ik dan weer riskant, puur omdat het een derde partij is, maar 9/10 keer komen dit soort lekken door mensen die op een rechtmatige manier toegang hebben gekregen en hier niet zorgvuldig mee omgaan.

[sfranken]

Wij hebben op het werk ook een git server draaien, maar ik mis toch echt wel de web-ui van GitLab of Gitea.

Waarschijnlijk een schot voor open doel, maar GitLab kun je op je eigen server(s) ook draaien. Doe ik ook, voor privé projecten of dingen die ik niet wil delen maar wel in versiebeheer wil hebben.

[morphje]

Voor prive gebruik zou ik persoonlijk Gitea nemen. Dat kan je tenminste nog draaien op een pi. Gitlab eist nogal wat van je hardware helaas

[Ryaka]

Gitlab draait toch ook op een Rasp Pi 2?
https://about.gitlab.com/install/#raspberry-pi-2

[morphje]

Ja Windows 10 kan je ook draaien op 2GB geheugen, snel zal het alleen niet zijn.

Minimum viable requirements voor gitlab is 4GB geheugen, maar als je een beetje actief bent is dat zelfs al snel onvoldoende. Wij draaien ongeveer 60 private repo's op een gitlab instance en liepen al vrij snel tegen beperkingen aan. Je kan oa het aantal unicorn processes naar beneden brengen om het geheugen/cpu gebruik wat in te dammen.

Nu heeft gitlab voor ons een aantal voordelen in termen van samenwerking en meer functionaliteit voor teams, maar voor prive heb ik gitea en dat is meer dan voldoende en werkt default install perfect op een kleinere instance.

[MrFax]

Een Pi 4 4GB lijkt me dan toch een oplossing?

[Single Core]

Ik draai hier thuis ook Gitlab en zou toch echt minimaal 8 Gb ram aanraden voor comfortabel gebruik en snelheid.

[sfranken]

Ik heb alleen geen Pi's in huis. Wel een aantal HP servers ;-) Mijn Gitlab draait bij TransIP trouwens. Gitea kan ik niet mee uit de voeten, daar mis ik een aantal features welke Gitlab wel bied.

[Oon]

Helaas niet mijn keuze. Ik draai zelf wel GitLab voor mijn freelance projecten (heb overigens ook een Gitea draaien maar die gebruik ik (nog) niet), maar degene die daarvoor verantwoordelijk zou zijn ziet het nut niet zo in van zicht hebben op repositories vanaf je browser.

Tenzij er een manier is om GitLab (of Gitea) als client te koppelen aan een externe git server zonder hiervoor aan de serverkant iets in te regelen is dat iets waar ik het voorlopig maar mee moet doen.

[Verwijderd]

Wat mis je precies uit de web ui als ik vragen mag?

[Oon]

Ik mis vooral het snel bladeren en zoeken door code zonder deze eerst binnen te halen. Ik heb de meeste code inmiddels al lokaal, maar het is niet altijd praktisch om van branch te moeten wisselen om deze te doorzoeken.

Al zijn er ook nog andere belangrijke voordelen voor iets als GitLab of Gitea + Drone mbt automatisch controleren en compilen van code. Dit gebeurt bij ons nu wanneer we naar productie gaan, wat vaak tot last-minute fixes leidt die niet altijd dezelfde kwaliteit hebben als de code zelf. Als je meteen na je commit te zien krijgt dat er fouten in zitten dan kun je deze ook direct oplossen (in de feature branch zelf) en krijg je uiteindelijk een veel schoner proces bij het mergen. Helemaal wanneer je ook met merge requests gaat werken i.p.v. dat iemand lokaal alles samen in een branch gooit.

[Verwijderd]

Bladeren door je code doe je toch in je editor?

Ik gebruik de github pagina niet meer voor projecten die op github staan nadat ik voor een aantal projecten met een pure git server moest verbinden.

Ik gebruik nu alleen nog de command line en was benieuwd of je een feature op github.com hebt die ik niet ken en mogelijk wat kan toevoegen voor mijn workflow. Als je een situatie omschrijft waarin je het idee hebt via de website sneller te zijn heb ik misschien nog een paar mooie commands voor je.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 21:06]

[Oon]

Bladeren door je code doe je toch in je editor?

Je vergeet daarin het stukje 'zonder deze eerst binnen te halen'. Het komt nog wel eens voor dat ik met code uit één repo bezig ben en gevraagd word om mee te kijken naar code in een andere repo. Als ik deze dan helemaal binnen moet gaan halen en hier een PHPStorm project voor moet aanmaken dan ben ik een stuk meer tijd kwijt dan als ik even vlug op een web UI zou kijken. Het gaat hier dan ook om het gebruiken van een web UI als een soort git client.

Ik gebruik zelf CLI voor alle 'lastige' dingen. Ik heb de evaluatieversie van Git Fork draaien voor wanneer ik met merges bezig ben omdat het toch een stukje overzicht biedt. Ik gebruik de git integratie in PHPStorm om mijn commits naar meerdere repos tegelijk te doen (gesplitste server en client repo voor hetzelfde project die in PHPStorm één project worden), maar het pushen en het aanmaken/verschuiven/wisselen van branches doe ik dan ook weer CLI. Ik kan me zo niet bedenken dat ik iets mis in mijn dagelijkse workflow, maar er zijn wel verbeteringen die het gebruik van GitLab, GitHub of Gitea zou kunnen brengen voor het team waarin ik werk.

[Verwijderd]

Ah oke cool dan snap ik hem, inderdaad handig via github inzicht in projecten hebben zonder deze lokaal te hebben staan. Om nog een keer door te vragen, wat doe je dan als je in de code kijkt, is je rol hierin beslissend, bijvoorbeeld dat 2 mensen een verschillende mening over een functie hebben en jij de knoop doorhakt over wat het wordt?

Of gebruik je Github dan ook om eventuele aanpassingen aan code in een repo te doen die je niet lokaal hebt staan?

[Reactie gewijzigd door Verwijderd op 25 juli 2024 21:06]

[Oon]

Om nog een keer door te vragen, wat doe je dan als je in de code kijkt, is je rol hierin beslissend, bijvoorbeeld dat 2 mensen een verschillende mening over een functie hebben en jij de knoop doorhakt over wat het wordt?

Of gebruik je Github dan ook om eventuele aanpassingen aan code in een repo te doen die je niet lokaal hebt staan?

Mijn rol zou in dit geval puur ondersteunend zijn. Bij mijn vorige baan was dit nog wel eens leidend, waar ik het vooral fijn vond om dus projecten van meerdere collega's tegelijkertijd te kunnen inzien. Nu werk ik gewoon als developer in een team, en gaat het er puur om dat ik de code waar we het over hebben kan zien en advies kan geven.

Ik zou in beide gevallen nooit een commit doen via een web UI. Er is niet direct iets mis mee wanneer CI ingesteld is om code style te forceren, maar je mist toch flink wat IDE features zelfs in de beste online editor. Als het op het punt komt waar ik code ga schrijven moet ik toch volledig naar die context switchen, dus dan kan ik net zo goed de code binnen trekken en er lokaal aan werken.

[joost00719]

Wij gebruiken tegenwoordig bitbucket. Vroeger hadden wij bitbucket op een eigen interne server draaien. Ik geloof dat we daar zijn mee gestopt omdat de servers van bitbucket stabieler waren (lol?).
Daarnaast is het geloof ik ook goedkoper om het in bitbucket cloud te draaien. Je kan gewoon ip-restricties opzetten, en 2 factor authenticator eisen om in de repositories te komen, maar dat houdt een hacker natuurlijk niet tegen als ze op de server zelf kunnen.
Jira draaien we nog wel op eigen servers. Werkt prima.

[Oon]

Bitbucket is inderdaad een goede optie als je al Jira gebruikt, maar als losstaande dienst heb ik daar dan weer geen goede ervaring mee.

Wij maken gebruik van een of andere proprietary tool voor projectmanagement, en hebben ook geen Confluence oid voor documentatie. Alles lekker in tekstbestanden op Dropbox!

[TheVivaldi]

Kwestie van smaak, want ik kan juist niet wennen aan de UI van GitLab. Ik vind GitHub vele malen overzichtelijker en sneller.

[hottestbrain]

Er is niets wat erop duid dat dit een lek in Github zelf is. Social engineering bijvoorbeeld lijkt me vele malen waarschijnlijker...

[NoobishPro]

Dat is ook een lek.
Ik heb nergens gesproken over een softwarematig beveiligingslek

[Aardedraadje]

Technisch gezien heeft Microsoft dat hier toch ook? Aangezien zij eigenaar zijn van Github

[DutchKevv]

Ik betwijfel of jou server net zo goed beveiligd is als een dienst als GitHub, en daarnaast hebben je collega's de code ook nodig, daar grenst de beveiliging meestal

[blinchik]

Alleen is zijn aanvalsvector *gigantisch veel* kleiner. Iedereen gebruikt Github, dus het is een quick win om dit aan te vallen (net zoals andere cloudproducten uiteraard). Je moet zijn server eerst kennen of weten te vinden, en dan specifiek willen aanvallen. Daarenboven werkt hij misschien enkel samen met mensen uit Belgie en Nederland. Een geoblock er op, en de aanvalsvector is nog eens veel kleiner.
Zet dan de private server nog eens netjes achter een VPN, en de aanvalsvector is nog eens een factor kleiner geworden.

[DigitalExorcist]

“Je moet eerst zijn server kennen” is onzin natuurlijk, daar zijn poortscans voor uitgevonden en dat gaat gewoon automatisch. Je router bevat waarschijnlijk meer vulnerabilities dan die van Microsoft/Github. Hoe weet je dat er nog niemand is komen kijken in jouw netwerk? Hou je actief alle logs bij en analyseer je die ook dagelijks?

[blinchik]

Poortscans gebeuren automatisch, door botnets, klopt. Maar gewone poortscans worden dan ook gewoon afgeblokt door je firewall. Je moet dus al vanuit je botnet een slow portscan doen over miljoenen ip's, waar dan toevallig jouw servertje opzit. Dit tegenover gewoon 1 site waar miljoenen klanten op zitten. Denk je nu echt dat je attack-vector niet groter is?! Ik bedoel zeker niet dat dit "beveiliging" is, maar de kans is wel gigantisch veel kleiner dat je aangevallen wordt, het gaat hier over een speld in een hooiberg tegenover de hooiberg zelf.

"Je router bevat waarschijnlijk meer vulnerabilities" is nog zo'n flauw argument van de cloudmaffia. Firmwares worden tegenwoordig automatisch geupdated, os wordt automatisch gepatched, en je draait dezelfde servercode als github. Als daar een fout in zit, dan in de cloud ook. Het beheer zit ook een heel groot stuk in de setup, als je dat on premise niet goed doet, dan doe je dat in de cloud ook fout (zwakke wachtwoorden, 2FA, geen correcte permissies). Je gaat toch ook niet naar je baas met het argument, hey, die bedrijfsauto, de kans dat de chauffeurs een groot taxi bedrijf veiliger en minder verkeerd rijden vind ik groter, dus laat me maar overal naartoe voeren? Of denk je eerder, belangrijkste is dat ik weet waar ik naartoe moet, en dan weet ik zelf wel hoe ik rij, en ik heb een GPS?

Alle logs bijhouden, ja, gedurende enkele maanden, en analyseren: hier heb je monitoring en analysetools voor, dat doe je niet zelf.

Ik ben ongeveer 20 jaar systeembeheerder. Ik ben nooit gehacked geweest (tja, je zal wel zeggen, of ik zou het niet weten, maar met alle detectiesystemen is die kans toch klein). We hebben wel een paar keer compromised mail accounts gehad, maar die werden meestal binnen de 3 a 4 minuten automatisch geblokkeerd. We hebben om de 2 jaar een externe audit met een penetration test. Deze pen tests zijn interessant, maar men is ook nog niet binnengeraakt. Sinds anderhalf jaar zitten we op O365. Qua kostprijs zijn we verdubbeld (hierbij tel ik wel de kost van onze firewalls niet mee omdat we die toch nodig hebben, alhoewel die 40k op 5 jaar de zaak nu ook niet zal maken). Ondertussen 3x hacked accounts gehad, terwijl we toch 2FA hebben (inlogform gaat gewoon naar Azie waar een of andere "medewerker" alles overtypt in de echte O365 omgeving).

We willen wel verder met Advanced Protection, zodat we terug geoblocking kunnen aanzetten en suspicious logins kunnen blokkeren zoals we vroeger "gewoon zonder extra kost" op onze firewall konden, maar daar moeten we het management (die naar o365 wilden) nog van overtuigen. Want het is nu al 2x zo duur, en het wordt nog veel duurder? Ja, ik heb een mooie financiele vergelijking gemaakt. Binnenkort zitten we over een periode van 5 jaar op 5x de kost. Dat kan toch niet, want het is toch de cloud ? Dat is toch sowieso veel goedkoper en veel veiliger?

[Reactie gewijzigd door blinchik op 25 juli 2024 21:06]

[Wim-Bart]

Hoe weet je dat het twee keer zo duur is? Is het wel 2 keer zo duur? Misschien is het veel goedkoper doordat mensen beter samenwerken? Maar dat laatste zie je niet terug in de "kosten" maar misschien wel in productiviteit. Misschien is er bij een afdeling een FTE minder nu, dan is dat toch even 60K per jaar minder, dat zie je niet.

[blinchik]

Klinkt heel verkoper-achtig :-)

Kosten die zichtbaar zijn, zijn zichtbaar. "Misschien", "waarschijnlijk", "hopelijk", dat is leuk als het zo uitdraait, maar dat wil ik dan wel ook eerst echt in de cijfers zien. Ik wil graag een Tesla of een Bugatti in plaats van een Audi of een Mercedes als bedrijfswagen, de aankoopprijs is misschien wel 4x zo duur, maar ik kan er sneller mee rijden, dus ik win tijd en "mogelijk" is er wel productiviteitswinst.

Anyway, dan kan ik de zaken ook omkeren en de bal terugkaatsen : misschien moet ik ook rekening houden met extra support voor gebruikers, want in de cloud veranderen zaken zomaar te pas en te onpas. Je hebt geen controle meer op "features uitrollen". En dat heb ik inderdaad echt al vaak meegemaakt: opeens staat er een knopje op een andere plaats, vinden de gebruikers dat niet terug, en na een kwartier zoeken staat de helpdesk roodgloeiend.

We hebben een support medewerker tussen 08:30 en 17:00 maar we zijn open vanaf 07:30 tot 18:30. En inderdaad al op stafvergadering de opmerking gekregen : "opeens was alles veranderd en we konden niemand bereiken". Moeten we hier dan een FTE extra voor voorzien? In dat geval spreek ik niet over 2x zo duur, maar wordt het nog duurder.

[Reactie gewijzigd door blinchik op 25 juli 2024 21:06]

[Wim-Bart]

Ik krijg netjes een e-mail van Microsoft over de komende veranderingen, hieruit kan ik als Office 365 admin netjes een mail maken met instructies voor de mensen op kantoor. Nog voordat de wijziging er is.

[DigitalExorcist]

Je hebt volledig gelijk op alle punten uiteraard, ook ik ben al 20 jaar als systeembeheerder werkzaam en herken alles wat je zegt wel. Maar het ging me vooral even om thuisgebruik en iemand die een *eigen* servertje draait.

Tuurlijk ben je minder interessant, maar als er een of andere random mafkees een portscan op je IP adres loslaat is de kans er bést wel dat 'ie binnenkomt. Normale portscans zouden afgeslagen moeten worden ja, maar DDoS een huis- tuin- en keukenreutertje eens of probeer eens wat OOB-data naar de inlogpagina te sturen en kijk eens of ie dan nog overeind blijft...

Dat je als particulier minder interessant bent, dat klopt. Maar een automatische portscan op een range IP adressen maakt geen onderscheid of je belangrijk bent of niet.

[Verwijderd]

De vraag is even of hij zijn servertje dan ook aan internet heeft hangen of niet gewoon enkel intern gebruikt, of er een VPN omheen heeft zitten.

[Sandor_Clegane]

Hack je liever 1 bedrijf voor 100.000 doelen of hack je liever 100.000 bedrijven voor 1 doel?

[turbojet80s]

Ik snap je punt, maar mocht het servertje van NoobishPro gehackt worden. Wordt dan dan gedetecteerd? Of kan er jaren misbruik van worden gemaakt? In dat geval is het misschien toch veiliger om gebruik te maken van de dienstverlening van een expert, ookal ligt die meer onder vuur.

[morphje]

Hoeveel meer beveiliging kan je hebben dan het draaien van je updates?

Natuurlijk heeft Microsoft meer resources beschikbaar en kunnen sneller code kloppen om bugs op te lossen. Maar meer dan dat is het ook weer niet. Sterker nog, github is altijd closed source geweest, dus wie weet hoeveel bugs er nog inzitten?

Git in zichzelf is altijd een command line tool geweest. Je kan het combineren met SSH om je gits te dupliceren naar een remote target. Gitlab/Gitea zijn leuke add-ons om er een GUI omheen te bouwen.

Maar in volgorde:
Git en SSH vertrouw ik ten volste. Dat zijn zeer solide en betrouwbare projecten.
Gitlab/Gitea zijn ook vrij stabiel en snel met updates, weinig problemen daar.
Collega's: Dat is hoe dan ook een probleem, maakt niet uit welke basis je gebruikt.

[aikebah]

Hoeveel meer beveiliging kan je hebben dan het draaien van je updates?

Als draaien van updates je enige beveiliging is dan zijn nog best verbeteringen aan de beveiliging mogelijk hoor.

Daaronder zijn ook verbeteringen die lang niet iedereen in een prive-situatie wil doen, maar waar op enterprise niveau, meestal tegen enterprise-level prijzen zeker nog mogelijkheden zijn.
Zoals bijvoorbeeld de webapplication firewall (WAF) - een trusted MITM die je verkeer op applicatielayer nivo beoordeeld op veiligheid en daarmee ook nog niet gepatchte vulnerabilities kan afvangen (en kan rapporteren over afwijkende gedragingen op applicationlayer nivo)

Heb je die nodig: denk het niet echt, maar als je op je prive-servertje military-grade projecten draait dan zou ik die toch maar toevoegen aan de mix (net als nog een hele set aan andere maatregelen om de beveiliging van de omgeving van je git server op een hoger nivo te brengen dan alleen het uitrollen van updates als ze gepubliceerd zijn).

Bedenk dat veel security patches reactief zijn: eerst wordt een security-lek gevonden, meestal private disclosure naar het project. Pas daarna START de ontwikkeling van een patch. Die patch kan wel eens veel meer behelzen dan de paar regels signature die een WAF nodig heeft om het type request (al dan niet selectief) te blokkeren om jou instance al weer veilig en 99% functioneel te houden terwijl de patch nog even op zich laat wachten.
Als een groot lek in software actief blijkt te worden misbruikt dan gaat vaak ook de oorspronkelijke melding alsnog publiek.... en soms kunnen dan alleen instanties met een WAF vrij snel de dienst weer veilig aanbieden, de rest kan even niks anders dan de dienst tijdelijk te stoppen of, als accepted risk, alleen nog op het intranet aan te bieden wachtend op de patch die nog niet af is.

En ja: aan het eind hou je nog altijd de human factor over en die is vaak genoeg het relatief hoogste risico... daar kun je verder niet veel aan doen, anders dan ze niet meer toegang geven dan waarvoor je ze vertrouwt en zorgen dat ze minstens zo paranoide op securitygebied zijn of worden als jijzelf.

[SuperDre]

Je eigen server is misschien nog gevaarlijker dan Github, behalve als je je server niet aan het internet hebt hangen, maar dat betwijfel ik ten zeerste. Je kunt nog zo goed je server proberen te beheren, maar er hoeft maar 1 keer een lek te zijn waar je niet van op de hoogte was en je bent de klos.

[NoobishPro]

Als je de comments van @blinchik leest begrijp je waarom deze logica niet per sé opgaat.

Natuurlijk zal ik niet snel aan de veiligheid voldoen van Github, maar ik ben een extreem veel kleiner doelwit, als überhaupt.

Github daarentegen is een gigantisch doelwit.

Omdat ik zó enorm klein ben, weten veel mensen niet eens dat mijn bedrijf bestaat, wat voor producten ik heb en of er winst uit te halen valt om mij te hacken. Daarnaast zijn er weinig "ins" omdat mijn producten niet allemaal gekoppeld zijn aan gigantische cloud-samenwerkingsverbanden waardoor er simpelweg gewoon minder open hoeft te staan. Niemand hoeft bij mijn server behalve ik zelf dus staat mijn IP op een whitelist. Alleen daardoor zullen bijvoorbeeld bots al niet in mijn server kunnen komen en wordt het snel complexer -- echter sta ik weer niet op de radar voor die complexe hacks.

Daarnaast heb ik geen 25.000 werknemers, waardoor ik automatisch minder kans heb dat één hiervan slachtoffer wordt van een hack welke weer leid tot een grotere... Snap je wat ik bedoel?

Ik wil dus zeker niet beweren dat mijn server veiliger is dan Github, enkel dat ik een aanzienlijk veel kleinere kans heb om een doelwit/slachtoffer te zijn/worden van zoiets, in combinatie met weinig dependencies/koppelingen en dus weinig openstaande rommel.

Edit; Als ik hierin iets verkeerd zie, hoor ik het natuurlijk graag van je. Ik ben geen hacker dus ik zal heus wel wat over het hoofd zien.

[Reactie gewijzigd door NoobishPro op 25 juli 2024 21:06]

[Rutix]

Maar je valt als kleine partij (en helemaal als je alleen private repositories gebruikt) helemaal niet op tussen iedereen die op github zit. Dus als je serieus een repo alleen voor jezelf hebt (of voor een paar man) is je doelwit sowieso kleiner ongeacht of je op github zit of op je eigen server. Wat hier is gebeurt is dat ze mogelijk toegang hebben gekregen tot de organisation account en nieteens tot github zelf.

[Octium]

Wacht maar tot een keer de onedrive data van een groot bedrijf op straat ligt. Dan is het snel afgelopen met die alles in de cloud trend.

[Joecatshoe]

Daar twijfelen sommige forumgebruikers aan de authenticiteit van de data, onder andere omdat er Chinese teksten in de code staan.

Dat is helemaal niet zo gek, veel Microsoft software wordt in China geprogrammeerd. Gigantisch aanbod aan hooggeschoolde software engineers daar en MS is ook een zeer populair bedrijf bij schoolverlaters. In de States is MS geen "hip" bedrijf meer, in China echter wel.

[ilaurensnl]

Github is niet de juiste plaats om back-ups te maken, maar laten we zeggen dat het dat wel is, waar is volgens jou wel de geschikte plek?

Google Drive? USB stick? op je eigen server? het zijn allemaal risico factors; dat je huis geplunderd word is de kans groter dan dat je het op GitHub zet; servers zijn net zo goed een grote risico.

[xoniq]

Een eigen VPS is iets minder risico vol. Als GitHub gekraakt wordt, is alles van jou collateral damage. Je eigen VPS zal nooit interessant zijn voor hackers tenzij je Microsoft, Google, Apple of een andere grote tech speler bent.

De kans dat je je USB stick verliest, is het grootst. Dan heb je nog de kans dat je huis geplunderd wordt (zoals je al aangeeft) en dat de boel afbrand.

Dus als ik iets off-site moet backuppen, gaat dat via een externe VPS, met enkel public key auth, git met enkel public key auth, en geen troep als FTP enz. Verder ook alle poorten dicht. Dat is naar mijn inziens de veiligste optie als je niet een andere cloud dienst durft te gebruiken.

[page404]

Vergis je niet, als je SSH open zet op je VPS wordt je aan de lopende band aangevallen. Ik heb dat uiteindelijk opgelost door fail2ban te installeren en de SSH Port op een ander nummer te zetten. Maar ik heb een volstrekt onbeduidend domein en VPS en als daar al zo hard op aangevallen wordt, dan wil je geen Microsoft zijn

[com2,1ghz]

fail2ban/denyhosts zijn lapmiddelen die wel goed werken. Poort veranderen houdt domme bots tegen, alleen de slimmere doen lekker pogingen op alle poorten die open staan

Je zet password authenticatie uit, en staat pubkey authenticatie toe. Helemaal mooi zou zijn IP whitelisting. Met consumentenlijntjes/mobiel internet is dit helaas een luxe geworden.

Een mitigatie tegen het toestaan van alle IP addressen is weer port knocking.

[Reactie gewijzigd door com2,1ghz op 25 juli 2024 21:06]

[mkools24]

Klopt maar dat zijn scanners die standaard wachtwoorden proberen, daaron altijd public key aurhenticatie instellen en geen passwords gebruiken.

[xoniq]

Dat vergat ik te melden inderdaad. Ik gebruik een 4 cijferige poort die niet common is hiervoor. 22 is dodelijk met die Chinese en Russische scanners. (Zie vooral die 2 landen in f2b voorbij komen)

[page404]

Ik checkte net de f2b log en zie dat ze mijn poort helaas ook ontdekt hebben. Tijd om de tip van @mkools24 mee te nemen en volledig over te gaan op public keys. Die gebruik ik al wel voor het gemak maar passwords staan nog aan.

Jahoor, china

2020-05-08 09:31:26,313 fail2ban.actions [794]: WARNING [sshd] 104.236.224.69 already banned
2020-05-08 09:31:26,784 fail2ban.filter [794]: INFO [sshd] Found 104.236.224.69 - 2020-05-08 09:31:26
2020-05-08 09:31:32,150 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:31:32
2020-05-08 09:31:32,158 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:31:32
2020-05-08 09:31:32,323 fail2ban.actions [794]: WARNING [sshd] 114.98.126.14 already banned
2020-05-08 09:31:33,944 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:31:33
2020-05-08 09:32:06,388 fail2ban.actions [794]: NOTICE [sshd] Unban 49.232.174.219
2020-05-08 09:32:47,862 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:32:47
2020-05-08 09:32:47,863 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:32:47
2020-05-08 09:32:49,654 fail2ban.filter [794]: INFO [sshd] Found 114.98.126.14 - 2020-05-08 09:32:49
2020-05-08 09:32:49,677 fail2ban.actions [794]: WARNING [sshd] 114.98.126.14 already banned
2020-05-08 09:32:55,792 fail2ban.filter [794]: INFO [sshd] Found 139.59.67.82 - 2020-05-08 09:32:55
2020-05-08 09:32:55,793 fail2ban.filter [794]: INFO [sshd] Found 139.59.67.82 - 2020-05-08 09:32:55

[Reactie gewijzigd door page404 op 25 juli 2024 21:06]

[xoniq]

Ik heb echt enkel public key auth. En die key is weer gebackupped op een fysiek medium. (Stel dat m'n computer crashed)

[mkools24]

Je kunt altijd nog op de console aanmelden he en pw authenticatie weer inschakelen tijdelijk (mocht je je key verliezen)

[xoniq]

Lastiger als je een fysieke machine gebruikt in een eigen rack.
Ik gebruik dan wel een VPS, maar heb mezelf gewoon aangeleerd om altijd met public key te werken, en die tevens te backuppen.

[mkools24]

Ja heb ook een rack maar met iDrac

[ilaurensnl]

Je vergeet dat je VPS in beheer is van iemand anders, als je een server goed beveiligd dan is de kans inderdaad; maar als je het laat verstoffen zoals waarschijnlijk de meeste die gitbucket of zoiets installeren. Dan is dat snel gebeurd; je geeft aan dat hackers grote partijen interessant vinden, dat is zeker waar maar slecht beveiligd of verouderde software houden ze van!

Dat is prima; alleen wachtwoord authenticatie moet je niet willen; zelf ben ik van mening dat de veiligste plek in een datacenter is; met harde schijf encryptie en een eigen kast.

Het mooie van back-ups is ook; dat het redundant is; dus het laptop/pc is dan ook een risico gebied ^.^

[Reactie gewijzigd door ilaurensnl op 25 juli 2024 21:06]

[guillaume]

GitHub is idd niet voor blobs bedoeld, maar Git kan wel heel mooi ingezet worden voor het beheer en de synchronisatie van grote hoeveelheden blobs, bijvoorbeeld met https://git-annex.branchable.com. Altijd een charmant idee gevonden.

[likewise]

Voor back-ups heb je zaken als BorgBackup, waarbij een remote data lek geen info lekt. Er wordt nl. encryptie toegepast voordat je informatie de cloud in gaat.

[Magic V]

"De kans dat je huis geplunderd word is groter dan dat *insert cloudplatform* geplunderd word"
Dit argument hoor je wel vaker, maar om eerlijk te zijn denk ik dat de kans dat jouw data er bij een grote lek toevallig tussen zit vele malen groter is dan dat een specifieke dief het op jouw woning voorzien heeft en die ene serverkast leegrooft.
Ligt er natuulijk wel een beetje aan hoe waardevol je data is (en hoe groot doelwit je dus bent). Maar voor kleine projecten die je desalniettemin toch veilig wilt houden ben je denk ik beter af met een lokale backupstrategie + eventueel een encrypted cloudbackup.

[Verwijderd]

Tot nu toe is er meer data naar buiten gelekt vanaf github, dan dat er data ontvreemd is uit mijn huis.

[Verwijderd]

Server met encrypted disks voor de 'vluchtige' data. En een encrypted disk in een kluis voor de data die wat langer houdbaar moet zijn.
Als je bijvoorbeeld LUKS disks gebruikt in een thuissituatie, dan is de kans erg klein dat deze data (leesbaar) via de backups op straat komt te liggen, hoor.

[Wim-Bart]

Een klasgenoot op een ICT opleiding zei vandaag nog dat hij altijd een back-up van zijn bestanden op GitHub zet... Ik vond het idee al dom,dit bevestigt het wel.

Toevoeging: Met bestanden bedoel ik de documenten die op zijn drive staan zoals foto's, documenten, etc...

Zolang je via SSL werkt en goede wachtwoorden gebruikt is er niks aan de hand. Bronnen zeggen al dat het fake data is, dus om zo maar iets te roepen zonder te controleren..... Dus laten we eerst maar afwachten voordat we conclusies trekken.

[Reactie gewijzigd door Wim-Bart op 25 juli 2024 21:06]

[nils83]

Wat kort door de bocht om dat dom te noemen, nog altijd beter dan geen backup, en je klasgenoot zal vast geen schade ondervinden als die code gestolen wordt...

Dat een bedrijf dit doet, misschien niet de beste manier, maar we weten nog steeds niet wat er exact op stond, dus moeilijk te oordelen. Ik geef Microsoft alleszins genoeg krediet om te geloven dat het niets kritiek zal zijn.

[StefvE]

Het ging ook niet om code, van documenten tot foto's.. Ik heb mijn commentaar aangepast om dit te verduidelijken.
GitHub is juist uitermate handig om code op te zetten en revisies bij te houden. Maar niet als Cloud Storage.

[djwice]

Waarom niet? Omdat je er overal met een sha1 key bij kunt, slaan ze gegevens onversleuteld op of ... ?

[Reactie gewijzigd door djwice op 25 juli 2024 21:06]

[Verwijderd]

1. Omdat het omslachtig werkt, als je fatsoenlijk versioning wil gebruiken (tov. storage met snapshotting).
2. Omdat zelfs met GIT LFS de performance niet op kan tegen bijvoorbeeld S3.
3. Omdat het gebouwd is als een tool voor samenwerken aan code, en het gebruikt als cloudstorage dus geen onderdeel van het ontwerp. (Over het algemeen is het zo dat als iets geen onderdeel is van een ontwerp, het vaak ook sub-optimaal werkt).

Security is niet het punt.

[djwice]

Bedankt voor de aanvulling :-)
Op AWS maak ik juist vaak dingen die services gebruiken op een manier die initieel niet in het ontwerp zat.
AWS is tot nu toe heel vriendelijk en past hun service op mijn verzoek gewoon weg aan. Uiteraard GA.

[Reactie gewijzigd door djwice op 25 juli 2024 21:06]

[Verwijderd]

Vergeet ook niet het 'detail' dat GitHub van Microsoft is natuurlijk. Mocht er echt iets mis gaan qua cloud dan kunnen ze vast en zeker bij de fysieke servers. Voor Microsoft zou het bijna raar zijn om geen GitHub te gebruiken voor hun code.

[IStealYourGun]

Grappig genoeg niet, gezien GitHub nog steeds op de cloud van Amazon draait.

[AtleX]

Think again. Zie bijvoorbeeld https://github.com/microsoft en https://github.com/dotnet/. Waarschijnlijk staat niet alles op Github, maar zeker hun open-source producten staan er gewoon.

[Stannieman]

Ja die wel, omdat ze al open source zijn en er dus ook niks te lekken of stelen valt.

De code van Windows, Office, Azure, ... gaat achter slot en grendel intern staan.

[mrmrmr]

Microsoft closed source code zelf is al meerdere keren gelekt.

Bijvoorbeeld: https://www.theregister.co.uk/2017/06/23/windows_10_leak/

[ZaZ]

Dat doen ze hoogstwaarschijnlijk wel, dat blijkt uit meerdere dingen.
Zoals AtleX al aankaart, gebruiken ze het voor hun open source projecten.
Maar als je de blogs en vlogs van Microsoft een beetje volgt zie je ook dat ze actief meewerken met de ontwikkeling van git omdat die voor geen meter performt met hun gigantische code base. Ze hebben grote aanpassingen gemaakt zodat de performance veel beter is met hun omgezette Windows repo's

[RobIII]

Want de code van je klasgenoot is miljarden waard...
Is nogal een verschil he? Als je klasgenoot zijn huiswerk wil backuppen op GitHub moet 'ie dat lekker doen. Deze vraag speelt pas bij (veelal "gesloten") codebases die interessant zijn voor derden om te hebben; veel van wat er op GitHub staat is gewoon open source...

[Reactie gewijzigd door RobIII op 25 juli 2024 21:06]

[StefvE]

Want de code van je klasgenoot is miljarden waard...
Is nogal een verschil he? Als je klasgenoot zijn huiswerk wil backuppen op GitHub moet 'ie dat lekker doen. Deze vraag speelt pas bij codebases die interessant zijn voor derden om te hebben; veel van wat er op GitHub staat is gewoon open source...

Ja tuurlijk is het minder waard. Ik zou GitHub alleen niet gebruiken als Cloud Storage voor backups, daar is het ook niet voor bedoeld.

[Cartman!]

Waar zet jij je code dan liever wel neer? Ik vind het ideaal om Github en Bitbucket te gebruiken voor prive projectjes, zowel open source (public repo) als closed source (private repo)

[Reactie gewijzigd door Cartman! op 25 juli 2024 21:06]

[StefvE]

Code zet ik natuurlijk op GitHub. Ik zal alleen nooit een backup naar GitHub maken. Vooral niet als het privé bestanden bevat zoals documenten en foto's...

[Cartman!]

Afhankelijk van t soort documenten vind ik Github helemaal geen gekke plek.

[Verwijderd]

Ik vind mijn schoenen bewaren in de koelkast ook een gekke plek, het kan wel, maar het is toch een beetje gek.

[Nevel]

Backups die niks met code te maken hebben (niet op een git manier met anderen gedeeld hoeven te worden) zou ik eerder toevertrouwen aan backup oplossingen als SpiderOak, ipv ze als plain text naar Gitlab, Github, BitBucket, etc te sturen.

[RobIII]

Het hangt er nogal vanaf wat 'ie onder "bestanden" verstaat. In context van dit artikel leek 't me veilig aan te nemen dat 't om code ging/gaat. En op GitHub kun je ook gewoon LFS gebruiken. Of GitHub dé ge-eikte all-purpose backup locatie is? Nee, tuurlijk niet. Maar je klasgenoot heeft tenminste een (offsite) backup - belangrijk in élke 3-2-1 backup strategie. Wat heb jij?

Overigens: als je klasgenoot z'n bestanden fatsoenlijk versleutelt is er weinig te verliezen; ik ken zelfs mensen die zo backuppen (en dan heb ik 't dus over documenten, foto's, original content zeg maar en dus geen piraterij) naar usenet

[Reactie gewijzigd door RobIII op 25 juli 2024 21:06]

[StefvE]

Het is altijd goed om een back-up te hebben, wil alleen zeggen dat ik denk dat GitHub daar niet de best uitgekozen plek is om bestanden naast code op te plaatsen.
Ik heb zelf 3 back-ups verspreid over 2 woningen die live worden gesynchroniseerd met ransomware protection + een extra hdd die ik eens per week koppel om een backup te maken van de gehele drive.

[Peetz0r]

live worden gesynchroniseerd met ransomware protection

Kun je daar neer over vertellen? Ik ben benieuwd hoe dat werkt tegen ransomware die nieuw genoeg is om niet door de meeste AV gevonden te worden.

[djwice]

Machine van netwerk, clear mem, reboot from ROM. Run.

[StefvE]

https://nextcloud.com/blo...ansomware-protection-app/
Herkent bestandsnamen logt alles en schakelt in wanneer de situatie verdacht wordt. Zal natuurlijk niet 100% gaan voorkomen maar grotendeels wel.

[Verwijderd]

Daarnaast natuurlijk snapshotting gebruiken op het filesystem. Kun je altijd je bestanden nog terugzetten naar de situatie vlak voordat de ransomware actief werd.

[StefvE]

Oh ja heerlijk!

[Blubkens]

Misschien kan je je klasgenoot helpen of adviseren.
Maar het kan ook zo zijn dat hij niet die mogelijkheid heeft om 3 backups te verspreiden.
Of is geld misschien een kwestie.
Who knows. Zoals eerder gezegd. Een backup is altijd beter dan geen.
Miss kan jij hem wel ruimte aanbieden. Altijd beter dan dat “domme” idee toch.

[Verwijderd]

En waarom is dat waardevol voor de discussie?

[ikt]

Naja, dom is het niet, onhandig - wellicht, git is niet ingericht om binary blobs te backuppen. Al is het wel heel slim als het om configuratiebestanden en dergelijke gaat, of hij maakt zijn werk in iets als Markdown of LaTeX.

Dom is het in ieder geval niet

[StefvE]

Onhandig zou dan inderdaad een betere woordkeuze zijn.

[Verwijderd]

GIT LFS (Large File Storage) kan dat wel, maar dat is inderdaad bedoeld voor als je project wat resources heeft, zoals documenten, plaatjes, geluid samples, enz.

[Clemens123]

Git voor cloud backup is beetje zoals dt-fouten...niet ideaal maar zeker ook geen drama.

dit bevestigd

Zeker als het om een eenmalige backup gaat valt het mee. Het grootste probleem is namelijk dat als je ooit iets wist om plaats te besparen, het toch nog aanwezig blijft. Dit is ook niet ideaal vanuit een privacy perspectief als je een enkel bestand wissen wilt.

[Reactie gewijzigd door Clemens123 op 25 juli 2024 21:06]

[CodeCaster]

Waarom bevestigt dit dat feit voor jou?

Het bericht meldt dat het account van Microsoft is gehackt, op GitHub, waardoor de aanvallers data konden downloaden vanuit Microsofts private repositories.

Het is niet alsof álle private repo's van GitHub ineens op straat liggen.

[Verwijderd]

Nou ja. Wat wel een beetje een puntje is, is dat het een Microsoft account is wat gekraakt is. Je weet wel, Microsoft, de eigenaar van GitHub.

[CodeCaster]

Dit is niet een of ander übermegaadminaccount, het is het opensource-account van Microsoft. GitHub is pas anderhalf jaar van MS, dit account is veel ouder.

Als dit nieuws al waar is, dan is het waarschijnlijker dat het wachtwoord "SourceSafeRulez!" is en dat two-factor auth om een of andere reden uit staat, of dat er een ontevreden (ex-)medewerker een login heeft gedeeld, dan dat GitHub zo lek als een mandje is.

[Reactie gewijzigd door CodeCaster op 25 juli 2024 21:06]

[SuperDre]

Aan de andere kant, waarom niet? Elke cloudbackup is vatbaar voor dit soort hacks, want het lijkt hier weer mee te gaan om een account waarop men heeft kunnen binnendringen (door mogelijk phishing etc). Daarom altijd verstanding om op zijn minst TFA aan te zetten waar nodig.

[mjz2cool]

Waarom is dat dom? Het is niet helemaal waar Github voor bedoeld is, maar het werkt prima. Of werkt die klasgenoot in zijn vrije tijd voor Microsoft, en gaat het in dit artikel om het Github account van die klasgenoot?

[RobIII]

Nutteloze semantische discussie. Feit blijft dat er (naar zeggen) 500GB aan data ergens in handen is beland waar 't niet hoort. Of je 't dan stelen of kopieëren of lenen wil noemen; who cares. Stelen begrijpt iedereen.

[Blubkens]

Als ik een Game of Software huur en maak er een kopie dan is dat ook stelen.

[MsG]

Dan is het vaak opeens niet zo, als ik de comments daar lees. Dan wordt er gezegd illegaal binnenhalen is heel iets anders. Maar bij dit soort nieuwsberichten blijkbaar weer niet .

[xoniq]

Dat zie ik dus altijd bij nieuwsberichten over BREIN en Dutch Filmworks. (Ja, ik ga niet maanden wachten tot het op blu-ray komt, en wordt nergens ter stream aangeboden, dus ik moet wel. - dat soort reacties continu)

[EchoWhiskey]

"Ja rechter, u hoort het goed: Ik eis vrijspraak!"
"Het klopt dat ik voor 50mln euro kopietjes heb gemaakt van een 50 euro bankbiljet, maar dat kan echt geen stelen zijn. Het originele bankbiljet is er namelijk gewoon nog"

[rustybolt]

Als je aangeklaagd wordt voor diestal wegens het kopiëren van een bankbiljet zal je waarschijnlijk vrijuit gaan. Het gebruiken van vals geld valt namelijk onder valsmunterij, niet onder diefstal.

[EchoWhiskey]

Niet als het bankbiljet gestolen is...

Maar mijn reply gaat helemaal niet over of het gestolen, ontvoerd, whatever is..

[dfijma]

Dat is dan ook geen diefstal maar valsmunterij. En dat is ook stout

[xoniq]

En zelfs expliciet in de wet vastgelegd

[hackerhater]

In dit geval gezien het kraken van het account zou de correcte aanklacht computervredebreuk zijn.
Het is inderdaad geen stelen.