Slipping Past LastPass

Update: LastPass has confirmed that they’ll address this issue in the next release.

Update 2: LastPass has addressed this issue in their new v2.0 release. There is still a way to bypass the password prompt in Chrome, but they will address that in the next release. Overall, it looks like we can close the books on this one.

I’m a big fan of LastPass – it’s a great service that has impressed me every step of the way. Though it’s not perfect, and I’ve found a small hole that makes it easier for an attacker to get your passwords – if the following are true:

The attacker has physical access to your PC.
You’ve made the mistake of not locking your PC when you walk away.
You’ve select the option to stay logged on – which happens to be a default, or, you’ve left your browser open (as I expect most people do).

If all three of these are true (or your PC is otherwise compromised) – you probably shouldn’t expect much in the way of security, but LastPass does protect you – most of the time. If you try to copy or view a password, you’ll be prompted to enter your Master Password – but there’s one case that can easily expose your passwords without needing to know the Master Password.

The issue is that LastPass allows you to change the address associated with a login without confirming your master password. This would allow an attacker to update an entry in your vault to a specially crafted page to echo the password – allowing the attacker to see the password and leave minimal tracks behind. I setup a special page to test this, it echoes the password as soon as LastPass enters it, allowing me to see the password in a few seconds without providing the master password (it’s also possible to update the password without providing the Master Password, providing another opportunity for mischief).

Automation #

While I’ve not taken the time to build a tool to automate this – it would be a fairly simple process to do, just a matter of investing the time (which unfortunately I don’t have). The obvious solution would be to automate the GUI interaction to perform the following steps:

Change the URL to a malicious page.
Navigate to the page, and log the login data.
Revert the URL to the original value.

Using this method it would be possible to collect all of a users credentials within just a few minutes. It’s possible there may be a simpler & faster route available by interacting directly with the plug-ins, though in looking at the exports and COM interfaces I didn’t see an obvious way to achieve this (which as a LastPass user, this makes me happy).

For an attacker, one substantial upside is that there would be little evidence of the event – while the LastPass Vault will show that all entries have been “touched” recently, I would venture to say that very few users would actually notice.

While this attack requires full access as the logged-in user, if a PC is otherwise compromised (perhaps as part of an APT type attack), it could allow an attacker to greatly expand their activities with a minimal time investment. This is the type of situation that could take a fairly small local information disclosure and turn it into a real nightmare scenario for a targeted user.

Solution #

The simplest solution for this issue is to require Master Password verification if the URL changes, or at least require it if the domain changes. This should be a minor change for them and will eliminate this attack vector. Thankfully this is a minor issue, due to the three requirements required to pull this off – so I don’t believe there is too much risk due to this oversight.

Adam Caudill

YAWAST v0.7 Released

It has now been over a year since the last major release of YAWAST, but today I am happy to release version 0.7, which is one of the largest changes to date. This is the result of substantial effort to ensure that YAWAST continues to be useful in the future, and add as much value as possible to those performing security testing of web applications. If you are using the Gem version, simply run gem update yawast to get the latest version.

Developers: Placing Trust in Strangers

Much has been said, especially recently, about that mess of dependencies that modern applications have – and for those of us working in application security, there is good reason to be concerned about how these dependencies are being handled. While working on YAWAST, I was adding a new feature, and as a result, I needed a new dependency – ssllabs.rb. While most Ruby dependencies are delivered via Gems, ssllabs.rb is a little different – it pulls directly from Github:

Hash Storage: Make Attackers Work

So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack? I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.

Snapchat: API & Security

Update 3: In 2014 the FTC filed a complaint against Snapchat for their failure to provide the level of security they promised. The findings listed below were sent to the founders of Snapchat, that email was quoted in the FTC compliant as proof that Snapchat was aware of these issues. Update 2: The Snapchat API has changed to address the issues I pointed out to them – and the new API has issues as well.

MiniPwner

I recently finished building my first MiniPwner – a tiny OpenWrt-based system for pen-testing. At only 2.25 x 2.25 inches, the device plus battery is still extremely small – it easily fits in a pocket, and could be hidden anywhere. The device is based on the TP-LINK TL-WR703N, which uses a 400Mhz Atheros AR7240 CPU – not exactly a power-house, but enough power for standard pen-testing (or even just as a super-portable linux box).