image

GitHub reset wachtwoorden na brute force-aanval

woensdag 20 november 2013, 10:50 door Redactie, 9 reacties

Het populaire online platform voor softwareontwikkelaars GitHub heeft de wachtwoorden van een aantal gebruikers gereset nadat die via een brute force-aanval door aanvallers waren achterhaald. Bij de aanval werd er via 40.000 unieke IP-adressen geprobeerd om op accounts in te loggen.

Van een aantal gebruikers met een zwak wachtwoord werd het account gecompromitteerd. GitHub heeft van deze gebruikers het wachtwoord, persoonlijke toegangstokens, OAuth-autorisaties en SSH-sleutels gereset. Gebruikers moeten nu nieuwe, veiligere wachtwoorden aanmaken en hun account op verdachte activiteit controleren.

Broncode

In het geval GitHub ontdekt dat er verdachte activiteit met betrekking tot de broncode en gevoelige accountgegevens heeft plaatsgevonden, zal het gebruikers wederom waarschuwen. "Dit is een goede gelegenheid om je account te controleren en ervoor te zorgen dat je een sterk wachtwoord gebruikt en twee-factor authenticatie hebt ingeschakeld", zegt Shawn Davenport van GitHub.

Reacties (9)
20-11-2013, 11:26 door Anoniem
Dan is niet alleen het account gecompromiteerd maar is ook de sourcecode van de betreffende gebruikers/project niet meer betrouwbaar!
20-11-2013, 11:52 door Anoniem
Gelukkig zit er vesion controll op en kun je dus de onbetrouwbare commit er uit halen...
20-11-2013, 12:49 door N4ppy
Hmmm waarom blocken ze niet voor een uur na 5 pogingen? Dan valt er weinig te brute forcen.
20-11-2013, 13:22 door hx0r3z - Bijgewerkt: 20-11-2013, 13:25
Door N4ppy: 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!!=_"
20-11-2013, 14:47 door Briolet - Bijgewerkt: 20-11-2013, 14:54
Door Anoniem: Dan is niet alleen het account gecompromiteerd maar is ook de sourcecode
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. (:
20-11-2013, 15:21 door Anoniem
Door Anoniem: Dan is niet alleen het account gecompromiteerd maar is ook de sourcecode van de betreffende gebruikers/project niet meer betrouwbaar!
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.)
20-11-2013, 17:05 door Arie1980
Door hx0r3z:
Door N4ppy: 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!!=_"

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
21-11-2013, 08:45 door N4ppy
Door N4ppy: Hmmm waarom blocken ze niet voor een uur na 5 pogingen? Dan valt er weinig te brute forcen.
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 :)
25-11-2013, 12:22 door hx0r3z
Door N4ppy:
Door N4ppy: Hmmm waarom blocken ze niet voor een uur na 5 pogingen? Dan valt er weinig te brute forcen.
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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.