Electronic Arts: Hack von 700 Millionen Konten

 (battleda.sh)
1 Punkte von GN⁺ 2024-11-06 | 1 Kommentare | Auf WhatsApp teilen
  • Durch das Zusammenspiel aus offengelegter Swagger-Dokumentation für die EA-Authentifizierungs- und Gateway-APIs und fehlender Berechtigungsprüfung bei Persona-Updates konnten auch Daten anderer Nutzerkonten und sogar Login-Abläufe betroffen sein
  • Der Kern des Problems war, dass PUT-Anfragen an /identity/pids/{pidId}/personas/{personaId} mit dem Scope dp.client.default eines normalen EA-Desktop-OAuth-Clients möglich waren und die Eigentumsprüfung für die pidId im Request-Body sowie die personaId im Pfad unzureichend war
  • Angreifer konnten Änderungen von Persona-Benutzernamen, das Setzen des Status BANNED, das Verschieben von Personas, das Auffinden von Persona-IDs versteckter Konten und die Umgehung des Logins über Xbox-Personas kombinieren, um bis zum Web-Login des Kontos zu gelangen
  • Die Auswirkungen reichten vom Diebstahl von Benutzernamen und einigen Spieldaten über das Blockieren des Zugangs zu Online-Spielen und das Umgehen von Spiel-Bans bis hin zum Login in EA-Konten über Xbox; die Schwere wurde mit CVSS 10.0 bewertet
  • Die Schwachstelle wurde am 16. Juni 2024 an EA gemeldet; EA stufte sie am 25. Juni als kritisch ein und rollte vom 8. Juli bis 8. Oktober Patches aus, darunter Prüfungen der Persona-Eigentümerschaft und die Entfernung der Dokumentation

Offengelegte API-Dokumentation als Ausgangspunkt in der EA-Authentifizierungsumgebung

  • Ausgangspunkt war ein im EA Desktop entdeckter Entwicklungstest der Umgebung integration
    • Die Produktions-Authentifizierungs-API war accounts.ea.com
    • Der Authentifizierungs-Host der integration-Umgebung war accounts.int.ea.com
  • In der integration-Umgebung ließ sich ein berechtigtes Access-Token erhalten; um zu prüfen, welche APIs damit zugänglich waren, begann die Suche nach offengelegter Dokumentation
  • Die Authentifizierungsendpunkte lagen hinter einem Reverse Proxy; die 404-Antworten für den Pfad /connect und den normalen Pfad / hatten unterschiedliche Formate, und der server-Header war istio-envoy
  • /connect/api-docs lieferte im Gegensatz zu anderen /connect-Pfaden ein leeres 404 zurück, was auf mögliches separates Service-Routing hindeutete; unter /connect/api-docs/index.json wurde dann eine Swagger-1.1-Dokumentation gefunden
  • Die Swagger-Dokumentation verwies auf /api-docs/connect; diese wurde mit swagger-codegen-cli in eine OpenAPI-3.0-Spezifikation umgewandelt und lokal in Swagger UI geprüft

Interne API-Liste im Gateway

  • EA Desktop nutzt eine GraphQL-API namens „Service Aggregation Layer“, doch die SAL der integration-Umgebung lag hinter einer Firewall
  • Die ältere, offenbar frühere Gateway-API unter gateway.ea.com verwendete Endpunkte im Format proxy/{service}/{route}
  • gateway.int.ea.com/proxy/api-docs/index.json lieferte eine Dokumentenliste für mehr als 80 Services
    • Darunter waren Services wie addresses, agerequirements, billing, commerce und weitere
  • Die einzelnen API-Dokumente wurden heruntergeladen, in aktuelle OpenAPI-Spezifikationen konvertiert und dann auf zugängliche Funktionen geprüft
  • Einige Endpunkte lieferten „projects“-Daten zu EA-Game-Teams und erforderten den Berechtigungsumfang basic.domaindata; auch in der Produktion wurden Clients mit diesem Scope gefunden
    • In Beispieldaten tauchten unter anderem ein eingestelltes Star-Wars-Spiel und Apex Legends mit einem Gruppennamen zu Titanfall3 auf
  • In der integration-Umgebung war auch dokumentiert, wie sich benutzerdefinierte Spiel-Entitlements vergeben lassen; da die für Download und Nutzung nötigen integration-Services jedoch hinter einer Firewall lagen, war der praktische Nutzen gering
  • Es gab auch einen Endpunkt, der Xbox Live Server Tokens zurückgab, doch weil die Sandbox-ID nicht RETAIL war, wurde dies nicht weiter untersucht

