My 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.
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?
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.
The only thing that makes sense to me at this point is that this was an SNI bypass. By using either `/etc/hosts` or `curl --resolve` like this:
That will cause `curl` to make a connection to 20.223.25.152:443 with a ClientHello SNI=bypass.blob.core.windows.net. Presumably this connection is then allowed to continue. The server is likely going to send back the wrong certificate, thus the `-k`, but then the HTTP Host header selects the correct server.So that all fits. What doesn't make sense is that these agents were allegedly running in Azure and AFAICT this isn't sufficient to bypass Azure network restrictions/firewall which enforces that the SNI hostname matches the destination IP by doing the DNS resolution on the SNI hostname itself.
In any case, the environment should be blocking all outbound port 80/443 connections except to the proxy or to Azure Block Storage. But it seems that's not the case, that `curl` is able to connect directly to 20.223.25.152:443, and that maybe something else is doing SNI filtering that's more easily fooled than Azure firewall. Certainly some firewalls are (or have been) susceptible to SNI bypass:
https://dl.ifip.org/db/conf/im/im2015exp/137348.pdf
Edit: the agents refer to it as an SNI bypass:
> Breakthrough: independently reproduced Azure SNI allowlist bypass and POSTed captured qbody
https://collusion.wiki/explorer/page/dse~Apr25OECDLive.html#...
Further SNI mentions on these pages:
https://collusion.wiki/explorer/page/dse~OAIEquityDec02.html
https://collusion.wiki/explorer/page/dse~OECDEquityFeb22Live...
https://collusion.wiki/explorer/page/dse~OECDEquityFeb23Live...
https://collusion.wiki/explorer/page/dse~OECDEquityLiveApr19...
https://collusion.wiki/explorer/page/dse~OECDEquityMay28Live...
https://collusion.wiki/explorer/page/dse~OECDJun26PrecisionS...
https://collusion.wiki/explorer/page/dse~OpenAIResearchMar22...
> 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?
Your initial question was how do we know that the proxy blocks POST requests. Perhaps I went on a tangent with my answer, but we know that because the agents were trying to find a way around the proxy.
So then I assumed that editing `/etc/hosts` was an attempt to fool a proxy co-located on the same host as the agent, which editing `/etc/hosts` would do, but using `--resolve` would NOT do.
But after looking into it more I no longer think that's the case. It turns out that some of agents did use `--resolve` while others used `/etc/hosts`. This only makes sense as an SNI bypass, which once I downloaded the full dataset and searched for, is what the agents believe they were doing:
https://news.ycombinator.com/item?id=49570417
So the agents were skipping the proxy entirely, then getting past additional network restrictions that should have prevented them from doing so by exploiting a weakness in whatever was supposed to be preventing them from doing so by lying about the SNI hostname.
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.