Lek in Github maakte aanpassen software van anderen mogelijk

Ontwikkelaarsplatform Github gaat zijn gehele infrastructuur controleren op verdachte handelingen. Door een beveiligingsfout konden kwaadwillenden extra rechten krijgen en zo eventueel eigen code aan een project toevoegen.

De beveiligingsfout heeft te maken met de manier waarop Rails, het framework waarop onder meer Github is gebaseerd, omgaat met het toewijzen van attributen. Hierdoor kunnen buitenstaanders waarden aanpassen in projecten van ontwikkelaars die zich niet wapenen tegen mass assignment en zo zichzelf volledige lees- en schrijfrechten geven. Hoewel ontwikkelaars zich kunnen wapenen tegen dit misbruik, zal dit in de praktijk niet vaak gebeuren.

Als gevolg hiervan waren veel Rails-projecten - en dus ook alle Github-projecten - vatbaar voor misbruik. De fout kon worden misbruikt op alle Rails-sites waar de input niet goed wordt afgevangen. Zo waren onder meer de Linux-kernel, Postereous, Speakerdeck, Scribd en het ontwikkelaarsplatform van Github zelf 'kwetsbaar'. Projecten kunnen worden afgeschermd voor derden en binnen een project kunnen verschillende rollen worden toegewezen. Door de fout konden kwaadwillenden wijzigingen aan de code doorvoeren en deze committen of zelfs het gehele project verwijderen.

De fout die aan het probleem ten grondslag ligt, werd enkele dagen geleden ontdekt en kenbaar gemaakt door de Russische hacker Egor Homakov. Om zijn bevinding kracht bij te zetten, heeft Homakov de kwetsbaarheid misbruikt om zijn public key te koppelen aan het ontwikkelaarsteam van Rails. Hierdoor kon hij zich voordoen als Rails-ontwikkelaar en was hij in staat daadwerkelijk een nieuw bestand toe te voegen aan het Rails-project. Het is niet bekend waarom de hacker voor deze aanpak heeft gekozen. Hoewel hij in een eerder stadium al wel contact had gehad met Github over zijn ontdekking, heeft hij mogelijk uit onvrede over de aanpak van de Rails-ontwikkelaars ervoor gekozen zijn tweede ontdekking niet eerst te rapporteren.

Homakov had zijn eerste ontdekking aanvankelijk via Github gedeeld, maar de Rails-ontwikkelaars stelden dat dit geen beveiligingsprobleem van Rails was en sloten zijn topic. Hun manier van reageren kwam de ontwikkelaars achter Rails op de nodige kritiek te staan.

Github heeft inmiddels een fix uitgerold die moet voorkomen dat kwaadwillenden op deze manier nog extra rechten kunnen krijgen op bij Github gehoste projecten. Omdat de gevolgen van eventueel misbruik verstrekkend zijn heeft het ontwikkelaarsplafform aangekondigd dat het de complete codebase naloopt om te kijken of het lek eerder is misbruikt.

Github wordt gebruikt door ontwikkelaars als hostingplatform voor hun ontwikkelcode, die vanaf hun werkplek op eenvoudige wijze kan worden gecommit naar het Github-project. Het platform voorziet hierbij in versiebeheer en een eventtracker.

Reacties (40)

[s.stok]

Dit is dus één van de redenen waarom ik tegen het gebruik van magie ben, je gaat magie toepassen zodat je niet allemaal setters hoeft te typen?

Hoe was dat pattern ook alweer?
Oh ja, "program to an interface, not an implementation."

Met een hash-table/associative-array naar het 'interne' systeem te sturen en deze blindelings te verwerken krijg je dit soort problemen. Je bied geen solide interface, maar gaat blindelings invoer accepteren en verwerken.

Door gebruik te maken een uitdrukkelijke functie aanroep kan je NOOIT meer doen dan die functie toestaat (met uitzondering van lekken in de uiteindelijke uitvoer uiteraard, SQL injectie o.a.), je kan bijv. geen rechten toewijzen door het wijzigen van je gebruikersnaam, je kan hoogstens een ongeldige gebruikersnaam invoer maar meer ook niet.

