2 ms·
> then deliver the page using that key and afterwards remove the other keys. Per bullet 1, this seems self-defeating since at that point all that would need to
by eganist 11y ago
> then deliver the page using that key and afterwards remove the other keys.
Per bullet 1, this seems self-defeating since at that point all that would need to happen is for the victim to forensically extract the private key from the compromised webserver. So long as there's one private key corresponding to a pinned public key, the malware's defeated if the private key can be recovered (assuming I'm understanding your suggestion correctly).
I say "forensically" since I'd presume any malware following this pattern would likely build in some protections to try and blow the private key in the event that someone tries to recover it.
- pfg 11y agoIt's not technically necessary for a TLS web server to have unfettered access to the private key. The web server could offload the signing operations to a separate server under the control of the attacker. The web server only has access to premaster and session keys. CloudFlare calls this Keyless SSL. This would make the attack quite complex, though. It's more likely that the malware will just use the new key for a few hours and then delete it and scrub the disk, which will be enough for the majority of production deployments.
- TimWolla 11y ago> So long as there's one private key corresponding to a pinned public key, the malware's defeated if the private key can be recovered (assuming I'm understanding your suggestion correctly). Once the ransomware delivered the page to enough users (for some number of enough) it can permanently remove the key used to do so. The header now contains the just-removed key used to poison the browser and a randomly generated hash that does not correspond to a valid key. This assumes that the administrator does not detect the ransomware before it does so.