Dan is niet alleen het account gecompromiteerd maar is ook de sourcecode van de betreffende gebruikers/project niet meer betrouwbaar!

Gelukkig zit er vesion controll op en kun je dus de onbetrouwbare commit er uit halen...

Hmmm waarom blocken ze niet voor een uur na 5 pogingen? Dan valt er weinig te brute forcen.

Sherlock, dan heb je nog steeds 200000 mogelijkheden over. Een zwak wachtwoord zit daar zeker tussen. Waarschijnlijk een goede dictionary die voor het success zorgde bij het aantal account met bijvoorbeeld 1234 als wachtwoord.

Ik zou zeggen eigen schuld dikke bult.

Vraag me af is het zo moeilijk om een goed wachtwoord te verzinnen? Druk eens op een paar random toetsen op je keyboard en je hebt een super sterk wachtwoord zoals dit bijvoorbeeld "^%$#RE754HGfsw(swi9!!=_"

Gelukkig zie je steeds de veranderingen voorbij komen. Vooral de actieve deelnemers van een project die alle veranderingen willen volgen, zal dat direct opvallen.
Daarnaast wordt er nog per ingelogde computer een nieuwe SSH key aangemaakt. Als je hier dus naar kijkt valt het ook op als er van een onbekende locatie ingelogd is. Of kijk naar de security History waar alle logins vermeld zijn. Hier had ik ook nog nooit eerder naar gekeken , moet ik toegeven. Er was in elk geval geen mailtje dat mijn wachtwoord te zwak was. (:

Dat valt nog wel mee. Github gebruikt git, en in git wordt elk object (opgeslagen bestand [blob], directory [tree], commit) geïdentificeerd door een hash, tree-objecten verwijzen naar die hashes (van blobs en sub-trees), commit-objecten verwijzen naar de voorgaande commit (of commits na een merge) en het root-tree-object van de repository in de staat die gecommit wordt.

Als je één bestandje wijzigt wijzigt de hash (de oude versie blijft natuurlijk ook staan in een SCM), en dus de samenstelling van de tree, de hash daarvan, en dat plant zich voort naar de root-tree (root-directory) van de repository. Het commit-object bevat die hash en de hashes van parent-commits, en de hash over elke commit is daarmee effectief een hash over de volledige repository-inhoud én de volledige historie die tot die commit heeft geleid. Wijzig één bit waar dan ook in de historie en de integriteit van de hele repository is naar zijn grootje, en dat komt snel aan het licht. Probeer je dat recht te breien door een hele geschiedenis te herschrijven dan levert dat onvermijdelijk nieuwe hashes op, en in git is dat een nieuwe branch. Iedereen die met de gewijzigde repository synchroniseert krijgt foutmeldingen, en als iemand toch een synchronisatie weet te forceren dan ziet die de histories als afzonderlijke branches naast elkaar staan, er wordt niets bestaands overschreven. Branches zijn in git geen concept dat er pas is als nadrukkelijk een branch is gecreëerd, het volgt automatisch uit de onderlinge verwijzingen tussen commits, op basis van de hashes.

en dat is in wezen een nieuwe historie waar iedereen die zijn locale kopie probeert te synchroniseren onmiddelijk fouten op krijgt. Andere hashes zijn automatisch andere branches in git.

En voor de duidelijkheid: git is een gedistribueerd systeem waarbij elke ontwikkelaar een volledige kopie van de repository heeft staan, het is dus nooit zo dat die kopie op de server de enige is.

Een aanvaller kan hierdoor (zonder rechtstreekse toegang tot het filesysteem van de server) alleen nieuwe commits toevoegen. De staat van de repository kan aan de hand van locale kopieën tot aan het moment van de aanval geverifieerd worden, en dan blijft een relatief klein aantal commits over waarvan de wijzigingen inhoudelijk moeten worden gecontroleerd. Dit is hanteerbaar.

De gebruikte hash is SHA-1. Die is voor cryptografische toepassingen aan vervanging toe, maar git zit zo in elkaar dat het niet van de cryptografische sterkte van de hash afhangt. Als een aanvaller een blob met een al aanwezige hash weet te maken en die probeert toe te voegen, dan zal een git-repository *altijd* het oude object blijven gebruiken. De aanvaller zal dus alleen meemaken dat zijn gemanipuleerde bestand door het origineel is vervangen als mensen zijn commit ophalen, het deel van de repository van voor de aanval blijft integer. En dan wordt voor de oplossers het probleem alweer gereduceerd tot het inspecteren van de laatste commits.

Als de aanvaller buiten de normale interfaces voor git om toegang tot het filesysteem van de server heeft (daar is hier geen sprake van) kan hij wel zijn blob inbrengen. Alleen zullen bestaande mirrors van de repository die nooit ophalen omdat ze al een object met die hash hebben. Als een inbraak op de server zelf wordt geconstateerd (dus niet op de voor git gebruikte interface naar de server die geen rechtstreekse toegang tot het filesysteem geeft) dan is het zaak repositories grondiger te controleren. Ik stel me voor dat je dan een hash op alle objecten met een ander algoritme dan SHA-1 maakt en op basis daarvan controleert of mirrors voor alle objecten gelijk zijn. Dat is eenvoudig te doen voor iemand die voldoende thuis is in git en *nix.

Ik heb zelf jaren geleden git als SCM gekozen omdat de basis zo sterk is. Het was op dat moment het enige SCM waarvan ik op basis van een tekst die de opslag beschreef (content-addressable storage op basis van de hashes) volledig kon beredeneren waarom er ijzersterke audit trails op basis van alleen al de manier van opslaan van objecten te maken is.

(Er is een rebase-actie die volgens critici een audit trail onbetrouwbaar maakt, maar daar ben ik het niet mee eens; het voert wat ver om die discussie te gaan voeren hier.)

Daarnaast worden bruteforce attacks vaak anders uitgevoerd dan gedacht.
1) Er wordt gebruik gemaakt van 1000en ipadrressen
2) Er worden verschillende truuks gebruikt, zoals :
2A) met 1 password alle usernames van het systeem testen
2B) inlog progingen met user+pass van gehackte databases van andere partijen (zoals linkedin, adobe etetc)
3) IPadrresen worden "schoon" gehouden door fake login pogingen er tussendoor te doen met een account waar ze wel mee kunnen inloggen

Remedies:
A) Captcha per IP ( of IPint/1024 oid) obv X failed per Y minuten. Voordeel: is dat je niet al je users lastig valt met captchas
B) Captcha vragen als er een voor de user onbekende ASN wordt gebruikt. (UserProfiles aanleggen)
C) A&B kunnen niet altijd (denk aan SIP logins) dan moet B worden uitgevoerd icm een 2way auth

While we aggressively rate-limit login attempts and passwords are stored properly, this incident has involved the use of nearly 40K unique IP addresses. These addresses were used to slowly brute force weak passwords or passwords used on multiple sites. We are working on additional rate-limiting measures to address this. In addition, you will no longer be able to login to GitHub.com with commonly-used weak passwords.

Doen ze dus al :)

Ja ja dat snap ik het is ook niet zomaar een brutefoce attack er zijn tricks gebruikt waardoor deze hoeveelheid ip adressen kon blijven bruten. Zoals Arie1980 al zei.