5 ms·

Plaintext HTTP in itself isn't a vulnerability. Suppose that Steam ran some kind of load balancing server at http://loadbalancer.steam.com http://loadbalancer.

Plaintext HTTP in itself isn't a vulnerability. Suppose that Steam ran some kind of load balancing server at http://loadbalancer.steam.com http://loadbalancer.steam.com (no TLS). Its only job is to respond to HTTP GET requests with the URL of the least-busy steam server like "https://a.store.steampowered.com" https://a.store.steampowered.com" or "https://b.store.steampowered.com" https://b.store.steampowered.com". If the mobile client makes the request to the load balancer over plaintext HTTP and then verifies that the response has the steampowered.com domain and is https:// https:// then that's not a vulnerability, despite the fact that an attacker can MitM the plaintext HTTP part. I would recommend that Steam just do everything over HTTPS for the sake of defense in depth, but I definitely wouldn't award a bounty to someone for proving they could MitM my load balancer and cause no damage. The worst the attacker can do in that scenario is cause the app to see network failures (specifically, TLS handshake failures), but if the attacker is middling traffic, that's possible regardless.

notwedtm 7y ago
There could also be a captive portal check going on.
djsumdog 7y ago
No. No. No. No! Everything about this is wrong. The load balancer ABSOLUTELY should be HTTPS only and all request from the app, from the very first request, should be over HTTPS. If you want more security, add Strict Transport security as well as certification pinning in the app. But at a very basic level, there is absolutely no excuse for this app to making HTTP plain-text requests to steam at all. In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com http://loadbalancer.steam.com, have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. You can't just have a plain text load balancer redirect to https because someone else can intercept you BEFORE that redirect takes place.
- detaro 7y ago
  > and then verifies that the response has the steampowered.com domain and is https://* https://* One would still need a justification for that design IMHO, but I don't think it is vulnerable to what you describe.
  - djsumdog 7y ago
    But why even deal with that complexity? It's another place where thinks can break or you forget something. You can verify the doamin there too, but that still doesn't mean you can just make the request for the redirect over http and think that's okay.
  - staticassertion 7y ago
    It's definitely a fine sanity check but I'd have to really think about whether it's a barrier. Immediate things I worry about are around URL parsing. Is evil.com<insert something here>steampowered.com going to pass as "steampowered.com" when it isn't? Will it handle punycode? All sorts of shit can go wrong when parsing a URL, and it's a real world problem when people implement the mitigation you're describing[0]. https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/ https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi... This is just for starters. I think if I were being paid to think about it I'd probably be able to come up with some more. Can I mess with DNS? Can I inject some other malicious payload into the page, to take advantage of other vulns? etc etc etc I would be extremely wary of this technique as a real boundary rather than just an assertion in code.
- mtlynch 7y ago
  >In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com http://loadbalancer.steam.com, have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to http://loadbalancer.steam.com http://loadbalancer.steam.com 2. Load balancer responds with a URL string like "https://a.steampowered.com" https://a.steampowered.com" 3. App verifies that the domain ends with "steampowered.com" and starts with "https://" https://" 4. If verification passes, app loads the response URL in the in-app browser In that case, replacing http://loadbalancer.steam.com http://loadbalancer.steam.com with a spoofed page doesn't do anything because the app's internal logic sees the response, not a human user. If you replaced it with anything but a https://*.steampowered.com https://*.steampowered.com, the app would refuse to load the URL, so I don't see the vulnerability.
Cpoll 7y ago
> verifies that the response has the steampowered.com domain and is https:// https:// But you're trading an easy solution (only use https:// https://) for several points of failures (validate potentially untrusted input all along the chain). > verifies that the response has the steampowered.com domain An attacker is going to look for any exploits on steampowered.com (open redirect, xss, etc.). So now your domain name check is insufficient, you also need to make sure that all of steampowered.com is secure (which, odds are, is managed by multiple teams).

notwedtm 7y ago

There could also be a captive portal check going on.

djsumdog 7y ago

No. No. No. No! Everything about this is wrong. The load balancer ABSOLUTELY should be HTTPS only and all request from the app, from the very first request, should be over HTTPS. If you want more security, add Strict Transport security as well as certification pinning in the app. But at a very basic level, there is absolutely no excuse for this app to making HTTP plain-text requests to steam at all. In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com http://loadbalancer.steam.com, have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. You can't just have a plain text load balancer redirect to https because someone else can intercept you BEFORE that redirect takes place.

detaro 7y ago
> and then verifies that the response has the steampowered.com domain and is https://* https://* One would still need a justification for that design IMHO, but I don't think it is vulnerable to what you describe.
- djsumdog 7y ago
  But why even deal with that complexity? It's another place where thinks can break or you forget something. You can verify the doamin there too, but that still doesn't mean you can just make the request for the redirect over http and think that's okay.
- staticassertion 7y ago
  It's definitely a fine sanity check but I'd have to really think about whether it's a barrier. Immediate things I worry about are around URL parsing. Is evil.com<insert something here>steampowered.com going to pass as "steampowered.com" when it isn't? Will it handle punycode? All sorts of shit can go wrong when parsing a URL, and it's a real world problem when people implement the mitigation you're describing[0]. https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/ https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi... This is just for starters. I think if I were being paid to think about it I'd probably be able to come up with some more. Can I mess with DNS? Can I inject some other malicious payload into the page, to take advantage of other vulns? etc etc etc I would be extremely wary of this technique as a real boundary rather than just an assertion in code.
mtlynch 7y ago
>In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com http://loadbalancer.steam.com, have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to http://loadbalancer.steam.com http://loadbalancer.steam.com 2. Load balancer responds with a URL string like "https://a.steampowered.com" https://a.steampowered.com" 3. App verifies that the domain ends with "steampowered.com" and starts with "https://" https://" 4. If verification passes, app loads the response URL in the in-app browser In that case, replacing http://loadbalancer.steam.com http://loadbalancer.steam.com with a spoofed page doesn't do anything because the app's internal logic sees the response, not a human user. If you replaced it with anything but a https://*.steampowered.com https://*.steampowered.com, the app would refuse to load the URL, so I don't see the vulnerability.

Cpoll 7y ago

> verifies that the response has the steampowered.com domain and is https:// https:// But you're trading an easy solution (only use https:// https://) for several points of failures (validate potentially untrusted input all along the chain). > verifies that the response has the steampowered.com domain An attacker is going to look for any exploits on steampowered.com (open redirect, xss, etc.). So now your domain name check is insufficient, you also need to make sure that all of steampowered.com is secure (which, odds are, is managed by multiple teams).