原文:
https://laconicwolf.com/2018/09/21/mfa-bypass-and-privilege-escalation/

本文主要讲解两个MFA(多因素验证)应用在web应用程序中部署实现时存在的问题。MFA的确是非常好的,我非常支持它,但在很多应用系统中,第二个因素的验证与第一个因素无关,这导致了可以将帐户“A”的用户名/密码与账号“B”的第二个因素混合。在第一个MFA应用中,导致可以绕过第二个因素。在第二个MFA应用中,导致了权限提升。

  1. 应用一 Okta:第二个因素绕过,没有帐户锁定
    该系统允许自行注册,并使用Okta强制执行身份验证。你可能不知道Okta是什么,它就是一个身份和访问管理解决方案,可以集成到你的应用程序中,以提供集中管理和单点登录。在进一步讲解之前,我想提一下,我无法在.okta.com这个域上复现这一点,也就是绕过第二个因素,所以我认为Okta是没有任何问题的,问题出在我要测试的这个特定的应用程序上,它采用Okta验证的实现方式有问题。

我们先来走一遍该系统的正常身份验证流程,然后再来讨论这些漏洞。

正常身份验证流程

使用用户名和密码登录,如图:

服务器检查用户名/密码是否正确,返回第二个因素要提交的必要数据,这些数据具体来说就是状态令牌,oktaUserId和factorId:

在上述响应之后,将自动提交一个请求以启动第二个因素的SMS通知,然后你会看到如下的提示:

提交第二个因素并确认后,会自动发起第二个身份验证请求,如图:

服务器验证你的凭证,如果凭证有效,会返回JWT(json web token)响应,这样你就可以访问应用程序了。

漏洞
使用MFA的应用对无效的用户名/密码的不断尝试并没有严格的账户锁定策略。这个应用只是通过JavaScript向你显示锁定警告,但在服务器后端却没有进行逻辑验证,刷新页面后,锁定警告就消失了。我将身份验证请求发送到repeater中,并且在进行正确的身份验证之前故意多次尝试错误的用户密码,发现并没有锁定账户。

没有账号锁定就太好了,不过,即使我们可以暴力破解出密码,我们仍然要考虑第二个因素。幸运的是,该应用对MFA和身份验证请求是独立验证的。

于是我就执行了下列操作:

没有帐户锁定,我能够暴力破解出另一个用户的密码。我已经在该系统上有一个有效的帐户(可以自行注册),所以我用初始用户名/密码进行登录(服务器返回了stateToken和factorId),提交了SMS MFA码,然后拦截第二个用户名/密码身份验证请求,进行暴力破解得到正确的用户和密码,替换掉我的用户名和密码 ,如图:

然后,服务器返回了一个JWT响应,这样我就能够以第二个用户的身份访问应用了,如图:

  1. 应用二 Symantec VIP:提权到任意用户
    这个漏洞更严重。该应用没有自行注册功能,但我和团队每个人都有两个帐户(一个普通用户,一个管理员)进行测试。该系统使用Symantec VIP验证第二个因素。同样,使用Symantec VIP本身没有任何问题,但在这个案例中,实现方式是有问题的。我们先还是来走一遍正常的验证流程,然后再来讨论其中的问题。
    正常身份验证流程
    使用用户名和密码登录,如图:

    服务器检查用户名和密码,返回提交和验证第二个因素所必需的数据,也就是hidUserId和hidMfaId,它们只不过是一个防篡改的查询字符串值,实际上是一个带有签名的参数,用base64编码。防篡改查询字符串的值如下所示:
    Mjc3OA == - 5CBeGaUhkiA =
    ' - '的左侧解码为2778,' - '的右侧是签名,但即使我想更改该值并重新编码,签名也不正确,我会得到一个错误。hidUserId只是一个数字,而hidMfaId只是用户名,但两者都使用防篡改查询字符串进行编码。

使用用户名密码登录后,hidUserId和hidMdaId值存在于响应包中,然后进入到下一步,需要我进行第二个因素验证,如图:

security code(安全码)与hidUserId和hidMfaId一起提交,如果安全码正确,则授予访问权限,如图:

漏洞
与第一个系统类似,此应用程序将MFA作为两个独立的步骤来处理。第一个请求验证用户名/密码并返回了防篡改的hidUserId和hidMfaId,第二个请求验证了安全码。我注意到这个应用程序的问题是,当提交安全码时,hidUserId也会被提交。我开始琢磨我是否可以替换为另一个有效的hidUserId并冒充该用户。不过,这里有个问题,就是hidUserId是一个防篡改的字符串,我无法获取到或也无法猜到它的值。

凑巧的是,这个应用程序还有另一个漏洞,让我能够获得该值。
下面就是我所操作的:
如果我使用一个有效用户名和无效密码进行登录,那么应用程序就不会返回hidUserId,但是状态会改变,当我再次尝试登录时(使用相同的有效用户名和无效密码),hidUserId将会动态生成并且在请求中提交。有了这个漏洞,我就能得到任何用户的hidUserId,所以我选择了一个管理员账户,如图:

现在测试是否可以在普通用户的有效身份验证请求中替换成admin用户的hidUserId。所以我再次使用我的普通用户帐户pentest_jake,并使用用户名和密码登录,如图:

然后我提交了我的安全码并拦截请求,用管理员帐户UserId替换了我的hidUserId值,如图:

这样,我就以admin用户登成功录到应用了,如图:

最后,我重申一下,我绝对支持MFA,但实现起来可能会出现问题,而且这些问题非常常见。

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