5 ms·

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, sh

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.
- tptacek 7y ago
  1. Nobody competent would do this in a modern design. 2. Any security engineering team would flag this design. 3. Allowing https:// https:// (anything) .steampowered.com / (anything) allows for arbitrary redirection into any property under that domain, some of which could be user (or customer) controlled. Does that matter on this domain? Who cares? Why have a design where you even have to ask? The first contact with the load balancer should be HTTPS.
  - deleted 7y ago
    [deleted]
  - mtlynch 7y ago
    Hey Thomas, you actually kind of started me in web app security. You interviewed me for Matasano, and when I told you I didn't have experience with web apps, you overnighted me a copy of The Web Application Hacker's Handbook. You ultimately made me an offer, but after difficult deliberation, I ended up joining iSEC. Thanks again for sending me the book! It's been tremendously helpful. I 100% agree that people shouldn't design systems this way, and if I were still a pentester, I'd write it up if I found it. But if the implementation correctly checked the domain and verified it was https:// https:// (and maybe did some cert pinning), I couldn't justify anything higher than low severity. We've kind of gone way into the weeds on my made up example, but it was initially in response to this: >> > I think the author is partially at fault for repeatedly failing to communicate the issue clearly. > I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" ... If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. I just disagree with the idea that any plaintext HTTP request in an app inherently is a vulnerability.

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.

tptacek 7y ago
1. Nobody competent would do this in a modern design. 2. Any security engineering team would flag this design. 3. Allowing https:// https:// (anything) .steampowered.com / (anything) allows for arbitrary redirection into any property under that domain, some of which could be user (or customer) controlled. Does that matter on this domain? Who cares? Why have a design where you even have to ask? The first contact with the load balancer should be HTTPS.
- deleted 7y ago
  [deleted]
- mtlynch 7y ago
  Hey Thomas, you actually kind of started me in web app security. You interviewed me for Matasano, and when I told you I didn't have experience with web apps, you overnighted me a copy of The Web Application Hacker's Handbook. You ultimately made me an offer, but after difficult deliberation, I ended up joining iSEC. Thanks again for sending me the book! It's been tremendously helpful. I 100% agree that people shouldn't design systems this way, and if I were still a pentester, I'd write it up if I found it. But if the implementation correctly checked the domain and verified it was https:// https:// (and maybe did some cert pinning), I couldn't justify anything higher than low severity. We've kind of gone way into the weeds on my made up example, but it was initially in response to this: >> > I think the author is partially at fault for repeatedly failing to communicate the issue clearly. > I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" ... If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. I just disagree with the idea that any plaintext HTTP request in an app inherently is a vulnerability.