瑞典 BankID 存在严重漏洞，导致用户数据泄露

瑞典 BankID 是一种数字身份证明形式，大多数（如果不是全部）瑞典居民使用它来验证多种服务，例如：互联网提供商、网上银行服务、博彩网站，尤其是政府网站。

我自己住在瑞典，脑子里一直萦绕着黑客的心态，所以我认为在一个领域进行安全研究会非常有趣。

在这篇文章中，我将介绍由于 BankID 的身份验证协议实施不安全而导致大多数瑞典服务提供商存在的新漏洞。

我将简要介绍一下这种协议的工作原理、易受攻击的配置是什么样的、如何利用它、如何补救它，以及最后这些类型的攻击对 eID 的整体实施意味着什么。

BankID 身份验证协议

BankID 是一种安装在用户设备上的服务，只要您有瑞典个人财务代码persunnumer ，即可向瑞典银行申请获得。该应用程序安装在用户的设备上，并与他们的财务代码相关联，本质上是将他/她的身份与这样的应用程序联系起来。电子识别系统通常就是这样工作的：政府授权和信任的第三方发放一款与特定个人绑定的软件，然后服务与该软件的提供商集成，以允许其用户在其平台上进行身份验证，这是一种共享信任模型，允许服务轻松对人员进行身份验证。

BankID 也不例外，它为此类服务提供了文档，从现在开始将被称为依赖方（RP），以便他们可以轻松地将其身份验证流程与 BankID 集成。https ://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion 。

使用 BankID 进行用户身份验证的主要流程有两个：

• 在同一设备上进行身份验证

• 在另一台设备上进行身份验证

  
  

我们很快会重新讨论这两个流程，但是，这两个流程都是从 RP 向 BankID 的 API 发送请求以启动身份验证顺序开始的。在此 post 请求中，RP 必须指定endUserIp参数，该参数包含尝试登录的用户的 IP，这在报告的后面部分很重要。

/auth API端点将会做出如下响应：

 HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" }

• orderRef是一个标识符，RP 可以使用它来针对/collect端点检查身份验证状态，然后从该人那里获取所需的用户信息
• autoStartToken是 RP 用来创建深层链接的令牌，点击后将打开 BankID 应用程序并提示用户进行身份验证（这非常重要）

下面将介绍qrStartToken和qrStartSecret ，但对于所进行的安全研究来说，它们并不是十分重要。

除了用户的 IP 之外，RP 还可以为身份验证顺序指定更多参数，包括要在 BankID 应用程序上显示的文本和身份验证要求。

在身份验证要求中，本文将重点关注证书策略，这些策略允许 RP 向 BankID 传达用户选择了哪个流程。

同一设备上的身份验证

当用户选择在同一设备上使用 BankID 进行身份验证时，RP 使用autoStartToken创建一个深层链接，如下所示： bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login 。然后，用户的操作系统会获取此深层链接并将其传递给 BankID 应用程序。

在调查此流程时，发现了一个开放重定向漏洞，因为 BankID 方面没有对redirect参数进行验证，我将在后面解释为什么这个额外的错误使得会话劫持攻击更加强大。

在另一台设备上进行身份验证

当用户选择在另一台设备上使用 BankID 进行身份验证时，RP 使用qrStartToken和qrStartSecret生成动态二维码（通过从前面提到的/collect端点获取下一帧的数据），用户可以使用他的移动 BankID 应用程序进行扫描。

证书策略

这些应该由 RP 在发起身份验证订单时指定，它们允许 BankID 在流程不匹配时拒绝身份验证尝试，以减轻网络钓鱼。例如，如果用户选择“在同一设备上进行身份验证”，RP 应该将此情况告知 BankID，这样如果在移动 BankID 上和/或使用二维码尝试进行身份验证，应用程序可以拒绝该操作。

