Fascinating discovery by @mholt. Thought folks here would be interested. There's apparently an RCE bug (or feature?) in acme.sh that a Chinese CA reseller is exploiting in order to
render an ASCII QR code during the cert validation flow in order to request payment for the resulting cert wrap a non-ACME http validation flow into something acme.sh can process. They also sent error messages during the cert download stage that would render an ASCII QR code asking for payment for the resulting cert before the download would work. The bug relies on the ACME Server intentionally acting maliciously, so it's unlikely to affect folks using the major public CAs. But it could potentially be abused more easily by ACME implementations intended for use with private CAs.
More details in the Github issue Matt submitted.
Update: @neilpang released acme.sh 3.0.6 with a fix for the exploit and it looks like the chinese CA reseller has shut down.
Oh ha, I just posted a thread about the same thing, deleted now.
When I saw Amir link to the CA on the ietf acme wg onion email thread, and then saw the payloads when I made Certbot pretend to be acme.sh, I got really worried that a bunch of people had been pwned already. I'm glad that's not the case.
Totally absurd and they deserve to have their CA deleted. (Edit: I'm heartened to see that they do not actually operate an CA, which I suppose is the why for the RCE).
WTH. did they made entire CA to pwn some servers and blow itself up?
I second the motion.
And in the aftermath...
How will we stop ACME clients from such exploits/abuse/misuse?
for what we can do:
should we try to send malformed token from peeble and try to catch if client is accepted/tricked?
(what client should do if they see such reponse?)
and. should LE send mail about this? they should Safeish until mitm ca domain though
I hate to go down this path but...
Isn't this forcing the hand towards?:
Should ACME clients be "ACME certified"?
[If so, then who would be the ACME client certification authority?]
[sounds like an unpaid service that may be exposed to unreasonable liability - death before it ever takes one breath]
I think pebble maybe have to get bigger and nastier. (like 100k token thrown to get buffer overrun/ cert returned it not matching with public key from csr/ validation page given is actually a php persistance script etc..)
Clients should never ever run remote code?
Have you seen the sample code it ran?
Is there no safely line?
but it was downloaded payload from remote, not injected one itself, so whatever it can be if it's high enough profile/ before tweet of it appears
For what it's worth the payload appears to be implement so that an alternative challenge type/variation can be implemented. Wasn't it sectigo that used to use "pki-validation"?
Obviously they'll have to stop this working, there's no way they can tolerate running an arbitrary payload but I'd be interested in knowing why they went this direction.
The fact you also then have to pay for your cert download using crypto kind of says it all.
.well-known/pki-validation directory is the standard BR 22.214.171.124.18 method of a CA validating domain name control by having the web site owner put a file on the site. It's like the HTTP-01 method that ACME uses, but how a CA does it if not using ACME.
I think of shells like C code: both are dangerous but in different ways.
With C you have obvious memory safety problems.
With shells, it's just really hard to sanitize inputs. (Although in this case the fix was to remove an
exec call - I agree with an earlier comment that an ACME client should never execute remote code.)
Props to the acme.sh dev for the quick fix and release!
My simple recommendations:
Avoid CAs that require a certain ACME client or have other unusual restrictions / requirements!
Keep your client patched.
This is a massive find. THANK YOU.
Have you generated a CVE yet?
The latest "fix" doesn't change the version number
How can anyone be certain they are patched?
[Fri Jun 9 16:28:42 UTC 2023] Installing from online archive.
[Fri Jun 9 16:28:42 UTC 2023] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
[Fri Jun 9 16:28:42 UTC 2023] Extracting master.tar.gz
[Fri Jun 9 16:28:42 UTC 2023] It is recommended to install socat first.
[Fri Jun 9 16:28:42 UTC 2023] We use socat for standalone server if you use standalone mode.
[Fri Jun 9 16:28:42 UTC 2023] If you don't use standalone mode, just ignore this warning.
[Fri Jun 9 16:28:42 UTC 2023] Installing to /root/.acme.sh
[Fri Jun 9 16:28:42 UTC 2023] Installed to /root/.acme.sh/acme.sh
[Fri Jun 9 16:28:43 UTC 2023] Good, bash is found, so change the shebang to use bash as preferred.
[Fri Jun 9 16:28:44 UTC 2023] OK
[Fri Jun 9 16:28:44 UTC 2023] Install success!
[Fri Jun 9 16:28:44 UTC 2023] Upgrade success!
Which actually shows to which lengths this malicious CA was willing to go to exploit such a vulnerability in this one ACME client..
I'm not sure, but hopefully the CA/Browser Forum has a strong opinion about this. Did anyone find any public email trail or other statement yet?
@Osiris It wasn't its own CA, they were just "reselling" SSL.com and others. I think the CA/B forum only gets involved if they're a root CA or the BRs were violated.
Uhh, you're welcome I guess
No... I don't really care for CVEs. I think the DB is too noisy to be useful.
Perhaps. But it wouldn't be the first time if the root CA got penalized for the actions of one of the subordinate CAs or resellers I think.
For most people, yes. And wow - the number of insane CVEs that some projects I work with get is high.
Unfortunately, this is the only way some environments find out about stuff like this.
Interesting thread methinks. Looks like QuantumCA is going to loose their
ssl.com signed intermediate cert.