“同形异义字”钓鱼攻击,钉钉中招

作者:expsky

同形异义字钓鱼攻击号称“几乎无法检测”,是最狡猾的钓鱼攻击!这种攻击产生的原因是国际化域名IDNs(Internationalized Domain Names)支持多语种域名,而其中一些非拉丁字符语种的字母与拉丁字符非常相似,字面看很难区分。关于同形异义字钓鱼攻击的相关技术,freebuf上之前已有文章介绍,这里就不再过多介绍这个技术,不清楚可以自行搜索.

0x01 腾讯、京东、支付宝、微博、淘宝已面临同形异义字钓鱼攻击

真有这么多网站面临威胁?其实还不止,还有爱奇异、小米……

目前发现的威胁都是通过西里尔字母来进行混淆

上图是西里尔字母表,我们可以发现有不少字母与拉丁字母相识,这就是为什么用西里尔字母来进行混淆的原因

浏览器会通过Punycode来编码非拉丁字符的域名,编码后就可以避免产生混淆,但发现如果域名的一个字段里所有字符都是同一种语言,就不会进行编码(之前freebuf上有篇文章可能是笔误,关于这点刚好说反了)。据说这个问题chrome已经修复了,并且google还给相关发现者2000美金的奖励。

但我还是发现chrome有时候编码了,有时候又没编码

比如上面看到的“淘宝”,并没有编码。后面要讲的钓鱼攻击对是否编码已经不重要,所以现在就不用深究这个问题

我们先从јԁ.com开始(这里的јԁ.com 已不等于 jd.com了,是不是认不出来有什么区别 ^_^)

我们尝试注册јԁ.com,先Punycode转码后再查询

јԁ.com   转码后   xn--e2a25a.com

4 5

在国内不允许注册Punycode转码后的域名

6

在国外的域名网站就可以正常查询了,这里显示的not available是指已经被注册了,而不是说Punycode转码域名不能注册。之前获得谷歌2000美金的安全人员就注册过аррӏе.com(xn--80ak6aa92e.com)这个域名

14

直接在浏览器中打开 јԁ.com (xn--e2a25a.com )

目前域名还没被解析,来到了域名服务商提供的默认页面。

15

继续点击“了解如何才能拥有此域名”,可以看到明确说明此域名已经出售。

我们还可以再做个实验:

xiami.com虾米是阿里旗下的音乐网站,

我们查询西里尔字母的хіамі.com,这个域名就没有被注册,显示的available

хіамі.com   转码后   xn--80ayza2ec.com

7

不是所有的英文字母都有与之相似对应的西里尔字母

我尝试了一些可以用西里尔字母拼出的国内知名网站

ԚԚ.com   转码后   xn--x7aa.com  (腾讯)

ԛԛ.com   转码后    xn--y7aa.com (腾讯)

јԁ.com    转码后   xn--e2a25a.com (京东)

аӏірау.com    转码后   xn--80aa1cn6g67a.com (支付宝)

іԛіуі.com    转码后   xn--s1a1bab69g.com (爱奇艺)

ТаоЬао.com    转码后   xn--80aa5bbq6d.com (淘宝)

ԝеіЬо.com    转码后   xn--e1as5bzb58e.com (微博)

ЅО.com    转码后   xn--n1a9b.com (360搜索)

Мі.com   转码后   xn--l1a6c.com (小米)

8

显示全部已被注册

又尝试了部分以上可以用大小写混淆的形式

Ӏԛіуі.com   转码后   xn--s1a1bb53bvo.com (爱奇艺)

іԚіуі.com   转码后   xn--s1a1bab19g.com (爱奇艺)

іԚіҮі.com    转码后   xn--c2aaa96axr.com (爱奇艺)

ԜеіЬо.com    转码后   xn--e1as5bzb08e.com (微博)

ТАОВАО.com   转码后   xn--80aaf1cct.com (淘宝)

9

同样显示已被注册

试了这么多域名都被注册了,可能我们会再次怀疑是系统问题或是巧合,我在上面的ТАОВАО后面再加个О试试

ТАОВАО О.com   转码后   xn--80aaf1ccaw.com

10

这个域名就没有被注册了,所以不得不怀疑以上的域名是被刻意注册的

11

上图是јԁ.com(xn--e2a25a.com)的whois信息,whois信息被隐藏保护的,其他域名也类似或者提示无法显示或者有相关信息也无法追溯,只追溯到一个域名是国内安全圈的老司机注册的,这位可能是用来做研究

0x02 实施同形异义字钓鱼攻击,钉钉存在安全隐患

前面提到的chrome的漏洞就是浏览器地址栏没有进行Punycode转码,导致相似的文字可能产生混淆,存在钓鱼攻击的威胁。

我们这里不管google的这个漏洞有没有修复,换一个攻击思路:

