QUIC trickery

Its probably lesser known that OpenSSL in their recent 3.5.0 Beta version has added full support (client and server side) for TLS over QUIC.

RFC9001 runs the TLS messages - including handshake and anything - on top of the QUIC transport layer. This is somewhat exciting, as it means that - if you already have an OpenSSL infra - you can get QUIC support with relatively little effort into your app. So I went ahead and added QUIC support for crash. As roaming/mobility is not yet supported with OpenSSL's QUIC impl, so it is neither supported in crash. For roaming and suspend/resume you still use DTLS. But SOCKSing your connections through GfW with QUIC is working.

As a funny side-note, as the QUIC support within OpenSSL is pretty new, it would not have been possible to use AI coding agents to add support for it, as they could not have learnt about it yet. This kind of model-rot has implications about malware development and forensics which I am not yet digging into here.

Whats the benefits and drawbacks of using QUIC in general and where is the fun ahead?

QUIC itself effectively was designed for HTTP/3 - as a replacement for HTTP/1 and HTTP/2 over TCP. It runs on top of UDP and has its own ordering, reliability and security layer. Unlike DTLS, which does not offer reliability beyond the handshake.

One of the drawbacks for me is, that it requires a minimum MSS of 1200, which means that QUIC is not a tunneling-friendly protocol, since it requires a lot more effort to tunnel it across links with a lesser MTU, e.g. DNS or reduced NTP (Tier1 networks sometimes limit NTP pkt sizes). But of course you can tunnel other protos across QUIC.

So, whats good about QUIC? It adds new attack surfaces from many sides: Implementation wise with many new software stacks that could potentially contain bugs as well as from protocol side since its not using TCP and therefore it is easier to spoof and confuse monitoring systems and firewalls. This brings me to the point that QUIC is an exfiltration-friendly protocol. As there basically is no notion of [IP:port] endpoint pairs but IPs and ports can be floating. It is much harder, if not impossible, to detect or supress UL/DL of large amounts of data between networks. As there is no network-level connection as with TCP, there is no connection that could be resetted and blocking only works for that particular [IP:port] pair, which is a moving target. Whats more, as QUIC does not require OS/Kernel support, it would be possible by malware to carry free-standing implementations and run it on the most ancient systems, if it just speaks UDP.

I will not dig further in the pro's and con's of QUIC and TLS-over-QUIC, since the nifty details should be reserved for paying customers. :)

New bridge protocol trickery

The Network Time Protocol in its newest version (NTP4) allows to add extension fields beyond their standard header.

So we are going to shamelessly use it for our own profit, which means I am integrating NTP4 into fraud-bridge to have another protocol at hand when someone is blocking traffic.

Some tests in Germany showed that large providers block NTP packets larger than 256 bytes (presumably "DoS protection"?), so I made the MSS option configurable in fraud-bridge so that the TCP stack is sending segments small enough to fit. It still allows for good enough performance to tunnel web-sessions and messengers.

AI 0day trickery

This month I declared Month of AI framework bugs, and here are the 0days that came around. I analyzed the two most common AI frameworks, PyTorch, (with TorchVision) and TensorFlow which are mostly Python with C++ at the lower level (for serving trained models or deploying the actual training to GPUs via CUDA libs). Both frameworks were/are actively developed and backed by Big Tech, which results in certain company repos being hardcoded in the Python code as trusted, among other artefacts.

For classical security - i.e. keeping your infra safe from intruders - you can basically divide the attack surface in two parts.

1. Server-side to get RCE on the deployed servers or somehow get a shell by the prompt or REST/gRPC interfaces.

2. Client-side to get RCE on either developer machines or also on the deployed instance at the server, but by other means than the REST/gRPC interface.

I skipped the Pickle/Deserialization surface this time, as this is a known breaking point being addressed already (although not with great results). All results of my research can be found in my tensor-pwn repo.

The actual results:

* File overwrite in all Python's core tar extractor module can lead to  RCE by overwriting either ~/.bashrc or Python code in the .local cache.

* When obtaining datasets for training and/or deployment on the server, the fetched tar archives will be extracted and the previous issue manifests. This is bad enough for https:// URLs already, as its known that relying on CA-bundle is not sufficient to prevent RCE attacks. But ...

* ... some frameworks replace https:// URLs by http:// on failure, so that the archives will eventually be fetched in plain-text and can be replaced on the network-path even by attackers who are not capable of infecting HTTPS sessions (this is far easier than it sounds). This leads to unauthenticated RCE when deploying torchvision-based models. Note, that the training data fetch and extract (read: overwrite/RCE) often happens automatically when the class of the model is instanciated and there is no manual download necessary. Therefore this resembles more of a 0click RCE. Some training data downloaders contain MD5 hashsum-"protection" but this is not the case for the Kinetic model thats shown in the screenshot below. MD5 is considered broken anyways, so downloaders that rely on it are eventually subject to bespoken RCE conditions too.

* RCE and LPE opportunities when downloading and executing scripts when developers handle with the `cuda.memory` module.

So, whatever preference you might have you can choose which bug you like most and give it the best chances for owning AI deployments in your pen-tests. 

Enjoy the repo!

More censorship trickery

I updated some of my git repos. crash can now be used with Disguise Filters to serve an innocent redirect webpage when certain secrets are not passed beforehand so nobody except you will ever see that there is a shell server inside, even if they observe the SNIs that are in use. I also updated the docu on how you setup WA proxies with it since this changed in newer versions of the app.

Then there is an entirely new PoC repo to tunnel traffic through passkey servers. Thx to the ppl that tested it with me. Check it out, its fancy new Perl code!

Easterbug trickery

 Happy Easteregg searching.

rustup client sides trickery

I tried to understand some things about the rust build/eco system and were surprised how easy it is to pwn. Wonder whether its the same for golang.

crash + psc 37c3 release

crash and psc now build and run on Windoze systems. psc contains a new feature that lets you bounce binary data back and forth through your local pty to a e.g. remote netcat, dd or other utilities so you can fwd SSH connections directly through your terminal or up/download binary data without any remote agent.

Roaming trickery

I added support for roaming and suspend/resume to crash. Now you can change your IP, VPN, physlayer, NAT, VM-routing etc. at runtime and stay connected to your remote shell. You may also suspend the session to a ticket and resume it from a different laptop from the other side of the globe while keeping your shell.

Privacy side note: As always, this implies that you know what you are doing when using VPNs. Disrupted VPN routing may leak your IP address regardless of roaming but with roaming enabled you wouldn't immediately notice as the session just continues. However, to reveal the IP a single leaked packet suffices.

It is now also possible to build and run crash and psc on Windows, including all the nice features.

More crash + psc trickery

I reworked the local address binding and connecting part of my anti censorship tools crash and psc, so it is now possible to use SOCKS5 client side connects by using -x (similar to curl) and to let the SOCKS5 proxy resolve DNS names (-N) in order to allow browsing with chrome (but check README).

You can also check out @fullspectrumdev's blog writeups on pentest use-cases and cross-compilation.

Interestingly, OpenSSH now also supports traffic blinding, which is included in crash since years.

New 7350 0day trickery (cybah cybah)

 

Manjaro seems to be quite popular distro, according to distrowatch. LPE can be found here.