Rewording (and hopefully simplifying) for my own benefit because I think the OP is a little loose with the details.
There are two parts:
Part 1: Subdomain takeover
1) DNS for domain X points to service Y (Y=Heroku in this case).
2) Service Y allows anyone to claim an unused domain.
3) Domain X is then claimed by an attacker.
4) Domain X is then served by an attacker.
5) Bonus points if the owner of X has a wildcarded HTTPS cert, so the hijacked subdomain gets HTTPS automatically.
So now attacker serves content on a domain they don't own (possibly over HTTPS). This is already a known cloud hosting mis-configuration problem.
In this case, investor.example.com for HTTPS was not claimed on Heroku but DNS was pointed to Heroku, so it was vulnerable to subdomain takeover. However, the author only had HTTPS access and example.com did NOT have wildcarded cert, so the author was in an edge case of having control of a subdomain but only over HTTPS with no cert.
This prompted them to look for...
Part 2: Abusing TLS-SNI-01 validation
TLS-SNI-01 works by having LetsEncrypt request a cert with a secret from the specified domain.
1) LE does a DNS lookup of the desired domain.
2) LE connects to that domain using TLS-SNI. SNI specifies a hostname in the pre-encryption request.
3) ACME TLS-SNI-01 has the SNI requested domain in the form foo.bar.acme.invalid.
4) Author claimed the necessary foo.bar.acme.invalid hostname on Heroku (and later AWS).
5) Author initiated a LetsEncrypt cert request for a different domain on the same hosting provider.
6) When LE made the SNI request to that domain it did a DNS lookup and got pointed to the shared hosting provider, but the SNI hostname was of the form foo.bar.acme.invalid which was controlled by the attacker, so it was passed to the attacker's app.
6.a (Side note: Because there was no valid cert offered by the hosting provider, I'm guessing the front-ends passed the SNI request through to the backend app. Because if there was a cert configured for the Heroku app then I think the front-ends just serve the cert directly without checking with the backend app.)
7) The attacker then finished the LE cert negotiation and got a cert on behalf of the other domain.
I'm a little fuzzy on exactly how choosing the domain in (3) and (6) works since the spec[0] doesn't seem to match what the blog post shows, but I'm sure it works somehow.
There are two parts:
Part 1: Subdomain takeover
1) DNS for domain X points to service Y (Y=Heroku in this case).
2) Service Y allows anyone to claim an unused domain.
3) Domain X is then claimed by an attacker.
4) Domain X is then served by an attacker.
5) Bonus points if the owner of X has a wildcarded HTTPS cert, so the hijacked subdomain gets HTTPS automatically.
So now attacker serves content on a domain they don't own (possibly over HTTPS). This is already a known cloud hosting mis-configuration problem.
In this case, investor.example.com for HTTPS was not claimed on Heroku but DNS was pointed to Heroku, so it was vulnerable to subdomain takeover. However, the author only had HTTPS access and example.com did NOT have wildcarded cert, so the author was in an edge case of having control of a subdomain but only over HTTPS with no cert.
This prompted them to look for...
Part 2: Abusing TLS-SNI-01 validation
TLS-SNI-01 works by having LetsEncrypt request a cert with a secret from the specified domain.
1) LE does a DNS lookup of the desired domain.
2) LE connects to that domain using TLS-SNI. SNI specifies a hostname in the pre-encryption request.
3) ACME TLS-SNI-01 has the SNI requested domain in the form foo.bar.acme.invalid.
4) Author claimed the necessary foo.bar.acme.invalid hostname on Heroku (and later AWS).
5) Author initiated a LetsEncrypt cert request for a different domain on the same hosting provider.
6) When LE made the SNI request to that domain it did a DNS lookup and got pointed to the shared hosting provider, but the SNI hostname was of the form foo.bar.acme.invalid which was controlled by the attacker, so it was passed to the attacker's app.
6.a (Side note: Because there was no valid cert offered by the hosting provider, I'm guessing the front-ends passed the SNI request through to the backend app. Because if there was a cert configured for the Heroku app then I think the front-ends just serve the cert directly without checking with the backend app.)
7) The attacker then finished the LE cert negotiation and got a cert on behalf of the other domain.
I'm a little fuzzy on exactly how choosing the domain in (3) and (6) works since the spec[0] doesn't seem to match what the blog post shows, but I'm sure it works somehow.
Corrections/clarifications welcome.
Related specs:
[0] https://tools.ietf.org/html/draft-ietf-acme-acme-01#page-40
[1] https://tools.ietf.org/html/rfc6066#page-6