一般内嵌手机APP的webview是没有地址栏的,所以转码也好,没转码也好,用户是看不到网址的

这里选了两个手机端最常见的即时聊天APP:

微信钉钉

用域名:

ТаоВао.com    转码后   xn--80aaf1cct.com

在我自己的iphone上进行了试验:

16

在微信里,这样的域名无论是否加http前缀都不会自动识别为url,所以也无法点击。(像上面baidu.com识别为url的会显示为蓝色,就可以直接点击打开)

然后再在钉钉里进行相同的尝试

微信截图_20170607180127

12

在钉钉里三种形式都自动识别为url,点击后就可以直接打开网址

按住手机屏幕下拉可以看到当前的url为 xn--80aaf1cct.com 即 ТаоВао.com

也就是说在钉钉里发起同形异义字钓鱼攻击很难防范,存在很大的安全风险。加之前面的分析,大量这样的钓鱼网址已被注册,随时可能面临威胁

这里就没再对其他的APP做实验,很可能或多或少都有这样的问题

0x03

按照惯例总有个结尾,这次就只说一句,希望马爸爸看到这篇文章,看是否也能给个奖励.

分享一种可关闭大多数杀软的技术(对360安全卫士已验证成功)

作者:expsky

360公司针对此文发出回应:

360安全卫士能够防御“模拟用户退出安全软件”的攻击方法,本文的演示应该是在64位系统关闭了360“核晶引擎”的情况下进行的。

由于64位系统的限制,安全软件需要应用CPU硬件虚拟化技术才能具备完整的防护能力,否则任何安全软件都可以被轻易关闭。核晶引擎是360在国内首家针对64位系统推出的CPU硬件虚拟化防护引擎,在开启了64位系统默认打开的“核晶引擎”后,360能够防御本文描述的攻击方法,读者可以自行验证。

木马与杀软的对抗从未停止,这样的对抗客观上也促进了安全技术的进步与发展。病毒、木马除了本身的功能以外,最重要一部分就是与杀软的对抗,这也是技术难点所在。试想一下如果在一台没装杀软的电脑上,病毒木马不需要什么注入、白加黑、rootkit技术来隐藏进程,不需要用什么高深未公开的方式来实现自启动,不需要精心构造隐秘通道实现C&C通信,不需要加密混淆来躲避静态查杀,也不用担心调用了跨进程内存读写或者注册表敏感位置读写、磁盘扇区读写、驱动加载等被杀软主防列为的危险API…….只需一个十多年前的简单木马就可以为所欲为。

关闭杀软,是病毒木马追求的最理想状态,但能做到这点只有极少数的特种木马或rootkit型木马能办到,绝大部分木马也只是通过各种技术手段来绕过杀软的部分功能,少有听说能关掉杀软的木马。

真有能关掉杀软的技术手段吗?

0x01 原理思路

我们尝试用模拟真实用户的操作,来关闭杀软。这里用360安全卫士目前最新版作为实验对象。是否能成功,我们一起往下看。

(声明:本人并不刻意针对360,而正是认可360在国内安全行业具有的代表性,并且该技术思路可以适用于其余绝大部分杀软)

要模拟真实用户关闭360安全卫士的流程如下:

1)鼠标右键点击桌面右下角360卫士的系统托盘图标

2)在弹出的托盘菜单中点击【退出】按钮

1

3)在弹出的360卫士退出窗口中点击【继续退出】按钮

2

完成以上步骤后360安全卫士就会被关闭。

接下来就是如何用程序自动模拟完成这些动作。

0x02 技术实现

点击相关窗口的按钮是通过对应的窗口类名得到相应的窗口句柄,然后实现点击。

通过“彗星小助手”的窗口SPY功能可以找出需要的窗口类名,而通过窗口类名找出窗口句柄是常规windows编程的知识,本文就不再累述

3

这里需要注意的是,系统360卫士托盘图标可能直接显示在桌面右下角的系统托盘上,也可能在隐藏的系统托盘区域。两种情况都需要考虑到

系统托盘的窗口类

Shell_TrayWnd   >>   TrayNotifyWnd   >>   ToolbarWindow32 通过这样的窗口关系找出系统托盘

而隐藏区域的系统托盘窗口类名是NotifyIconOverflowWindow

360卫士托盘菜单窗口类名:Q360TrayMenuClass

360卫士退出窗口类名:Q360HIPSClass

到此就可以定位到所有需要的窗口,我们还需要定位到窗口上的两个【退出】按钮

7.jpg8.jpg

这里需要注意的是,按钮实际上也是一个子窗口,普通的windows按钮通过彗星小助手可以直接定位识别,但现在很多软件包括这里的360卫士,按钮都是自绘出来的,不是传统的按钮控件,不能直接识别。不过也有办法,因为【退出】按钮相对于父窗口的位置是固定,通过父窗口的位置与【退出】按钮的相对位置就可以分别定位到两个需要点击的【退出】按钮,模拟鼠标点击就可以自动关闭360安全卫士

