Ci sono più da considerare rispetto ai nuovi certificati (o meglio, nuove coppie di chiavi) per ogni server interessato. Significa anche:
- Patching dei sistemi interessati su OpenSSL 1.0.1g
- Revoca dei vecchi keypair che sono stati appena sostituiti
- Modifica di tutte le password
- Invalidazione di tutte le chiavi e i cookie di sessione
- Valutare il contenuto reale gestito dai server vulnerabili che potrebbero essere stati trapelati e reagire di conseguenza.
- Valutare qualsiasi altra informazione che potrebbe essere stata rivelata, come gli indirizzi di memoria e le misure di sicurezza
Neel Mehta (l'ingegnere della sicurezza di Google che ha segnalato per la prima volta l'errore) ha twittato :
Heap allocation patterns make private key exposure unlikely for #heartbleed #dontpanic.
Tomas Rzepka (probabilmente dalla società di sicurezza svedese Certezza ) replied con quello che dovevano fare per recuperare le chiavi:
We can extract the private key successfully on FreeBSD after
restarting apache and making the first request with ssltest.py
Il furto della chiave privata è stato dimostrato anche dalla Sfida CloudFlare .
E l'utente di Twitter makomk ha risposto in con :
I've recovered it from Apache on Gentoo as a bare prime factor in
binary, but your demo's a lot clearer...It has a lowish success rate,
more tries on the same connection don't help, reconnecting may,
restarting probably won't...Someone with decent heap exploitation
skills could probably improve the reliability. I'm not really trying
that hard.
Ho riassunto i punti elenco qui sopra da heartbleed.com (enfasi mia):
What is leaked primary key material and how to recover?
These are the crown jewels, the encryption keys themselves. Leaked
secret keys allows the attacker to decrypt any past and future traffic
to the protected services and to impersonate the service at will. Any
protection given by the encryption and the signatures in the X.509
certificates can be bypassed. Recovery from this leak requires
patching the vulnerability, revocation of the compromised keys and
reissuing and redistributing new keys. Even doing all this will still
leave any traffic intercepted by the attacker in the past still
vulnerable to decryption. All this has to be done by the owners of the
services.
What is leaked secondary key material and how to recover?
These are for example the user credentials (user names and
passwords) used in the vulnerable services. Recovery from this leaks
requires owners of the service first to restore trust to the service
according to steps described above. After this users can start
changing their passwords and possible encryption keys according to the
instructions from the owners of the services that have been
compromised. All session keys and session cookies should be invalided
and considered compromised.
What is leaked protected content and how to recover?
This is the actual content handled by the vulnerable services. It
may be personal or financial details, private communication such as
emails or instant messages, documents or anything seen worth
protecting by encryption. Only owners of the services will be able to
estimate the likelihood what has been leaked and they should notify
their users accordingly. Most important thing is to restore trust to
the primary and secondary key material as described above. Only this
enables safe use of the compromised services in the future.
What is leaked collateral and how to recover?
Leaked collateral are other details that have been exposed to the
attacker in the leaked memory content. These may contain technical
details such as memory addresses and security measures such as
canaries used to protect against overflow attacks. These have only
contemporary value and will lose their value to the attacker when
OpenSSL has been upgraded to a fixed version.
