1、 ECB入门简介

首先,在介绍ECB模式之前,我们先大概了解下什么叫做分组密码。分组密码将需要进行加密的明文序列划分为若干固定长度的分组,然后使用固定长度的密钥加密固定长度的分组得到等长的加密分组。
ECB(Electronic CodeBook,电码本)模式是分组密码的一种最基本的工作模式。在该模式下,待处理信息被分为大小合适的分组,然后分别对每一分组独立进行加密或解密处理。其加、解密过程如下图:
ECB模式作为分组加密的一种基本工作模式,具有操作简单,易于实现的特点。同时由于其分组的独立性,利于实现并行处理,并且能很好地防止误差传播。
但ECB还有一致命缺陷,相同的明文块会加密成相同的密文。因此,它不能很好的隐藏数据模式。因为ECB的每一块都是使用完全相同的方式进行界面解密,这样就使得信息不能受到完全的保护,容易遭受统计分析攻击和重放攻击。
下图三幅图中,第一幅是原图,第二幅是经过ECB加密的图,第三幅是是使用了伪随机的非ECB加密图。我们可以看到使用ECB模式加密并不能对数据起到完全的加密作用,图中企鹅的轮廓形状还是可以看出来的。

2、ECB实例分析

下面我们以一个具体的例子对ECB模式的缺陷进行分析。应用程序使用ECB来对用户提供的信息进行加密,用户在登录后只使用ECB加密后的cookie来确保认证。
测试的应用程序中cookie使用用户名做ECB加密,然后base64编码。ECB加密以8个字节为一块进行分组加密。我们来看看ECB模式会对认证造成什么样的影响,以及怎样利用这个缺陷去进行攻击[hw3] ,在这个例子中我们会尝试在不知道admin密码的情况下利用ECB加密模式的缺陷去登录admin帐号。
首先分别注册用户test1、test2,密码均为password,分别查看cookie。test1的cookie:auth=vHMQ%2FNq9C3MHT8ZkGeMr4w%3D%3D
test2的cookie:auth=Mh%2BJMH1OMhcHT8ZkGeMr4w%3D%3D
很明显cookie已经做过了base64编码了,我们先将它们解码一下。下面进行的解码是通过ruby命令实现的。
test1:\xBCs\x10\xFC\xDA\xBD\vs\aO\xC6d\x19\xE3+\xE3
test2: 2\x1F\x890}N2\x17\aO\xC6d\x19\xE3+\xE3
我们可以看到解码出来的数据都包含一串相同的部分:\aO\xC6d\x19\xE3+\xE3 ,接下来,我们尝试通过利用ECB密码的缺陷,直接通过修改cookie登录admin账号 。
现在,我们创建一个用户名为aaaa aaaa aaaa aaaa aaaa的帐号。这个帐号的cookie为auth=GkzSM2vKHdcaTNIza8od1wS28inRHiC2GkzSM2vKHdcaTNIza8od1ys96EXmirn5
进行解码出来得到:
\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7\x04\xB6\xF2)\xD1\x1E\xB6\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7+=\xE8E\xE6\x8A\xB9\xF9
可以看到,上面解码后的cookie包含有重复的\x1AL\xD23k\xCA\x1D\xD7。我们猜测这是对aaaaaaaa进行ECB加密得到的结果。
我们再注册一个帐号,用户名为aaaaaaaa admin(即8个a后面再跟着admin),密码任意。注册完后,查看这个帐号的cookie,为:auth=GkzSM2vKHdeNfdXZwrPF0A%3D%3D。
对这个cookie进行解码。
从解码结果我们可以看到\x1AL\xD23k\xCA\x1D\xD7这一部分是和上一步aaaaaaaaaaaaaaaaaaaa这个帐号的cookie解码得到的重复出现的一部分是相同的。这部分实际上是对aaaaaaaa这8个字节进行ECB加密的结果。我们把\x1AL\xD23k\xCA\x1D\xD7这部分去掉,只剩下admin加密的结果,取\x8D}\xD5\xD9\xC2\xB3\xC5\xD0编码一下 。
我们把编码后的base64码作为cookie提交。这时我们已经成功以admin的身份登录了。

3、小结

从各种各样的数据泄漏安全事件中,我们可以看到数据已经成为了黑客攻击的一个主要目标。同时,数据也成为了企业重点保护对象。为了防止黑客攻击,对数据进行加密是非常必要的。但仅仅考虑对数据进行加密是远远不够的,我们还应该进一步考虑所采用的数据加密算法是否安全。ECB加密的缺点在于同样的明文组会得到同样的密文组,相对于ECB模式来说,CBC模式则较安全,攻击者不易发起主动攻击,同时,CBC(密码分组链接)适合于传输长度较长的报文,依据的是SSL、IPSEC的标准。

4、题目

第三届安恒杯 web1
源码没有找到,没法复现,根据wp写一下解题过程。
注册并登陆,提示
看到判断用于登陆不是用session而是用cookie的username和uid,把username的值换到uid,发现显示的用户名变成了uid。可以推断判断用户用的是uid
由于我们不知道加密过程无法直接修改cookie内容,但是我们可以通过加密的username来替换uid。
方法1:注册用户名为1到1000的用户,逐个登录后将uid内容替换为username内容。但是经测试,注册有用户名长度限制长度必须大于等于三位数。法1无效。
经测试,我们注册用户名为12abc的用户,登录后替换uid可成功登录uid为12的用户。所以有法2.
方法2:注册用户名为1abc到1000abc的用户,逐个登录后将uid内容替换为username内容。直至登录管理员账户。
根据上文提到的ECB缺陷,简单点来说,uid为特定的(这里是6)才可以得到flag。fuzz发现16个字符为一组,然后
aaaaaaaaaaaaaaaa1
aaaaaaaaaaaaaaaa2
aaaaaaaaaaaaaaaa3
……
aaaaaaaaaaaaaaaa6
分别求出对应的解密,解密利用ruby。
cookie修改uid得到flag。
参考:

http://www.freebuf.com/news/topnews/56506.html