除此之外，一旦身份验证完成，RP 可以从/collect API 端点获取用于打开 BankID 应用程序的ipAddress 。如果用户选择了“在同一设备上进行身份验证”，则应在 RP 上根据用户的 ip 地址进行检查。

应使用证书策略和ipAddress来确保身份验证流程不能被篡改。

尽管这些安全措施已经到位，但 BankID 未能概述它们的重要性，甚至在其提供的示例实施中也没有正确实施它们！ https://github.com/BankID/SampleCode

会话修复漏洞

那么，当该协议不能安全地实施时会发生什么情况？

我第一次看到bankid:///深层链接时，正在浏览我的大学申请表，可以通过使用 BankID 登录来访问。起初，我想：如果我将此深层链接发送给某人会发生什么？所以我将它发送给了我的一个朋友，他点击了它，令我惊讶的是，在他打开 BankID 后，我面前出现了他所有的大学申请！

那时我开始研究 BankID 的 API，实现我自己的 RP，并了解我刚才概述的所有内容。

经过几周的研究，我开发了一个脚本，可以自动为 30 多个 RP 抓取bankid:///深度链接，该脚本将启动一个 Web 服务器并为每个服务创建一个路径，当用户访问特定服务的链接时，脚本将获取一个新链接并将用户重定向到该链接。这将导致用户的设备打开 BankID 应用程序，并且在身份验证后，我将代替他们进行身份验证。

我之所以能做到这一点是因为：

• RP 未将证书策略发送给 BankID，因此我能够获取深层链接并将其转发到移动 BankID 应用程序

• RP没有将请求链接的IP地址与已完成认证的IP地址进行比较

• 即使选择了“在另一台设备上进行身份验证”选项，RP 也会提供链接

  
  

这导致了会话固定漏洞。

攻击

让我们想象一个名为 AmazingSevice AB 的易受攻击的服务，他们按照提供的示例代码实现了 BankID 流程，并在https://amazingservice.se/login/bankid上托管此类实现。

威胁者对 AmazingSevice AB 上存储的用户数据感兴趣，并且已经盯上了受害者。他只需自动抓取bankid:///链接，将其托管在他的服务器上，然后将链接发送到他的恶意服务器并发送给受害者即可。在选择喜欢的网络钓鱼传递方式（短信、电子邮件等）后，他会将链接嵌入冒充 AmazingSevice AB 的消息中并要求受害者登录。

这种账户接管几乎不需要社会工程学，因为一旦受害者点击链接，系统就会立即提示他打开 BankID，从而离开攻击者网站的“未知领域”，转而使用更熟悉的界面 BankID。此外，受害者在 BankID 应用程序中看到的身份验证请求是由 AmazingSevice AB 请求的，因此无法检测到欺诈行为。

一旦受害者通过身份验证，攻击者的会话就会被验证到受害者的账户，受害者可以利用 BankID 中存在的开放重定向漏洞进一步被欺骗，攻击者可以将redirect参数指定为https://amazingservice.se/login/bankid 。这将导致受害者被重定向到合法的服务网站，让他只是认为身份验证未成功。

演示

由于显而易见的原因，我无法使用我报告过的其中一家公司，因此演示中显示 BankID 的演示服务容易受到此漏洞的影响！

右上角是受害者接收链接的视图，这里是通过访问攻击者的网站进行模拟的。一旦受害者访问链接，攻击者的服务器就会打开无头浏览器并提取bankid:///链接，然后将其转发到受害者的手机。在 BankID 的应用程序中，您可以看到“Test av BankID”，这是 BankID 演示网站的合法来源。此外，在视频开始时，VPN 已打开，以确保在身份验证期间没有进行任何 IP 地址检查。最后，可以看到在攻击者的笔记本电脑上，他以受害者（Johan Johansson）的身份登录。

影响

