Hacker News Reader

Comment by TimWolla | Hacker News Reader

IIRC The pin must contain at least one key that's in the current chain and at least one key that's not in the current chain.

So it first would need to set the header to include the ransomed key, then deliver the page using that key and afterwards remove the other keys.

Edit: I just read in the RFC. It is in section 2.5 (https://tools.ietf.org/html/rfc7469#section-2.5):

   o  The TLS connection was authenticated with a certificate chain
      containing at least one of the SPKI structures indicated by at
      least one of the given SPKI Fingerprints (see Section 2.6).

   o  The given set of Pins contains at least one Pin that does NOT
      refer to an SPKI in the certificate chain.  (That is, the host
      must set a Backup Pin; see Section 4.3.)

View on HN

IIRC The pin must contain at least one key that's in the current chain and at least one key that's not in the current chain.

Then the malware could call out to let's encrypt to issue a certificate, then load the certificate into nginx/apache/whatever, then remove the let's encrypt private key from the file system. That allows the webserver to continue serving traffic with LE's key + ransomware key until it's restarted.

1.) Infect webserver

2.) Generate public/private key pair for the purposes of the ransom on the CC server, then send back the public key back to the compromised server.

3.) Use webserver to issue LE SSL certificate. Delete the private key once it's loaded into the webserver process.

4.) Serve traffic with the hashes of the LE key and the ransomware key.

If the sysadmin restarts the webserver process, they are screwed since that's the only process that contains the LE private key.

> 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.

It'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.

> 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.

Reply on news.ycombinator.com