4 ms·

Other way around, boundary needs to exec your client application. They're more clear about how it works here: https://www.boundaryproject.io/docs/getting-starte

Other way around, boundary needs to exec your client application. They're more clear about how it works here: https://www.boundaryproject.io/docs/getting-started/connect-to-target https://www.boundaryproject.io/docs/getting-started/connect-... Boundary comes with built-in wrappers for ssh, rdp, and postgres, but you can "boundary exec" to run some other application inside the TCP-wrapped transport, apparently.

zokier 6y ago
Some sort of LD_PRELOAD style trickery? Or are they intercepting syscalls? edit: seems nothing that complicated, more like ssh-style tunnel where Boundary has a local listening socket which you need to point the client to. That is if I'm understanding it correctly.
- armon 6y ago
  That is correct! The local proxy has a listening socket and handles all the authentication, encapsulation, and forwarding transparently.
  - parliament32 6y ago
    So does it intercept all connections on that port (from the client app) and pass them along? Or do I need to reconfigure my client application to talk to localhost:whatever? Your only example is that curl using a hostname, it's not really clear.
    - armon 6y ago
      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-...
  - zokier 6y ago
    I started thinking, using network namespaces to intercept traffic from client applications would be pretty neat trick.

zokier 6y ago

Some sort of LD_PRELOAD style trickery? Or are they intercepting syscalls? edit: seems nothing that complicated, more like ssh-style tunnel where Boundary has a local listening socket which you need to point the client to. That is if I'm understanding it correctly.

armon 6y ago
That is correct! The local proxy has a listening socket and handles all the authentication, encapsulation, and forwarding transparently.
- parliament32 6y ago
  So does it intercept all connections on that port (from the client app) and pass them along? Or do I need to reconfigure my client application to talk to localhost:whatever? Your only example is that curl using a hostname, it's not really clear.
  - armon 6y ago
    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-...
- zokier 6y ago
  I started thinking, using network namespaces to intercept traffic from client applications would be pretty neat trick.