8 ms·

Acme.sh runs arbitrary commands from a remote server

291 points by Kesseki 3y ago

AmenBreak 3y ago
Is this part of Plan 9?
- com 3y ago
  Unfortunately this is related to acme.sh, a shell script tool to request new and replace free certificates. So far, this GitHub issue is quite disturbing.
  - tinus_hn 3y ago
    IMO it’s just a demonstration why you don’t write complicated or security sensitive code in shell script: it’s basically impossible to get right, there’s pitfalls around every corner and it’s extremely difficult to check for mistakes.
    - pazderski 3y ago
      I wouldn't say there are too many pitfalls. Quote all variables (acme.sh seem to do well on that part) and don't use eval (probably the reason for this problem).
      - Eeems 3y ago
        I just read the entire issue thread, yes eval was the reason.
- MisterTea 3y ago
  No. This is not the acme editor. This is what ACME they are referring to: https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment https://en.wikipedia.org/wiki/Automatic_Certificate_Manageme...
regecks 3y ago
I think the title buries the most horrifying part of this. The HiCA certificate authority is relying on an RCE to do an end-run around the semantics of the ACME HTTP-01 validation method. Fucked up and they should be booted from every root program for this.
- stavros 3y ago
  Wow, that's... bold.
- agwa 3y ago
  They aren't in any root programs. They're just taking certificate requests and relaying them to real CAs, which is why they need to exploit an RCE in the ACME client, since the ACME client wouldn't otherwise be able to complete the validations required by the actual CA.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- chunk_waffle 3y ago
  When confronted they just flat out shut down the service. They also donated $1000 to the project, and they've redirected requests to their payment site to the US White House's website, and they're from China. They were also suggesting that user's ran the utility as root... All really shady...
