Cosa dovrebbe fare un operatore di un sito web riguardo all'exploit Heartbleed OpenSSL?

Deer Hunter

2014-04-08 08:10:31 UTC

view on stackexchange narkive permalink

CVE-2014-0160

This is supposed to be a canonical question on dealing with the Heartbeat exploit.

I run an Apache web server with OpenSSL, as well as a few other utilities relying on OpenSSL (as client). What should I do to mitigate the risks?

The bug dissected
Check if your site is vulnerable (Duckduckgo.com is, for instance!)

 I looked at some of the data dumps from vulnerable sites, and it was ... bad. I saw emails, passwords, password hints. SSL keys and session cookies. Important servers brimming with visitor IPs. Attack ships on fire off  the shoulder of Orion, c-beams glittering in the dark near the Tannhäuser Gate. I should probably patch OpenSSL.

Credit: XKCD.

Vale la pena sottolineare che OpenSSH non è influenzato dal bug di OpenSSL. Sebbene OpenSSH utilizzi openssl per alcune funzioni di generazione di chiavi, non utilizza il protocollo TLS (e in particolare l'estensione heartbeat TLS che ha provocato gli attacchi heartbleed). Quindi non c'è bisogno di preoccuparsi che SSH venga compromesso, anche se è comunque una buona idea aggiornare openssl a 1.0.1go 1.0.2-beta2 (ma non devi preoccuparti di sostituire le coppie di chiavi SSH).

@Adnan: tranne per il fatto che ci sono alcune altre cose da fare con i certificati ... Se pensi che non serva a niente, VTC.

@drjimbob a meno che le tue chiavi SSH non siano nella memoria di un processo che utilizza TLS di OpenSSL. Improbabile ma possibile.

A giudicare dai tentativi attivi segnalati nella [DMZ] (http://chat.stackexchange.com/rooms/151/the-dmz), la cosa migliore ora è ** FERMARE IL SERVER FRIKKIN AL PIÙ PRESTO **. Le sessioni vengono dirottate, le password trapelate, i dati aziendali riservati rivelati.

@OrangeDog - Sebbene "possibile", sembra richiedere un exploit completamente separato. Non c'è motivo (almeno sui miei sistemi) che qualsiasi processo che ha accesso a una chiave privata SSH utilizzi anche TLS. Le chiavi private SSH sono limitate a ssh, sshd e ssh-agent. Quindi preoccupati di cambiare i tuoi certificati TLS usati per HTTPS, FTPS, email, ecc. Preoccupati di cambiare tutte le password che hai mai usato su una connessione HTTPS o TLS a un sito web che potrebbe aver utilizzato OpenSSL negli ultimi tre anni che apprezzi. Ma in realtà non c'è motivo legittimo per preoccuparsi delle chiavi SSH.

Apparentemente, Gabriel Weinberg @ DuckDuckGo aveva i suoi server [patchati] (https://twitter.com/yegg/status/453590663695966208). Qualys ha incorporato il controllo Heartbleed nel proprio [strumento di valutazione] (https://www.ssllabs.com/ssltest/analyze.html?d=duckduckgo.com&s=50.18.192.251).

Per collegare: [Cosa dovrebbero fare gli utenti finali su Heartbleed?] (Http://security.stackexchange.com/questions/55083), [Come funziona esattamente l'exploit OpenSSL TLS Heartbeat (Heartbleed)] (http: // security. stackexchange.com/questions/55116)

Aggiornamento di Node.JS: [indutny ha commentato l'8 aprile 2014: No, non è che HEARTBEATS è disabilitato dal nodo v0.10.2.] (Https://github.com/joyent/node/issues/7424#issuecomment-39820298 )

[Un altro collegamento utile] (http://security.stackexchange.com/questions/7790/guidance-for-implementors-of-https-only-sites-server-side)

Per facilità di comprensione: http://security.stackexchange.com/questions/55343/how-to-explain-heartbleed-without-technical-terms. Per i binari statici: http://security.stackexchange.com/questions/55107/heartbleed-how-to-find-out-applications-using-statical-compiled-version-of-ope

Per ancora più "facilità di comprensione": http://xkcd.com/1354/

TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can beused to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and toAdam Langley and Bodo Moeller forpreparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediatelyupgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

Check if you're using the mentioned versions of OpenSSL, if yes patch it to 1.0.1g (by compiling it from source and wrapping the package with e.g. FPM).

(Addition by atk) Afterwards, replace your exposed certificates and revoke them.

(Addition by dr.jimbob) It's worth pointing out that OpenSSH is not affected by the OpenSSL bug. While OpenSSH does use openssl for some key-generation functions, it does not use the TLS protocol (and in particular the TLS heartbeat extension that heartbleed attacks). So there is no need to worry about SSH being compromised, though it is still a good idea to update openssl to 1.0.1g or 1.0.2-beta2 (but you don't have to worry about replacing SSH keypairs).

(OrangeDog): @drjimbob unless your SSH keys are in the memory of a process that's using OpenSSL's TLS. Unlikely but possible.

(Addition by Deer Hunter): Judging by the active attempts being reported in the DMZ, the best thing now is STOPPING THE FRIKKIN SERVER ASAP. Sessions are being hijacked, passwords leaked, confidential business data revealed.

(An extra bit courtesy of EFF.org): "To reach a firmer conclusion about Heartbleed's history, it would be best for the networking community to try to replicate Koeman's findings. Any network operators who have extensive TLS-layer traffic logs can check for malicious heartbeats, which most commonly have a TCP payload of 18 03 02 00 03 01 40 00 or 18 03 01 00 03 01 40 00, although the 0x4000 at the end may be replaced with lower numbers, particularly in implementations that try to read multiple malloc chunk bins." In a nutshell, if you keep detailed TLS logs (not likely for the majority of operators out there), check for past exploitation attempts (and share what you've got).

Related Q&A over at ServerFault:

OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)