SA sites vulnerable to massive security bug

[deweyzeph]

Who the hell needs to reboot? Just install patched openSSL and bounce the webserver daemons.

Unless the vulnerability allows malicious processes to be run on the compromised machine or allows compromising of processes not related to the web server. I'd rather reboot to be sure that everything has been cleared and reset.

 

[Sinbad]

Unless the vulnerability allows malicious processes to be run on the compromised machine or allows compromising of processes not related to the web server. I'd rather reboot to be sure that everything has been cleared and reset.

It just reveals memory afaik.

 

[ReenenLaurie]

Any idea if any of our banks use it, and *if* they do, have they communicated that they have it patched?

 

[Anthro]

If you don't know the answer to that question then I hope you are not managing any servers yourself!

Luckily not my department - advised our web guy and he drew some pictures - sorted out now !

It has nothing to do with the cert issuer. The vulnerability is in the OS stack (Linux) and has the potential of leaking your SSL private key which allows an intruder to use it to impersonate your site. More severe issues are around leaking user information or gaining access to VPN.

If you are running Linux it is very likely that you are affected. In this case you would have to upgrade to a patched OpenSSL version and then recycle your private keys and reissue certs.


But did you ever manage to pull your pants up? First time in 12 months that we had to reboot servers - and you?

Shweet, TX for the explanation - we run Windows server hosts, but as stated above 'the other guy' fixed it

 

[elvis_presley]

First time in 12 months that we had to reboot servers - and you?

I know *nix guys love the epeen the get from uptimes, but is it really good practice? We reboot and fail over our servers on at least a quarterly basis (*nix and Windows) in a controlled manner in a maintenance window to test disaster scenarios, to make sure everything comes up 100%; if you have a failure that takes out enough infrastructure to knock a service offline, you need to know it can come back up properly, and not trying to scramble to remember what's changed in the last year on that box. I would pull my sysadmin through the ringer if he boasted about year+ uptimes.

 

[Sinbad]

I know *nix guys love the epeen the get from uptimes, but is it really good practice? We reboot and fail over our servers on at least a quarterly basis (*nix and Windows) in a controlled manner in a maintenance window to test disaster scenarios, to make sure everything comes up 100%; if you have a failure that takes out enough infrastructure to knock a service offline, you need to know it can come back up properly, and not trying to scramble to remember what's changed in the last year on that box. I would pull my sysadmin through the ringer if he boasted about year+ uptimes.

Agreed.
My home box had something like 1400 days, but that's a different story

 

[elvis_presley]

Agreed.
My home box had something like 1400 days, but that's a different story

Sure. Interrupting your leeching is a no-go.

 

[MagicDude4Eva]

I know *nix guys love the epeen the get from uptimes, but is it really good practice? We reboot and fail over our servers on at least a quarterly basis (*nix and Windows) in a controlled manner in a maintenance window to test disaster scenarios, to make sure everything comes up 100%; if you have a failure that takes out enough infrastructure to knock a service offline, you need to know it can come back up properly, and not trying to scramble to remember what's changed in the last year on that box. I would pull my sysadmin through the ringer if he boasted about year+ uptimes.

Depends on the setup. In our environment we use templated virtual machines and floating IPs as well as loadbalanced servers across different racks - never had a site outage and a rack outage would be relatively easy to manage. Some servers (especially non mission critical such as blog, forum etc, do get recycled more frequently). The full power-recycle as part of the patching of the servers was perhaps not necessary, but a cautionary measure.

 

[shadow_man]

Nobody notes that the 2x biggest hits from this were mail.yahoo.com and Lastpass.com?

I hope these people have 2 factor auth. If you used the internet yesterday and had a password vault service like Lastpass I'd be more than just a little worried...

 

[Noah]

I'd be interested to see a list of SA sites which are affected and how long it takes for them to fix the vulnerability.

At 5AM this morning

• www.ebucks.com
• www.domains.co.za

were still vulnerable but have now been fixed.

I know of 2 popular businesses that are still vulnerable.

 

