WithEasy Passwords I develop a product which could be considered a Last Pass competitor. In this particular case however, my interest was sparked by the reports of two Last Pass security vulnerabilities ( 1 , 2 ) which were published recently. It’s a fascinating case study given that Last Pass is considered security software and as such should be hardened against attacks.
I decided to dig into Last Pass 4.1.21 (latest version for Firefox at that point) in order to see what their developer team did wrong. The reported issues sounded like there might be structural problems behind them. The first surprise was the way Last Pass is made available to users however: on Addons.Mozilla.Org you only get the outdated Last Pass 3 as the stable version, the current Last Pass 4 is offered on the development channel and Last Pass actively encourages users to switch to the development channel.
My starting point were already reported vulnerabilities and the approach that Last Pass developers took in order to address those. In the process I discovered two similar vulnerabilities and a third one which had even more disastrous consequences. All issues have been reported to Last Pass and resolved as of Last Pass 4.1.26.
Password autocompleteHaving your password manager fill in passwords automatically is very convenient but not exactly secure. The awareness for the issues goes back to at least year 2006 when a report sparked a heavy discussion about the Firefox password manager . The typical attack scenario involves an (unfortunately very common) Cross-site scripting ( XSS ) vulnerability on the targeted website, this one allows an attacker to inject javascript code into the website which will create a login form and then read out the password filled in by the password manager― all that in the background and almost invisible to the user. So when the Firefox password manager requires user interaction these days (entering the first letter of the password) before filling in your password― that’s why.
Last Pass on the other hand supports filling in passwords without any user interaction whatsoever, even though that feature doesn’t seem to be enabled by default. But that’s not even the main issue, as Mathias Karlsson realized the code recognizing which website you are on is deeply flawed. So you don’t need to control a website to steal passwords for it, you can make Last Pass think that your website malicious.com is actually twitter.com and then fill in your Twitter password. This is possible because Last Pass uses a huge regular expression to parse URL s and this part of it is particularly problematic:
(?:(([^:@]*):?([^:@]*))?@)?This is meant to match the username/password part before the hostname, but it will actually skip anything until a @ character in the URL . So if that @ character is in the path part of the URL then the regular expression will happily consider the real hostname part of the username and interpret anything following the @ character the hostname― oops. Luckily, Last Pass already recognized that issue even before Karlsson’s findings. Their solution? Add one more regular expression and replace all @ characters following the hostname by %40 . Why not change the regular expressions so that it won’t match slashes? Beats me.
The bug that Karlsson found was then this band-aid code only replacing the last @ character but not any previous ones (greedy regular expression). As a response, Last Pass added more hack-foo to ensure that other @ characters are replaced as well, not by fixing the bug (using a non-greedy regular expression) but by making the code run multiple times. My bug report then pointed out that this code still wasn’t working correctly for data: URL s or URL s like http://foo@twitter.com:123@example.com/ . While it’s not obvious whether the issues are still exploitable, this piece of code is just too important to have such bugs.
Of course, improving regular expressions isn’t really the solution here. Last Pass just shouldn’t do their own thing when parsing URL s, it should instead let the browser do it. This would completely eliminate the potential for Last Pass and the browser disagreeing on the hostname of the current page. Modern browsers offer the URL object for that, old ones still allow achieving the same effect by creating a link element. And guess what? In their fix Last Pass is finally doing the right thing. But rather than just sticking with the result returned by the URL object they compare it to the output of their regular expression. Guess they are really attached to that one…
Communication channelsI didn’t know the details of the other report when I looked at the source code, I only knew that it somehow managed to interfere with extension’s internal communication. But how is that even possible? All browsers provide secure API s that allow different extension parts to communicate with each other, without any websites listening in or interfering. To my surprise, Last Pass doesn’t limit itself to these communication channels and relies on window.postMessage() quite heavily in addition. The trouble with this API is: anybody could be sending messages, so receivers should always verify the origin of the message. As Tavis Ormandy discovered, this is exactly what Last Pass failed to do.
In the code that I saw origin checks have been already added to most message receivers. However, I discovered another communication mechanisms: any website could add a form with id="lpwebsiteeventform" attribute. Submitting this form triggered special actions in Last Pass and could even produce a response, e.g. the getversion action would retrieve details about the Last Pass version. There are also plenty of actions which sound less harmless, such as those related to setting up and verifying multifactor authentication.
For my proof-of-concept I went with actions that were easier to call however. There was get_browser_history_tlds action for example which would retrieve a list of websites from your browsing history. And there were setuuid and getuuid actions which allowed saving an identifier in the Last Pass preferences which could not be removed by regular means (unlike cookies).
Last Pass resolved this issue by restricting this communication channel to lastpass.com and lastpass.eu domains. So now these are the only websites that can read out your browsing history. What they need it for? Beats me.
Full compromise When looking into other interactions with websi