Produktions-Kontoinformationen und Persona-Struktur

  • Für jeden Endpunkt zeigte die Dokumentation die nötigen Auth-Scopes; die Prüfung konzentrierte sich daher auf Endpunkte, die mit Produktions-OAuth-Clients erreichbar waren
  • /identity/pids/me gibt allgemeine Kontoinformationen zurück
    • Dazu gehören maskierte E-Mail-Werte, E-Mail-Status, Teile des Geburtsdatums, Land, Sprache, Kontostatus, AGB-Version, Zeitpunkte für Erstellung, Änderung und letzte Authentifizierung sowie der 2FA-Status
  • /identity/pids/me/personas gibt die Liste der mit dem Konto verknüpften Personas zurück
    • Das Standard-EA-Konto nutzt den Namespace cem_ea_id
    • Verknüpfte externe Konten wie Steam oder Xbox erscheinen ebenfalls jeweils als eigene Persona
  • Spiele speichern Daten wie Statistiken oder Inventar oft unterhalb einer Persona, wodurch plattformspezifische Daten getrennt sein können
  • Im weiteren Verlauf wird die Persona im Namespace cem_ea_id als „Origin“-Persona bezeichnet

Kernschwachstelle: fehlende Berechtigungsprüfung bei Persona-Updates

  • Der Endpunkt /identity/pids/{pidId}/personas/{personaId} akzeptiert GET-, PUT- und DELETE-Anfragen
  • PUT-Anfragen erlaubten die Scopes dp.client.default und dp.server.default, und der normale Auth-Client von EA Desktop besaß dp.client.default
  • Der Request-Body konnte displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId und weitere Felder enthalten
  • Eine PUT-Anfrage zum Ändern von displayName der eigenen Origin-Persona war erfolgreich, und der Benutzername auf der EA-Konto-Website änderte sich
    • Damit wurden sowohl die Cooldown-Zeit für Namensänderungen als auch die E-Mail-Bestätigung für Namensänderungen umgangen
  • Eine Änderung von namespaceName zeigte keine Wirkung
  • Für status waren die Werte ACTIVE, DISABLED, PENDING, DELETED, BANNED möglich; wurde der Status der eigenen Origin-Persona auf BANNED gesetzt, ließ sich EA Desktop weiter nutzen, aber Spiel-Logins wurden blockiert
  • Noch gravierender war, dass sich die pidId im Request-Body auf die ID eines anderen Kontos ändern ließ
    • Eine Anfrage, die die eigene Steam-Persona auf das EA-Konto eines Freundes verschob, war erfolgreich
    • Anschließend konnte sie auch wieder auf das eigene Konto zurückverschoben werden

Login-Prüfung und XSS-Versuch

  • Nachdem die eigene Steam-Persona auf das Konto eines Freundes verschoben worden war, erschien beim Login in die EA-Website über Steam eine E-Mail-Bestätigung wegen neuem Standort bzw. nicht vertrauenswürdigem Gerät
  • Ein Teil der angezeigten E-Mail-Adresse gehörte nicht zum eigenen Konto, was zeigte, dass der Ablauf bereits den Login in das Konto des Freundes erreichte, dort jedoch an der standortbasierten 2FA scheiterte
  • Auch eine Anfrage, die den Persona-Benutzernamen auf BattleDash <script>alert(1)</script> setzte, war erfolgreich
  • Auf der Seite zur Kontoverknüpfung wurde dadurch ein Alert ausgeführt, also war XSS möglich
    • Wäre ein Nutzer im EA-Konto eingeloggt und würde auf diese Verknüpfungsseite geführt, könnte Code im Browser ausgeführt und die Session extrahiert werden

