Für die Anmeldung mit der belgischen eID sind mehrere Komponenten nötig: eine physische Smartcard, ein Kartenleser per USB, eine lokale Host-Software und eine Browser-Erweiterung als Brücke zwischen Webanwendung und eID-Programm. Gerade diese letzten beiden Bausteine unterliefen laut Arnott und seinem Team jedoch das Sicherheitsmodell des Verfahrens.
Ein zentrales Problem lag demnach in der Connective-Erweiterung selbst. Sie übermittelte der nativen Host-Software nicht, mit welcher Website sie verbunden war. Stattdessen setzte das System auf ein allgemeines „Aktivierungs“-Token. Die Forscher konnten ein solches Token von einer anderen Website mit Connective-Anbindung übernehmen – in ihren Versuchen von einer belgischen Plattform für digitale Verwaltung – und erneut verwenden.
Damit ließ sich jede Operation in der Anwendungslogik von Connective auslösen. Ein Angreifer hätte also eine präparierte Website aufsetzen, das Token einer anderen Website übernehmen und so vollständig mit dem eID-Authentifizierungssystem eines Opfers interagieren können. Laut Arnott wären auf diesem Weg Daten von Ausweiskarten und die damit verknüpften personenbezogenen Informationen abgreifbar gewesen. Offenbar ließ sich ein ähnlicher Angriff auch gegen Zahlungskarten der Marke Mastercard Maestro durchführen.
Auch die PIN-Eingabe erwies sich nach Darstellung der Forscher als unzureichend geschützt. Zwar wurden die PIN-Codes auf dem Weg zur empfangenden Website verschlüsselt übertragen, sie wurden aber zusammen mit den Entschlüsselungsschlüsseln mitgeschickt und waren damit leicht lesbar. Hinzu kam, dass der Text im PIN-Eingabefenster nicht von der Connective-Software, sondern von der jeweiligen Website definiert wurde. Eine gefälschte Website, die einen legitimen belgischen Dienst nachahmt, hätte diese Nachahmung damit bis in das PIN-Fenster hinein fortsetzen können.
Arnott skizzierte auch ein Missbrauchsszenario für Bankzugänge: Ein Angreifer könnte einen eID-Anmeldevorgang anstoßen, die Challenge der Bank erhalten, sie über ein iframe oder eine bösartige Anzeige auf einer völlig anderen Website an das Opfer weiterreichen, die gültige eID-Signatur des Opfers abfangen und an die Bank zurückgeben.
Als besonders weitreichend beschrieb er ein Szenario rund um „itsme“, eine in Belgien weit verbreitete Alternative zum physischen Kartenleser, bei der die Anmeldung über das Smartphone erfolgt. Mit einer einmal erbeuteten eID-Signatur hätte ein Angreifer laut Bericht das itsme-Konto eines Opfers zurücksetzen und mit der eigenen Telefonnummer neu registrieren können. Das hätte fortlaufenden Zugriff auf potenziell sämtliche verbundenen Behörden-, Bank- und Handelskonto ermöglicht.
Zusätzlich entdeckte Bay Area Labs eine Schwachstelle zur Remotecodeausführung in der nativen Host-Anwendung. Demnach konnte jede beliebige Website das Programm anweisen, eine beliebige DLL-Datei auf dem Rechner des Opfers zu laden. Wenn ein Angreifer das Opfer zuvor etwa per Phishing zum Herunterladen einer präparierten DLL gebracht hätte, wäre diese laut Arnott ohne Weiteres geladen und ausgeführt worden. Für diesen Angriff musste sich das Opfer nicht einmal in der Nähe einer Login-Seite befinden.
Der Sicherheitsforscher Gal Weizman von Rebora ordnete das Grundproblem allgemeiner ein: Browser-Erweiterungen seien „von Natur aus unsicher“, weil sie weitreichende Browser-Funktionen nutzen und gewöhnliche Websites mit zusätzlichen Interaktionsmöglichkeiten ausstatten. In seiner Arbeit beobachte er eine „beunruhigende Menge“ an seitenübergreifenden Angriffen über Erweiterungen, oft verursacht durch Content-Script-Nachrichtenempfänger, die Nachrichten von der Website selbst nicht ausreichend filtern.
Als pragmatische, wenn auch aufwendige Gegenmaßnahme nannte Arnott das Beschränken von Erweiterungen auf eine Positivliste von Websites in den Erweiterungseinstellungen. Das verschlechtere zwar die Benutzererfahrung, könne aber die Angriffsfläche verringern. Nitro Software Belgium reagierte laut Bericht zunächst nicht auf eine Anfrage von Dark Reading.