1

I see that using AWS S3 with https, it comes with a wildcard SSL cert.

Does that mean man-in-the-middle attack is possible by DNS/network rogue and redirect users into another S3 link (having the same wildcard)?

Assuming that noone can acquire Amazon CA private key, thus cannot install the certs on their own host, they can only spoof another fake S3 site. E.g.

The original request is: https://good.s3.amazon.com/important.data

Can attacker redirect to: https://bad.s3.amazon.com/important.data (but actually corrupted data) with DNS/network rogue trick?

Then users instead of getting correct data, they will get corrupted data.

enter image description here

Khanh Nguyen
  • 13
  • 5

1 Answers1

1

If somebody has access to the private key of the certificate he can use it for man in the middle attacks. Such attack can be used to redirect the user to another machine if the DNS lookup for the host given in the redirect results in the IP address of the other machine. This can be a different hostname in the same domain as in the original request and thus can be covered by the same wildcard certificate. But it can also be a different domain, for example a domain controlled by the attacker where he also has a certificate to do MITM where he controls the full server (no MITM needed).

Actually, I don't see the problem with a wildcard certificate in this case. It is enough that the attacker has access to any accepted certificate (wildcard or not) and its private key in order to sniff and modify the traffic. The attack is also not limited to redirecting to another system.

Can attacker redirect to: bad.s3.amazon.com/important.data (but actually corrupted data) with DNS/network rogue trick?

One way is to trick the user into using the wrong URL in the first place (social attacks). Then an attacker near the user (i.e. local network, ISP,...) might try do DNS spoofing, ARP spoofing or similar to let the user access the intended URL but on the wrong host. Only, in this case the HTTP host header of the request will show the intended domain and the HTTP based routing inside AWS will cause the request to either end up at the good bucket or to get rejected since the good bucket is not accessible using the specific IP address.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thx. Do I understand correctly then hosting HTTPS content on AWS S3 won't protect users from MITM attack? – Khanh Nguyen May 09 '18 at 10:23
  • @KhanhNguyen: there is always somebody who you need to trust. If you don't trust Amazon to not misuse the certificates installed on their servers don't use AWS. If you don't trust another hoster to not access your systems don't host there. If you don't trust the software of your OS to protect your certificate properly don't use it. There is no 100% security and the less you trust somebody the more you need to do by your own - if you can trust yourself to do it properly. – Steffen Ullrich May 09 '18 at 10:28
  • Sorry maybe I need to rephrase myself. Your answer were quite holistic. I edited my question for a more specific example. I.e. Yes, I do trust AWS, but anyone can put up another S3 bucket having the same wildcard SSL cert which my users installed. I understand the point of having HTTPS is that MITM would not be possible. It doesn't seem like this case with AWS S3, or I misunderstood the trick there. – Khanh Nguyen May 09 '18 at 10:33
  • @KhanhNguyen: see edited answer which addresses this point. – Steffen Ullrich May 09 '18 at 10:38
  • That's right. It's clear to me now, certainly internal S3 routing will not allow such tricks by checking intended domain in HTTP header. Super. – Khanh Nguyen May 09 '18 at 10:46