1

Cloudfront supports adding external origins, i.e. domains that are not S3 buckets or ALBs. This led me to wonder whether adding domains that are not owned by the entity as an origin could allow for intercept the request payload, and potentially act as an Man in the Middle Attack.

Let's say I have a REST API running on ECS behind an Application Load Balancer(ALB) on AWS. The ALB is fronted by a cloudfront domain, called abcd.cloudfront.net. As one would expect, there's a CNAME record setup on the DNS provider called app.mysite.com pointing to the cloudfront domain with a valid SSL cert from ACM. The ALB has a rule to only allow requests that have the header HOST:app.mysite.com. This create a pretty standard API flow on AWS.

What would happen if someone, with no access to my AWS account, sets up a new cloudfront domain, abcd2.cloudfront.net with the domain app.fake-mysite.com and valid ACM cert for app.fake-mysite.com, and adds a behavior to point to app.mysite.com. Can this external entity use it's own ACM cert to cause a Man in the Middle Attack?

The request flow would look like this:

app.fake-mysite.com -> abcd2.cloudfront.net -> app.mysite.com -> abcd.cloudfront.net -> my-alb.domain -> 10.0.0.100:8080 (REST API)

Would it be possible for the external entity to intercept the request at the first hop and capture the encrypted data? If so, how can this be prevented?

As far as the REST API container is concerned, the request would have originated from the app.mysite.com, and would be completely unaware of this wrapper cloudfront distribution (app.fake-mysite.com)

Note: I had initially asked this question on Stackoverflow, and I was told this is a better place to discuss this.

Improve this question

1 Answer 1

Reset to default
1

What you describe is basically providing access to a website under a different domain, i.e. a domain you own yourself. This can not only be achieved with Cloudfront but also with running a reverse proxy on any publicly reachable system/VPS you control yourself.

But, you have to somehow trick the victim into visiting your site and not the original site - which is a different domain. If the victim is using a password manager it will not automatically fill in passwords, since these are for a different site. So it is less a traditional MITM attack were the victim still tries to access the original site. It is more a phishing attack, where the victim is tricked into using a different site. Nevertheless, it can be successful.

Improve this answer
9
  • Thank you for your answer! This is a great explanation, and I see how this is a phishing attack. Do you have any recommendations on how this can be prevented?
    – Arshit Arora
    May 8, 2021 at 15:04
  • @ArshitArora: On the server side it is not directly visible what URL the client is using to access the site. One might check Referer or Origin header, but the attacker proxy might "fix" these when forwarding the traffic. One could include some Javascript in the page which uses the URL used in the client (i.e. location.href) in some logic to make sure it is the expected. Note that this is not foolproof either, since the attacker could also replace the served Javascript with something else. But it can be made harder to deal with, than with the Referer and Origin headers.
    – Steffen Ullrich
    May 8, 2021 at 15:19
  • Thanks again for the explanation. I'll make sure to use this check in my applications!
    – Arshit Arora
    May 8, 2021 at 15:34
  • @SteffenUllrich Your thoughts please on: a) the javascript and UI running on browser will be from fake.com or genuine.com.. given the setup in question i believe it will redirect to genuine.com and browser will talk directly to genuine.com b) in case fake.com is running on browser then wouldn't CORS protect the browser from reading the response c) Irrespective, If backend is secure (e.g. with captcha or MFA) then this attack will fail.
    – Vikram Rawat
    May 9, 2021 at 2:10
  • @VikramRawat: I'm not sure what you mean with a), b) and c) exactly. Given that your original question was answered it might be better to ask these things in a new question with enough context to understand and with more details than would fit in a comment.
    – Steffen Ullrich
    May 9, 2021 at 4:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .