@hichris123: if I understand the heartbeat bug properly, it gives you a random piece of data
so if you know you're looking for a specific bit of data, you'd just hit the server a lot of times, and match bits that overlap. Its slightly easier than trying to get lots of random data and putting it together
Don't get me wrong here. Its scary, but I rather doubt anyone but the most determined adversery can get usable data. Its a little like taping together shredded paper out of a dumpster.
it all depends on how long adversaries have had knowledge of this bug, and whether they've been exploiting it to get private keys... if they've had private keys to many services for a long time, their next step is to MITM either users or the service itself, and they can effectively use Firesheep (not quite that simple, but darn simple) on https connections
still, executing MITM is not always easy. it also depends on how well the transport layer is protected, and what type of medium the endpoints are using
this is why unencrypted wifi at a coffee shop is never a good idea
it's about half the length of a car key and about half as thick as a standard full-size USB-A male connector
hard plastic construction, seems sturdy. it does NFC perfectly to my phone, and USB perfectly to my computer
via USB, you plug it in; it gets recognized as a "USB keyboard" (standard HID-compliant); then you touch a metallic circle on the unit with your fingertip and it "types" your second factor authentication in a Yubikey field (the field has to have focus first obviously).
via NFC, it can be a substitute for Google Authenticator (supporting anything Google Authenticator supports), or you can use it for apps that "natively" support the Yubikey, like Lastpass
for me I'm mainly using it to protect my Lastpass account... to sign into it on my phone, I type my LastPass password (which is complex but not very long), then touch the Yubikey to the back of the phone for a split-second, and I'm in
my phone is using Android's NAND encryption now too so things are looking pretty secure
2-factor enabled for Google, Microsoft, Lastpass and Github accounts
I know which is the reason I use it. The only thing I wish was it had better session support. I have configured Firefox to load the same session every single time which was easy. After Chrome failed to recover sessions I had to use an extension to handle it. IE is the only problem child. It likes to lose the "last browsing session" at times. There are also times an entirely different session will be started if say a program launched IE
Make sure "restore tabs from last session" is set in Tools -> Internet Options.. I don't recall that being there before, maybe it wiped your settings in an update
So I recently installed the Spring Update ( the day it was released ) on my Windows 8.1 installation. This feature was working last Saturday today I noticed that it wasn't.
The first thing I attempted to do was toggle the feature on and off. As you can see the feature is indeed enabled.
So h...
@Bob the point is, even if someone knew my LastPass password, it would be useless for obtaining my passwords (even with physical access to the LastPass databases) without coming to my house and stealing my YubiKey.
the YubiKey token is used as part of the decryption sequence for the password vault (along with the master password).
not even a deliberately evil LastPass employee could exfiltrate my passwords, unless they modified the LastPass client to send the data in the clear, but unless you compile KeePass from source and scrutinize every line of code within it and all its dependencies, you take the same risk with a local password vault.
but from the server side, there is nothing a LastPass employee could do to steal my passwords unless they come here and take my YubiKey
@Ramhound where was the information stored? The issue (aparently) has been around for a long time. answers.microsoft.com/en-us/ie/forum/ie10-windows_8/… Here we get pages of people dicussing it, but a Bare mention of the storage location for the information?
usually with LastPass I deliberately wait a few days to see if they're going to send me an email saying "whoops, an insider pushed a client update that sends your data in the clear; sorry"
@Bob it's a browser extension; that's where the real "vulnerability" lies; it's a piece of a program running on your system with user trust (gee, just like any other electronic password vault)
""At least I didn't have to resort to trying to use %LocalAppData%\Microsoft\Internet Explorer\Recovery
although I was contemplating trying that option before I found where my Checkpoint Favorites subfolder had been saved. Have you tried looking at that option? "" Checkpoint favorites?? whaaa
basically LastPass is about as secure as having a paper-based card file with your passwords written on them... someone with physical access to your YubiKey can probably gain access, but physical access is a lot less likely IMO than remote attackers, since the remote method is harder to trace, carries lower risk for the attacker, and can be done en-masse
it's as secure as a paper-based card file exactly because a program running with user trust that's malicious can trivially exfiltrate any password you type in via the keyboard, and any malicious or compromised password vault can do the same thing, so they're equivalent risk from a security perspective
the important thing is to make sure you never run any malicious programs with user trust, period... because if you do, all bets are off, no matter how you keep track of your passwords
@allquixotic - Aye; The extension client side decrypts the information and places it in your buffer and/or fills the form for you.
Which if properly configured is once an hour.
Alright so C:\Users\Jason\AppData\Local\Microsoft\Internet Explorer\Recovery\Last Active has files that were created today 17 minutes ago when I last tried it
Oh and "grayed reopen last session" happens all the time. But that's not what is going on here.
@Bob it's not that hard to foresee a situation where keepass has some malicious code that executes a privilege escalation attack; opens the firewall as far as it needs it; then proceeds to send your passwords
there are so many input vectors for a clientside program that can execute arbitrary instructions on your CPU, even in usermode on a non-administrator account, that it's foolhardy to think that you're at all secure in the presence of malicious code running under that context
@allquixotic That's assuming that a. a priv escalation attack exists and is not discovered for a very very long time (discovery would destroy their reputation) and b. all firewalls behave the same and can be bypassed with the same method.
It's not secure by any means - but it's less likely to leak anything.
LP just needs a vuln in the encryption, and your data is already stored on their servers.
@Bob the only firewall it really needs to worry about, on Windows, is the Windows Firewall that would be blocking specifically the keypass program -- because chances are you're not going to block port 80 outbound, so it can do its exfiltration over that port... hardware firewalls don't block specific programs
@Bob on Win7 and later, 99% of all firewall "programs" are just nice GUI wrappers around the Windows Advanced Firewall, much like there are tons of wrappers around iptables on Linux
@Bob there's no way KeePass could be worse from a theoretical perspective, true, but the once-in-a-decade vuln that directly impacted LastPass (since they used OpenSSL on their authentication servers) did not result in any customer data loss or account theft
even if someone used Heartbleed on Lastpass, all it'd enable them to do is successfully fool you in a MITM... so now, good luck MITMing people who aren't using public unencrypted wifi hotspots
I don't suppose you already tested by opening the most benign tiny addresses , like Yahoo.com (and not 2 pages of referance linkage) and some other simple stuff to see if it is a storing the data problem? Todays links are like (as one person said it) "Can they store the whole Web Site in them" :-)
According to the wiki the OpenSSL was abandoned by its makers back in 1998 :-) and the vulnerability has existed for about 2 years. This seems like a tech version of Opera wears White shoes in april.
basically the exploit finders detected that a door was hanging wide open to a room full of gold and treasure chests and diamonds and rubies, and they said "you might also be able to find a really gigantic diamond in there"
and the cloudflare challenge was "go find the big freaking diamond"
vulnerability was disclosed -> cloudflare thinks "don't worry guys, they can't actually steal any private keys, that's just theoretical" -> challenge breakers say "nope, it's totally real dudes"
@Ramhound and if they've known about it for a long time, they could have generated billions of requests attempting to exploit during the ~2 years time it was out
@Ramhound it actually has broader support for a wider array of algorithms, on more architectures, than pretty much anything else -- the performance is also very very good -- it's not trash, it's just that the programmers don't perform proper verification that the code is secure
it needs a larger, more active development team that consists of security-conscious developers who spend much of their time just auditing existing code
and it needs companies like Google to spend a lot of time looking at it
Let me rephrase my statement. The code works but its written using non-standard best methods. Seriously who doesn't check the length of the data before doing anything with it?
It is probably just a scam because the US government doesnt have a backdoor pass to the encryption, so they want people to quit using it :-) Ok so admit it if the government offered you 1.5mill for you to add a single code item to your programming to thwart terrorism and mafia and baby killing, would you turn em down?
@Ramhound the code hasn't been "known to be like that for a while" by the good guys (the people looking at the code trying to find vulnerabilities and fix them)
what happened is that Google and Codenomicon found the vulnerability. they reported it to the OpenSSL project and to large stakeholder companies that have a huge SSL attack surface. privately. to give them a chance to prepare for the backlash and fix their systems
otherwise on release day, script kiddies who read the news would see the article disclosing it and start exploiting every major site out there
@Bob actually, doesn't NSS just implement what's required for TLS? OpenSSL does pretty much all kinds of encryption; NSS does what's required for SSL/TLS only
if they wait and privately notify corps and big services to fix their stuff, and wait a very long time, small time folks will complain "well WE weren't notified, so you made us wait longer and have longer exposure time!"
if they release it immediately upon discovery without notifying anyone privately first, all the big corps get up in arms that their services are now being massively exploited and they had no chance to mitigate it
@Bob true, not disputing that, just saying, some people (rightly or wrongly) are going to bitch no matter whether they wait 1 second, 1 hour, 1 day, or 1 year between the time of discovery and the time of public disclosure
also, the simplicity of this vulnerability made PoC code pretty much inevitable as a result of disclosing the nature of the vuln, so they couldn't have done anything to help people patch or mitigate it without giving away the essential data needed to develop an attack
@allquixotic What I want to question is why Cloudflare, Amazon, etc., were notified but RHEL, Debian, etc., took hours after public disclosure to come out with a patch.
@Ramhound it was discovered independently by two separate people (actually, one individual, and a separate team of 3 people), all of whose day job is basically "find exploits in common software and responsibly report the vulnerabilities so they can be fixed"
@allquixotic If i had a job of breaking into people houses and cars, my guess would be there wouldnt be very many that it could not be done easily after a while.
> NCSC-FI took up the task of reaching out to the authors of OpenSSL, software, operating system and appliance vendors, which were potentially affected. However, this vulnerability was found and details released independently by others before this work was completed.
@Ramhound the vulnerability was introduced by accident into the OpenSSL codebase in late 2011. that means that, presumably, at the point it was introduced, 0 people knew about it. then, until some unknown time in 2014, the vulnerability was "in the wild", and "the Good Guys" didn't know about it, but there's a non-zero probability that "a Bad Guy" found out about it first, didn't report it, and exploited it (against Google et al)
basically, because it is impossible for anyone to know whether there are any malicious actors out there who discovered and used this vulnerability some time after it was released but before it was fixed/patched, that's the reason why you're being told to reset your passwords
@Bob some people just can't keep their mouth shut. anyone who's trusted to receive and responsibly handle such a huge piece of information should have the moral courage to resist spilling the beans until everyone is ready
@Bob they might have been the first visible public release, but perhaps on some hacker's forum somewhere it was leaked to a small group of mixed white and black hats, at which point it's irresponsible not to spill the beans to the public at large and get the fixing started
Which is the reason people saying NSA might have known about is so ridiculous. if they had known about it, then that would mean our own infrastructure was vulnerable.
I think, if NSA knew about it first, they would've patched it in their own systems and their allies' systems (FBI, Secret Service, GCHQ, etc), and not told the public, and exploited the hell out of it for a month or so hitting China and Russia as much as possible, THEN notified the OpenSSL project and companies and distros, THEN the public
@ekaj estimates range between 50% and 70% of web servers. plus there are other services that tunnel through OpenSSL that don't serve HTTP traffic, but those are much less likely to be targeted
With the vuln, they can potentially intercept traffic as much as they like.
They're in the best position to be a MITM attacker.
Remember: this vulnerability generally does not affect the server itself.
It risks the leak of the private key and anything else in webserver memory (e.g. passwords, request and response data, etc.). Or in client (web browser) memory.
I am saying there is a ton of infrastructure that if the NSA had known it would have been stupid not to get patched but this problem went unpatched until it was discovered. I am just thinking of all the possible military clients that might be effected
I cleared out the "Active" folder from ..\Recovery\
and it started to work again :$
What I Actually did was cleared it out, the use the "Last Active" contents. This resulted in what appears to RecoverStore files and a bunch of DAT files.
Anyone have advice on how to tell somebody who knows nothing about computers how to tell the difference between an actually notification window and an image within an instance of IE of a notification window?
They got upset when I picked up my shoe and ask "how do you know this is an actual shoe and not a picture of a shoe" :-(
When in doubt, Throw it out. The passive "spywareblaster" blocking activex and crapsites, can limit the occurances of that stuff without any other changes.
So I recently installed the Spring Update ( the day it was released ) on my Windows 8.1 installation. This feature was working last Saturday today I noticed that it wasn't.
The first thing I attempted to do was toggle the feature on and off. As you can see the feature is indeed enabled.
So h...
