2016年 十一月八日 星期二
摘要
IOS的WebView可以被利用去控制手机自动的拨打一个被攻击者控制的电话号码，这种攻击可以在短时间内锁住手机的用户界面并阻止受害者取消呼叫行为。这个bug是一种app的bug，貌似是由于严重的操作系统/框架错误导致。一个主要并且致命的问题是这个bug极易被利用。App的开发者们必须尽快修复他们的代码，因为Twitter和Linkedin的IOS端app是极易受到攻击的（其他的app也可能受到攻击）。演示视频点击这里：Twitter（https://youtu.be/oYDfe_P9uAQ）和Linkedin（https://youtu.be/WuFx4lxF8DY）

正文
大概一周前（星期五）我读到一篇新闻报道【1,2】说一个人使用手机时打开了一个网页，结果出乎意料的，手机自动呼叫了911，此人因为“调戏”911而被逮捕。这最大的可能是因为一个手机的URI（IMS用户的身份标识）处理上的bug【4,5】。我立刻想到了一个我在2008年十月报告给苹果的bug（https://archive.cert.uni-stuttgart.de/bugtraq/2009/06/msg00190.html）。我不敢相信这个bug又重新出现了，所以我进行了调查研究。那篇文章说了一些有关在Twitter上发布的链接的事。
如果你认为在一个app中点击了一个链接然后手机自动拨打一个电话号码不是一个大新闻，再想想。且不说调戏911已经是件麻烦事了，还有其他的例子，像是如果拨打的是昂贵的900号码，攻击者可以因此而获得金钱；一个跟踪狂可以令他的受害者手机自动拨打他的号码，这样他就可以获得他的受害者的号码。以上所有的例子你都不会想看到它发生的。
无论如何…我去检查了IOS端的Twitter的app。我在很短时间内就发现了一个非常简单的自动拨号工作器。我很开心同时也很崩溃因为这很容易。我一开始认为我准确的重现了那个的bug，但在更加集中精神的重新阅读了那篇文章后，我确定了这可能是一个不同的bug，或者至少是一个不同的触发器。那篇文章报道了负荷使用JavaScript和弹出窗口显示等问题，而我的原始的触发器是一行HTML(一个指向TEL URL的中继刷新标记)，因此我决定在HackerOne上通过Twitter的bug赏金计划去上报这个bug给Twitter。我之前从来没有上通过bug赏金计划上报过bug，所以我对于能获得这些经验（我一般通过安全的@来上报bug）感到十分开心。除此之外，现在是2016年，企业会为他们的bugs付出代价。所以我们会发现，Twitter在短短几日内就承认了这个看起来是个问题。
在十一月六日，我给Twitter更新了那个bug报告，增加了一个锁定用户界面的问题（continue reading），并且上传了一个视频。今天Twitter就像是复制般仅仅是关闭了这个bug，并没有任何的言论。尽管这可能只是一个复制行为，但是表现出了，他们对于做的更好应该是有兴趣的，也表现出了感谢给予那些上报了他们在业余时间所发现的bugs的人们。基于此，我决定今天公布这个问题的全部细节。
我在周末花了些时间去进一步研究这个问题。我认为这可能是一个使用WebViews来显示内容的IOS apps的普遍问题。我测试了一些我安装过的流行的apps，那些易受攻击的apps需要一个方法来为使用者发布网页链接，且网页链接将被在app内部打开。而那些在手机的Safari或者Chrome浏览器中打开网页链接的apps则不易受到攻击（我测试了这一点）。Linkedin是我测试的相当早的一个app因为Linkedin基本上是一个为商务环境提供的社交媒体软件。人们可以发送信息或者发布动态，动态通常是文本或者链接。我发布了一个链接然后点击它，然后没错，它拨打了我的另一个手机（演示视频在下方）。
我想给Linkedin提交这个bug，然后发现他们有个bug赏金计划。不幸的是，那是个私人赏金，只有你在截止之前提交的bugs才会被添加进去。我试图绕过它，但是没用。经过一些思考后我决定不去以私人的方式上报给Linkedin，而是将它公开（与这篇博客同时发布）。到现在，2016年了，如果他们不想将我的建议加入他们的程序中，那是他们的自由。事实上如果私人bug赏金计划仍存在的话，我并不想通过博客公布bugs而非通过错误赏金计划。
又一个周末到来了，我有了些时间，于是开始再次与这个bug周旋。事实上当我试图去搞明白我是否将这个bug上报给了Linkedin时，我从我2008年的PoC（Proof of Concept）开始浏览。在稍稍周旋了一会后，我或多或少的使我以前的PoC与Twitter和Linkedin的apps一起工作了。哇！
回到之前的事情上。我上报给Twitter的原始bug是通过访问网页来重新定向到一个TEL URL，从而触发一个电话。一个人可以通过很多种技术来实现这个bug，像：http的元刷新, 框架, 设置文档，定位, 获得当前界面, 或者是一个HTTP的重定向(定位到首位)。这将轻松的使手机自动拨打一个号码。受害者会在屏幕上看到拨号器和目标号码，当然，还是可以通过按下那个大红按钮来取消掉呼叫。只是呼叫取消后会造成迷糊的人感到疑惑（为什么我的手机在拨打一些号码）。
我在2008年发现的bug的美妙之处在于我可以在短时间内锁定手机的用户界面，从而防止使用者取消呼叫。我试图去用我在2008年用过的相同的技巧来锁定用户界面。这个技巧能造成操作系统在手机拨打指定号码的同时打开另一个app的情况。打开另一个app很简单,你打开一个URL,导致操作系统运行另一个app。这可能是任何来自信息app（通过SMS：URL）或者iTunes（通过itms-apps：URL）的app。你几乎可以使任何有URI绑定的app启动。在2008年我试过用SMS URL和一串十分长的电话号码来阻塞用户界面线程。对于这个技巧是如何工作的，我最好的猜测是IPC子系统事实上很难将几个字节的URL数据通过各层进入app,而目标app可能对于很大的URLs也不会感到很开心。我用下面的代码作为结束，这个代码使用组合元刷新标签和获得当前界面来完成攻击。这个代码会拖延设置获得当前界面1.3秒去保证拨号首先完成。这个拖延不能太长，否则这个WebView将不会执行这个URL去控制运行这个信息app，所以基本上你不得不使时机刚刚好。