Direkte Manipulation fremder Personas

  • Um zu prüfen, ob auch für die personaId im Pfad die Eigentumsprüfung fehlte, wurde versucht, den Benutzernamen einer nicht selbst besessenen Persona zu ändern
  • Nach Ermittlung der Persona-ID eines neuen Testkontos war eine Anfrage erfolgreich, die den Benutzernamen dieses Kontos ohne Authentifizierung des Zielkontos änderte
  • Auf die gleiche Weise ließ sich auch der status auf BANNED setzen, wodurch sich das betroffene Konto nicht mehr in Spiele einloggen konnte
  • /identity/personas durchsucht Personas nach displayName und gibt Persona-ID, Konto-ID, Erstellungsdatum und Zeitpunkt des letzten Logins zurück
    • Nutzer, die ihr Konto verborgen hatten, wurden dabei allerdings nicht angezeigt
  • /identity/namespaces/{namespace}/personas sucht innerhalb eines bestimmten Namespace und gibt nur Benutzername und Persona-ID zurück, liefert aber auch versteckte Konten
    • Schon dieser Endpunkt reichte aus, um die benötigte Persona-ID zu erhalten

Einschränkungen beim Verschieben von Personas und partielle Kontoübernahme

  • Beim Versuch, die Origin-Persona eines anderen Nutzers auf das eigene Konto zu verschieben, trat der Fehler TOO_MANY_PERSONAS_FOR_NAMESPACE auf
    • Der Grund war, dass das eigene Konto bereits eine Origin-Persona hatte
  • Da über Konsolen registrierte Konten möglicherweise nur die jeweilige Plattform-Persona und keine Origin-Persona besitzen, wurde ein Konsolenkonto genutzt, um Namespace-Konflikte zu vermeiden
  • Dadurch war es möglich, zunächst die Origin-Persona eines Testkontos auf das Konsolenkonto zu verschieben und anschließend die Origin-Persona des Opfers auf das eigene Konto zu übertragen
  • In diesem Zustand wurden beim Login der Benutzername des Opfers, nicht plattformübergreifende Spielstatistiken und einige weitere Kontodetails angezeigt
  • Beim Login in das Opferkonto erschien dann der Ablauf „Finish setting up my account“, als würde ein neues Konto eingerichtet und ein Benutzername gewählt werden müssen
  • Entitlements, Freunde und gespeicherte Daten moderner plattformübergreifender Spiele wie Battlefield 2042 waren jedoch nicht an die Persona, sondern an das EA-Konto selbst gebunden und wurden daher nicht mit übertragen
  • Trotzdem konnte ein Angreifer Nutzer bannen, Spiel-Bans umgehen, Benutzernamen stehlen und Kontodaten als Druckmittel festsetzen

Login-Umgehung über Xbox-Personas

  • In diesem Zustand waren unter anderem folgende Aktionen möglich: die eigene verknüpfte Konto-Persona auf ein beliebiges EA-Konto verschieben, eine beliebige Persona auf das eigene Konto verschieben sowie Personas bannen oder umbenennen
  • Wenn zum Login in ein fremdes Konto die eigene Persona dorthin verschoben wurde, erschien weiterhin eine E-Mail-Bestätigung
  • Da auf Konsolen beim Spielen von EA-Titeln offenbar keine 2FA-Abfrage erschien, wurde der Login über Xbox-/PSN-Tokens untersucht
  • Die Dokumentation der Nexus Connect API beschrieb die Übergabe von Xbox-/PSN-Tokens; aus dem PSN-Login-Ablauf der EA-Seite wurde eine PSN-Client-ID gewonnen und ein Login per PSN-Token getestet
  • Der Login per PSN-Token erstellte eine Persona im Namespace ps3 und erlaubte den Konto-Login ohne 2FA, doch Clients mit dp.client.default konnten den Namespace ps3 nicht verwalten
  • Durch Hinzufügen des Headers X-Include-Namespace zu /connect/tokeninfo zeigte sich, dass es je OAuth-Client eine Liste manipulierbarer Persona-Namespaces gab
    • Das Beispiel JUNO_PC_CLIENT enthielt die Namespaces cem_ea_id, steam, epic, xbox
  • Der Namespace Xbox war also erlaubt, doch da sich kein gültiges Microsoft-XSTS-Token für Spiele manuell erzeugen ließ, erfolgte der Test auf einer echten Xbox
  • Nach dem Anlegen eines neuen Microsoft-Kontos und der Verknüpfung seiner Xbox-Persona mit einem Test-EA-Konto wurde diese Xbox-Persona auf das Opferkonto verschoben
  • Beim Login in die EA-Website mit dem Xbox-Konto erschien zunächst die E-Mail-Bestätigung für neuen Standort, doch nach der Anmeldung in Battlefield 2042 auf der Xbox erfolgte der Zugriff auf das Opferkonto
  • Danach gelang auch der Login in die EA-Website mit demselben Xbox-Konto ohne E-Mail-Bestätigung direkt in das Opferkonto

