欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

AES加密的安全问题

来源:本站整理 作者:佚名 时间:2019-03-15 TAG: 我要投稿

aes加密简介
AES算法全称Advanced Encryption Standard,是DES算法的替代者,旨在取代DES成为广泛使用的标准,于2001年11月26日发布于FIPS PUB 197,并在2002年5月26日成为有效的标准。2006年,高级加密标准已然成为对称密钥加密中最流行的算法之一。
AES是典型的对称加密算法,对称加密不同于md5 sha的哈希摘要算法,对称加密是可逆的,通常是明文+密钥,再利用算法来加密成密文,如果要还原也很简单,只要根据密钥+密文+生成算法的逆运算,即可解出,对称加密特点为可逆,并且加密解密都是使用同一个密钥,而非对称加密则是公钥私钥加解密模式这里不做讨论。
 
aes加密五种模式
aes加密的方式有五种工作体制。
1.电码本模式(Electronic Codebook Book (ECB))
这种模式主要是将明文划分为几个明文段,分块加密,但是加密密钥是相同的。
2.密码分组链接模式(Cipher Block Chaining (CBC))
这种模式是先将明文切分成若干小段,然后每一小段与初始块或者上一段的密文段进行异或运算后,再与密钥进行加密。
3.计算器模式(Counter (CTR))4.密码反馈模式(Cipher FeedBack (CFB))5.输出反馈模式(Output FeedBack (OFB))
其中分组如,aes-128-ecb即为16字节为一组,16字节即为128位。
其他三种模式较为复杂,本文仅讨论前两种加密的安全性。
 
aes-ecb加密

aes-ecb加密是将一段明文,按照固定长度分组,然后对每一个分组,按照算法使用固定的密钥进行加密。假设123456加密。那么123为一组加密,456为一组加密,然后两段明文加密后的密文拼在一起,就算完整的密文。
注意:这里每一组的加密都是使用相同的密钥,相同的算法,所以在这种机制下,很可能出现安全问题。
比如:在身份认证中,查询用户是否是管理员还是普通用户,如果is_root=1则为管理员,如果不为1则为普通用户,如果采用aes-ecb加密,对原文进行分组加密。
明文:user_id:1.000000 is_root:0(其中is_root来判断是否为管理员。)  然后用一段密钥加算法进行加密。
这种提交的加密数据是在cookie中提交,明文不可控,但是密文是可控的,但由于是进行分组进行,所以我们可以推算出每一分组明文对应的密文,假设明文八个一组来进行加密,分组后变为 (提示:仅仅是假设理想情况八位,实际并不是)
第一组:is_user
第二组:1.000000
第三组: is_root:
第四组: 0(不够的八位自动填充)
其中user_id 通常情况下我们前端可以修改,进行修改为1.000000,此时原文被加密之后为四组 每组为八个数字的密文
假设加密后密文为 
c4ca4238a0b923820dcc509a6f75849b 在cookie中被提交,将密文分为四组
c4ca4238
a0b92382
0dcc509a
6f75849b
此时密文我们是可控的,如果正常提交,服务器解密之后为user_id:1.000000 is_root:0,很显然我们不是管理员,但是如果将第二组密文和第四组密文替换呢,那么user_id就是0,is_root就是1.000000。服务器就解析为user_id:0xxxxxxx(xx为填充字符) is_root:1.000000,显然我们不需要知道密钥,同样可以进行绕过。
还有一则在转账中,如果采用aes-128-ecb加密,在cookie中使用ecb分组加密,比如
付款人账户:XXX //假设密文abc收款人账户:XXX //假设密文efg
试想一下,一旦这个分组是刚好分为四组,我们仅仅将abc与efg交换,那不就造成了支付收款反转,几乎不需要什么技术就可以造成严重的攻击。
ctf-案例
接下来以真实题目来进行详解。
ctf address:https://mixer-f3834380.challenges.bsidessf.net/(国外的一道ctf)

首先尝试输入admin admin 登陆。

返回内容重点为红色框内的东西,需要使得第三个参数 is_admin=1即可获得flag,但是session cookie并不是这个题关注的点,接下来就是抓包分析参数。修改参数。

经测试修改url,get cookie post传参都不能改变is_admin的值,所以只有一种可能,是在cookie里的user参数里加密了,然后传递给服务器,我们get参数传入的账号密码被服务器端加密,然后服务器返回来加密后的user信息。
接下来测试是何种加密,测试为aes-ecb加密,那么是如何确定的呢,
由于ecb是分组加密,所以一旦一组的密文我们修改了,其他组的密文解密之后是正常的,而被我们修改了的密文解密会是乱码,所以我们随便修改下user参数。

可以看到报错,并且第一组的密文解密后是乱码,而其他组的加密解密后为正常,所以猜测这一定是aes-ecb的分组加密的方式,
此时,我们应该先确定分组,几个为一组,先破坏第一组加密然后破坏第二组加密,然后确定解密后json数据为,
{"first_name":"admin","last_name":"admin","is_admin":0}
总共为55个字符,
服务器密文为:d37c125ab4eae2ed02428d6d619016b06500bafffbeebe0c011977ad06c6946a45ba82569e93332195a36e61ae1fe26b325f7afd1eaa5ee8bb11efe6eebc5b54
为128个字符,五十五个字符补位为64个字符,分组测试破坏每一组,测试到一组明文16个字符,加密密文为32个字符。

[1] [2] [3] [4]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载