[Closed] Singletrack vulnerable to heartbleed

*reported*

[edit] is this spam? Or just odd.

Thank you for bringing this to our attention. We have patched our SSL and all indications are that we are not vulnerable to this bug. In the future, PLEASE send concerns to security@ singletrackworld.com or tech@
Thanks.

Really, genuinely, not what I was expecting of this thread.

Awesome! I thought this was a cutting post about the "bleeding hearts" on here, but it's actually a real network vulnerability. (I think) 😀

Apologies for the alerting you to this via the forum. As far as I can see you are correctly patched now.
I assume you are considering whether to recommend that everyone changes their passwords. Does your credit card validation run through a seperate server and was it also compromised for a while.?

Sinister poster freaks everyone out?

Or a Trollist?

Eitherway..

I..B...T....

Was hoping for an advert for a singles ride. Scuttles off...

Alas chaps, this is a valid and genuine concern across the internet right now. In fact, I've spent the last 24 hours doing seemingly nothing else but dealing with the fallout from this wonderful finding...

Still, it pays the bills.

Yes, quite a bug. We do not process credit cards or bank details on our servers, so they will not have been exposed. We also limit other data stored on them. It is possible that passwords entered over the last day may have been exposed. We recommend regularly changing your password, and not using the same password on this site as you do on others.

On the plus side, thanks to the publicity it has gotten in the last few days, it seems that the fixes are rolling out very quickly as everyone is ensuring they are patched.
Even those that are taking a little longer to patch the bug seem to have taken the sensible precaution to simply disable the feature that is exploited in order to minimise risk while they patch and get recertified.

It should be pointed out that the recertification part is important here as the bug allows anyone who gains access to the server to get hold of your private key and therefore they can access the secure data even after the patch is applied unless a key is generated and a new certificate issued.

If I'm reading this right (and not just this page and links) we should be looking at revoking certificates and reissuing as well as patching, on a risjk assessed basis? Is that what others here are looking at too? As you can't be sure what has already been compromised.. if 'they' have the keys patching alone isn't sufficient to prevent reading the encrypted content.

EDIT: LoL, cross over of posts 🙂

Exactly right. If you have been compromised while unpatched then it's literally like having your house broken into and your keys stolen, getting the broken window fixed but not changing the locks.!

On the plus side, thanks to the publicity it has gotten in the last few days, it seems that the fixes are rolling out very quickly as everyone is ensuring they are patched.

I think this has had remarkably little publicity for such a serious vulnerability, I only heard about it last night.

The vulnerability only became public knowledge on the 7th April.

In that case, oh balls. Bit of work to do then..

What I do find concerning is that so far there has been little to no rollout of information to potentially compromised customers with advice on changing passwords/login details and c/card details that may have been compromised.
I'd also been a bit concerned about how many 'less well informed' admins are simply patching the error without having their private key re-generated and a certifaicate reissue. As always in these cases it's a battle between customers who want all the information so they can decide how far they need to go in securing themselves and the business that does not want to appear 'unsecure' by issuing a blanket 'we may have been compromised and given away all your data' notice to all their customers.

I mean to put the severity of this in perspective, the people who administer the TOR network are recommending not using the Internet AT ALL until the fixes have been rolled out across the network. Now they are highly security conscious and therefore likely to err on the side of extreme caution in these cases, but that gives you an idea of how potentially serious this is.
Any compromised site has NO WAY of knowing what data they may have given up or how many people have taken it..

