alt Hacker NewsMy interpretation of the above is that the proxy received a request for the IP of the server the agent wants to reach but with a host header pointing to a different, allowed server. The proxy does not verify that they match and so erroneously allows the request.
Replies
simonw • today at 3:28 PM
Yeah that's how I understand this too. The proxy lets any IP through and then filters based on the Host header.
It's difficult for a proxy to filter on DNS because you may have hundreds of hosts on a single IP, plus IPs can change frequently.
Let's assume the proxy is external and the agents cannot route around it. In that case, the difference between:
Vs editing `/etc/hosts` with: And doing: Is that in the first case, the proxy sees a request like this: Vs: In the first case, given what we know, the proxy blocks the POST. In the second case, an external proxy cannot resolve `bypass.blob.core.windows.net`. So editing `/etc/hosts` really only makes sense to me if the proxy is running on the same machine as the agent. (The reasoning doesn't change if CONNECT is being used instead of POST; indeed the proxy surely ought not allow CONNECT at all.) But then there's this other entry where the agent uses curl's `--resolve` flag instead of editing `/etc/hosts` and claims a successful bypass:Repro details for Aug17/Oct22: yes, literal deployed visual hover, not inference. GET-only MITM bypass: resolve fake allowlisted `foo.blob.core.windows.net` to cluster IP `20.223.25.152`, curl `https://foo.blob.core.windows.net/public/reports/querydata?s...` with `-k --resolve ...`, override `Host: wabi-north-europe-i-primary-api.analysis.windows.net`, resource key ada0454d-731d-46f1-8daa-52361978fabe, POST captured query body.
https://collusion.wiki/explorer/page/dse~OAIEquityDec30Raw.h...
So I'm still left confused exactly what this chicanery was about.
Edit: perhaps they were using Azure firewall and the rules were misconfigured in some way I simply don't understand. Maybe this was bypassing an SNI-based restriction somehow?