0x0 3y ago
Looks like they are issuing under a sub-CA of "ssl.com" according to https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1583611298 https://github.com/acmesh-official/acme.sh/issues/4659#issue... Interestingly, the mozilla dev-security-policy group seems to contain a recent discussion about including "ssl.com" in the root store here https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/VqnAop6IPcc https://groups.google.com/a/mozilla.org/g/dev-security-polic... Curious to know if this could, maybe it should, have ripple effects to the various SSL Root CA programs. Having someone run a subCA that actually exploits an RCE against ACME clients doesn't seem very trustworthy, and any CA enabling this behaviour should probably be kicked out of the trust stores?
- agwa 3y ago
  The sub CA is operated by ssl.com, not HiCA (which is not a trusted certificate authority). HiCA is relaying the certificate requests to ssl.com, which is properly validating the requests in accordance with all the requirements. ssl.com isn't doing anything wrong. That's why HiCA needs to exploit an RCE in acme.sh - ACME doesn't support relaying certificate requests to other CAs like this.
  - 0x0 3y ago
    Someone posted a comment on github claiming they are the founder of Quantum (the sub CA of ssl.com - see https://crt.sh/?caid=200960 https://crt.sh/?caid=200960 ) and that they are the provider of the HiCA service. So it does sound like there is a closer link here than your comment would indicate: https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584414218 https://github.com/acmesh-official/acme.sh/issues/4659#issue...
    - agwa 3y ago
      Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA with the name "Quantum" in it, but this intermediate CA is operated by ssl.com under all the same controls as ssl.com's other intermediate CAs. Quantum has no ability to issue trusted certificates themselves.
Vecr 3y ago
Even if this is just RCE in the script somehow (I doubt it, it can probably do anything the user running it can), it's horrifying. It means the certificate authority could just take your newly generated certificates and upload them anywhere they want. That's a catastrophic compromise in the TLS security model.
- paulgb 3y ago
  If the CA is compromised, can’t they just bypass ACME verification and generate a cert for your domain anyway?
  - mholt 3y ago
    Yes, but with serious consequences (it would go into public transparency logs, at least for CAs in most public root stores). If the CA can access your private key, then it can reuse (or worse, redistribute) it without anyone knowing.
  - Vecr 3y ago
    Yeah, but that's more likely to be noticed in cert transparency and by the website operator, as there's either a duplicate cert in the log or the website server does not work.
  - dspillett 3y ago
    The CA isn't directly compromised so a third party couldn't generate any arbitrary certificate this way. Essentially though, assuming my understanding is correct, it would allow them to be a man-in-the-middle and take copies of the keys & certificates used by this tool, allowing them to use keys and certificates generated by that tool. Also, if such a tool is run by root (bad practise, but not uncommon practise) or other significantly privileged user, they potentially have access to far more.
- diarrhea 3y ago
  Why is distributing the certificate dangerous? It’s public knowledge anyway.
j16sdiz 3y ago
<quote> ... HiCA is injecting arbitrary code/commands into the certificate obtaining process and acme.sh is running them on the client machine. </quote>
predictabl3 3y ago
Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me" (until it does). Seemingly just so they can avoid some reverse proxy rules to host the challenge endpoints at the right place? Holy wow. Oh there we go baby, eval'ing with arbitrary input in the shell script, complete with lazy inproper string quoting. I should probably just stop before I say more unkind things. Was it even run through shellcheck?! Stop writing this stuff in shell people. 95% of the time I review any (posix, nushell lacks most of these issues) shell scripts, it's obvious they would fall apart the second any string unexpectedly had a space in it. Even scripts written by darling companies of HN.
- yjftsjthsd-h 3y ago
  Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp edges (if we're allowing eval, then not many languages are going to be safe, really).
  - Bystroushaak 3y ago
    I usually replace shell scripts with python (using sh module: https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ for calling other scripts/programs).
    - cozzyd 3y ago
      yeah until your scripts stop running someday because python...
      - 3y ago
ronsor 3y ago
These sorts of hacks remind me of when AOL's AIM server was exploiting bugs in their own client to run verification code[0]. Hardly an acceptable practice in 2023, though. [0] https://www.geoffchappell.com/notes/security/aim/index.htm https://www.geoffchappell.com/notes/security/aim/index.htm
WirelessGigabit 3y ago
This means that acme.sh has an RCE. Once the patch is in I'm rotating all my certs, even though I use ZeroSSL. I do wonder if what HiCA did gave possibilities to post the private key somewhere else?
- mholt 3y ago
  If the executed script transmits the key, then yes. (But the script we observed does not.)
MrStonedOne 3y ago
[dead]
freedomben 3y ago
Major props and thanks to the HiCA person for engaging on the thread even though they were getting hammered. Yes they made some really (damn clever but) bad implementation decisions to use an RCE in the client to basically hack around the entire system, and then compounded it with other bad decisions to redirect to the US White House website to stop a DDoS, but the fact that they engaged, admitted, and explained what was going on I thought was really big of them. Everybody makes mistakes people. If this person was trying to be malicious they would have disappeared, not come straight clean about it on the thread.
- clysm 3y ago
  But... HiCA just disappeared. Their site is gone now.
catkitcourt 3y ago
This raise one more issue about Chinese providers. The site using this exploit, HiCA is run by xiaohuilam on Github. He/She is also the founder of two famous SSL certificate provider in China, DigitalSign and QuantumCA. Additionally, he is also a contributor of acme.sh repository. The acme.sh repository locked issue #4659 quickly after it raise attentions in the developer community in China. It's hard to imagine that, as one of the repository's contributor, once you have found a vulnerability, you are going to use it in your own product, instead of fix it. They are just another version of Pinduoduo (owner of Temu, and also the one who put spyware on user's android phone).

291 points by Kesseki 3y ago

AmenBreak 3y ago

Is this part of Plan 9?

com 3y ago
Unfortunately this is related to acme.sh, a shell script tool to request new and replace free certificates. So far, this GitHub issue is quite disturbing.
- tinus_hn 3y ago
  IMO it’s just a demonstration why you don’t write complicated or security sensitive code in shell script: it’s basically impossible to get right, there’s pitfalls around every corner and it’s extremely difficult to check for mistakes.
  - pazderski 3y ago
    I wouldn't say there are too many pitfalls. Quote all variables (acme.sh seem to do well on that part) and don't use eval (probably the reason for this problem).
    - Eeems 3y ago
      I just read the entire issue thread, yes eval was the reason.
MisterTea 3y ago
No. This is not the acme editor. This is what ACME they are referring to: https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment https://en.wikipedia.org/wiki/Automatic_Certificate_Manageme...

regecks 3y ago

I think the title buries the most horrifying part of this. The HiCA certificate authority is relying on an RCE to do an end-run around the semantics of the ACME HTTP-01 validation method. Fucked up and they should be booted from every root program for this.

stavros 3y ago
Wow, that's... bold.
agwa 3y ago
They aren't in any root programs. They're just taking certificate requests and relaying them to real CAs, which is why they need to exploit an RCE in the ACME client, since the ACME client wouldn't otherwise be able to complete the validations required by the actual CA.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
chunk_waffle 3y ago
When confronted they just flat out shut down the service. They also donated $1000 to the project, and they've redirected requests to their payment site to the US White House's website, and they're from China. They were also suggesting that user's ran the utility as root... All really shady...

0x0 3y ago

Looks like they are issuing under a sub-CA of "ssl.com" according to https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1583611298 https://github.com/acmesh-official/acme.sh/issues/4659#issue... Interestingly, the mozilla dev-security-policy group seems to contain a recent discussion about including "ssl.com" in the root store here https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/VqnAop6IPcc https://groups.google.com/a/mozilla.org/g/dev-security-polic... Curious to know if this could, maybe it should, have ripple effects to the various SSL Root CA programs. Having someone run a subCA that actually exploits an RCE against ACME clients doesn't seem very trustworthy, and any CA enabling this behaviour should probably be kicked out of the trust stores?

agwa 3y ago
The sub CA is operated by ssl.com, not HiCA (which is not a trusted certificate authority). HiCA is relaying the certificate requests to ssl.com, which is properly validating the requests in accordance with all the requirements. ssl.com isn't doing anything wrong. That's why HiCA needs to exploit an RCE in acme.sh - ACME doesn't support relaying certificate requests to other CAs like this.
- 0x0 3y ago
  Someone posted a comment on github claiming they are the founder of Quantum (the sub CA of ssl.com - see https://crt.sh/?caid=200960 https://crt.sh/?caid=200960 ) and that they are the provider of the HiCA service. So it does sound like there is a closer link here than your comment would indicate: https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584414218 https://github.com/acmesh-official/acme.sh/issues/4659#issue...
  - agwa 3y ago
    Quantum is not a trusted CA. ssl.com has a white-labeled intermediate CA with the name "Quantum" in it, but this intermediate CA is operated by ssl.com under all the same controls as ssl.com's other intermediate CAs. Quantum has no ability to issue trusted certificates themselves.

Vecr 3y ago

Even if this is just RCE in the script somehow (I doubt it, it can probably do anything the user running it can), it's horrifying. It means the certificate authority could just take your newly generated certificates and upload them anywhere they want. That's a catastrophic compromise in the TLS security model.

paulgb 3y ago
If the CA is compromised, can’t they just bypass ACME verification and generate a cert for your domain anyway?
- mholt 3y ago
  Yes, but with serious consequences (it would go into public transparency logs, at least for CAs in most public root stores). If the CA can access your private key, then it can reuse (or worse, redistribute) it without anyone knowing.
- Vecr 3y ago
  Yeah, but that's more likely to be noticed in cert transparency and by the website operator, as there's either a duplicate cert in the log or the website server does not work.
- dspillett 3y ago
  The CA isn't directly compromised so a third party couldn't generate any arbitrary certificate this way. Essentially though, assuming my understanding is correct, it would allow them to be a man-in-the-middle and take copies of the keys & certificates used by this tool, allowing them to use keys and certificates generated by that tool. Also, if such a tool is run by root (bad practise, but not uncommon practise) or other significantly privileged user, they potentially have access to far more.
diarrhea 3y ago
Why is distributing the certificate dangerous? It’s public knowledge anyway.

j16sdiz 3y ago

<quote> ... HiCA is injecting arbitrary code/commands into the certificate obtaining process and acme.sh is running them on the client machine. </quote>

predictabl3 3y ago

Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me" (until it does). Seemingly just so they can avoid some reverse proxy rules to host the challenge endpoints at the right place? Holy wow. Oh there we go baby, eval'ing with arbitrary input in the shell script, complete with lazy inproper string quoting. I should probably just stop before I say more unkind things. Was it even run through shellcheck?! Stop writing this stuff in shell people. 95% of the time I review any (posix, nushell lacks most of these issues) shell scripts, it's obvious they would fall apart the second any string unexpectedly had a space in it. Even scripts written by darling companies of HN.

yjftsjthsd-h 3y ago
Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp edges (if we're allowing eval, then not many languages are going to be safe, really).
- Bystroushaak 3y ago
  I usually replace shell scripts with python (using sh module: https://amoffat.github.io/sh/ https://amoffat.github.io/sh/ for calling other scripts/programs).
  - cozzyd 3y ago
    yeah until your scripts stop running someday because python...
    - 3y ago

ronsor 3y ago

These sorts of hacks remind me of when AOL's AIM server was exploiting bugs in their own client to run verification code[0]. Hardly an acceptable practice in 2023, though. [0] https://www.geoffchappell.com/notes/security/aim/index.htm https://www.geoffchappell.com/notes/security/aim/index.htm

WirelessGigabit 3y ago

This means that acme.sh has an RCE. Once the patch is in I'm rotating all my certs, even though I use ZeroSSL. I do wonder if what HiCA did gave possibilities to post the private key somewhere else?

mholt 3y ago
If the executed script transmits the key, then yes. (But the script we observed does not.)

MrStonedOne 3y ago

[dead]

freedomben 3y ago

Major props and thanks to the HiCA person for engaging on the thread even though they were getting hammered. Yes they made some really (damn clever but) bad implementation decisions to use an RCE in the client to basically hack around the entire system, and then compounded it with other bad decisions to redirect to the US White House website to stop a DDoS, but the fact that they engaged, admitted, and explained what was going on I thought was really big of them. Everybody makes mistakes people. If this person was trying to be malicious they would have disappeared, not come straight clean about it on the thread.

clysm 3y ago
But... HiCA just disappeared. Their site is gone now.

catkitcourt 3y ago

This raise one more issue about Chinese providers. The site using this exploit, HiCA is run by xiaohuilam on Github. He/She is also the founder of two famous SSL certificate provider in China, DigitalSign and QuantumCA. Additionally, he is also a contributor of acme.sh repository. The acme.sh repository locked issue #4659 quickly after it raise attentions in the developer community in China. It's hard to imagine that, as one of the repository's contributor, once you have found a vulnerability, you are going to use it in your own product, instead of fix it. They are just another version of Pinduoduo (owner of Temu, and also the one who put spyware on user's android phone).