Kitz Forum
Computer Software => Security => Topic started by: Berrick on April 08, 2014, 05:58:34 PM
-
Hot on the tail of security flaws with GnuTLS (http://forum.kitz.co.uk/index.php?topic=13660.0 (http://forum.kitz.co.uk/index.php?topic=13660.0)) comes a potentially more serious flaw with OpenSSL effecting many Linux distro's. Read about it here http://heartbleed.com/ (http://heartbleed.com/).
List of known OpenSSL vulnerabilities here http://www.openssl.org/news/vulnerabilities.html (http://www.openssl.org/news/vulnerabilities.html)
There is a site to test if you are effected here http://possible.lv/tools/hb/ (http://possible.lv/tools/hb/) OR
If you're running any of these versions 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1, you are likely affected by this vulnerability
This should work to check your OpenSSL version with this command. OpenSSL version -a
-
I heard about it a day ago and there is a fix available now although in most distros you need to install it manually as it's not in the repos yet.
Stuart
BTW the command on Fedora has to be lower case!
-
Trouble with bugs like this is you can update your home system to your heart's content and still remain vulnerable.
The distinction is (correct me if I'm wrong anybody) that it affects the servers too. So if you are connecting to a secure Linux based server operated by, say, a social network, an email host, or a bank, then it is the server that needs to be updated otherwise your data may leak to an attacker.
And by above reasoning, even windows users are vulnerable if (say) their bank uses an affected server. :(
-
The distinction is (correct me if I'm wrong anybody) that it affects the servers too.
Im with you on that 7LM, in fact anyone exploiting this type of bug would likely only target servers.
I cant imagine many home users running SSL. SSL is only really needed for websites that operate financial or similar sensitive type transactions or personal information, such as banks or online stores, which in turn are most likely to use Linux.
-
I cant imagine many home users running SSL
What about those who use SSL VPN (OpenVPN)? kinda brings a whole new meaning to OPEN ;)
-
I just found the fixes for this are available now for Fedora from the repos.
Stuart
-
Slackware fixed too: 2014-04-08 - [slackware-security] openssl (SSA:2014-098-01)
Cheers,
Peter
Added: Just tried the tester here: https://www.ssllabs.com/ssltest/index.html with several of my online banks.
Most came out with a B or A- rating. But one came out with an F rating.
I have contacted the bank pointing this out, and telling them a major competitor gets a B rating.
But I'm left wondering how realistic the tests are, and does this low rating mean that I am really exposed.
Or is it just theoretical stuff that doesn't mean anything in the real world.
PPS - just noticed on the ssllabs website that ebay.co.uk is rated F - which seems to be the lowest rating.
-
But I'm left wondering how realistic the tests are, and does this low rating mean that I am really exposed.
It is interesting test but try as I may, none that I could think of appear to be vulnerable to this new heartbleed issue. As you say, ebay scores poorly, but even then it's not vulnerable to heartbleed. So it appears there is no reason to be any more concerned today than a week ago. :)
The banking (etc) sites that worry me the most are the ones that simply encourage bad habits. Nat Savings for example, I recently discovered, have very strict password requirements... it must be case mixed, mixed alpha & numeric, and must contain at least one punctuation mark, and contain no less than 6 , no more than 8 characters.
Somebody probably advised NS&I thatbsuch passwords are difficult to hack, and they thought that meant 'secure'. But IMHO 99% of people will have to make a written note of such a password in which case it doesn't require an SSL vulnerability, all it takes is a casual house burglar who finds your password book. :(
-
reminds me when at work many years ago I had an ultra secure long password
Then along come the smart arrses who implemented a rule it must be changed every xx days.
So my passwords became 'Monday', 'Tuesday', 'Wednesday' etc to be endlessly rotated.
I recall the next stage was that they had to have a number in them
so I think I then used Monday1, Monday2, Monday3,
Basically I didn't give a toss.....
-
(OpenVPN)? kinda brings a whole new meaning to OPEN ;)
heh - doesnt it just :D
-
Then along come the smart arrses who implemented a rule it must be changed every xx days
Password policies are a difficult one and comes down to acceptance of risk, you have to find a balance. IF you make them to difficult people just write them down (as others have mentioned) and IMHO if that happens you might as well not have a password. But no matter how easy you make it for users to have very secure access people still don't follow process.
eg. We implemented a very complex password policy which would have made it impossible for the password to be guessed. It also made it un usable for us humans. So we issued smart cards to all the people that needed one and installed keyboards that required the user to put the card into. If the card was removed the user was logged out. All the user had to do was input a pin number of their choosing and follow company policy which stated when they were away from their desk they took the card with them. Failure to follow process was on pain of death and people still left the cards inserted ???.
I wonder if these same people would leave their atm card in the atm :lol:
-
I think the bank password strategy is more about liability shift than anything else.
By enforcing a policy of 'unhackable' passwords they can claim to be making best efforts. The fact you'll probably have to write it down is not their problem. They may even tell you not to do so, even though they know you will.
And if you then write the password down, especially if they told you not to, I suspect they could claim you are to blame if anything goes wrong. I don't know if they have ever done so but, in the event of a catastrophic drain of funds caused by something such as this 'heartbleed', I suspect they could use it to save their skins bonuses.
-
Fortunately both the financial institutions I have dealings with have issued the small calculator type devices which I have to put my debit card into to generate a pass code so capturing this data makes it much less likely they will be able to use this to hack in. Sadly the do not enforce the use of this and still allow anyone to use with their original login credentials which is stupid in my view.
Stuart
-
Banks balance risk and cost against ease of use so providing they cant prove you are grossly negligent will generally accept the loss.
It may interest ppl to know that easycard are pushing out new systems to online shops where you don't re iterate the long card number and security code on the back to the sales person. You enter it via the keypad on the phone. Easycard claim it is 100% safe?
-
Not sure of my facts, but I'm coming around to the idea that home users (SSL clients) are at risk too, as the client software apparently contains the bug as well as server-side
The attack mechanism would presumably be as follows…
1) You connect to a legit SSL server, such as your bank
2) You then connect to a malicious site that happens to use SSL, or even a legit one that's already been compromised.
3) Since the malicious system can execute the broken SSL code on your system it is able to run the exploit which, I believe, is to get memory snapshots of your system, which may contain all sorts of things like passwords and keys.
I understand it affects some Android phones too, BTW.
-
Then along come the smart arrses who implemented a rule it must be changed every xx days
Password policies are a difficult one and comes down to acceptance of risk, you have to find a balance. IF you make them to difficult people just write them down (as others have mentioned) and IMHO if that happens you might as well not have a password. But no matter how easy you make it for users to have very secure access people still don't follow process.
eg. We implemented a very complex password policy which would have made it impossible for the password to be guessed. It also made it un usable for us humans. So we issued smart cards to all the people that needed one and installed keyboards that required the user to put the card into. If the card was removed the user was logged out. All the user had to do was input a pin number of their choosing and follow company policy which stated when they were away from their desk they took the card with them. Failure to follow process was on pain of death and people still left the cards inserted ???.
I wonder if these same people would leave their atm card in the atm :lol:
very good point, this is why policies such as forcing password changes every 30 days, blocking browser's caching passwords is counter productive. If you changing password every 30 days you be hard pressed to find something memorable every time, in addition every site on the internet wants you to register if you want to post, someone got a blog you want to comment on? register, comment on news article? register, before you know it you registered on 100 sites and if following reccomended pratice to never use same password twice then of course you have 100 or so passwords to remember, not going to happen. So people put them in notepad, write it down whatever. To me a solution is use something like keeppass to store them encrypted.
-
To me a solution is use something like keeppass to store them encrypted.
I've been using PasswordSafe for some years now, which has the nice feature that it runs on both Windows and Linux.
http://passwordsafe.sourceforge.net/
Cheers,
Peter
-
I use KeepassX (also Windows and Linux), which I believe started life as a Linux port of Password Safe.
-
interesting roseway it does indeed look very similiar to the normal keepass.
-
I myself use Lastpass.
You can test your security there and see which if any sites needs your security updating
https://lastpass.com/
-
7LM: Not sure of my facts, but I'm coming around to the idea that home users (SSL clients) are at risk too, as the client software apparently contains the bug as well as server-side
Just to confirm 7LM's suspicion. Information from AstLinux site
Keep in mind this "heartbleed" issue isn't limited to servers, it affects clients and desktop machines as well, perform your due diligence to eliminate any risk associated with this serious vulnerability
My concerns have turned to verifing which routers, modile phones and embedded devices (wireless printers etc etc) are effected. For example
- Smartphones and tablets running Android 4.1.1 Jelly Bean are effected
- Windows PCs, Macs, most Linux desktop and laptop machines are not effected
This site has some interesting info and advice which others my find useful http://www.tomsguide.com/us/heartbleed-bug-to-do-list,news-18588.html (http://www.tomsguide.com/us/heartbleed-bug-to-do-list,news-18588.html)
-
I notice Talktalk is listed as vulnerable.
BT not vulnerable.
sky is saying no SSL but unsure about that.
https://github.com/musalbas/heartbleed-masstest/blob/master/top10000.txt
An up to date check shows TT have now patched their systems and are issuing this statement
http://help2.talktalk.co.uk/heartblead-bug-%E2%80%93-changing-passwords
-
Ive read Sky, Talk Talk and Virgin all say they are not vulnerable but I dont believe them because if they were they would not admit it in case it caused a drop in sales... Cisco and Juniper have come forward and said some of their equipment is affected
this is what I got from Netgear about my router....hmmm
The NETGEAR Routers will not be affected by the heartbleed bug since it only affects SSL protocol and our routers are using http.
there are a few testers for websites but they cant give clear answers... my own website hosts says they have patched it but how can I be sure?
-
you can check their url's on one of the sites that are providing free tests. Of course they may have already patched.
-
there are loads of testing websites all of which seem to give odd or differing answers, i got the all clear on my website:
http://filippo.io/Heartbleed/#defiant.servers.eqx.misp.co.uk
- also as I say Talk Talk were one of the ISPs to say they were unaffected but now they are saying they were but have patched it and are asking all customers to change passwords....Iam with Sky...god knows where they stand in reality with it...regardless of them 'officially' "being unaffected"
also.. Netgears answer about my router seems to be a bit "fob off" too me>? or am i wrong? Netgears routers arent affected because they use HTTPS...and not SSL... can this be true?
-
this is what I got from Netgear about my router....hmmm
The NETGEAR Routers will not be affected by the heartbleed bug since it only affects SSL protocol and our routers are using http.
Which router do you have? The only entities to be affected would be SSL servers and SSL clients. Your netgear router is probably neither of these. Traffic passing through most home routers router, say from your PC to your bank, might or might not be affected, but the router would be irrelevant.
If you have a more advanced router that implements supposedly secure VPN access so that remote users can access your your home PCs, such a router might be an issue.
The parodoxical response or me, is google. In all statements I have seen the seem to say that their servers were affected, but that users do not need to take action. I can only assume they feel, as the bug was exposed by a google researcher, that they were able to block it before the news broke?
Biggest worry for me though will be the loads and loads of embedded devices. Everything from your media DVD player to your electric toothbrush these days may be running Linux and, if it has any need for secure comms, using openssl. How the heck are they ever going to sort it all out?
-
Netgears routers arent affected because they use HTTPS...and not SSL
If they dont use https then they 'shouldnt' be affected.
The reason I went hmmm for Sky and said that I was unsure, is that they use https. Suppose it depends if their servers run on windows or linux.
Windows servers are supposedly unaffected, which is why some banks systems have remained unaffected.
-
- also as I say Talk Talk were one of the ISPs to say they were unaffected but now they are saying they were but have patched it and are asking all customers to change passwords....Iam with Sky...god knows where they stand in reality with it...regardless of them 'officially' "being unaffected"
I think the bit in bold says it all really
Rest assured no customer data has been reported compromised and we’ve secured all our servers and websites
ie they dont know.
-
I'd been coming around to the idea that Open Source software needs to be better scrutinised, but interesting and opposing comments in The Guardian,
http://www.theguardian.com/commentisfree/2014/apr/10/stop-next-heartbleed-bug-open-source-support-open-ssl
in particular...
some future Edward Snowden will have to tell us whether the NSA found the Heartbleed flaw before researchers at Google
Now there's a cheery thought :o :o
And of course, just like public/private key cryptography in the first place, it'll turn out that GCHQ has known about it longer than anybody. ???
-
- also as I say Talk Talk were one of the ISPs to say they were unaffected but now they are saying they were but have patched it and are asking all customers to change passwords....Iam with Sky...god knows where they stand in reality with it...regardless of them 'officially' "being unaffected"
I think the bit in bold says it all really
Rest assured no customer data has been reported compromised and we’ve secured all our servers and websites
ie they dont know.
I was angling at more them denying being affected...then later saying they were but then patched it...
my router does have remote management facilities...so am I right in saying it then has some form of SSL library?
I dont use it..but WAS thinking about it not long ago for accessing it from work for e.g.
edit: actually when I look at that page the URL is HTTPS so guess its fine
Now I just need to be sure Sky's servers arent affected.
-
I'd been coming around to the idea that Open Source software needs to be better scrutinised
By definition, open source software is fully open to scrutiny at all times. That's something you can't say about closed source software. The open source world isn't perfect (nothing is) but I know what I prefer to trust.
-
>> I was angling at more them denying being affected...then later saying they were but then patched it...
yup I got what you meant :)
I also found that statement I emboldened very cleverly worded and covers a multitude of sins.
If you read it carefully what its saying is Nobody has yet owned up to compromising our systems, but thats not to say it hasnt been...
...otherwise they would have said 'No customer data has been compromised".
-
I'd been coming around to the idea that Open Source software needs to be better scrutinised
By definition, open source software is fully open to scrutiny at all times. That's something you can't say about closed source software. The open source world isn't perfect (nothing is) but I know what I prefer to trust.
Exactly. Mistakes happen, and bugs occur even in the best written software. What is surprising is how long this has been undiscovered ???
-
I'd been coming around to the idea that Open Source software needs to be better scrutinised
By definition, open source software is fully open to scrutiny at all times. That's something you can't say about closed source software. The open source world isn't perfect (nothing is) but I know what I prefer to trust.
I'm sorry but I can't agree.
In the commercial environment the programmers chosen to work on sensitive and secure software would be selected based on experience and track record. They would also most likely be subject to the most stringent security vetting before being allowed to work on the project, and any changes they make would be subject to fully audited code inspection and high-level management signoff.
Mistakes may still happen, but they are perhaps less likely?
-
I'd been coming around to the idea that Open Source software needs to be better scrutinised
By definition, open source software is fully open to scrutiny at all times. That's something you can't say about closed source software. The open source world isn't perfect (nothing is) but I know what I prefer to trust.
I'm sorry but I can't agree.
In the commercial environment the programmers chosen to work on sensitive and secure software would be selected based on experience and track record. They would also most likely be subject to the most stringent security vetting before being allowed to work on the project, and any changes they make would be subject to fully audited code inspection and high-level management signoff.
Mistakes may still happen, but they are perhaps less likely?
compare number of disclosed vulns on openssl to eg. windows.
-
compare number of disclosed vulns on openssl to eg. windows.
There have been none to my knowledge that remotely compare to heartbleed. :)
Bur it is an unfair comparsison to the programmers too. In the commercial world if one made a mistake, one simply accepted a poor annual review and moved on. The employer took the flak. But I have already seen websites naming the individual who wrote this bug. And that's definitely not fair. The guy's probably a lot cleverer than I ever was, yet here he is in the world headlines, just cos of one little slip up... :(
-
The point about closed source software is that we just don't know what happens behind the closed doors. We have no idea how many times vulnerabilities and bugs have been discovered and quietly fixed without the world knowing, nor do we know how long it took to discover and fix them. The commercial companies aren't going to tell us, for fear of being sued for consequent damages. And we can be sure that there are bugs still lurking which haven't yet been discovered.
By contrast, open source issues happen in the open. There are no secrets. When bugs are discovered, the world knows in a flash, and the issues get fixed very quickly. Open source works by an informal process of peer review, which may seem haphazard, but is far more satisfactory than the reliance on goodwill and good practice in commercial companies.
The seriousness of the heartbleed issue is of course in the fact that it took so long to be discovered. But that, together with the fact that there are no publicly known instances of its ever being exploited, means that it must be quite obscure. There are lots more obscure bugs out there, in both open source and closed source software. It's an imperfect world.
-
I have to agree with Eric.
Open source is most likely more secure then close source software. Because it is "open" more eyes get to see the source and contribute or spot mistakes which can be corrected.
-
I agree with Eric on open source.
I think one thing which is probably misunderstood by the public at large is that there is really no such thing as an error or bug in the actual code created. The problem is that the code executes exactly as the writer coded it, the problem happens at the design stage where not all possibilities of using the software have been considered and actually it is unlikely you could ever do this. This is why you will always find problems when software is rolled out - there is nothing like millions of users running the software to find problems. So no matter how much peer review or any other kind of review is carried out prior to software being released I contend you will never find ALL the potential design flaws, and somebody somewhere is likely to find one. This applies as much to commercial closed source as it does to open source. The person who designs/codes flaw free software has not been born yet! Neither has the reviewer who finds all the flaws!!
Stuart
-
It would appear then that I am outnumbered on this one. :-[
I could argue that whatever the perceived benefits of Open Source may be, it has now been demonstrated that they can do still lead to howling security bloomers, and arguably one of biggest bloomers of all time. And, with that evidence in mind, the suitability of using Open Source for 'secure' products ought to be reassessed.
But I'm outnumbered and so instead of arguing the case above, I will pipe down now. :P
-
It would appear then that I am outnumbered on this one. :-[
I could argue that whatever the perceived benefits of Open Source may be, it has now been demonstrated that they can do still lead to howling security bloomers, and arguably one of biggest bloomers of all time. And, with that evidence in mind, the suitability of using Open Source for 'secure' products ought to be reassessed.
But I'm outnumbered and so instead of arguing the case above, I will pipe down now. :P
I think the point here is that I dont believe that commercial software is any more immune to this kind of error than the open source community. They are both exposed in exactly the same way.
I dont think this is one of the biggest bloomers of all time, certainly a serious issue but there have been others just as big but have not caught the public eye in the same way.
What I do think is that in general the open source community is more 'open' to admitting their problems and fixing them in a fast and effective way. In commercial software this kind of issue would be covered up if at all possible for financial reasons and it is far more likely that a new paid for version would appear which said that it just fixed some security issues without ever admitting what those issues were of their effect was, IF they could get away with it.
Stuart
-
Am I right in saying that with Open Source (while I agree its good) it makes it available to hackers with ease to probe and find ways in...where as closed source requires some knowledge/skill/experience in being able to "reverse engineer" the software to "find ways in"?
-
I can't really answer that question, as I know nothing about how people discover vulnerabilities in software. Certainly you can decompile or disassemble software to make it more human-readable. But I rather doubt that the vulnerabilities are discovered by poring over the source code; I think it's far more likely that they hit the software with various attacks and see what pops out.
-
Having spent most of my working life fixing bugs in commercial software where I did have the source code I can say that even when you know the issue and have the source it is often still time consuming and difficult to fix problems, so yes it is unlikely hackers use source code to find problems, as Eric suggests it is far more likely that they try brute force methods and see what pops out.
Stuart
-
...but i would imagine it would be easier if you knew how it was constructed (open source) - im no programmer (I know the fundamentals, I used to program basic in my teens) but I imagine that it would be easier to 'break in' if you had access too "blue-prints" (if you will) than it would if you didn't have them?
-
...but i would imagine it would be easier if you knew how it was constructed (open source) - im no programmer (I know the fundamentals, I used to program basic in my teens) but I imagine that it would be easier to 'break in' if you had access too "blue-prints" (if you will) than it would if you didn't have them?
The problem is that even with the source code you dont always know the way the various modules interact, and even when you have the original design plan it does not always mean that the programmer followed the plan! There are always examples of where it happens but in my view these are few and very far between. In most cases you have to have any idea of how one might break in before you can tell from the code, and it is usually easier to try the exploit first rather than sit and browse code.
Stuart