Auswirkungen und Schweregrad

  • Für Angreifer gab es im Wesentlichen zwei Hauptpfade
    • Sie konnten Persona-Daten anderer Nutzer aus deren Konten herauslösen und so Benutzernamen und Spieldaten entwenden
    • Oder sie konnten ihre eigene Xbox-Persona auf das Opferkonto verschieben, sich auf der Xbox in ein EA-Spiel einloggen und nach Aufbau eines vertrauenswürdigen Netzwerkzustands mit dem Xbox-Konto in die EA-Website einloggen
  • Hinzu kamen weitere erhebliche Auswirkungen
    • Fremde Personas konnten gebannt werden, wodurch sich die meisten Online-Spiele nicht mehr spielen ließen
    • Fremde Benutzernamen konnten geändert und anschließend übernommen werden
    • Da Spiel-Bans durch das Deaktivieren aller Spiel-Entitlements eines Kontos umgesetzt wurden, konnten sie durch Verschieben einer Persona auf ein neues Konto umgangen werden
  • Dieser Ablauf war weitgehend ohne Nutzerinteraktion möglich und lief vor allem über einen einzelnen API-Endpunkt
  • Die Schwere wurde nach AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H mit CVSS 10.0 bewertet

Zeitplan der Behebung und weitere Einschätzungen

  • Die Schwachstelle wurde am 16. Juni 2024 an EA gemeldet
  • EA bestätigte den Eingang am 25. Juni 2024 und bewertete sie als kritisch
  • Der Patch-Zeitplan sah wie folgt aus
      1. Juli 2024: Patch 1 ausgerollt, Prüfung der Persona-Eigentümerschaft
      1. Juli 2024: Patch 2 ausgerollt, Details unbekannt
      1. September 2024: Patch 3 ausgerollt, Details unbekannt
      1. September 2024: Patch 4 ausgerollt, Dokumentation entfernt
      1. Oktober 2024: Patch 5 ausgerollt, Details unbekannt
  • EA ging anfangs davon aus, dass die Behebung bis zum Jahresende dauern könnte; bei einer Lage, in der offengelegte Dokumentation und ein einzelner unsicherer Endpunkt den Kern bilden, wären schnellere temporäre Gegenmaßnahmen wünschenswert gewesen
  • EA hat weiterhin kein Bug-Bounty-Programm, und ohne greifbare Belohnung für Meldungen bleibt die Sorge bestehen, dass manche Schwachstellen lieber nicht offengelegt werden
  • Das an den frühen Tests beteiligte Konto eines Freundes wurde mit dessen Einverständnis verwendet

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-06
Meinungen auf Hacker News

  • EA nutzt für mehrere Spiele gern gemeinsame Systeme. Beim Herumstöbern in Madden habe ich entdeckt, dass es ein gemeinsames Backend namens blaze gibt und dazu generische Web-/TCP-Endpunkte.
    Ich baute ein Tool, das diesen Endpunkt aufrief, musste dafür XML hochladen und merkte später, dass dabei bei jedem Aufruf EA-Server abstürzten.
    Da pro Anfrage ein neuer Server gegriffen wurde, brachte ich nach und nach sämtliche Madden-Server zum Absturz, und am Ende baute EA eine API, damit die Leute nicht mehr herumstochern.

    • Blaze ist der Name eines C++-Frameworks/Dienstes zum Erstellen eigener Backends für Online-Spiele. Es ermöglicht Game-Teams, Online-Funktionen auf standardisierte Weise zu entwickeln, mit MySQL im Hintergrund.
      Soweit ich mich erinnere, brauchte man ungefähr eine Blaze-Instanz pro 5.000 bis 10.000 Spieler.
    • Ich bin der Autor des Beitrags; letztes Jahr habe ich auch einen Text über jede Menge Blaze-Schwachstellen geschrieben, die ich gefunden hatte, ihn aber nicht veröffentlicht.
      Man schien sich ziemlich darauf auszuruhen, ein proprietäres Format zu verwenden und anzunehmen, dass niemand herausfinden würde, wie das Interface funktioniert – also Security by Obscurity.
      Irgendwann möchte ich darauf zurückkommen; zumindest steckt darin einiges ziemlich Interessantes.
    • Ich glaube, ich habe diese API kürzlich in einem anderen Spiel gesehen. Das ist doch ein GraphQL-Frontend, oder? Introspection war abgeschaltet, aber die Fehlermeldungen machten freundliche Vorschläge bei falsch geschriebenen Feldnamen.
      Ein Tipp beim Reverse Engineering von APIs solcher bekannten Dienste: GitHub Code Search verwenden. Wenn man einen eindeutigen Endpunktnamen eingibt, findet man oft Leute, die sich ebenfalls kleine API-Clients zusammengehackt haben, und das hilft der eigenen Recherche auf unerwartete Weise.
    • Wenn man wiederholte PSN-Client-ID-Werte durchprobiert und versucht, sich beim EA-Gateway-Proxy anzumelden, wird ein aus persönlichen Daten stammender namespacename-Wert zurückgegeben. 2FA-Token-Informationen müssen über den /tokeninfo/-Endpunkt aus JUNO gehasht werden.
      Wenn man nachträglich eine Integration versuchte, gab die Infrastruktur für die C++-API oft die PSN-User-ID zurück.

  • Wie jeder vernünftige Mensch es natürlich getan hätte, habe ich eine Xbox mit Lieferung am nächsten Tag bestellt, Battlefield 2042 installiert, auf den entscheidenden Moment gewartet – und kam hinein.
    Hacker sind wirklich großartig <3

  • Interessant war der detaillierte Ablauf, wie man von einem Punkt zum nächsten kam. So sauber linear wie in einem Blogpost wird es wohl nicht gewesen sein.
    Um zu zeigen, wie viel Zeit und Aufwand solche Angriffe wirklich kosten, gäbe es vermutlich Berge von Notizen; die zu sehen wäre ebenfalls spannend.

  • Das Seltsamste an all dem ist, dass EA jahrelang behauptet hat, es sei technisch unmöglich, die Verknüpfung eines bestehenden Xbox-Kontos zu lösen und es mit einem neuen Konto neu zu verknüpfen. Siehe Beiträge wie https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... und zahllose Posts im EA-Forum.
    Ich bin selbst gegen diese Wand gelaufen und habe stundenlang mit dem EA-Support telefoniert, aber sie konnten mein sehr altes Xbox-Konto nicht verknüpfen. Deshalb kann ich mich auf der Xbox bei keinem EA-Spiel anmelden und auf der Plattform das meiste nicht spielen.
    Hier zeigt sich nun aber, dass es durchaus möglich ist.

    • Mir fällt ein, dass mein Hotmail-Konto 2004–2005 die üblichen 4 MB Speicherplatz hatte, während Microsoft gerade für alle ein kostenloses Upgrade auf 250 MB ausrollte.
      Seltsamerweise dauerte es bei meinem Konto viel zu lange, und ich schrieb über ein bis zwei Jahre mehrfach an den Support. Jedes Mal bekam ich die Antwort, man aktualisiere die Konten so schnell wie möglich, aber die Aufgabe sei so groß, dass es Jahre dauern werde.
      Später sah ich in irgendeinem Forum einen Trick: Wenn man das Konto kurz schloss und wieder öffnete, konnte man es immerhin auf 25 MB erhöhen – aber nicht auf die versprochenen 250 MB.
      Die Lage mit 2–4 MB für bestehende Konten, 25 MB für neue Konten und einem mehrjährigen Rollout bis 250 MB vermittelte den Eindruck, dass Microsoft enorme Schwierigkeiten hatte, freien Speicherplatz aufzutreiben. Doch wenige Monate später mussten sie mit Gmail konkurrieren und beschlossen, allen 2 GB zu geben; das wurde auf einen Schlag für alle Hotmail-Konten ausgerollt, meines eingeschlossen. Außerirdische müssen ein UFO voller Festplatten vorbeigebracht haben.
      [1] Beispiel für einen alten Forenbeitrag zu diesem Trick, inklusive einer Antwort, die das neue Gmail lobt: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
    • Dieser Angriff zeigt, dass es möglich ist, die Verknüpfung zu ändern und das Spiel zu spielen, aber man weiß nicht, welche Nebenwirkungen außerhalb des im Beitrag leicht überprüften Szenarios auftreten können.
      Eine geänderte Verknüpfung könnte Daten ungültig machen, die im Abrechnungssystem gespeichert sind, die monatlichen Reports an Microsofts Xbox-Abteilung durcheinanderbringen oder eine interne Admin-Seite beim Laden abstürzen lassen.
      Ich will EA nicht verteidigen, aber wer viel mit komplexen Microservice-Systemen zu tun hatte, weiß, dass das Ändern einer Datenstruktur an einer Stelle nicht immer simpel ist.
    • Vielleicht war man gerade dabei, diese Funktion hinzuzufügen, um genau dieses Problem zu beheben, und sie wurde unglücklicherweise vor der Veröffentlichung missbraucht.
    • Leider werden bei modernen Cross-Platform-Spielen wie Battlefield 2042 Spielberechtigungen, Freunde und Speicherdaten nicht in der Persona, sondern im EA-Konto selbst gespeichert; diese Daten werden daher nicht übertragen.
    • Es war wohl nicht technisch unmöglich, sondern vermutlich vor allem für den Kundensupport unmöglich zu bearbeiten.

  • Es wäre auch lustig gewesen, alle Accounts zu sperren und zu hoffen, dass es kein DB-Backup gibt

    • Ich würde gern sehen, wie das jedem Milliardenunternehmen passiert, das kein Bug-Bounty-Programm hat. Wenn es für das Melden von Schwachstellen keinerlei Belohnung gibt, ermutigt man Hacker im Grunde dazu, sie zum eigenen Vorteil auszunutzen oder Chaos zu stiften.
      Als zahlender Kunde erwarte ich von solchen Unternehmen eine bessere Haltung, und wenn es kein Programm gibt, würde ich Hacker persönlich nicht dafür verurteilen, wenn sie das ausnutzen, was sie gefunden haben.
    • Für einen Moment könnte das lustig sein, aber sie haben mit Sicherheit Backups.
      Niemand speichert 400 Millionen Datensätze auf einer einzigen Maschine, und am Ende hätte man nur den Dienst für einen ganzen Nachmittag lahmgelegt und würde 15 Jahre Bundesgefängnis bekommen.
    • Genau deshalb hat sich die Welt von der Tech-Branche abgewandt.
      Weil die erste Reaktion – oder zumindest derzeit der bestbewertete Beitrag – der Gedanke ist, es wäre „lustig“, Millionen Menschen zu schaden, um dem Unternehmen, mit dem sie Geschäfte gemacht haben, eine Lektion zu erteilen.
    • Es wäre viel lustiger gewesen, auf allen Accounts alle Spiele freizuschalten. Wirklich alle. Ziemlich einfallslos.
    • Daran habe ich auch gedacht. Was wäre tatsächlich passiert, wenn man es nicht gemeldet, sondern sich bewusst für einen Streich entschieden hätte? Wäre man zurückverfolgt worden? Wäre EA wochenlang offline gewesen?

  • Im Beitrag steht diese Passage:
    I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.
    Kann jemand diesen Teil etwas genauer erklären? Ich dachte, solche Zugangsdaten sollten sich nicht einfach aus einer ausführbaren Binärdatei auslesen lassen, und wenn die Spiel-Executable sich gegenüber einem Remote-Server authentifizieren muss, weiß ich auch nicht recht, was Entwickler sonst tun sollten.

    • Zugangsdaten werden als Strings gespeichert; wenn man also in der Binärdatei nach Mustern sucht, die wie Zugangsdaten aussehen, findet man sie irgendwo.
      In einer Client-Server-Architektur gilt: Dem Client ist nie zu trauen. Die ausführbare Datei sollte sich nicht selbst gegenüber dem Server authentifizieren müssen. Sie sollte mit den vom Nutzer bereitgestellten Informationen den Nutzer oder Account authentifizieren.
      Bei Telemetrie etwa nehmen solche Endpoints normalerweise Daten ohne oder mit schwacher Authentifizierung entgegen und führen mehrere Validierungsschritte durch, um Missbrauch zu verhindern. Meist sind sie außerdem nur zum Schreiben/Anhängen gedacht.
    • Ich weiß nicht, warum man annehmen sollte, dass eine Binärdatei nicht leicht lesbar ist. Auf einer nicht abgeschotteten Plattform sind Binärdateien durchaus gut lesbar.
      Man bräuchte ein System, das die Executable verschlüsselt und bei dem ein Sicherheitsbereich im CPU-Die die Entschlüsselung mit einem privaten Schlüssel übernimmt, aber selbst dann ist es wahrscheinlich nur eine Frage der Zeit, bis jemand den Chip decappt und den Schlüssel bekommt.
    • Wenn der Computer es lesen kann und du diesen Computer vollständig kontrollierst, kannst du es auch lesen. Mit physischem Zugriff ist die Sache vorbei.
      Selbst wenn man verschlüsselt und den Schlüssel in ein HSM legt, ist das auf beliebigen Client-Maschinen vermutlich ohnehin nicht möglich; außerdem muss das Spiel den String irgendwann entschlüsseln und in den Speicher laden. Und diesen Speicher kann man lesen.
    • Wenn ein Programm Zugriff auf Zugangsdaten hat und dieses Programm auf meinem Computer läuft, dann habe auch ich Zugriff auf diese Zugangsdaten, egal wie sie verschleiert sind.
      Was Spieleentwickler tun sollten, ist ein Account-System im Backend zu betreiben und den Spieler im Spiel seine eigenen Zugangsdaten eingeben zu lassen. Dann kann sich das Spiel gegenüber dem Backend-Server als dieser Spieler identifizieren.
      So lassen sich Aktionen im Backend einem bestimmten Spieler zuordnen, und man hat eine gute Grundlage für Sicherheitsentscheidungen.
    • Solche Zugangsdaten in einer ausführbaren Binärdatei zu finden, ist schwierig, aber nicht unmöglich. Es ist lästiger, als Strings aus einer minifizierten JavaScript-Datei zu ziehen, aber keineswegs auch nur annähernd unmöglich.
      Es gibt Tools wie IDA; man muss also nicht mit bloßem Auge zwischen allem suchen, was wie ein String aussieht, um Zugangsdaten zu finden.
      Das Problem ist weniger, dass in der Binärdatei hartcodierte Zugangsdaten stecken, sondern dass diese Zugangsdaten privilegierte Rechte haben.

  • Als Engineer in so einem Unternehmen frage ich mich manchmal, wie es sich anfühlt, wenn private APIs, seltsame Bugs und schmutzige Interna in einem öffentlichen Bericht über einen Sicherheitsvorfall auftauchen.
    Allerdings ist es in so einem Fall unwahrscheinlich, dass eine einzelne Person für die Schwachstelle verantwortlich war. Vermutlich besaßen fünf oder sechs Teams jeweils unterschiedliche Teile, die ausgenutzt wurden, und genau deshalb existierte der Exploit überhaupt. Es ist ein riesiges, komplexes System, in dem jeder nur seinen kleinen Teil versteht.

    • Wenn man emotional – oder auch nur finanziell – in das Team investiert ist, fühlt sich das schlecht an. Aber als ich bei EA war, schien man sich fast Mühe zu geben, es einem schwer zu machen, emotional investiert zu sein.
      In einem Unternehmen von der Größe EAs wird so etwas ziemlich sicher für interne Politik benutzt werden, und Leute werden es nutzen, um mehr Kontrolle über ein kleiner gewordenes Unternehmen zu bekommen, selbst wenn das dem Unternehmen insgesamt schadet.
    • In so einem großen Konzern interessiert das niemanden. Es ist nur ein Job, für den man bezahlt wird.
      Alle sind austauschbare Ressourcen – warum sollte man sich emotional in die Arbeit investieren?
    • Als jemand, der vor etwa zehn Jahren wahrscheinlich im selben Team gearbeitet hat, das genau diesen Code noch betreut, habe ich den Beitrag schnell überflogen, um zu prüfen, ob es Code war, den ich geschrieben oder angefasst hatte.
      Das Team hieß damals Nucleus, weshalb in einer der Antworten im Beitrag refType den Wert NUCLEUS hatte. Dieses Team erstellte und betreute Backend-APIs für Berechtigungen, Accounts und Zahlungen.
      Es war ein Sommerpraktikum, und ein Jahr später bekam ich von diesem Team ein Angebot und fing dort an. Zu diesem Zeitpunkt war der Teamname in EADP geändert worden und es wurde langsam mit Origin zusammengeführt. Ich bin mir nicht mehr sicher, ob DP für Data Platform stand, aber deshalb beginnt einer der Endpoints mit dp..
      Damals gab es keine GraphQL-Datenbank; alles war Enterprise Java, OCI, Spring, Hibernate usw., und bevor ich ging, gab es auch etwas neueres Groovy/SpringBoot. Es lief nicht in der Cloud, sondern auf Servern im Rechenzentrum.
      Trotzdem habe ich an interessanten Dingen gearbeitet und viel Backend-Entwicklung von guten Engineers gelernt, auch wenn ich zwei bis drei Jahre nach einem großen Vorfall gegangen bin.
      Ich habe keine Ahnung, wie das Team heute aussieht, wer dort als Engineer arbeitet oder was passiert ist, aber so etwas zu sehen macht mich traurig. Damals waren wir sehr sicherheitsbewusst und arbeiteten auch an Systemen, die Brute-Force-Versuche auf der Login-Seite erkannten und behandelten.
      Ich weiß nicht, ob das noch aktiv ist oder läuft, aber Security-Checks und Reviews zur Verringerung möglicher Kompromittierungen und der Angriffsfläche waren Teil der Sprint-Arbeit.
    • Besonders schlecht fühlt es sich an, wenn man nicht in dieser Abteilung arbeitet und keine Kontrolle hat, aber weiß, dass man es besser machen könnte als diese Abteilung.
    • Wenn ich so einen Beitrag lesen würde und wüsste, dass ich diese API implementiert habe, würde mir das Herz in die Hose rutschen.

  • Wenn euch dieser Beitrag gefallen hat, findet ihr mehr davon auf Bug-Bounty-Plattformen wie Hacktivity von HackerOne: https://hackerone.com/hacktivity

  • Gibt es irgendwo einen Best-Practices-Leitfaden zum Einrichten eines Bug-Bounty-Programms?

    • Ich arbeite in diesem Bereich, daher ist es schwer zu sagen, welche Informationen fehlen, aber für mich wirkt es ziemlich simpel
      Man veröffentlicht irgendwo auf der Website, dass technische Sicherheitsprüfungen erlaubt sind, sofern sie einem koordinierten Verfahren zur Offenlegung von Schwachstellen folgen, und schreibt dazu, welche Prämien es für welche Bugs in welchem Scope gibt. Natürlich muss das etwas konkreter sein als dieser eine Satz
      Ausnahmen wie dass man nicht zahlt, wenn jemand zu jung oder zu alt ist, oder wenn jemand im falschen Land geboren wurde und deshalb Sanktionen unterliegt, sollte man ebenfalls vorab festhalten, damit es später keine verletzten Gefühle gibt
      Wenn es konkrete Fragen gibt, kann ich sie beantworten oder gute Referenzen heraussuchen

  • Wenn man diese Stelle im Artikel liest:
    It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.
    Hat der Autor das also gemeldet und gar nichts dafür bekommen?

    • Dass er gar nichts bekommen hat, stimmt nicht. Es besteht immer die Möglichkeit, wegen der Meldung einer Schwachstelle mit rechtlichen Schritten bedroht zu werden
    • Es ist enttäuschend, dass so viele Unternehmen keine Bug Bounties anbieten. Die Schwachstellen, die ich über die Jahre gefunden habe, stapeln sich nur in meinem Kopf
      Beim Melden gibt es rechtliche Risiken, und es hilft auch nicht, dass Unternehmen einen technisch gesehen bis zum Ende verklagen können. Das gilt aus EU/UK-Sicht
    • So treibt man Leute in die dunkleren Ecken des Internets, wo sie die Informationen an den Höchstbietenden verkaufen
    • Ja, genau, er hat nichts bekommen