How are paypal fairing in this? (fingers crossed it's [i]probably[/i] the only one I need to worry about)

[url= http://filippo.io/Heartbleed/#paypal.com ]Seems ok[/url]

Paypal seems to be patched. No way of knowing if they were compromised in the past. With them I would highly recommend enabling their 2 factor authentication for your login as a way of further securing your account. I'd actually recommend enabling 2 factor authentication whenever you can. I know that Google, Dropbox, Apple, Paypal and Microsoft offer it on their accounts, there are likely more but you'd have to check with accounts that you have.

Aye, two-factor auth makes a lot of sense in any sort of internet facing deployment.

Paypal seems to be patched. No way of knowing if they were compromised in the past.

The tricky thing with this problem is that there is no real way of knowing just how long the 'crooks' have been aware of it and taking advantage of it, the bug has been 'in the wild' since 14th of March 2012, it was only discovered and patched by the honest folks a matter of days ago but someone dishonest could have known about it for going on 2years.!!!!
Additionally there is no way for a site to know if it has been compromised, the bug exposes the data in a way that shows up as normal usage in the server logs and it is therefore impossible to know if a site has lost data. Normally in a situation like this something abnormal shows up that exposes the attack and allows the site to identify what data has been compromised, in this case that is not possible.
Theoretically, there should be a blanket resetting of all passwords on all sites once they have patched themselves. I'd probably be looking at having any c/cards used online reissued once the leak is plugged too as there is a good chance that it's gotten out somewhere.
For example, I believe Amazon only patched itself yesterday, and I'm not sure what the status of their SSL certificate is

For those of you using Chrome, there is an extension that checks any site you are visiting for this vulnerability.

[url= https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic ]Chrome Heartbleed Extension[/url]

I'd like to see a LOT more of these in the next few days..

[url= http://arstechnica.com/security/2014/04/dear-readers-please-change-your-ars-account-passwords-asap/ ]Ars Technica issues password reset[/url]

*reported*
[edit] is this spam? Or just odd.

Note to self: Don't go to wwaswas for IT security updates. 8)

Have any exploits for this bug been seen in the wild yet?

A list of most(all?) sites that support 2 factor authentication and how to enable it..

[url= http://evanhahn.com/2fa/ ]2 Factor Authentication list[/url]

Note to self

[i]Note to self: Don't go to wwaswas for IT security updates[/i]

It just seemed to have the classic spam pattern - seemingly random thread title, 'hidden' links to a non standard url (.io).

More like one of those 'visit our site and we'll infect your pc' posts.

I'm more than happy for lots and lots of people not to come to me for IT security updates 🙂

[thanks Tom!]

It's going to be difficult if not impossible to tell if there have been exploits as it leaves no evidence. The only real way to tell would be for someone to steal the data and then exploit it en-mass thereby exposing the hack by virtue of so much data being compromised at once. Any sensible criminal is going to sit on the data and pick and choose what he steals and when.
The more I read up on this the scarier it sounds. It's possible that every currently issued SSL certificate will have to be revoked and blacklisted in order to be certain of re-established security. Unless this happens then there is a way to use the compromised private key to initiate a 'Man in the middle' attack even after a new certificate is issued.
As i read on another IT site, in terms of disaster level from 1-10, this bug registers an 11..

Just so everyone knows, if you check the issue date of the certificate on any website you login to and the issue date is before 07/04/2014 then it has been potentially compromised and your data is at risk even if you update your password.

This is a HUGE deal folks, please don't fob this off as not affecting you. For example Amazon cannot be considered safe as of now. I am looking at there certificate information now and the certificate is almost a year old.!!!

If you don't know how to check, when you get to a login page on any site, BEFORE you login click on the little padlock next to the URL on the address bar of your browser, you can view the certificate information from there, if the issue date is before 7/4/2014 then the site cannot be considered safe and anything you do there is potentially at risk for being stolen.

So given that all our sites run on Windows servers we're ok as we don't use open ssl?

or can someone stick something in an open source router that gives them the info they need?

Ah.

Is this why I have been getting a security warning popup from Windows when using the STW login and search functions for the past few weeks?

The server has to use OpenSSL for security, indications are that IIS is ok.
This is why it's only 66% of the internet that's potentially compromised rather than all of it. OpenSSL is the most popular implementation and is part of the standard install of Apache web server.

Does this qualify as enough publicity.. currently on the front page @ BBC news..

[url= http://www.bbc.co.uk/news/technology-26954540 ]http://www.bbc.co.uk/news/technology-26954540[/url]

xkcd did well;

[img] [/img]

Public urged to reset all passwords

Well that's blown it; anarchy iminent.

Thanks for the warning, Highlander. Muchos membranos or something...

wwaswas was probably personally responsible for preserving a lot of privacy today.

You're right. He has been a true hero.

*salutes*

Does this qualify as enough publicity.. currently on the front page @ BBC news..

http://www.bbc.co.uk/news/technology-26954540

My only concern about that link, is:

Several tech firms are urging people to change all their passwords after the discovery of a major security flaw.

Probably best to make sure the site in question has patched to the newest version of OpenSSL, otherwise you're back to square one with having potentially compromised information.

You're behind square one. If you change your password on a compromised site you're giving it fresh credentials; ie, you're *more* at risk.

Well, like an ass, I was assuming the site had not been compromised yet. But you're correct, if the site has already had it's pants pulled down, and not been patched then...

[img] [/img]

This is where I am starting to see some resistance. I got intouch with my hosting provider asking if they were patched and whether they are recertifying and got quite a snitty response saying that updates were done on a daily basis, the OpenSSL vulnerablilty had been patched and that revoking the SSL certificate was not necessary.!

This is where this could be a long running issue, any servers that do not recertify are essentially still open if their private key has been compromised. If that's the case then the patch is useless and their systems are wide open. As I understand it even where the certificate expires and is renewed the problem may still exist. The certificate has to be revoked to close the hole..

It's not all sites out there mind, even those runing Apache/Nginx plenty are sat behind hardware load balancers (especially big, high throuput sites), which often use dedicated hardware, which usually isn't vulnerable.

Could you elaborate.? I'm not sure exactly how a hardware load balancer would prevent this.?

Paypal gift suddenly gallops from the back of the field as the most secure payment option.

I'm trying (and failing) to get a handle on the difference between potential leaks of data and guaranteed leaks of data.
The stories talk about being able to download private keys along with usernames and passwords.
As I understand, through a flaw you can download 64K chunks of data from the application.
What I can't seem to find out is -
Are these addressable chunks, random chunks, or do they all have the same memory offset?
Presumably the data memory downloadable is compiler dependent? (though I guess gcc does mem allocation in a fairly standard manner) So do all compilers / os / hardware platforms have the same vulnerable data in the same 64K segment?
Or am I misunderstanding something?

Just typed out a huge explanatory post and realised that I was likely just going to make things more confusing..

Look here for a decent technical explanation..

[url= http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html ]http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html[/url]

The upshot of it is, because of the nature of the bug, there is no way to know if or what has been stolen. Therefore you have to assume that EVERYTHING was stolen. Hence the calls for blanket revoking of SSL/TLS certificates and blanket changing of all passwords.

As the man said.. 'Nuke it from orbit, it's the only way to be sure!!'

Assuming the author can be trusted, the tweet on that explanation page is interesting.

@neelmehta

Heap allocation patterns make private key exposure unlikely for #heartbleed #dontpanic.

Though,

Neel Mehta has validated some of my concerns, but there are many reports of secret key discovery out there.

It is unlikely in most circumstances.
You have to remember though that by running a relatively simple script someone could have been monitoring the contents of that memory basically constantly for the last 2 years.!! It's not inconceivable to assume that the data collected in that time can be reconstructed to form critical data.

The key here and the one that I hope sites are going to take to heart is that there is no way to know what might have been taken. However unlikely, they are going to have to assume that the keys to the kingdom have been copied and respond accordingly.

Probably find the whole thing was a bug added by the NSA and they've been leaching data for years......

Interesting you should say that. OpenSSL is open source software and one of the key advantages of such is supposed to be that things like this don't happen due to the peer review like process that the code goes through. Given what everyone has been assuming about open source software for many years there has to be some serious questions asked about how it is written and maintained in mission critical situations. I can only imagine what kind of gleeful meetings they are having at Microsoft today. Their server infrastructure business might just have gotten a massive boost.

Nothing to stop the NSA anonymously checking in code to OS projects. They pretty much ran one of the encryption standards bodies and rigged one of the random number gens.

Look here for a decent technical explanation..

http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Thanks!

Nothing at all.. but in theory they should be prevented from checking in malicious code as it would be spotted by other coders who look at it and figure out what they were up to.. Clearly something that isn't working as well as it should in this case.

Oh and you are very welcome Ian. 🙂

My understanding is patching and new cents are required. I don't see how sticking an LB in front helps. Sure the LB depending on OpenSSL version itself may not be vulnerable but what's behind it is.
Happy to be corrected by someone more geeky 🙂

Don't see the point in changing passwords until it's verified all aspects of the vulnerability are removed.

In actual fact, changin passwords before the site is patched and certificate re-issued could actually make you MORE vulnerable. If the site is being monitored this way then you logging in to change your password makes you more likely to be caught than by simply staying away until it's fixed.. Basically everyone needs to unplug and go for a ride for a day or two until this is fixed..

+1 and the most sense I've heard all day

if the issue date is before 7/4/2014 then the site cannot be considered safe

My understanding is that this is possible but is not the default way it works.
Yahoo for example has had a new certificate issued that started yesterday. I'm not up to speed with the way certificates are issued but I believe it may need to be issued as a new certificate because the private key needs to be regenerated, a standard re-issue of a cert would not regenerate this key. Seeing as the key is what's been stolen potentially, getting a new cert issued without a new key is totally pointless.

Please note I could be wrong on that point. However getting keys re-issued with the original start date is hardly going to help rebuild shattered confidence. I'd have thought affected sites would be trumpeting about their shiny new, secure certificate.

captainslow - depending on the load balancer config, that will normally terminate the ssl connection first then start the connection to the next destination, using its implementation of ssl (perhaps it is openssl or not), sometimes offloading the calculations to dedicated hardware cards.

e.g. my citrix load balancers run openssl, but dont run the affected versions (slightly older) so its all a-ok for me.

Where are all the open-source zealots today? 😯

oh if you have cisco read this: [url= http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed ]cisco[/url]

vsphere [url= http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076225 ]this[/url]

Its just a ploy for us to take our eyes of the XP systems that will be getting pwoned today of course.

😆

If you believe the speculation, pwoned is an understatement. The theory is that the hacker groups have been saving up all the undocumented exploits, security holes and bugs in XP until today. Now that Microsoft has washed their hands of it, it's open season.!!

yup - theory. where are they all then?

The first of many I assume.

[img] [/img]

Thx dh

well if you use strava you certainly might be asking questions...

[url= https://lastpass.com/heartbleed/?h=strava.com ]too busy with KOMs strava admin team?[/url]

I feel old.........

Here's another one.. glad to see that at least some sites are attacking this headon..

[url= https://www.wunderlist.com/blog/how-we-fixed-the-heartbleed-bug ]Wunderlist[/url]

Not sure if this makes it better or worse but it looks like there is some evidence that the bug has been exploited for at least several months... Better, because it looks like it may be possible to identify an attack (assuming you were logging to the right level), much much worse because it means that it was a known exploit in the community and has been used in anger.!!

[url= http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/ ]Heartbleed may have been exploited[/url]

@Highlander -sorry been busy.

Most times if you're using a hardware (or 'clever' software) load balancer, you're going to terminate SSL on that device. While some lower end devices might use OpenSSL, the bigger payers will have something like a Cavium Nitrox SSL processing chip, which won't be vulnerable to this attack (but might be to others, of course). Better software load balancers might have a different proprietary stack also.

Often,the range of ciphers supported by hardware is smaller than OpenSSl so it's possible if the device is configured away from the default that it might fall back to OpenSSL, which could be a vulnerable version.

However, I'd say that in general sites which are using high end Application Delivery Controllers (posh load balancers) are less likely to be vulnerable to this and other TLS based attacks.

It would appear that both ebay and PayPal still have old certificates in place.

On a work related note I'm in for some headaches today.

There is some useful information about certificate issue dates here:
https://news.ycombinator.com/item?id=7563095

Our Digicert cert has been revoked, rekeyed, and reissued, retaining the original date. There are some other high profile sites who were previously vulnerable, and must surely have revoked and rekeyed, but have retained old issue dates. Lastpass.eu and stackoverflow for example.

I'm looking forward to work today. There's going to be more dancing around the issue than a Michael Flately production.

One thing to bear in mind that this is going to give the people who email you fake 'reset your password and give us your bank details' emails a field day. Everyone will believe they are genuine.

If you're going to reset your password as a result of an email notification type the url into a browser, don't follow a link.

Easy way to test whether sites of interest are potentially at risk

https://www.ssllabs.com/ssltest/

If you're like me and have a passing interest into the background of this, but struggle to understand all the connected elements, I thought this was quite a good "plain-English" explanation of what has happened:

[url= http://www.newyorker.com/online/blogs/elements/2014/04/the-internets-telltale-heartbleed.html ]http://www.newyorker.com/online/blogs/elements/2014/04/the-internets-telltale-heartbleed.html[/url]

I am still getting a security warning when logging into STW -

[i]Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.

Are you sure you want to continue sending this information?[/i]

Never used to get this until the past week or so. Not computer savvy really. Is this related to the current problem or something else?

Thanks, rj2dj, good article.

As expected. Apparently our VPN having the vulnerability is 'not a big deal'.

🙄