iOS浏览器安全漏洞分析与利用技术详解

本文深入分析了iOS第三方浏览器的安全漏洞,包括UXSS通用跨站脚本和地址栏欺骗等技术细节,探讨了WebKit框架的安全隐患及针对密码管理器和SSL证书处理的攻击手法。

iOS浏览器与UIWebview

iOS平台非常流行(根据StatCounter数据,它是第三大流行平台)。移动浏览器约占市场份额的20%到25%。iOS提供与桌面浏览器和云的集成(因此攻击者可以获取相同数据)。许多第三方iOS浏览器存在相似的弱点,这些弱点仍被新浏览器复制……且iOS被某些漏洞赏金计划采纳。

默认iOS浏览器是Mobile Safari。根据iOS应用商店审核指南,“浏览网页的应用必须使用iOS WebKit框架和WebKit Javascript”。当然,Mobile Safari不是苹果商店中唯一的浏览器,其中一些也在桌面上使用。

浏览器使用UIWebView构建,该组件允许在应用中嵌入网页内容。UIWebView与原生Mobile Safari的主要区别围绕UI展开。它们核心都使用WebKit,但原生浏览器使用Viewport而非UIWebView。UIWebView API相当简单直接,允许获取远程文件/HTML字符串/二进制数据,并可编程实现基本导航功能(前进、后退、停止加载、重新加载)。stringByEvaluatingJavaScriptFromString函数允许从字符串执行JavaScript,且权限与来源页面(request.mainDocumentURL)相同。远程Web服务器可通过内容安全策略(CSP)阻止JavaScript执行。JavaScript用于实现浏览器功能并重写原生函数,以通过Objective-C代码桥接实现多标签页等功能。最后,UIWebViewDelegate API允许响应加载文档中的特定事件。

演讲者解释其研究主要关注多标签页、地址栏、自动填充与密码管理器、下载、对不受信任SSL证书的支持及其他功能(安全评级、恶意软件防护、云集成)的行为。他们表示灵感来自《浏览器安全手册》(http://browsersec.googlecode.com),该手册提供可在浏览器上运行的测试用例集(参见http://browsersec.googlecode.com/files/browser_tests-1.03.tar.gz)。此外,他们还从Web角度进行黑盒测试、审查JavaScript代码及少量逆向工程/调试。他们准备了跨浏览器测试用例并发布于https://ios.browsr-tests.com。

此外,他们重新测试了部分旧版Mobile Safari漏洞(如CVE-2011-3426),发现某些修复不完整。

UXSS(通用XSS)

Lukasz指出,在UXSS中,攻击者利用浏览器中的漏洞。报告某些漏洞时,浏览器开发者通常回应“WebKit应处理同源策略,对吧”,将责任归咎于iOS。他们发现这种假设/反应并不总是正确的。人们往往只关注功能而忽视安全性。CVE-2013-6893、CVE-2013-7197和CVE-2012-2899是不同浏览器(Mercury、Yandex、Google)中UXSS漏洞的示例。多数情况下,问题源于浏览器支持多标签页且可指定子窗口/标签页中显示/执行的内容。在iOS上,WebKit并无真正多标签页,这意味着浏览器开发者需自行实现所有必需功能。桌面浏览器中使用的技术相对安全,但iOS浏览器中并非如此。

他们解释,父窗口/标签页使用原生UIWebView同源策略。创建新标签页必须使用Objective-C“桥接”,且开发者需记得更新地址栏等其他UI元素。为实现这些,需要自定义同源策略。最终子窗口/标签页再次使用原生SOP。

此外,由于移动浏览器无原生文件下载方式,它们通常加载文件后通过本地file://源写入。某些情况下,文件(通过Content-Disposition: attachment)显示在托管站点的源中。iOS 5+实现了新的“隔离附件源”,但未解决所有问题。操纵Content-Type也产生有趣结果:text/plain可在iOS 7前作为HTML执行(现已修复),application/octet-stream同样可作为HTML执行,且打开application/other页面会触发Mobile Safari询问使用何种应用打开文件(可能获取本地跨源权限)。总之,若能够执行JS打破同源策略,可窃取Cookie、访问内部网站等。他们解释窃取密码并不容易。

为正确处理本地HTML文件,开发者应作为text/plain打开文件、应用内容安全策略标头、使用HTML5沙盒或使用Quick Look替代UIWebView(因Quick Look不支持JavaScript)。

从攻击视角看,利用UXSS时,若还能欺骗地址栏,成功几率将增加。事实上,有时无需UXSS漏洞,仅欺骗地址栏即足够。实际上,无法使用框架且通常只能攻击移动浏览器的父/顶层窗口,无法将窗口隐藏于另一窗口下……因此UXSS漏洞的成功可能相对有限。

ABS(地址栏欺骗)

Marek解释地址栏是移动浏览器开发者编程的部分,不属于UIWebView。更改网站内容而不更新地址栏显然有害。实现此的一种方式是使用超时函数更新当前页面内容。“初始化和中断”技术是另一种实现ABS的方式。代码不等待页面加载完成即中断加载并加载其他内容。还可让浏览器回退到特定页面。在卡巴斯基安全浏览器和F-Secure安全浏览器中发现漏洞。某些情况下,即使使用自签名证书加载页面,浏览器仍保持绿色“证书正常”图标。

部分浏览器易受先加载无效页面再重定向到最终钓鱼页面而不更新地址栏的场景影响。循环加载页面且先连接到未监听端口再连接到实际页面/端口,也可能允许控制地址栏中的URL(因端口常不显示)。

修复这些问题需显示UIWebView中当前加载的URL,而非预期URL。同时,在每个事件(包括webView::didFailLoadWithError)中更新地址栏。最后,仅当存在实际成功且有效的SSL连接时显示SSL锁图标。

其他常见弱点

他们还研究了其他漏洞,包括URI方案(影响下载、发送未认证推文和绕过弹窗阻止器)及URL处理(Mobile Safari中的格式字符串内存破坏漏洞可泄露栈内容,甚至在使用代理渲染时访问服务器文件系统)。

密码管理器功能也由Web浏览器开发者实现。在一种场景(卡巴斯基安全浏览器)中,研究人员通过MITM漏洞(插入自动接收用户名/密码的隐藏框架)从密码管理器窃取密码。地址栏会短暂更新(除非与ABS结合),但演示的攻击成功。

最后,SSL处理方式很重要。默认情况下,iOS UIWebView HTTPS请求中的无效证书无需用户交互即被拒绝。某些漏洞可改变此行为(使用户接受自签名证书)。Opera Coast 3.0是易受简单MITM攻击的浏览器之一。

关于演讲者

Lukasz Pilorz – 曾任职国际电子商务平台应用安全专家,现为某大型英国银行渗透测试员。OWASP波兰会议常邀演讲者及波兹南分支发起人。其Web安全生涯始于2006年的sla.ckers.org。

Marek Zmyslowski – 拥有多年渗透测试经验,包括多家波兰银行及金融机构的银行系统和电子银行。现任某世界最大银行内部系统首席渗透测试专家。持有Offensive Security的OSCP和OSCE证书。同时为OWASP波兰董事会成员。毕业于华沙大学电子与信息技术学院。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计