尝试访问

http://mdsec.net/auth/361/

7.2.3 加密令牌

一些应用程序使用包含用户有意义信息的令牌,并通过在向用户发布令牌之前对令牌进行加密来避免这种做法导致的明显问题。由于使用了用户未知的密钥对令牌进行加密,这种方法似乎较为稳妥,因为用户无法解密令牌并篡改其内容。

但是,在某些情况下,根据所采用的加密算法以及应用程序处理令牌的方式,用户甚至不需要解密令牌,就可以篡改令牌中有意义的内容。这听起来可能有些匪夷所思,但实际上,这些攻击确实可行,而且有时轻易就可以实施;事实证明,现实世界中的许多应用程序都易于受到这种攻击。不过,这类攻击是否可行,要取决于加密令牌时所采用的具体加密算法。

1.ECB密码

采用加密令牌的应用程序使用对称加密算法,用于解密用户返回的令牌,恢复令牌中有意义的内容。一些对称加密算法使用“电子密码本”(ECB)密码。这种密码将明文划分成同等大小的分组(如每组8个字节),然后使用密钥加密每个分组。在解密过程中,再使用相同的密钥对每个密文分组进行解密,将其恢复为原始的明文分组。这种加密方法有一个特点,即如果明文分组存在某种模式,这可能导致密文分组也存在一定的模式,因为明文分组与加密后的密文分组完全相同。对于某些类型的数据(如位图图像)而言,这意味着可以从密文判断明文中的有意义信息,如图7-4所示。

img185

图7-4 使用ECB密码加密的明文中的模式可能会在生成的密文中可见

尽管ECB存在上述缺点,但Web应用程序仍然经常使用这类密码来加密信息。即使“明文模式”问题不会出现,这种加密方法仍然存在漏洞。这主要是因为它的明文分组与密文分组完全对应所致。

以下面的应用程序为例,该应用程序的令牌包含几个不同的有意义组件,包括一个数字用户标识符:

img186a

对这个令牌进行加密后,它变得没有任何意义,并且可能通过所有标准的随机性统计测试:

img186b

ECB密码用于加密8字节的分组,其明文分组与对应的密文分组如下所示:

img186c

现在,由于每个密文分组将始终解密成同一个明文分组,因此,攻击者就可以改变密文分组的顺序,以某种有意义的方式修改对应的明文分组。根据应用程序处理生成的加密令牌的具体方式,攻击者可以通过这种方法切换到其他用户,或提升自己的权限。

例如,如果将第二个分组复制到第四个分组之后,将得到如下所示的分组序列:

img186d

现在,加密的令牌中包含一个经过修改的uid值,以及一个复制的app值。具体会出现什么情况,将取决于应用程序如何处理加密令牌。通常,以这种方式使用令牌的应用程序仅检查加密令牌的某些部分,如用户标识符。如果应用程序这样处理令牌,那么,应用程序将处理uid为992(而不是最初的218)的用户的请求。

上述攻击能否奏效,取决于你在操纵分组时,应用程序是否发布一个令牌,在其中包含与有效的uid值对应的rnd值。另一种更加可靠的攻击方法,是以适当的偏移值注册一个包含数值的用户名,并复制该分组以替换现有的uid值。假设你注册用户名daf1,并且应用程序发布以下令牌:

img187a

该令牌的明文分组和密文分组如下所示:

img187b

然后,如果将第七个分组复制到第四个分组之后,加密令牌将包含uid值1:

img187c

通过注册适当范围的用户名并重新实施这个攻击,你就可以循环使用所有有效的uid值,从而伪装成每一个应用程序用户。