Hacker Newsnew | past | comments | ask | show | jobs | submit | thekos's commentslogin

LastPass does actually know URLs. After logging into LastPass.com, you can navigate to https://lastpass.com/getaccts.php (only accessible post authentication with a valid session cookie.)

This will return an XML document with your vault data. Most of it is encrypted, however an URL parameter is encoded as hex, in plaintext. I am able to look at all URL. They could be storing the blog fully encrypted in a server datastore, but at some point, the LastPass servers are handing the client non-encrypted URLs.


Taviso has been on a rampage.


Yeah I forgot to mention Sophos. I'm glad we have him.


Don't forget FireEye



Thanks! I knew I read about that years and years ago but wasn't sure if it was still true.


You can go back further by modifying the startTime parameter in the download link.

https://maps.google.com/locationhistory/b/0/kml?startTime=14...



This works also, and doesn't require a hosted file: https://xss-game.appspot.com/level6/frame#data:text/plain,al...


SSH tunneling, of course!

But seriously, the github wiki says that it uses SSL also.



They are claiming, over their twitter account, that the email was faked:

https://twitter.com/purevpn/status/386700121053736963


Guys, email tht u received is a fake. v r NOT closing down nor hav ANY legal issue of ANY sort.

Wow. I seriously would not pay any money to a company that communicates like that.


So, compromised instead... Seems I am not the only one thinking this.

https://mobile.twitter.com/TeamAndIRC/status/386703066285633...

Especially if only account owners have been mailed (which I am not, BTW). And what is up with the unprofessional response on twitter: V r ?


Oh man, come on!

I know Twitters can be hard to read but that is just unprofessional.

It looks like a kid wrote it.



From the #linode IRC channel, caker (CEO) states it was a segfault in bind.

13:53:14 caker@ : They operate completely independently, other than loading from the same zones. This looks to be a segfault in bind itself


Isn't having two independent name-servers supposed to prevent this kind of thing?


Appears that it cascaded across all of their nameservers. Seems like it could be an attack (remote or local DoS condition bug, since all users can create their own zones), or maybe just a random bug - hopefully they'll update us.


Weird!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: