The CA determines "permission of Google" by "can put something on a web page at google.com". This is well-accepted, and as long as the CA's own connection to the internets is hard to MITM, it's pretty reasonable for what domain-validated SSL does. (If you want more security than that, try EV, or something other than SSL.)
Usually, "a web page at google.com" means to put a specific, CA-picked string at a specific, CA-picked URL. The ACME protocol has you put it under /.well-known/, which is reserved for this sort of thing. Other CAs will give you a randomly-generated filename. The intention is that you shouldn't be able to, say, upload a file to GitHub or some forum and claim control of it; you actually have to operate the site.
StartEncrypt neglected to enforce that check.
For google.com in particular, when you click "Sign in with Google" to a third-party service, it sends you to a URL on google.com, and google.com will redirect you back to the third-party site when it's done. What the attacker does is they set up their own website and enable Google sign-in on it (which anyone can do without Google's permission). Then they sign in, and save the URL that's redirecting them back, and send that URL to StartEncrypt. StartEncrypt dutifully follows the redirect when fetching content from google.com, and tricks itself into thinking the file was actually at google.com.
Usually, "a web page at google.com" means to put a specific, CA-picked string at a specific, CA-picked URL. The ACME protocol has you put it under /.well-known/, which is reserved for this sort of thing. Other CAs will give you a randomly-generated filename. The intention is that you shouldn't be able to, say, upload a file to GitHub or some forum and claim control of it; you actually have to operate the site.
StartEncrypt neglected to enforce that check.
For google.com in particular, when you click "Sign in with Google" to a third-party service, it sends you to a URL on google.com, and google.com will redirect you back to the third-party site when it's done. What the attacker does is they set up their own website and enable Google sign-in on it (which anyone can do without Google's permission). Then they sign in, and save the URL that's redirecting them back, and send that URL to StartEncrypt. StartEncrypt dutifully follows the redirect when fetching content from google.com, and tricks itself into thinking the file was actually at google.com.