Comment by oasisbob
15 hours ago
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...