[PSTZine 0x01][0x04][安全幻想曲2008]
==Ph4nt0m Security Team==
Issue 0x01, Phile #0x04 of 0x06
|=-----------------------------------------------------------------------=|
|=------------------------=[ 安全幻想曲2008 ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=-----------------------------------------------------------------------=|
|=--------------------------=[ By axis ]=-----------------------------=|
|=------------------=[ axis_at_ph4nt0m_dot_org ]=-----------=|
|=-----------------------------------------------------------------------=|
我见过的大多数安全人员,都对技术有着一种狂热,甚至是一种偏执。这种情绪在做安全研究员的时候是非常有好处的,因为作为研究员,可能要偏执考虑到一些极端的情况。这种钻研精神,是光靠勤奋所无法达到的。但是在甲方做安全的话,可能更多时候需要的就不是狂热,而是掌握平衡的艺术。在商业利益与安全性发生冲突时,如何处理好这个平衡,是一个关键。
举一个简单的例子来说,眼下最流行的XSS攻击,其修补方案从总体上来说,大致可以分为 escape output和filter input两种。对于狂热的安全人员来说,当然是恨不得把网站全部弄成静态的,输出都采用escape output,全部输出纯文本,就天下太平了。然而现实与理想总是有差别的,首道难关就是网站肯定会有些富文本的需求。
当安全和需求相抵触时,一定是安全给商业需求让路。这里要避免一个误区,就是安全应该是为需求而服务的,而不是成为需求的障碍。其实这个观点大多数人都心知肚明,但是在实际操作起来的时候往往会事与愿违。
再回到富文本上来,当需求决定需要有富文本输出的时候,狂热的安全人员(下称为狂战士吧)就只好退而求其次,要求对富文本做filter input,对其他没有富文本的地方做escape output。接下来问题来了,对于程序员来说,富文本往往采用了一些第三方的,或者是基于第三方的富文本编辑器,还有的是自己实现了一个。而这些富文本编辑器,往往在考虑xss defense的时候有所欠缺。这时候采用什么样的策略来做filter input,就成为了新的问题。
第一个难关就是程序员会拉上商业,一起来和狂战士PK,说filter input很容易误杀客户的正常操作,还会影响到性能。当然这小小的难关还难不倒狂战士。狂战士往往会轻蔑的一笑,然后把风险推到商业上,说出了问题让他背黑锅之类。这种狠话一放出来,商业往往就会退缩了,毕竟狂战士这么个狠角色是摆在那里的。所以最后会决定让程序员去整filter。
于是程序员简单写了个基于正则的blacklist,并且禁用了部分标签,比如script。狂战士这时候又蹦了出来,对程序员指手画脚,要求禁用 style,因为这玩意太难控制了,黑客有几百种利用style的方式;狂战士还说,基于正则的匹配这个魔法等级太低了,要换个高级魔法,比如个语法分析器,类似html purify这种,还要有log analysis和realtime monitor功能。
一般到了这个时候,程序员对狂战士的忍耐已经差不多到极限了,因为甲方网站很少以安全为主要考核因素,没人会认为一个视频网站或者是交友网站的安全需要做的比FBI更好,因为没那么大的成本投入。于是程序员说要释放这么个高级魔法需要一个团的程序员配合,还需要召唤很长时间才能放出来,所以狂战士的这个非常牛B的魔法无法完成。而一般在这个时候,程序员往往会用啥性能和稳定性之类的因素来忽悠狂战士,说这种魔法一般有一定概率会反噬,没整好就把自己整残了。
狂战士无奈之下,只好同意程序员实现一部分的魔法,filter部分过滤完整有效就行了。做好这个之后,狂战士还让程序员去对没有富文本需求的地方使用 escape output。程序员这时候对狂战士已经忍无可忍了,因为由于以前从来没有注意过xss这方面的问题,所以需要escape的地方是以“千”或者是“万” 为单位的,多如牛毛。于是程序员开始消极怠工,并且开始诉苦。这条路走不通了,狂战士只好开始寻求更好的方案。
后来狂战士回家睡了一觉,在梦中有仙人传授武艺,于是马上想到了新的办法。第一招是filter output,不过这个扯淡的方法根本属于yy,因为对服务器压力太大。第二招是使用WAF,就是web application firewall,开个虚拟补丁,这样程序员不补也能搞定web漏洞。不过这样就依赖于WAF的规则了,而且治标不治本。看来昨晚那个仙人估计是灶君一类低级的小神,尽出馊点子。看来狂战士还得继续和程序员PK下去了。
可以见到,那些牛圈里的狂战士常认为是“奇技淫巧”的XSS问题里,有这么多头疼的问题。简单的问题变得越来越复杂。
安全是一个持续的过程(process)。既然是过程,就会有第一步、第二步 ... 第N步,有一个持续的概念在里面,不能今天整了,明天就不管了。今天的安全并不代表明天的安全,新的技术和应用在不断发展,就会不断带来新的问题。经常看到一个升级反而把漏洞升级出来的例子。所以安全是一个持续的对抗过程,hacking与anti-hacking的过程,广义来说,更是一个弱化风险的过程。
很多BOSS往往都会这么问狂战士:我上了这个720安全卫士是不是桌面安全就不用管了?我上了这个卖红茶IPS是不是就能挡住所有刺客入侵了?狂战士这时候很无奈的说:不行,还是有很多trojan和rootkit可以bypass主动防御,很多shellcode和0day可以anti IPS。 于是BOSS很生气的说: 那我花这么多钱买这个做啥? 狂战士一般会忽悠他说:上了这个可以解决90%的攻击。于是BOSS会很不满意,让狂战士出技术分析报告,一定要有充分的理由才行,狂战士往往要面对这种烦恼。
其实BOSS的这种观点是一种急功近利的想法,没有认识到安全是一个过程,并且是一个持续改进的过程。不是买个box就能解决问题的。没有100%的安全,有漏洞的地方太多了。经常有魔法师用木桶原理来阐述安全问题,但其实很多时候,连木板在哪里,到底那块木板才是短板,都没有一个很清晰的认识,因为很多时候根本无法量化,所以狂战士的工作经常陷入误区。板子太多了,系统、网络、用户、应用、数据、桌面......
放眼看去,全是短板,每块板子都能让刺客或盗贼轻松的进来,偷走核心数据或者弄摊网站然后扬长而去。或者各种短板互相组合,让问题变得更加扑朔迷离。
前面说的WAF就是一种比较功利的做法,虽然厂商经常会蹦出来说这玩意是需要有专人维护的,也是一个持续的过程。但实际上很多购买WAF的用户都没有好好的去做这个过程。其实WAF、IPS最大的软肋不是在没人跟进上,而是在于其是串联的网络上的,特别是开了虚拟补丁的阻断模式的时候。这对于高可用性的应用来说,绝对是无法忍受的。没人敢背这个误杀的黑锅。要是因此导致了PV下降,可能老板就要喊到办公室去喝茶了。不过WAF也不是完全没用,如果能够用好的话,对于网站还是还是很有帮助的,至少在monitor和攻击流量分析上起着积极的意义。不过前提是用好。
刚才说了安全是一个过程 (Process),其实有人跟进这个过程还不够,下面还要重点说说深度防御的思想。经常看到YY小说的作者在写到黑客攻防的时候,说到XXX在xx分钟内就突破了N道防火墙,N大于100;变形金刚里也这么有这种场景。其实这纯粹是扯淡,没事整那么多防火墙做什么,无端影响了可用性。不过YY作者深度防御的理念还是正确的,只是他不知道那玩意不应该单纯叫防火墙,要想表达这个思想,可以整个专业名词,比如:多层防御体系。这样装B就可以装的比较像样了。举例来说,可以在应用层校验用户输入数据,DB层面检查每条sql,操作系统上细分权限,服务最少化,网络上防御arp spoof,加密传输通道,做好ACL......类似措施还有很多,防御的方案交叉层叠起来,就能起来一个比较好的保护效果。
不过偏偏还有不识趣的,比如前面的很多程序员都会说,我都已经做了filter input,还要escape output做啥。狂战士一般听到后会有想要狂化的冲动。按耐住狂化,告诉程序员,说filter input可能会做不干净,会被bypass,毕竟如果遇到一个手执绝世0day(bypass filter)的9级刺客,什么牛B的防御魔法都挡不住,所以能escape output的地方,最好escape掉,这样最干净。可是即便是这样做好了,还是有些会有很难处理和发现的地方,比如在DOM里的XSS,比如在JS里面一些写的很BT的地方,等。这些只能靠肉眼去看了。PK还得进行下去。
但是程序员还是不能很好的理解,他们跑出来说:我这里做了完善的 access control,只有管理员才看的到,这里就算有注射有跨站就随他去了,不需要修复。想偷这种懒的人其实不在少数。这种想法违背了深度防御的思想。先姑且不论如果管理员密码泄露,或者管理员是个内鬼的情况。如果刺客通过注射拿到了管理员密码,或者是直接通过XSS和CSRF来对后台进行注射,那么前面的 access control就完全没作用了。
在一定程度上,是可以容忍风险的存在的,但是从长期来看,这种做法是非常不可取的。比如有的管理员会说防火墙只允许80端口,那么RPC漏洞或开其他端口的应用漏洞是否就可以不补了。也许一时来说是没什么问题,但是如果放置不管将导致没有人来维护漏洞,也许哪天的防火墙策略变更,或者来自内部系统的威胁,都有可能导致当时看起来无害的漏洞被利用。而这种做法的一个后果往往是难以检查原因,就是说咋死的都不知道。所以这又回到了开始的话题:安全是一个持续的过程。
在灌输完深度防御的思想给程序员以后,狂战士又被另外一种程序员打击到崩溃了。面对满目都是红色的扫描报告,他们说:我这个xxx ftp没漏洞,除非狂战士可以证明黑客能搞进来拿到shell。一般狂战士听到这种要求,狂化的概率在80%以上。首先,不是只有能拿到shell的才叫漏洞。一个dos可能会造成业务的中断,一个infomation leak可能会为后续攻击带来便利,等等。
面对scan report以及CVE查询出来的漏洞,大部分都是没有现成的exp能够利用的,而且要利用漏洞可能有各种苛刻的条件,比如要求本地交互shell啊,或者要求有帐户之类。而更多的时候,漏洞根本连细节的都没有,只有一个漏洞公告里一个简单的划分critical,标红。就算有exp,可能还要考虑到 exp的稳定性和成功率、语言版本啥的,打过去也不一定能成功。更何况狂战士无法处心积虑了为了POC给程序员看,而花费大量的精力来追求一个可能没有结果的漏洞。
但是无法POC不代表就没有风险了。我们的目标是要保证一个系统长期的在任何情况下都能安全运行,机密数据不会外泄,业务不会中断。所以这种程序员犯的错误就是偷换了概念,把威胁范围缩小了,用个体来代替全局。很多时候威胁可能来自内部,可能来自误操作,可能来自其他的风险。要说服这种程序员很辛苦,只能够靠长期的“忽悠”,来慢慢感化他们,要是运气好还能做出一两个POC来震撼下他们,刘震撼(ZhenHan.Liu)就是为此而生的。佛曰:我不下地狱谁下地狱。
作为一个优秀的狂战士,往往要有相当程度的mission impossible的修为。很多时候,需要为浏览器漏洞、操作系统漏洞擦屁股,不然最后吃亏的还是自己的用户。面对钓鱼和诈骗,很多时候那些认为web 安全是“奇技淫巧”狂战士们认为解决方案是impossible的,认为no patch for stupid。比如phishing,诚然,如果有一个一劳永逸的方案,那么这种完美魔法要是放出来了绝对可以获得圣阶魔导师的称号。但是YY归YY,现实归现实。狂战士们很头疼这种问题,但是却不得不去面对它。
魔法最终还是放出来了,可惜不完美。目前anti-phishing的魔法,有整到浏览器里内置对抗的(IE7/8),也有浏览器toolbar、扩展的,有在IM里做过滤的,还有穷举malicious sites的,更有发动人民战争来维护一个blacklist的,其难度和成本从低到高什么都有,不过基本都无法一次性解决问题。比较有创意的魔法属于 yahoo发明的sign seal,基于认证机器的原理来识别真实网站,不过这个方法的缺陷在于需要长期教育用户,实际使用效果不一定好。yahoo还整了个domainkey技术来在邮件里对抗phishing,不过这个缺陷更明显,需要邮件服务商支持。yahoo的狂战士挺有想法的,就是太理想化了一点。
说到安全世界的另外一股强大力量不能不提教廷,这个宗教从精神上统治了安全世界,一群群红衣主教们整出来了一堆标准、规范比如BS7799之类来帮助狂战士们更好的忽悠他们的BOSS。其实标准是死的,主教们的出发点是好的,不过这些标准啥的就和秘籍差不多,狂战士们以为他们读明白了,其实很少人真正读懂了。那玩意如果拿来忽悠BOSS们确实是一套套的,但用在实处则有一个本地化的过程。必须要把标准之类的东西和实际情况结合起来,不然就只能停留在忽悠的层面上。
最能体现问题的出在编码规范上。可能有N个权威的机构都出了他们自己的code规范,或者某些狂战士佣兵团(安全公司)也自己整了套。不过在具体使用的时候,很多狂战士都是拿了一套去用在所有的公司身上,其实这样的结果就是到最后没有程序员遵守用那玩意,因为在实际情况中往往不好用。每个公司都有自己的体系、环境和编码习惯。系统的designer和architect只要不是小白一般都或多或少的会考虑点安全风险,规范只有本地化以后才能很好的用起来,不然绝对会水土不服。所以要是再遇到什么安全公司拿标准、规范来忽悠的时候,狂战士们就要睁亮了眼睛了!
胡侃瞎吹了这么多其实也没说到重点,不过重点已经不是本文要讲的事情了,想要讲的东西还有很多,也许以后会陆续写出来。狂战士是份很好的职业,希望有更多的狂战士甚至是半兽人朋友能够加入我所在的狂战士佣兵团!
.
axis
axis@ph4nt0m.org
没有评论:
发表评论