定位360卫士托盘菜单的【退出】按钮位置:7.jpg

x坐标 = 托盘菜单的x坐标 + 托盘菜单的宽度(260)- 20

y坐标 = 托盘菜单的y坐标 + 托盘菜单的高度(560)- 10

说明:-20和-10 即为【退出】按钮相对窗口右下角的位置

定位360卫士退出窗口上的【继续退出】按钮位置:8.jpg

x坐标 = 360退出窗口x坐标 + 360退出窗口的宽度(600)- 120

y坐标 = 360退出窗口y坐标 + 360退出窗口的高度(400)- 40

说明:-120和-40 即为【继续退出】按钮相对窗口右下角的位置

0x03 真实演示

“空谈误国,实干兴邦”,理论讲得再好,实现不了还是等于零。所以按照上面的技术思路我实现了一个演示工具,成功关闭了360卫士。大概1秒钟左右360安全卫士就被关闭了。录制了一张gif动图展示了整个过程

demo.gif

从上面的动图可以看出,关闭过程中会有窗口闪动。因为实现原理本来就是模拟用户的实际操作,所以用户真实关闭360卫士会出现的窗口这里都会出现。

有人可能会质疑这样不是就被用户发现了吗,其实这已经不重要了,木马已经在没有防护的环境下植入用户电脑,相关恶意代码已经成功执行。

0x04 结尾

如何防御这种攻击手段,通常的做法是在关闭安全软件的时候要求输入验证码,确保是人的真实操作,但验证码这种方式会影响用户使用体验,也不是最佳的方案。要想找到一个特别理想的方案不是太容易,做安全很多时候都是不得不去牺牲一些其他代价

由于本演示程序具有危害,所以这里就不提供源码了,但本文已经把这个原理以及相关的窗口类名称等重要信息说的很清楚,熟悉windows编程的话很容易自己就可以实现。唯一还有一个小点需要注意的是在系统托盘里如何定位到360卫士图标的位置,我是通过图像识别的方法来实现的,也许还有其他更好的办法。

本文的目的不是宣扬去攻击安全软件,而是想说明攻防的博弈永远没有尽头,而攻击者对安全技术研究的深度、广度、还有脑洞的大小,都会使得各种新型攻击方式出现,安全从业人员不能放松警惕。

蓝牙App漏洞系列分析之一

作者:heeeeen@MS509

0x01 概要

2017年5月的Android安全公告修复了我们提交的一个蓝牙提权中危漏洞,这个漏洞尽管简单,但比较有意思,能够使本地恶意App绕过用户交互,使用户强制接收外部传入的蓝牙文件。漏洞概要如下:

* CVE: CVE-2017-0601
* BugID: A-35258579
* 严重性: 中
* 影响的Google设备: All
* Updated AOSP versions: 7.0, 7.1.1, 7.1.2

0x02 漏洞分析

蓝牙App暴露了一个广播接收器com.android.bluetooth.opp.BluetoothOppReceiver,本地普通App可以向这个Receiver发送广播,查看其OnReceive方法,包含了对多种传入广播Intent Action的处理,但是大多数Intent Action处于保护状态,简单用adb shell可以一一对其测试,比如

提示如下错误,说明action处于保护状态

但是android.btopp.intent.action.ACCEPT这个Intent Action,却没有保护

进一步分析AOSP代码,发现传入这个Action的Intent时,会将Intent携带Uri指向的db进行更新,更新为用户确认状态。

这个db其实就是蓝牙文件共享的provider,对应的uri为content://con.android.bluetooth.opp/btopp,当通过蓝牙共享接收、发送文件时,该数据库都会增加新的条目,记录接收、发送的状态。该provider记录的信息可以参考BluetoothShare

因此,如果我们在Intent中传入某个蓝牙共享对应文件的uri,那么它在蓝牙文件共享Provider中的状态就会被更改为用户确认状态。这里继续进行猜想,进一步,如果我们刚好通过蓝牙传入某个文件,将其状态改为用户确认,是否文件就无需确认,自动接收了呢?幸运的是,的确如此。

0x03 漏洞利用

这里还有一个问题要解决,content://com.android.bluetooth.opp/btopp只是整个provider的uri,我们如何知道刚刚通过蓝牙传入文件的uri呢?通过暴力穷举,下面的PoC简单地解决了这个问题,

0x04 测试方法

通过蓝牙向测试手机发送文件,此时,手机将会出现提示,要用户拒绝或者接受,这个对话框将会出现约1分钟

