“Einbruch” bei GitHub.com

Mit einer eher interessanten als gefährlichen Variante eines Einbruchs in Ihre Infrastruktur sah sich gestern, am 4. März 2012, der Code Hoster GitHub konfrontiert, als der russische Programmierer Egor Homakov diese Präsenz benutzte um auf eine Sicherheitslücke in Ruby on Rails (kurz: Rails), einem dem Ruby basierendem Framework für Webapplikationen, aufmerksam zu machen. GitHub ist ein sagenhaft populärer Hoster von Git-Repositorien, der neben dem reinen Hosting des Codes auch ein Wiki, Bugtracker, usw. bietet. Auch ich partizipiere darüber an Projekten wie z.B. “flora“. Zufällig verwendet GitHub selbst das Rails Framework; ebenso nutzen die Rails Entwickler GitHub als Code Hoster der Rails-Quellen. Ein ideales Ziel also für Homakov um, nach anfänglichen Schwierigkeiten sein Anliegen den Rails Entwicklern darzulegen, diese Lücke zu demonstrieren:

Er nutzte sie erfolgreich aus, verschaffte sich administrativen Zugang zum Rails-Projekt, bewies das er volle Admin-Rechte erlangt hatte und beispielsweise Fehlerberichte nach Belieben öffnen, schließen und sogar aus der Zukunft schreiben konnte. Außerdem fügte er dem Repositorium eine Datei hinzu. Auch das vollständige Löschen der gesamten Projekthistorie wäre möglich gewesen.

GitHub sperrte daraufhin den Account von Homakov, behob die Sicherheitslücke und gab eine Sicherheitswarnung heraus. Wenig später folgte eine zweite Ankündigung, in der man (wohl auch nicht zuletzt aufgrund anhaltender Proteste der Community) Homakov weitestgehend rehabilitierte und die Sperrung seines Accounts aufhob.
Einige  Leute, die nach wie vor keine wirklich schwerwiegenden Probleme zu haben scheinen und ansonsten offenbar wenig mit Ihrer Freizeit anzufangen wissen, diskutieren immernoch ob Homakov ein “Held” oder ein “Krimineller” ist … OMG!
Er selbst entschuldigt sich auf seinem Blog für sein Vorgehen:

Yes I behaved like a jerk.

GitHub selbst hat alleine dadurch, das sie dem Urheber eines wie auch immer beabsichtigten, jedoch dadurch juristisch nicht weniger strafbaren, Hackerangriffs bereits am nächsten Tag wieder uneingeschränkten Zugriff auf Ihre Systeme gewährten und dem ganzen scheinbar auch keine Strafanzeige folgen lassen, seinen guten Willen bewiesen.
Damit sollte doch alles gesagt sein, meine Güte! Beide sind sich einig und wieder Freunde :) . Das GitHub erstmal vorsorglich das Einfallstor schließt, bis alles geklärt ist, ist doch nur normal! Alles andere wäre strafbar fahrlässig.

Die Rails-Entwickler sind in meinen Augen die, die viel zu wenig tun. Sie wollen die Funktionen, die soetwas ermöglicht, auf Produktivsystemen künftig standardmäßig abschalten. Mit einem Fix ist “bereits” mit Rails 3 als Plugin zu rechnen … Sicherheit als zukünftige, optionale Alternative … na super. Leute, das ist armseelig und unterstreicht in meinen Augen das Rails ein Framework ist, von dem man tunlichst die Finger lassen sollte!
Man stelle sich folgendes Gespräch in einem Autohaus vor:

“Chef, Chef! Man kann in unserem neuen Auto Modell 2012 ohne den Originalschlüssel die Türen öffnen und losfahren! Ein Sicherheitsexperte vom ADAC hat das bereits im Fernsehen demonstriert! Was machen wir??” 

“Ruhig Blut … wir bieten mit dem 2013er Modell nächstes Jahr ein Bonuspaket an, mit dem man den Wagen dann wirklich abschließen kann … jetzt hauen sie ab und verkaufen erstmal die Hallen leer!”

Da hat jemand offenbar absolut keine Ahnung davon, was sie da anrichten und was sie auch nicht zuletzt dem Ruf von Ruby ansich antun. Ein Projekt solcher Größe sollte nicht von solch blauäugigen Diletanten geführt werden. Dann nimmt man halt viele bestehende Projekte erstmal vm Netz – na und ?? Das Fundament muss doch trotzdem frei von solchen Kloppern sein; wem das nicht passt soll halt auf ein Update verzichten! Und wenn es in der Tat zwei Lager gibt, dann muss man halt forken! Aber sowas,  was die jetzt auf die Roadmap gesetzt haben, ist die denkbar schlechteste “Lösung”.


Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *