A browser extension central to Belgium’s national identity card system was built like Swiss cheese, letting hackers steal victims’ identities and payment information, and even perform code execution on their local machines, a researcher warns.
The “Connective” signing extension allows Belgian citizens to use electronic ID cards (eIDs) to authenticate to government and banking services online. Its vendor, Nitro Software Belgium, boasted in 2021 that it was used by more than 60 Belgian government agencies and departments, 8 of the 10 largest banks in the country, and more than 1,000 enterprises. It currently has more than 2 million individual users, according to its Chrome Web Store page.
Don’t let its popularity fool you: it doesn’t work particularly well, according to user reviews. It currently enjoys an average rating of 1.7 out of 5 stars on the Chrome Web Store, from 542 reviewers who describe it as the “worst extension ever,” and request that “whoever is working on this bs needs to be fired instantly.” And those reviewers hardly knew the half of it.
At DEF CON 34 last week, Bay Area Labs founder James Arnott publicly revealed some colossal vulnerabilities in the Connective signing system. The vulnerabilities could’ve allowed hackers to steal Belgian citizens’ identities with relative ease, hijack their payment cards, and perform remote code execution (RCE) on their computers, until they were fixed on July 22.
How Belgium’s eID Logins Work
Imagine you’re Belgian and you’d like to log into a government or banking portal. To ensure your security online, instead of prompting you for some flimsy username and password, or an exploitable multifactor authentication (MFA) flow, the website may have you log in using an eID.
Logging in with your Belgian eID is a bit involved. You’ll need:
-
A physical smart card with your eID information encoded onto it
-
A physical card reader to insert your card into, which plugs into your computer via USB
-
Native host software on your computer
-
A browser extension that bridges your eID app with the Web page you’re visiting (the two couldn’t otherwise communicate, thanks to standard browser sandboxing)
If you’ve got all four, you can log into your most sensitive accounts by inserting your card into your reader and entering your PIN code in a pop-up window. In principle, this login flow is supposed to ensure that only a citizen in possession of their physical ID card can log into their most sensitive accounts online. What Arnott and his colleagues found, however, was that the last half of that chain — the browser extension and the host software — undermined that assumption, in more ways than one.
Vulnerabilities in the Connective Signing Extension
The first issue researchers discovered was that the Connective browser extension didn’t tell its native host software which website it was connecting to. Instead, to ensure that users were engaging with legitimate, trusted sites, it used a generic “activation” token.
The researchers found that they could simply grab one such token from any other site that integrated with Connective — in their experiments, a Belgian digital administration platform — and easily replay it. The token enabled any operation in the Connective application logic, thus the researchers could stand up a malicious website, adopt any other website’s activation token, and thereby fully interact with a victim’s eID authentication system. From there, a more malicious actor could steal a victim’s ID card data and the personally identifying information (PII) associated with it or, apparently, perform the same kind of attack against Mastercard Maestro-brand payment cards.
Stealing victims’ PIN codes turned out to be similarly effortless. PIN codes traveled encrypted on their way to receiving websites, but they were accompanied by decryption keys, so they were easily made readable. It’s also worth noting that the PIN code pop-up box text was defined by the Web page, not the Connective software, thus a website mimicking a legitimate Belgian service could have extended its brand impersonation into the pop-up window.
An attacker could have used all of Connective’s leaky data and failed trust logic to hijack a victim’s identity in devastating ways. Say, for example, the attacker wanted to access a victim’s bank account. They could trigger the eID login flow, receive a challenge back from the banking website, pass it onto a victim through an iframe or malicious ad on some totally unrelated website, grab the victim’s valid eID signature, and return that to the banking site.
A more elegant and persistent attack scenario might have involved “itsme,” a ubiquitous alternative to physical card readers, which allows Belgians to log into their sensitive accounts using their smartphones. By stealing a victim’s eID signature once, an attacker could have reset their itsme account, re-registered it using the attacker’s own phone number, and would thereby have gained continuous access to potentially all of the victim’s connected government, banking, and commercial accounts.
In an email to Dark Reading, the vendor, Nitro, quoted an official company statement, highlighting that there has been no evidence of exploitation in the wild and that customers running current software versions are now protected.
Browser Extensions: Risky by Nature
“Browser extensions are unsafe by nature,” argues Rebora security researcher Gal Weizman. “They make use of powerful capabilities granted to them by the browser, and they enrich ordinary websites with ways to interact with them. The combination of the two allows websites to abuse these interaction layers, tap into these powers, and escalate their privileges to attack the host or the browser.”
In his work, Weizman sees what he describes as an “alarming amount” of extension-enabled cross-page exploits, “which can sometimes be even worse than RCE, because they allow compromising every authenticated session in the victim’s browser. The vector is usually the same: content-script message-listeners that fail to filter out messages coming from the page itself, allowing malicious websites to command the extension to perform cross-website actions on behalf of the victim.”
To prevent these kinds of exploits, he says, “extensions should design their content-scripts to never trust messages coming from the Web page itself, unless the Web page is owned by them as well.”
Luckily, for organizations that have to rely on these buggy browser extensions, there’s a practical, if laborious, workaround. “It’s possible to prevent extensions from running on any site by going into the extension settings, and whitelisting the sites the user wants to use [it with],” Arnott tells Dark Reading. “It’s bad user experience (UX) so not many people do it, but this would reduce the attack surface.”
A Bonus, Full RCE Exploit Chain
As if all the identity theft weren’t enough, the Bay Area Labs researchers also found a RCE vulnerability in the native host application. It turned out any Web page could command the program to load any arbitrary dynamic link library (DLL) file on the host machine. Thus, if a hacker could get a victim to download a malicious DLL — for example, by phishing them into clicking a link that automatically downloaded the file to their computer — the program would unquestionably load and run it.
This RCE attack wouldn’t have required that a victim be anywhere near a login page. Arnott characterized this as the most impactful of his findings, but not necessarily unique to the vendor.
“There are a bunch of other extensions that enable drive-by RCEs like this,” he says, alluding to live zero-days he’s recently discovered. “They’re not all from small vendors. Militaries, judiciaries, banks, hospitals, and everyone in between is currently vulnerable. This is actually just the tip of the iceberg.”
