HITB2014AMS – 第2天 – iOS Web浏览器的探索与利用
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字符串/二进制数据,并可编程基本导航功能(goBack、goForward、stopLoading、reload)。stringByEvaluatingJavaScriptFromString函数允许从字符串执行javascript,且具有与来源页面(request.mainDocumentURL)相同的权限。远程Web服务器可通过Content-Security-Policy(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)
在UXSS中,Lukasz表示,攻击者利用浏览器中的漏洞。报告某些漏洞时,浏览器开发者通常回应“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可作为HTML执行(< iOS 7,现已修复),application/octet-stream也可作为HTML执行,且打开带有application/other的页面会触发Mobile Safari询问使用什么应用打开文件(可能获得本地跨源权限)。无论如何,如果能够执行JS并打破同源策略,则可窃取cookie、访问内部网站等。他们解释,窃取密码并不那么容易。为正确处理本地HTML文件,开发者应将文件作为text/plain打开,应用Content-Security-Policy头,使用HTML5沙箱,或使用Quick Look而非UIWebView(因为Quick Look不支持Javascript)。
从攻击角度,要利用UXSS,如果还能欺骗地址栏,成功机会将增加。事实上,有时甚至不需要UXSS漏洞,仅能欺骗地址栏就足够了。实际上,不能真正使用框架,且通常只能攻击移动浏览器的父/顶级窗口,不能真正将窗口隐藏在另一个之下……因此UXSS漏洞的成功可能相对有限。
ABS(地址栏欺骗)
Marek解释地址栏是移动浏览器开发者编程的部分,不属于UIWebView。能够更改网站内容而不更新地址栏显然是坏事。一种可能方式是使用超时函数更新当前页面内容。“Init & Interrupt”技术是实现ABS的另一种方式。代码不等待页面加载,而是中断加载并加载其他内容。还可以告诉浏览器回退到特定页面。在Kaspersky Safe Browser和F-Secure Safe browse中发现漏洞。在某些情况下,即使使用自签名证书加载页面,浏览器甚至保留绿色“证书正常”图标。
某些浏览器易受涉及先加载无效页面然后重定向到最终钓鱼页面而不更新地址栏的场景影响。循环加载页面并先连接到未监听的端口,再连接到实际页面/端口,也可能允许控制地址栏中的URL(因为端口通常不显示)。
要修复这些问题,重要的是显示UIWebView中当前加载的URL,而非认为会存在的URL。此外,在每个事件上更新地址栏,包括webView::didFailLoadWithError。最后,如果有实际成功且有效的SSL连接,显示SSL锁才有意义。而非之前。
其他常见弱点
他们还研究了一些其他漏洞,包括URI方案(影响下载、发送未认证推文和绕过弹出窗口阻止程序)和URL处理(Mobile Safari中的格式字符串内存损坏漏洞,允许泄漏栈内容,甚至在使用代理渲染时访问服务器文件系统)。
密码管理器功能也由Web浏览器开发者实现。在一个场景(Kaspersky Safe Browser)中,研究人员能够通过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波兰董事会成员。Marek毕业于华沙理工大学电子与信息技术学院。
© 2014 – 2021, Peter Van Eeckhoutte (corelanc0d3r)。保留所有权利。