Dit soort magische onzin breekt gewoon alle best practices.
• Programmeren naar een interface
• Encapsulation
• Validate every user-input

Of het nu Ruby, PHP, Python of wat dan ook word gebruikt.
Magie brengt gewoon teveel ellende met zich mee.

De ontwikkelaars mogen dan wel zeggen dat het geen veiligheidslek, is maar een slechte implementatie is het zeker.

[Reactie gewijzigd door s.stok op 23 juli 2024 05:39]

[Interfico]

In de echte wereld is het juist de magie die ervoor zorgt ontzettend efficiënt te kunnen werken. Mensen met voldoende kennis zijn in staat deze risico's te overzien en naar behoren te handelen.

[Tp21]

Het lek in kwesite is een probleem met de implementatie van Github. Maar er stond al langere tijd een bug open bij rails om de attr_accessible aan te passen en het standaard onmogelijk te maken om mass assignment toe te passen.

Er zit dus geen fout in rails zelf, maar alleen in de implementatie van Github. Rails had het wel moeilijker kunnen maken om dit lek te gebruiken en hier word nu ook aan gewerkt.

Een van de rails core developers heeft al een nieuwe idee om het mass assignment probleem goed aan te pakken (https://gist.github.com/1974187)

[Ossebol]

Dit is pijnlijk voor de ontwikkelaars van de Linux-kernel. Ze dachten dat het project na de kwetsbaarheid in Kernel.org veilig zou zijn bij Github. Dat blijkt dus niet het geval.

nieuws: Hack Kernel.org treft systemen ontwikkelaars

[Lennie]

De Linux kernel staat alleen niet meer mij Github, het gebruik van Github voor de Linux kernel was tijdelijk terwijl kernel.org werd herbouwd.

Alleen het artikel suggereerd dat in theorie in de tijd dat de Linux kernel op Github stond er mogelijk iemand iets aangepast kan zijn door een kwaadwillende.

Tevens wordt voor de Linux kernel een PGP-keyring gebruikt om de 'git-hash' te mailen, je kunt dus helemaal niet zo maar iets wijzigen aan de source code van de Linux kernel via Github.

[Reactie gewijzigd door Lennie op 23 juli 2024 05:39]

[Kajel]

De hele community is en masse naar GitHub getrokken, mede door de gebruiksvriendelijkheid, de mooie webinterface en het feit dat Google Code in eerste instantie geen git ondersteunde (doen ze nu wel). Ik denk niet dat mensen nu spontaan weer terug gaan naar Google Code. GitHub is gewoon een spil in de open source community.

Ook een beetje raar om bij elke fout maar weg te gaan bij je huidige service aanbieder. Zo kun je bezig blijven met verhuizen. Uiteindelijk komen fouten overal voor, want het is en blijft mensenwerk.

[Ossebol]

Zou het geen oplossing kunnen zijn om de code te splitsen en onder te brengen bij verschillende aanbieders? Als er dan iets wordt gekraakt, hoef je tenminste niet alles te controleren op aanpassingen.

[Reactie gewijzigd door Ossebol op 23 juli 2024 05:39]

[Verwijderd]

Ossebol,

voor git maakt dat juist totaal niets uit.

GIT : distributed revision control

Iedere gebruiker die een clone heeft van een bepaald project (github of niet) heeft een complete versie gedownload. Als er iets mis is met de repository vergelijk je gewoon de hash met wat de andere persoon/provider heeft en weet je of er zaken gewijzigd zijn.

Zeker in dit geval totaal geen reden voor paniek.

[TvdW]

En dit is waarom dit soort "white hackers" een positie moeten hebben in het wetboek (en dat van de VS). Wat Homakov gedaan heeft is namelijk gewoon strafbaar, op dit moment, met een paar jaar celstraf.

[Reactie gewijzigd door TvdW op 23 juli 2024 05:39]

[ANdrode]

Voor zover ik weet (en het gisteravond gelezen heb) heeft hij een bug bij rails gemeld. De rails developers meenden dat attr_accessible veiliger was, maar voor instappers het framework moeilijker maakt.
Hun mening was dat gebruikers security conscious moeten zijn, en dat dit gedrag gewenst is.

Daarna heeft Homakov een bug gevonden in github en deze exploit gebruikt om exposure te krijgen ipv eerst te melden bij github.

In mijn ogen is dit geen white hat gedrag; Hij mag blij zijn dat het er op lijkt dat github geen stappen onderneemt.

[Reactie gewijzigd door ANdrode op 23 juli 2024 05:39]

[BtM909]

Dan heb je dat verkeerd gelezen

Zie ook: https://github.com/blog/1069-responsible-disclosure-policy waarin github reageert op het voorval en de nieuwe security policy heeft toegevoegd aan hun security document: http://help.github.com/responsible-disclosure/

[Montaner]

Homakov had zijn eerste ontdekking aanvankelijk via Github gedeeld, maar de Rails-ontwikkelaars stelden dat dit geen beveiligingsprobleem van Rails was en sloten zijn topic. Dat kwam de ontwikkelaars achter Rails op de nodige kritiek kwam te staan door hun manier van reageren.

Niet gemeld? Wel dus. Het slap afhandelen van een serieus probleem heeft hem ertoe geleid actie te ondernemen. Soms moet je mensen wakker schudden.

Github mag blij zijn met zijn actie en dat het niet een kwaadwillende is geweest waardoor nu alle code geïnfecteerd zou kunnen zijn.

[ANdrode]

rails != github (!)

Hij heeft één bug gemeld bij github, waar github direct op gereageerd heeft en bug heeft gerepareerd.

Tweede bug niet gemeld bij github.

Let op; dit is geen bug in Rails maar een implementatiefout die vaak gemaakt wordt.

[Pozo]

Als de implementatiefout zo makkelijk te maken is, is het dan geen fout in Rails? Ik kan me niet voorstellen dat je ooit een 'Rails server' (of wat dat ook precies is) wil waarbij buitenstaanders zichzelf machtigingen kunnen toewijzen.

Rails zou op zijn minst bij/direct na de installatie moeten checken op die kwetsbaarheid & daar een waarschuwing voor (blijven) geven totdat de gebruiker aangeeft dat hij de fout heeft afgevangen, of actief besluit er niets mee te doen.

[Reactie gewijzigd door Pozo op 23 juli 2024 05:39]

[compufreak88]

Rails is geen applicatie of server of iets dergelijks, maar een ontwikkel framework wat ontwikkelaars gebruiken om webapplicaties te schrijven.

Direct bij installatie is er dan ook nog vrij weinig wat gecontroleerd kan worden. Het gaat juist fout op het moment dat ontwikkelaars een methode van het framework gebruiken zonder dat ze goed weten wat de implicaties daarvan zijn (het ongefilterd doorsturen van user input naar een model, waarbij alle waarden gewoon klakkeloos worden overgenomen.

Dit kan op twee manieren opgelost worden:

1. Door attr_accessible te gebruiken, waarbij je de velden kan beperken die op die manier geset kunnen worden

2. Door in de controler er voor te zorgen dat alleen geldige waarden naar de model worden gestuurd (volgens @dhh de juiste methode, zie https://twitter.com/#!/dhh/status/176465643107909632)

[Gamebuster]

Nom het "geen bug", maar het is wel degelijk slecht geregeld bij rails. Ik had liever dat je standaard een whitelist hebt, of validaties per rol.

[mindcrash]

In mijn ogen is dit geen white hat gedrag; Hij mag blij zijn dat het er op lijkt dat github geen stappen onderneemt.

In eerste instantie hadden ze dat ook gedaan en zijn account geblokkeerd vanwege het overtreden van de user policy. Na kritiek uit de community hebben ze dit weer ongedaan gemaakt.

Hij mag inderdaad blij zijn dat GitHub -mogelijk- geen verdere (juridische) acties onderneemt, want ze zouden hiermee inderdaad naar een instantie als de FBI kunnen stappen (indien Rusland tenminste een verdrag heeft met de US), maar ik denk niet dat ze het zover laten komen. Zover ik heb begrepen is men zelf namelijk ook vrij laks geweest en heeft men het niet zo nauw genomen met één van de belangrijkste regels voor web development: "never trust (the input of) a user". Ze mogen eigenlijk wel blij zijn dat Homakov deze exploit uiteindelijk alleen heeft gebruikt om een punt te maken, een blackhat had veel meer schade aan kunnen richten (repositories verwijderen, exploits kunnen verwerken in code etc.).

[Dreamvoid]

Hoe weet je dat dit niet allang gebeurd is?

[Superstoned]

Niet door hem, zou wel stom zijn om dan op deze manier de aandacht op zichzelf te vestigen... Maar anderen kunnen het gedaan hebben ZONDER iemand te vertellen (dat is precies waarom white hat hackers zo belangrijk zijn voor de security van het internet en veel websites; en waarom het zo ongelofelijk lomp is dat ze wettelijk vaak strafbaar zijn).

[Verwijderd]

Niet door hem, zou wel stom zijn om dan op deze manier de aandacht op zichzelf te vestigen... Maar anderen kunnen het gedaan hebben ZONDER iemand te vertellen (dat is precies waarom white hat hackers zo belangrijk zijn voor de security van het internet en veel websites; en waarom het zo ongelofelijk lomp is dat ze wettelijk vaak strafbaar zijn).

Klopt zoek maar op google white hat, en jail.. Is gewoon om te

[DeTeraarist]

Het labeltje White verloor hij toen hij er ook daadwerkelijk misbruik van maakte.
Ik snap z'n reactie wel, maar daar mee valt het niet goed te praten.
De manier waarop de Rails developers hier mee om zijn gegaan vind ik overigens ook belachelijk.

[Ruudjah]

Hoe heeft hij er precies misbruik van gemaakt? Ik heb dat nergens gelezen, en heb inmiddels aardig wat woorden erover gezien.

[DeTeraarist]

Hierdoor kon hij zich voordoen als Rails-ontwikkelaar en was hij in staat daadwerkelijk een nieuw bestand toe te voegen aan het Rails-project.

En dan gaat het niet om wat voor bestand het is, ook al was het maar een tekstbestandje met "hello world".

[Ruudjah]

Dat is toegang verschaffen, maar nog steeds geen misbruik maken. Choose your words carefully.

[Dreamvoid]

Er zijn al bakken aan wetten voor klokkeluiders, daar vallen "white hackers" ook onder.

1 van de saillante aspecten van de Amerikaanse klokkeluiderswet is trouwens dat de klokkeluider een percentage van de uiteindelijk opgelegde boete kan krijgen. Dat kan in de miljoenen lopen, dus krijg je nu het bizarre effect dat werknemers niet eens meer proberen om fouten intern aan te kaarten of op te lossen, maar direct naar de (inmiddels zwaar overbelaste) regulator stappen.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 05:39]

[Superstoned]

Hmmmm. Zo heeft elk voordeel zijn nadeel - in NL mag je jarenlang in een camper wonen als je misstanden aan de kaak stelt... Dan maar miljonair ;-)

[Oyxl]

Wat jij doet is dus liever je kop in het zand steken en wachten tot de echte hackers er mee aan de haal gaan? Zo prachtig altijd, jullie willen enerzijds wel dat er goed beveiligd wordt, maar als dat niet het geval is, dan hoor je het liever niet. Totdat iemand het halve bedrijf leeg trekt en al je persoonsgegevens door geïnfecteerde applicaties worden verzameld, waarna je alle accounts die je hebt een nieuw WW moet gaan geven en je volledige systeem overhoop gooien. Waarschijnlijk niet in die volgorde.

[Ruudjah]

Precies. Bij 'responsible disclosure' ofwel verantwoordelijke bekendmaking, zou je onschendbaar moeten zijn als whitehat hacker.

[mashell]

En dit is waarom dit soort "white hackers" een positie moeten hebben in het wetboek

Dat gaat me te ver. Ik vind wel dat het OM een beleid moet voeren dat een hacker die wat ontdekt, dit bij de politie en gehackte partij aangeeft en niet de publiciteit zoekt vrijstelling van vervolging dient te krijgen.

[postbus51]

En dat is waarom je moet lezen , dat hij in het FORUM door Rails-ontwikkel ontnomen werd van zijn aanspraak over een lek (github deed test na zijn uitspraak)

En het toevoegen van een txt met de mededeling dat het toch mogenlijk is dan
Ontspoort haha de boel (niet verwarren met trein ramp polen-argentinie)

[DrClaw]

zit het probleem nou in ruby on rails, of in github? blijkbaar in rails dus, maar github is een van de populairdere apps die gebruikt maakt van rails, en van delegated rights?

enfin, ik heb mijn code dus niet op github, maar op een eigen isntallatie van chiliproject (een redmind clone dus, op basis van het rails framework) .. dus mijn code repository zal ook wel aan te vallen zijn fijn.

eens gauw kijken wat eraan te doen valt.

[T020]

Het probleem zit in GitHub zelf, in het artikel staat een link met de oplossing.
Volgens de link is het wel pas van toepassing in Rails 3.1, terwijl GitHub al langer van het framework gebruik maakt. Het is wat dat betreft niet nalatig geweest bij de eerste implementatie, echter zijn ze niet meegegaan met deze beveiligingsupdate.

[Interfico]

Onzin. Wat Rails 3.1 heeft toegevoegd is makkelijk conditions toevoegen aan attr_accessible. Mass assignment tegen gaan kon al jaren d.m.v. attr_accessible en attr_protected.

[Interfico]

Dit is geen fout in Rails maar een fout in de implementatie van Github.

[copywizard]

@ TvdW : White "hat" hackers bedoel je denk ik?

maar dit is als ik het goed begrijp netjes aangegeven door de hacker in kwestie en vindt ik dan ook een goede zaak dat hij als hij geen gehoor krijgt het ze maar op de harde manier laat zien

[Interfico]

Simpelweg attr_accessible aan je model toevoegen is voldoende om mass assignment tegen te gaan. Vreemd dat dit door het team van Github in zo'n essentieel gedeelte van de applicatie over het hoofd werd gezien.

Het is zelfs mogelijk om globaal attr_accessible te verplichten:
config.active_record.whitelist_attributes = true

[Reactie gewijzigd door Interfico op 23 juli 2024 05:39]

[Verwijderd]

ik vind dat hij volledig in zijn recht had moeten staan, want ja wie niet luisteren wilt....

[bramkok]

Gelukkig heeft onze Russische vriend het gemeld i.p.v. uitgebuit. Hetzij op een discutabele wijze. Het beste was natuurlijk geweest dat er discrete en directe melding naar Rails (en GitHub) was gegaan. Rails had op haar beurt de community moeten inlichten op een gepaste wijze.

Nu deze melding publiekelijk is gedaan en het duidelijk is dat Rails de melding negeerde kan je jezelf afvragen of de partijen (Rails en GitHub) wel goed hebben gehandeld. Deze issue (https://github.com/rails/rails/issues/5239) waarin het probleem voor het eerst werd gemeld is, na een korte comment, gewoon geclosed zonder enige actie van Rails.

Want twee dagen later kon onze Russische vriend dezelfde kwetsbaarheid gebruiken om in de master branch van Rails een van zijn commits te kunnen pushen. Daarnaast kon hij dat in iedere repository op GitHub en ook had hij de mogelijkheid om alle commit history voor altijd te laten verdwijnen. (Zie commit: https://github.com/rails/rails/issues/5239)

Pas toen hij een commit heeft kunnen pushen in de Rails master branch is het balletje gaan rollen bij de GitHub ontwikkelaars en hebben ze zijn account disabled.

[Reactie gewijzigd door bramkok op 23 juli 2024 05:39]