Password Managers Attacks and Defenses_论文阅读报告

最新推荐文章于 2024-10-12 23:00:53 发布

Tsinghust

最新推荐文章于 2024-10-12 23:00:53 发布

阅读量1.1k

点赞数

分类专栏： Password manager 文章标签： Password manager 密码管理器安全阅读报告

本文链接：https://blog.csdn.net/Tsinghust/article/details/46827901

版权

Password manager 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

PasswordManagers: Attacks and Defenses

David Silver¹, Suman Jana¹, Eric Chen²,Collin Jackson², and Dan Boneh¹

¹Stanford University, ²Carnegie Mellon University

(Note: 这段上标的意思表示，David、Suman、Dan等人来自于Stanford，而Eric、Collin等人来自于Carnegie Mellon)

附原文链接：https://www.cs.utexas.edu/~suman/publications/suman_pwdmgr.pdf

Abstract

这篇文章主要研究password managers以及password managers有关Web密码自动填充策略安全性问题。

关注的password managers主要包括这三类： 1)browser built-in pm(浏览器自带填充功能)；2)mobile pm；3)3rd-party pm。

各个pm的密码自动填充策略都不相同，一些自动填充策略会导致灾难性的后果。在这种状况下，远程网络攻击者能够在和用户没有任何交互的情况下从用户的pm中获取众多密码。这篇文章不仅对这种攻击形式作出了实验，还对强化pm安全的技术作出了实验。实验结果表明，文章提出的安全强化机制有必要被现有的pm所采用。

1. Introduction

现在的pm都流行在用户访问一个Web登陆页面时采用自动填充机制填充用户名和密码。其中，第三方pm会通过浏览器扩展插件的方式来支持自动填充机制。

本篇文章提到，在研究市场上流行的pm工具发现它们的自动填充策略太过宽松，存在在易遭受攻击的环境下自动填充密码的问题，带来泄露密码的安全漏洞。攻击者可以通过远程网络在用户不知情的情况下就窃取到pm保存的密码。甚至对于云同步pm工具，远程网络攻击者可以在某一设备上窃取到从未在这一设备上登陆的账号密码。

这篇文章的工作包括研究pm的安全，并提出了一些提升pm安全的方法，主要有：

1）调查了10个流行pm工具在什么时候自动填充密码。不同pm有着不同的自动填充机制，给用户带来不同风险。

2）介绍了一些自动填充机制在用户不知情的情况下导致远程密码窃取的重大攻击案例，这一攻击仅需设备连上一个恶意公共路由（coffee stop）。

3）这篇文章强调了pm工具对于证书安全的重要意义（对证书安全有积极意义），从而强调了对于pm工具安全性提升研究是有意义的。这篇文章提出了强化pm工具的方法，使得pm工具比起手动输入密码更安全。这篇文章在Chrome浏览器上部署了这些改进，并对改进效果做出了报告。

An example：以HTTP协议提供login page，而以HTTPS协议提交密码的例子。（HTTPS协议在提交上对避免密码泄露有帮助，但是以HTTP协议提供login page却带来了安全漏洞）比如，Alice在一个公共wifi热点认证上网，这是wifi热点可能给Alice提供包含多个不可见的iFrames的landing page，而这些iFrames正是指向多个Alice通过pm保存密码的登陆页。当浏览器加载这些iFrames后，恶意路由可以向网页中注入JavaScript代码，从而获取pm工具自动填充的密码。

对于用户来说，他只是访问了一个wifi热点的登陆页面，就在没有任何提示的情况下被盗取了密码。10个测试的pm工具中有6个就存在这一漏洞。

图中的这些iFrames是不可见的。

2. Password managers：a survey

自动填充策略主要包括两种：

1） Automatic autofill：login page加载后无需用户交互自动填充用户名和密码。

2） Manual autofill：填充前需要一些交互，这种交互主要指点入用户名域，键盘快捷键，浏览器按钮等。

IE11使用了一个hybird approach：由HTTPS加载的页面自动填充，由HTTP加载的页面需要交互。

一些pm工具在特定环境下要求手动交互来自动填充：

1） Chrome在密码域被包含在iFrame中时需要手动交互；

2） Chrome在Mac OS X system-wideKeychain下只在被用户手动选择至少一次后才自动填充；

