Comment by js2
14 hours ago
Let's assume the proxy is external and the agents cannot route around it. In that case, the difference between:
curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' \
https://20.223.25.152/...
Vs editing `/etc/hosts` with:
20.223.25.152 bypass.blob.core.windows.net
And doing:
curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' \
https://bypass.blob.core.windows.net
Is that in the first case, the proxy sees a request like this:
POST https://20.223.25.152/...
Host: wabi-north-europe-i-primary-api.analysis.windows.net
Vs:
POST https://bypass.blob.core.windows.net/...
Host: wabi-north-europe-i-primary-api.analysis.windows.net
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?
Could this be SOCKS-specific behavior?
Haven't dove into RFC1928 yet, but curl documents the `--socks5-hostname` option and mentions that DNS resolution can be the responsibility of the client, or the proxy.
Wondering if it's possible the proxy receives both the destination IP address (resolved by the client) as well as the purported connection hostname, and is performing filtering on the later.
I suspect there could be other layers in their proxy too, eg for MiTMing TLS. `NO_PROXY` as described in the report might not be literally bypassing the proxy and sending a request directly from the client container, but rather a directive to the first tool/proxy layer to bypass later proxy layers.
Same fundamental question though: what is the agent trying to fool by editing `/etc/hosts`? I don't see how it helps bypass a proxy unless the proxy is reading the same `/etc/hosts`. In which case, why was using `--resolve` apparently sufficient to escape the POST sandbox?
Could the host name be in an allow list and then, when DNS resolution fails on the URL, the proxy falls back to the Host header for DNS resolution? I'm not an expert in Proxy config but I could understand, in the sea of typical http server config options, an option to fall back to the Host header if DNS fails on the URL.
1 reply →
> In the first case, given what we know, the proxy blocks the POST.
How do we know that?
The whole point is that something is inspecting all HTTP/HTTPS requests and only allowing POSTs to Azure Block Storage (`.*blob.core.windows.net`). Meanwhile the agent needs to make a POST request to a PBI host (`wabi-north-europe-i-primary-api.analysis.windows.net` / 20.223.25.152).
So a proxy should block any POST to 20.223.25.152 unless that IP somehow overlaps with ABS. But in that case, there's no reason for the agent to mess with `/etc/hosts` not `--resolve`. The agent could just use `curl` with the PBI IP in URL and the PBI Host header. But it doesn't do that.
The agent seems to think that it needs to exploit a difference between the actual destination IP and whatever is inspecting the contents of the connection and how it inspects that connection.
The agent has found some way to connect to PBI host 20.223.25.152, but made whatever is inspecting the connection think the destination is actually to ABS hosts `bypass.blob.core.windows.net`.
The only thing I can think of is an SNI bypass which fits with both `/etc/hosts` and `--resolve` techniques. In this case, `curl` will attempt to connect to the PBI host, but it will send an SNI header of `bypass.blob.core.windows.net`. This would make sense as an attempt to bypass a firewall inspecting the SNI header. I believe that Azure firewall is not so easily fooled, but maybe something else being used for filtering is.
Some references:
https://blog.compass-security.com/2025/03/bypassing-web-filt...
https://aws.amazon.com/blogs/security/enhance-tls-inspection...
> So a proxy should block any POST to 20.223.25.152 unless that IP somehow overlaps with ABS. But in that case, there's no reason for the agent to mess with `/etc/hosts` not `--resolve`. The agent could just use `curl` with the PBI IP in URL and the PBI Host header. But it doesn't do that.
I think this is the part I'm not following, and sorry if I've missed something. There are two ways to construct the request you showed. One is to mess with /etc/hosts. Another is to use `--resolve`. Just because the agent chose one doesn't mean it couldn't have done the other. What makes you think it couldn't have used `--resolve` as well?
1 reply →