Menü
Avatar von Valentin Hilbig
  • Valentin Hilbig

mehr als 1000 Beiträge seit 08.01.2000

2FA bei GitHub taugt nicht viel gegen solche Angriffe

GitHub fragt 2FA nur beim ersten Anlegen des Browser-Cookies an. Das ist recht sinnfrei, denn 2FA ist ja dazu gedacht, dass Du etwas WISSEN musst und etwas HABEN musst (halt ein 2. Faktor). Das gilt, so wie es GitHub gemacht hat, aber mehr nur für den Nutzer, und weniger für den Angreifer, bietet also nur einen sehr geringen Zusatzschutz.

Denn GitHub fragt den 2FA nur beim Login an. Alles, was Du nun machen musst ist, den Logout zu verhindern so dass es zu keinem neuerlichen Login kommt. Dann hast Du als Angreifer (im Browser oder Computer) alles, was Du brauchst:

- Cookie (das den 2FA verhindert)
- Passwort (mit dem Du selbst die sensibelsten Dingen tun kannst)

Diese Situation ist eigentlich die Regel wenn Du Fremdhardware verwendest (Internet-Cafe, Projektrechner, etc.). Ich würde raten, etwa 2/3 aller Accounts bei GitHub sind in genau dieser Situation (ich gehöre übrigens dazu!). 2FA bei GitHub hilft also nur wirklich ca. 1/3 aller Accounts dort, also nur diejenigen, die eh schon paranoid unterwegs sind. Als Firma (wie Canonical) kannst Du Dir das aber nicht leisten, da gehört man also zu 2/3 der Accounts, denen 2FA nicht wirklich viel nutzt (aber die Dinge sehr stark erschweren).

Für weniger sensible Dinge, wie z. B. einen Force-Push (Entfernen von Protected Branches) oder das Anlegen von Repositorien brauchst Du nicht einmal das Passwort, da reicht alleine das Cookie!

Gegen die Trojanisierung von Browser oder Computer, und das dürften eben 99,9% der Fälle sein, in denen ein solcher Account übernommen wird, hilft die 2FA-Funktionalität von GitHub also kein Stück. Es verhindert nur die 0,1% der Fälle, in denen das Passwort schwach ist, geraten werden kann oder über die Schulter mitgelesen wird.

Nicht gerade viel.

Hast Du beides, also Cookie+PW, kannst Du Dir ein API-Token anlegen, das dann auch noch funktioniert, wenn das Passwort oder 2FA gewechselt wird. Kein besonders hoher Schutz den 2FA so bietet.

Warum jemand 2FA implementiert und lediglich den rein INITIALEN Zugang durch 2FA sichert, aber alle GESCHÜTZTEN Aktionen genau so lässt wie gehabt, das wird mir immer ein Rätsel bleiben. Alibi-2FA nennt man sowas wohl.

Anders erklärt:

Wenn man etwas ändern will, fragt GitHub bei sensiblen Aktionen das PASSWORT ab.

Das ist Blödsinn, weil das an dieser Stelle nix verhindert. Richtig wäre hier, stattdessen den 2FA abzufragen, d. h. wenn ich etwas heftiges mache wie ein API-Token hinzuzufügen, muss ich einen weiteren 2FA eingeben. Etwas, das der Angreifer eben nicht tun kann (außer er hat das Token geklaut. Vermutlich wurde das nicht gemacht, weil das die SMS-Transaktionskosten gesteigert hätte als 2FA eingeführt wurde. Inzwischen sollte SMS-2FA aber eher selten genutzt werden - es ist schlicht sehr unbequem.)

Außerdem funktioniert 2FA bei Organisationen schlecht, wenn diese einen gemeinsamen Account haben. Beispielsweise schaltet sich bei GitHub der SMS-2FA ab, wenn man Google-Auth hinzuschaltet. WTF? Ich möchte gerne 3 Telefonnummern für SMS-2FA (Fallback wenn ich alles, inkl. Handy, vergessen habe - dann nehme ich eines meiner Notfallhandys die für genau den Zweck in den Autos rumliegen), eine Telefonnummer als Recovery, mindestens 10 Google-Auth-Token, 3 Yubikeys und 2 FIDO-Keys hinzufügen können (nur letzteres geht mehrfach). Und das gilt nur für meinen eigenen Privataccount! (FIDO-Keys sind mir zu unhandlich, weil die USB brauchen.)

Absolute Scheinimplementierung eines 2FA was GitHub hier vormacht. Aber vermutlich sehe nur ich das so, den die haben ja so ein tolles Facebook-Recovery (was auch immer das ist, mangels Facebook will ich's gar nicht wissen).

Und kommt mir nicht mit "SMS-TAN ist unsicher". Weil jedes Möchtegern-Scriptkiddie vom Mond aus in Deiner Nähe einen IMSI-Catcher spawnen kann und selbstverständlich beliebige Telefonnetze auf globaler Ebene kompromittieren kann um die SMS zu entführen. Klar doch. Realitycheck pls!

99% aller Schäden gehen auf Gelegenheitsangriffe zurück (die restlichen 1% der Angriffe durch Targeted Attacks kann man durch 2FA eh nichts ausrichten - die klauen einfach den 2nd Factor), z. B. durch trojanisierte Rechner oder Ergebnis irgendwelcher Daten-Dumps (vgl. Suchmaschinen wie Shodan). Genau gegen diese Form der Angriffe sollte 2FA zusätzlich schützen.

So wie es GitHub aber macht hilft das nur sehr sehr wenig. IMHO kann man 25% dieser 99% durch Maßnahmen verhindern, die ganz ohne 2FA auskommen. Und GitHub erhöht dies mit seinem 2FA dann auf 30%. Auf, nicht um. Mit einer sinnvollen Implementierung von 2FA könnte man die Schäden IMHO aber um 90% eindämmen.

Sprich:

Jemand klaut Cookie+Passwort. Damit kann er dann aber nur weniger schlimme Dinge machen wie Repos anlegen oder lesende Keys hinzufügen. Schreibzugriff bekommt er so nur FastForward über das Webinterface. Er kann auch keine protected Branches ändern usw. Bei Public-Repos also erhält so jemand also auch etwas zusätzliche Metadaten, die er sonst nicht hat, wie z. B. weitere Mailadressen.

So würde ich mir naiverweise eine sinnvolle 2FA-Implementierung vorstellen. Also ganz ungeschliffen, so als das Miniumum eines sinnvollen Anfangs.

Aber natürlich ist 2FA kein Sicherheitskonzept das man irgendwie berücksichtigen muss. Einfach dazupappen und gut. Was dabei dann rauskommt sehen wir bei GitHub. 2FA um des 2FA-Willen. Hauptsache, es sieht gut aus.

-Tino
PS: Es gibt auch Beispiele, da wurde 2FA etwas sinnvoller umgesetzt. Z. B. Hetzner. Zwar ist das Ding dort auch noch weit von der Perfektion entfernt, aber deren Lösung passt zumindest deutlich besser auf das, was sie tun soll, als bei GitHub.

Edits: Clarity

Das Posting wurde vom Benutzer editiert (12.07.2019 02:30).

Bewerten
- +
Anzeige