会话修复漏洞会导致任何使用瑞典 BankID 作为身份验证提供商且错误地（或根本没有）实施证书策略和ipAddress检查的应用程序一键接管帐户。这非常严重，因为使用 BankID 验证其用户的服务通常可以访问非常敏感的数据和操作。超过 30 个应用程序被发现易受此攻击，我们联系了尽可能多的应用程序，最终在主要平台上接受了 11 份漏洞赏金报告。

由于该漏洞影响范围广泛且严重，我向其中一家服务机构报告了此漏洞，并联系到了瑞典国家 CSIRT。会谈刚刚开始，如果你想了解最新情况，请关注我的 Twitter (X) @m4st3rspl1nt3r

补救措施

如果您正在寻找一个安全的 BankID RP API 实现的示例，我已经创建了一个示例，您可以将其用作 Golang 库，也可以将其自定义并部署为微服务。您可以在此处找到它。

BankID 的回应

大多数受影响的服务，尤其是那些拥有 BBP 和 VDP 的服务，对我的报告反应迅速，并且非常乐于接受。然而，BankID 的回应有些不同。在通过各种渠道多次联系他们后，我收到了一封电子邮件，他们解释说，他们知道这个问题，但他们认为为了保持 RP 的“易集成性”，他们对此无能为力。计划中的缓解措施（不幸的是，这仍然需要在 RP 方面进行更改）已传达给我（但出于某种原因，在他们的文档中找不到）：

RP 可以设置的另一个要求是风险。这将设置交易的可接受风险水平。如果交易风险高于所需限制，交易将被阻止“低” - 仅接受低风险订单“中等” - 接受低和中等风险订单（如果已设置）。如果 RP 提供 IP 检查，我们将在我们这边执行 IP 检查。如果提供，将进行风险监控的其他风险参数包括 referingDomain、userAgent 和 deviceIdentifier。

此外，还制定了修复开放重定向漏洞的计划。

我个人对此的看法是，如果您开发并运营如此关键且被广泛采用的身份验证提供程序（通常用于保护非常敏感的用户信息），则您应该正确记录您的安全机制，以便 RP 可以安全地集成它。可选的安全功能完全没用，如果开发人员可以节省时间而不实现某些功能/参数，那么就会发生这种情况，我们不能责怪 RP 方面。BankID 应尽最大努力将尽可能多的反欺诈和安全功能转移到他们这边以保持“易于集成”，但也应确保正确记录 RP 需要实现的任何其他安全功能；请注意，这些功能是必需的，而不是可选的。

私营企业面临公共危险

在我看来，这个漏洞就是一个例子，它表明让一家私营公司完全控制一个对一个国家人口至关重要的系统是多么危险。我认为这比软件公司的另一个漏洞更严重，因为 BankID 是850 多万瑞典居民使用的东西，它被用来登录你的银行、保险提供商、电力供应商和其他敏感平台，这些平台会对现实世界产生影响。

如果有人在 Facebook 上发现帐户接管，您可能会丢失一些照片，如果有人在您所在国家/地区的 eID 提供商（通常是私人的）中发现漏洞，那么对某人的生活造成的影响可能是难以想象的。

越来越多的欧洲国家正在采用电子身份证，欧盟计划在未来几年推出自己的欧盟电子身份证（您可以在此处阅读更多相关信息）。

我希望监管机构能够推动电子身份证提供商完全由公共机构开发和控制，可能还会要求此类系统开源并定期接受安全漏洞审核。

如果这些至关重要的软件是由私营公司开发的，我们如何才能在社会上安全地接受它们？

进一步的研究

虽然这篇博文的主题是针对 BankID 的会话固定攻击，但我发现许多其他身份验证/识别提供商都存在同样的设计缺陷。在需要使用另一台设备（通常是手机）来完成身份验证流程的提供商中可以发现一种新的漏洞类别。

研究仍在进行中，我希望很快能发布更多研究成果，以及我一直在研究的工具，可用于自动化和利用此类漏洞。请继续关注我的下一个主题《会话固定设计 - 跨设备身份验证噩梦》

到那时，入侵这个星球吧！