Password Managers: Attacks and Defenses David Silver, Suman Jana, Dan Boneh, Stanford University Eric Chen, Collin Jackson, Carnegie Mellon University 23 th USENIX Security Symposium, San Diego, CA, August /09/30 Advanced Defense Lab Seminar - Liang-Hsuan Lin

Outline Introduction Password managers: a survey Threat model Remote extraction of passwords from password managers (Sweep Attacks) Strengthening password managers Conclusion 2

A tool for… 3 Convenience?Security? Goal: Both!

Password Manager Workflow 4 Password Manager Save manually entered password Autofill username and password

Manual Autofill 5 Page Load

Automatic Autofill 6 Page Load X

Should We Autofill? 7

8

Autofill policies The domain and path Protocol: HTTP vs. HTTPS Modified form action Autocomplete attribute Modified password field name 9

The Domain and Path Autofilled on any page within the same domain as the page from which the password was originally saved All password managers i.e. example.edu/~linliang example.edu/~ On the same domain, treated as a single site

Protocol: HTTP vs. HTTPS Suppose the password was saved on a login page loaded over one protocol, but if the current login page is loaded over a different protocol with all other element of the URL are the same, will the password managers autofill? 1Password, Keeper, LastPass allow autofill after user interaction Norton IdentitySafe will autofill in this case Others, refuse to autofill 11

Modified Form Action 12 At Save: Now: Automatic Autofill If action changed by JavaScript after autofilling? form.action=“

Autocomplete Attribute If we set Respect attribute: Firefox, Mobile Safari, the default Android Browser Ignore attribute: others 13

14

Additional Password Manager Features iFrame autofill Not autofill: IdentitySafe, Mobile Safari, LastPass Manual interaction: Desktop Chrome Autofill: Firefox, Safari, Chrome for Android Visibility IdentitySafe Autofill method KeePass Autofill and submit 1Password, LastPass, IdentitySafe, KeePass 15

Sweep Attacks Stealing multiple passwords without user interaction 16

Thread Model: Coffee-shop Attacker 17 Goal: Trick password manager into revealing b.com’s password

Redirect Sweep Attack 18 GET papajohns.com GET att.com REDIRECT att.com + attacker JSatt.com automatic autofill get att.com password! GET papajohns.com papajohns.com

iFrame Sweep Attack Hotspot landing page contains invisible iFrames pointing to the arbitrary pages at multiple target sites Inject JavaScript in each iFrames then steal and exfiltrate credentials The increasing of network traffic and memory usage can be more reasonable by using hierarchical arrangement 19

Example: iFrame not same-origin with parent 20

Window Sweep Attack Uses windows instead of invisible iFrames Attacker trick users into disabling their popup blocker, the landing page can open each of the victim pages in separate window 21

Brief Summary 22

Injection Techniques HTTP login page Active mixed content XSS injection Leftover passwords 23

HTTP login pages HTTP pages trivially vulnerable to code injection by coffee shop attacker 24

Active Mixed Content Any HTTPS webpage containing active content (e.g. scripts) that is fetched over HTTP is also dangerous For example, embedding a Shockwave Flash (SWF) file over HTTP if not blocked correctly can be used by a network attack to inject arbitrary scripts [J. Hodges, et al][J. Hodges, et al] 25

Leftover Passwords The user’s password manager may contain leftover passwords from older, less secure version of a site An attacker could spoof the old site to steal the leftover password For example, if a user’s password manager contained a password for Facebook from before its switch to HTTPS, an attacker could spoof an HTTP Facebook login page to steal the password 26

Password Exfiltration Method #1: Stealth Method #2: Action 27

Method #1: Stealth The attacker waits until the login form is populated with the user’s credentials automatically by a password manager, and execute the following code: 28

Method #2: Action The attacker can modify a login form’s action attribute so that it submits to an attacker- controlled site 29

Strengthening Password Managers Defense #1: Forcing user interaction Defense #2: Secure Filling 30

Defense #1: Forcing User Interaction 31 Page Load Always require user interaction PM should show the domain name being autofilled before the filling occurs

Implementation of Forcing User Interaction Let wait_for_username = true; In password_form_fill_data.h [link]link But this will lose convenience

Defense #2: Secure Filling More secure than manual entry Don’t let Javascript read autofilled passwords Let form submit only if action matches action when password was saved (Site must submit form using HTTPS) Prototype implementation in Chromium (~50 lines) 33

Secure Filling Properties a)Store the “action” when the field were first saved b)Let the password field unreadable while autofill in progress c)If the username or password fields are modified while autofill in progress, the autofill aborts d)Once autofill is finished, wait for all JavaScript code done, the browser checks whether the form’s action are changed 34

Implementation of Secure Filling In password_autofill_agert.cc [link]link 35 FillUserNameAndPassword Fill the password field with dummy value Store the real password and the form’s action in a PasswordInfo object WillSendSubmitEvent Check the dummy value is still present If it is, and if the form’s action matches the action we had stored Replace the dummy value with the real password and submit

Limitation of Secure Filling AJAX-bases login When the login form’s submit button is pressed, these sites use JavaScript to read the form fields, then construct and submit an XMLHTTPRequest object. Not compatible with Secure Filling 10 sites out of Alexa Top 50 use AJAX to submit password forms Workaround Submit form in iFrame (X) Create browser sendPassword API 36

Conclusions Automatic autofill has lots of problems Sweep Attacks: steal passwords without any user interaction Defenses Require user interaction before filling passwords Secure Filling Just as convenient for user but much more secure 37