[MagicDude4Eva]

... I know of 2 popular businesses that are still vulnerable.

Using Qualys (https://www.ssllabs.com/ssltest/analyze.html) you will be even more shocked how many sites still sit with old vulnerabilities (such as man-in-the-middle) - going through ZA-Alexa should give you a hint

 

[Noah]

Using Qualys (https://www.ssllabs.com/ssltest/analyze.html) you will be even more shocked how many sites still sit with old vulnerabilities (such as man-in-the-middle) - going through ZA-Alexa should give you a hint

Hehe, I wonder why
.

 

[MagicDude4Eva]

Hehe, I wonder why
.

True - I heard that they are running at maximum capacity and really struggling - I guess sysadmins across the globe are busy patching servers and checking certs. If you just refresh the homepage you can't keep up with the servers being displayed...

 

[Johand]

It just reveals memory afaik.

That is like saying "We just gave the keys to our house as well as the alarm code pin as well as our ADT password as well as our calendar and movements to the robbers so there should not be any problem." If an attacker can read memory you should for security purposes assume they have your system passwords, your private keys, passwords to databases/other external systems the web server access. Even if they don't have that they can have a lot more information for social engineering attacks.

Any secure system that had the bug should be audited. This is a pretty scary exploit. It has the potential of compromising the systems top to bottom. The fact that it is undetectable AND has been in the wild for two years means all bets are off.

 

[Noah]

That is like saying "We just gave the keys to our house as well as the alarm code pin as well as our ADT password as well as our calendar and movements to the robbers so there should not be any problem." If an attacker can read memory you should for security purposes assume they have your system passwords, your private keys, passwords to databases/other external systems the web server access. Even if they don't have that they can have a lot more information for social engineering attacks.

Any secure system that had the bug should be audited. This is a pretty scary exploit. It has the potential of compromising the systems top to bottom. The fact that it is undetectable AND has been in the wild for two years means all bets are off.

Very powerful exploit, in the hands of people who know what they are doing targeting those who don't so much can be exploited. Session theft, private information leaked, passwords.http://noahi.me/egvhy

 

[_Snooze_]

And updated. I am now running openssl-devel-1.0.1e-16.el6_5.4.x86_64

Which distro you on? Apparently 1.0.1g is the patch that fixes this.

RHEL/CentOS 6.

Red Hat backports security fixes for some packages. That seems to be the dev package that you use when building other packages that require openssl.

By the looks of it the bug was fixed in 1.0.1e-16.el6_5.7 of the the openssl package.

$ rpm -q --changelog openssl | head
* Ma Apr 07 2014 Tomáš Mráz <[email protected]> 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

* Di Jan 07 2014 Tomáš Mráz <[email protected]> 1.0.1e-16.4
- fix CVE-2013-4353 - Invalid TLS handshake crash

* Ma Jan 06 2014 Tomáš Mráz <[email protected]> 1.0.1e-16.3
- fix CVE-2013-6450 - possible MiTM attack on DTLS1

* Vr Des 20 2013 Tomáš Mráz <[email protected]> 1.0.1e-16.2

 

[w1z4rd]

But did you ever manage to pull your pants up? First time in 12 months that we had to reboot servers - and you?

Why did you need to reboot? Kernel update? When I do kernel updates on CentOS they dont seem to require a reboot. I was able to update SSL, update the kernel and recompile apache without a reboot.

 

[Sinbad]

Why did you need to reboot? Kernel update? When I do kernel updates on CentOS they dont seem to require a reboot. I was able to update SSL, update the kernel and recompile apache without a reboot.

Kernel updates will need a reboot.

 

[w1z4rd]

Which distro you on? Apparently 1.0.1g is the patch that fixes this.

CentOS 6.X with latest version of whm/cpanel. They pushed the patch. Updating to that version and recompiling apache worked for me. I tested vulnerable before I did it and okay after I updated.

 

[w1z4rd]

Kernel updates will need a reboot.

Crap. Normally the system tells me when it needs to reboot:/ brb