3） Safari or Chrome在Mac OS X下第一次访问system Keychain密码时，会弹出一个请求用户权限的对话框。如果用户选择了Always Allow，对话框将不再显示并且密码会在将来自动填充。而当利用iCloud Keychain从另一个设备同步来密码时，对话框不会出现。

4）一些pm工具（LastPass、NortonIdentitySafe）提供非默认的配置选项使自动填充策略失效。这篇文章只讨论pm工具的默认配置，即采用自动填充策略的情况。

2.1 Autofill policies

一个问题：当pm遇到的登陆页面与当初密码被保存的登陆页面有所不同时应该如何处理？这时pm工具应该应用自动填充吗？对于不同的pm有着不同的策略。

（图片引用自原文）

Protocol：HTTPvs. HTTPS.

如果密码保存时使用的是HTTPS，而这次登陆的login page使用的是HTTP呢，此时pm应该自动填充密码吗（尽管其它的都一样，包括域名和路径，页面内容）？其实应对协议改变问题，无论是自动填充还是手动交互都是危险的。

Modifiedform action.

表单的action属性指的是表单的内容发送的目的地。因此攻击者可以改变login form的action属性指向受攻击者控制的URL上。因此，当login form的action属性变化后，pm是不应该自动填充的。

在这里主要有两种情况，一种是login form在加载action属性就不同于密码保存时；另一种是login form加载时指向正确地URL，然而login page中的JavaScript代码改变了login form的action域指向了不同的URL。当一些pm觉察到action属性改变时，采用了用户交互模式，但却没有给用户任何有关action属性改变的指示，当用户完成了相应的交互后，pm还是自动填充了用户名和密码。

密码框有着一个autocomplete属性，当autocomplete被设置为off时，pm本不应该自动填充密码，但是依然有pm忽略这一属性的设置自动填充了密码（尽管有些pm对于是否忽略这一设定给了一定选择的权限）。而且，尽管login form可以将password域的autocomplete属性设定为off，远程网络攻击者也可以更改这一属性设定。尽管autocomplete属性设定对于一些浏览器可以使得无法保存密码，防范我们的攻击，但这也影响了pm的正常功能。

BrokenHTTPS behavior.

假设密码被保存时HTTPS是有效地，而登录时HTTPS会话由于证书错误broken了，如果用户忽略掉证书警告，访问login page，pm工具应该自动填充吗？如果填充，这又会导致严重攻击。

Modifiedpassword field name.

“Self-exfiltration”attacks.(password域的name问题)

攻击：使密码被提交到公共发布界面，从而获取密码。

2.2 AdditionalPM Features

iFrame autofill. Login page中的iFrame与login page不同源如何处理？

Visibility. 表单通过CSS属性设定为不可见如何处理？（还有透明度）

Autofill method. 不直接与浏览器交互，而是自动输入表单，提交表单的行为。（包括输入用户名，Tab Key，密码，Enter key）

Autofill and Submit. 不仅自动填充表单，并且提交。

（Autofill method 和 Autofill and Submit的区别？ Autofill method是自动键盘输入的方式，Autofill and Submit是浏览器自带的表单填充的属性）

3. Threat Model

这一攻击模型只考虑网络中间人攻击形式，不要求用户在攻击者面前登录任何目标网站。攻击模型主要包括两步：

首先在攻击者不知情情况下用户登录众多网站，并且通过pm工具记录密码；下一步用户连接上被攻击者控制的恶意WiFi热点。在这种情况下，攻击者可以劫持，阻塞，更改数据包及目的地，以此在用户不知情的情况下偷取保存在pm工具下的密码。（这一模型被称作evil coffee shop attacker）

4. Remote extraction of passwordsfrom password managers

4.1 Sweepattacks

三步：首先，攻击者在用户不知情情况下让用户浏览器访问任意漏洞网页，然后通过篡改网络流量来向漏洞网页注入JavaScript代码，最后JavaScript代码抽取到密码。

iFrame sweep attack.

像漏洞页面内注入隐藏的iFrame及JavaScript代码。

the password extraction process can bemade more efficient by arranging the iFrames in a hierarchical structureinstead of adding one iFrame to the top-level page for each target website.

Window sweep attack.

the landing page can open each of the victim pages in a separate window.

使窗口不被察觉。

Redirect sweep attack.