1
此时运行POC,文件将会自动接收,因此这是一个本地用户交互绕过。如果有恶意程序利用该漏洞一直在后台运行,那么手机将会被强制接收任意蓝牙传入的文件。

0x05 修复

Google在Framework的AndroidManifest文件中,将android.btopp.intent.action.ACCEPT和DELINE设为保护状态,普通App无法发出携带这些action的Intent

0x06时间线

* 2017.02.09——提交Google
* 2017.03.01——漏洞确认
* 2017.05.01——补丁发布
* 2017.05.04——漏洞公开

首发 | Wannacry勒索软件母体主程序逆向分析(含临时解决方案自动化工具

声明:本文由expsky@MS509Team原创,仅用于技术交流分享
挺长时间没做逆向分析了,以前做逆向伤到了脑,也就成了所谓的脑残。但今天我手机里的微信公众号被Wannacry强势刷屏,于是又忍不住分析了下。
Wannacry勒索软件的背景大家都知道了,就是老美的重武器泄漏出来,结果被其他人捡了便宜所利用。类似这样的事情几年前我在以前的公司也做过,从国外弄来的高级样本,然后逆向后改良成自己的产品。毕竟这些高级货能原创出来的人太少了,逆向分析下改造改造这个擅长^_^    

继续阅读首发 | Wannacry勒索软件母体主程序逆向分析(含临时解决方案自动化工具

Android Telephony拒绝服务漏洞(CVE-2016-6763)分析

作者:heeeeen

0x00 概要

Google 12月的安全公告修复了我们提交的一个Telephony拒绝服务漏洞。

* CVE: CVE-2016-6763
* BugID: A-31530456
* 严重性: 高
* 影响的Google设备: All
* Updated AOSP versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0
继续阅读Android Telephony拒绝服务漏洞(CVE-2016-6763)分析

Details of Denial of service vulnerability in Telephony [CVE-2016-6763]

Summary

This month Google has fixed a vulnerability we reported. According to the Android Security Bulletin, this is a denial of service vulnerability in Telephony  that could enable a local malicious application to use a specially crafted file to cause a device hang or reboot. This issue is rated as High due to the possibility of local permanent denial of service.

CVE: CVE-2016-6763

BugID: A-31530456

Severity: High

Updated Google devices: All

Updated AOSP versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0
继续阅读Details of Denial of service vulnerability in Telephony [CVE-2016-6763]

MS509团队获得Google致谢

近日,Google发布了2016年12月份的Android安全公告,修复了我们发现的一个有关Telephony的拒绝服务漏洞,并予以致谢。

该漏洞编号为CVE-2016-6763,影响所有Android系统版本,严重性为高

credit_google

该漏洞可使手机永久损坏(需重置工厂设置恢复),Google对该漏洞的描述如下,

desc

漏洞详细分析链接

一个目录穿越引发的注入及后续——XG SDK漏洞回顾与思考

作者:小荷才露尖尖角

0x00 简介

XG SDK是一个流行的Android app推送SDK,有不少流行Android app均在使用,本文分析的版本主要针对100001_work_weixin_1.0.0.apk所使用的版本。

漏洞最初在2016年4月份的时候提交给了某云网站,厂商已经确认,但由于网站持续“升级”的缘故,不太可能公开细节了。后续漏洞也已经提交给了TSRC,时至现在,相关漏洞均已经完全修复,漏洞已经不影响使用该SDK的app了,因此本文决定对相关技术细节予以分享,并补充有关该漏洞后续的一些研究。 继续阅读一个目录穿越引发的注入及后续——XG SDK漏洞回顾与思考

MS509团队获三星官方致谢

近日,三星手机公司发布了2016年11月份的安全公告[1],对MS509团队发现的一中危漏洞予以致谢。

samsung-credit

漏洞详情如下:

SVE-2016-7044: system_server crash, DoS (AntService)

Severity: Medium
Affected versions: KK(4.4), L(5.0/5.1), M(6.0)
Reported on: September 6, 2016
Disclosure status: Privately disclosed.
The system services “AntService” doesn’t have proper access control and exception handling. And it allows attackers to use system API of “AntService” and cause rebooting of device by force-crashing the service.
The patch restricts unauthorized access to the “AntService” and filters out improper cases which may cause crash。

[1] http://security.samsungmobile.com/smrupdate.html#SMR-NOV-2016

JSRC成都站——一场诚意满满的安全交流

10月28日,京东安全响应中心联合猪八戒安全响应中心在成都世代锦江酒店共同举办了“2016年JSRC安全乌托邦——成都站”。

我们MS509 Team核心成员Thor是分享者之一,他带来的议题是《One Class to Rule Them All:Android反序列化漏洞分析》,我有幸跟着Thor大牛参与了这次安全分享会。 继续阅读JSRC成都站——一场诚意满满的安全交流