这个PoC是用来触发这个bug的。

下面两个视频证明了这次攻击。你可以清楚地看到,用户界面在很短的时间内是不响应的。时间长到足够让另一边有人接起电话(尤其是服务热线自动接听)。

通常的好的app行为：
   Apps通常应该在执行前检查URL模式，在执行app在设备上前显示用户弹出对话框。一些例子如下所示:

手机上的Safari会在拨打苹果支持的号码前询问。这是好的apps应该有的表现。

      Dropbox显示一个警告而不是显示目标数，也不错但是可以变得更好。

      Yelp app通常表现的像Safari一样，但如果你用一个HTTP重定向它，它不显示目标数。我只是因为它有趣的地方才列入这个。
app开发人员应该检查他们使用的webview去确定它们是否容易受到这种攻击。脆弱的apps需要被修复。像Twitter和LinkedIn一样的服务提供商可以检查发布到它们网站的链接是否包含恶意代码,防止这些链接被发布到它们的服务器。
在未来，苹果应该改变WebView的默认行为去排除TEL URL的执行，并使其显示明确的特性来避免这种问题。我已经把这个问题报告给了苹果。
引用：
[1] Bug Bounty Hunter Launches Accidental DDoS Attack on 911 Systems via iOS Bug (softpedia)

[2] iPhone hack that threatened emergency 911 system lands teen in jail (ars technica)

[3] 这是我在2008年十一月苹果修复了IOS 3.0中的这个bug后发布的充分的爆料: iPhone Safari phone-auto-dial vulnerability (original date: Nov. 2008)

[4] 原始的 TEL URI schema RFC2806 URLs for Telephone Calls

[5] 更新的 TEL URI schema RFC3966 The tel URI for Telephone Numbers

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)

上传的附件：

• 0.jpg （35.01kb，2次下载）
• 1.jpg （43.08kb，1次下载）
• 2.png （44.55kb，2次下载）
• 3.png （16.81kb，1次下载）
• 4.png （28.65kb，2次下载）
• 5.png （8.08kb，1次下载）
• 6.png （8.08kb，1次下载）