In ourimplementation, once the user connects to a network controlled by the attackerand requests an arbitrary page (say, a.com), the network attacker responds withan HTTP redirect to some vulnerable page on the target site (say, b.com). Theuser’s browser receives the redirect and issues a request for the page at b.com.The attacker allows the page to load, but injects a login form and JavaScriptinto the page. When the user’s browser loads the page from b.com,the vulnerablepassword manager will automatically autofill the login form with thecredentials for b.com, which the injected JavaScript can then exfiltrate.(这种攻击方式还存在一些缺陷，如浏览记录，地址栏网址)

（图片引用自原文）

(图解：Vulnerability to sweep attacks. + indicates vulnerability without restriction.HTTPS indicates vulnerability only on pages served over HTTPS. Single indicatesa single site is vulnerable per top-level page load. SO indicates vulnerabilitywhen the page containing the iFrame is same-origin with the target page in theiFrame.)

Attackamplification via password sync. 同步服务带来漏洞：从没有在这台设备使用过这一账号密码，却在这台设备上被盗。（安全的木桶理论）

4.2 InjectionTechniques

同源方式的密码窃取：不一定只在login form上注入代码，可以在任何同源的网页内注入登陆表单从而窃取密码。

HTTP login page.

Served as HTTP,Submit with HTTPS.

SSLstrip attacks 链接：

https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

SSLstrip attacks需要用户输入密码连接攻击者网络访问受害网页。(在提交表单后提取出密码)

Embedded devices 1：嵌入式设备存在网络信道安全的假想（WPA2， VPN）采用HTTP协议。

Embedded devices 2：采用HTTPS协议，但路由器使用自签名证书。

Broken HTTPS：使用自签名证书采用Redirect攻击，自签名证书的警告容易被忽略。（急于认证上网）

Active Mixed Content. If rendering active mixed content is enabledin the user’s browser, any HTTPS page containing active mixed content isvulnerable to injection.(Flash文件容易被注入任意脚本)

XSS Injection：跨站脚本攻击窃取密码模式

Leftover Passwords：伪造低安全度的网页版本，试图窃取leftover password。

4.3 PasswordExfiltration

Method1：将密码写入隐藏的指向攻击者控制的网页的表单再提交。

Method2：更改正确表单的action属性。

4.4 Attacksthat need user interaction

窗口伪造技术

5. Strengthening password managers

之前的方法：检测是否存在JavaScript注入很难；禁止自动填充iFrame，无法处理window or redirect sweepattacks，给用户填写表单带来不便。

5.1 Forcing user interaction

An obvious defense is to always require some user interaction beforeautofilling a form. Regardless of the type of interaction, it must be protectedagainst clickjacking attacks as described in Section.

防止JavaScript伪造用户交互。

在用户选择自动填充时应该被告知填充的是哪个网站。（当网页中包含多个表单时，选择填充哪个表单）

对于brokenHTTPS，pm应该选择拒绝自动填充。

Implementation.

We did so by hardcoding the wait_for_usernamevariable to true in the constructor of the PasswordFormFillData object.

Minimizing user inconvenience.

autofill-and-submit.

5.2 Secure Filling

仅仅要求用户交互是不够的。

The goal of secure filling is that even if an attacker injects maliciousJavaScript into the login page, passwords autofilled by the password managerwill remain secure so long as the form is submitted over HTTPS.

HTTPOnly cookies. 链接：http://tools.ietf.org/html/rfc6265

https://en.wikipedia.org/wiki/HTTP_cookie

Defense works：

1. 除了用户名和密码，pm工具还存储用户名和密码保存时的action。

2. 当pm自动填充密码后，使得密码域对于JavaScript变得不可读。

3. 在自动填充过程中，如果用户名和密码域被更改，自动填充停止，密码从密码域中清除，密码域变得重新被JavaScript可读。

4. 在表单提交之前判断这一表单的action是否与密码被保存时同时保存的action相同，相同则提交，否则停止提交，清除密码域。

考虑到网站的重新设计和login page的改变，当action域与保存时不同时，有必要可用户以一定的提示是否还提交表单。

Implementation. We implemented aprototype of this defense in Chrome by modifying the PasswordAutofillAgentclass. In the FillUserNameAndPassword method, we fill the password field with adummy value (a sequence of unprintable characters), then store the realpassword and the form’s action in a PasswordInfo object associated with theform. In the WillSendSubmitEvent method,we check if the dummy value is stillpresent in the password field; if it is, and if the form’s action matches the actionwe had stored, we replace the dummy value with the real password and allow theform to submit.