4 ms·

>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 m

>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.
  - tptacek 7y ago
    What a nice comment! And in a thread where I am definitely not at my best (it's been an allergy migraine kind of day). This made my evening; thank you. iSEC was a great team! I'm more of an absolutist about HTTPS than you are, though. :) I feel like every once in awhile I need to plow face-first into the brick wall of a friendly comment like this just as a signal to dial it back a bit. It's been a challenging couple weeks. I'll dial it back a bit! Thanks again.
oarsinsync 7y ago
> 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. I’m going to take this as what the intention was when designing this solution. > 3. App verifies that the domain ends with "steampowered.com" and starts with "https://" https://" I’m going to take this to be what would have actually been coded in this solution. I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. This solution is fragile. Why not just do the whole thing over TLS to begin with and avoid this vulnerability in the first place?
- mtlynch 7y ago
  >I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. Yeah, that's a good point. That's my mistake in spitballing, but the vulnerability wouldn't exist in an implementation that properly checked the domain. Again, I 100% agree with you that it's fragile and not a good idea. I wouldn't design a system this way, and I would flag it if I reviewed an app that did this. I was just objecting to the idea that the discovery of any plaintext HTTP request is a bounty-worthy vulnerability.
folkhack 7y ago
This is an insanely flawed design and the responses to it are 100% factually correct in their assessment. loadbalancer.steampowered.com could still respond with a bad entry just as long as it fits the "https://*.steampowered.com" https://*.steampowered.com" pattern. If the application does some sort of SSL pinning you may have to MITM the handshake but that's not outside of the realm of possibility for a sophisticated attacker. I know it's just an example of how something COULD work but I strongly disagree that the following is correct: > The worst the attacker can do in that scenario is cause the app to see network failures Also - it's worth noting that all of this DNS talk really makes the whole SSL discussion moot. This is exactly why things like DNSSEC exist. If I'm able to point your traffic wherever you're done.
- tptacek 7y ago
  No, not at all: the same LAN access that allows him to spoof DNS also allows him to spoof the authenticated-data bit in the DNS header to bypass DNSSEC. This is one of the great failings of DNSSEC. DoH: different story.
  - folkhack 7y ago
    I'm prefacing this with I'm VERY new to DNSSEC (apologies). I guess I always assumed that DNSSEC would blow up when changing the destination of the point but have never really dealt with may DNSSEC rollouts outside of light maintenance. Thanks for a great response, I'm going to formally learn on DNSSEC because this is a good flag that I need better understanding. Also DoH is a new topic to me too so definitely going to "dig" on that as well ;)
    - tptacek 7y ago
      The right way to think of it is that DNSSEC is a server-to-server protocol. It makes it difficult for an upstream authority server to cache a spoofed record in your recursive server. It provides basically no on-the-wire security between your browser and your DNS server.

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.
- tptacek 7y ago
  What a nice comment! And in a thread where I am definitely not at my best (it's been an allergy migraine kind of day). This made my evening; thank you. iSEC was a great team! I'm more of an absolutist about HTTPS than you are, though. :) I feel like every once in awhile I need to plow face-first into the brick wall of a friendly comment like this just as a signal to dial it back a bit. It's been a challenging couple weeks. I'll dial it back a bit! Thanks again.

oarsinsync 7y ago

> 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. I’m going to take this as what the intention was when designing this solution. > 3. App verifies that the domain ends with "steampowered.com" and starts with "https://" https://" I’m going to take this to be what would have actually been coded in this solution. I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. This solution is fragile. Why not just do the whole thing over TLS to begin with and avoid this vulnerability in the first place?

mtlynch 7y ago
>I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https. Yeah, that's a good point. That's my mistake in spitballing, but the vulnerability wouldn't exist in an implementation that properly checked the domain. Again, I 100% agree with you that it's fragile and not a good idea. I wouldn't design a system this way, and I would flag it if I reviewed an app that did this. I was just objecting to the idea that the discovery of any plaintext HTTP request is a bounty-worthy vulnerability.

folkhack 7y ago

This is an insanely flawed design and the responses to it are 100% factually correct in their assessment. loadbalancer.steampowered.com could still respond with a bad entry just as long as it fits the "https://*.steampowered.com" https://*.steampowered.com" pattern. If the application does some sort of SSL pinning you may have to MITM the handshake but that's not outside of the realm of possibility for a sophisticated attacker. I know it's just an example of how something COULD work but I strongly disagree that the following is correct: > The worst the attacker can do in that scenario is cause the app to see network failures Also - it's worth noting that all of this DNS talk really makes the whole SSL discussion moot. This is exactly why things like DNSSEC exist. If I'm able to point your traffic wherever you're done.

tptacek 7y ago
No, not at all: the same LAN access that allows him to spoof DNS also allows him to spoof the authenticated-data bit in the DNS header to bypass DNSSEC. This is one of the great failings of DNSSEC. DoH: different story.
- folkhack 7y ago
  I'm prefacing this with I'm VERY new to DNSSEC (apologies). I guess I always assumed that DNSSEC would blow up when changing the destination of the point but have never really dealt with may DNSSEC rollouts outside of light maintenance. Thanks for a great response, I'm going to formally learn on DNSSEC because this is a good flag that I need better understanding. Also DoH is a new topic to me too so definitely going to "dig" on that as well ;)
  - tptacek 7y ago
    The right way to think of it is that DNSSEC is a server-to-server protocol. It makes it difficult for an upstream authority server to cache a spoofed record in your recursive server. It provides basically no on-the-wire security between your browser and your DNS server.