Luckily it was a bit obscure to find, had never been exploited, and we patched it within a few hours, but it was the most significant vulnerability found in anything I've been involved in.
Not come across Smokescreen (very cool) but this would have been one of a number of additional measures we could have put in place to avoid our vulnerability. I'm going to seriously consider using something like that going forward for all outbound server initiated requests.
Some good examples: - From screenshot service to Kubernetes account takeover at Shopify: https://hackerone.com/reports/341876 - SSRF and the Capital One breach: https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-th...
It not easy to prevent data exfiltration if you allow connections to, say, S3 and the attacker can just send arbitrary data to their personal bucket.
Why not just use a firewall? The technology has been around since the 80s?
If you're running on AWS (EC2, Lambda, ECS, EKS, etc), for example, you can query `http://169.254.169.254/latest/meta-data/` and it'll return a valid AWS access token. (That's how attaching IAM permissions to an EC2 box works.)
That's being replaced with v2[0] but, at the time when I was building these SSRF proxies, that didn't exist.
Beyond that case, it's also pretty common to have sidecar processes running on the same machine in modern Kubernetes deployments. Having an additional firewall proxy is too expensive for certain high performance environments, so it's commonly assumed that traffic to sidecars is trusted. (Mutual TLS is being used more frequently now, but that's non-trivial to deploy because key management is a PITA)
[0]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configur...
SSRF are fun, sometimes the leak credentials directly also - when server is based on a trusted subsystem the auth headers might leak outside.
I don't understand why they built this.
The problem described here is solved by using a firewall, where certain machines/processes are either allowed or disallowed to communicate with other machines/processes based on a set of rules. What else is there to it?
The point is being able to place a particular (but not all) HTTP(s) requests in a sandbox when you don’t want to allow it “privileged” access to endpoints.
If you simply firewall the metadata end point (or other microservice your app needs) then none of your app code that needs it will work either.
Just use a local on-box proxy with a firewall (or a dedicated virtual NIC with a firewall, doesn't matter, it's practically the same thing). Have your specific part of the code issue calls that pass through that specific proxy (or the virtual NIC). Apply whatever firewall rules you need.
This solution involves literally zero lines of in-house code to keep and maintain. It builds on the same industry-standard tools we've developed for the last 40 years. Provides all the flexibility and visibility you'll ever need. It's modular, and can extend to accommodate new requirements as they come.
But I guess it just doesn't look as fancy on your CV though.
There are use cases for network firewalls in cloud environments,but this isn't one of them.