4 ms·

You would point the application at the local port. It operates very similarly to SSH port forwarding. No fancy magic to intercept all traffic.

• philsnow 6y ago
  mostly copy-pasta from an earlier comment[0] of mine: https://github.com/99designs/aws-vault/issues/578 https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only months ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more. I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both. I appreciate that Boundary gives completely generic identity-aware-authenticated TCP sockets, but I don't know of a way, today, to make those not accessible to browsers through dns rebinding attacks. This is probably much much too far in the weeds and this is unlikely to contribute to a major breach (unlike the aws-vault one where of course attackers would try to access the fake metadata service on the default port, because it's high-value and on a well-known port), but I'm interested in the space. [0] https://news.ycombinator.com/item?id=23265509 https://news.ycombinator.com/item?id=23265509 [1] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-2.jpg https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...