4n4s4zi/tfo-connect-bypassBypass des règles syscall basées sur connect() à l'aide de TCP Fast Open (PoC CVE-2026-63828)
connect() à l'aide de TCP Fast Open (PoC CVE-2026-63828)TCP Fast Open (TFO) est une méthode d'initialisation d'une connexion TCP dans laquelle le client peut envoyer des données dans le paquet SYN initial envoyé au serveur. C'est bénéfique pour la vitesse car les allers-retours de la poignée de main TCP initiale peuvent être évités. Il y a plus de détails d'implémentation si vous souhaitez l'utiliser dans un environnement de production, mais c'est utile pour contourner certains moteurs de règles basés sur les syscalls, car c'est un moyen d'ouvrir des connexions TCP sans utiliser explicitement le syscall connect.
D'un point de vue syscall, une connexion TCP de base ressemble généralement à :
socket() -> connect() -> write()/read()
Une connexion TFO, cependant, est initialisée à l'aide d'un syscall sendto avec le drapeau MSG_FASTOPEN :
socket() -> sendto(...,MSG_FASTOPEN,...) -> write()/read()
J'ai en quelque sorte exploré cela comme une quête secondaire pour autre chose sur laquelle je travaillais, mais en faisant plus de recherches sur TFO, CVE-2026-63828 est apparu comme un contournement connu (récent) spécifique aux processus confinés au réseau dans AppArmor. Cela s'applique à plus que simplement AppArmor, donc j'ai pensé publier un PoC de base ici.
Disons que vous vouliez interroger un serveur API Kubernetes depuis l'intérieur d'un conteneur dans le cadre d'une recon post-exploitation, mais qu'il existe des règles de surveillance/blocage basées sur les syscalls eBPF, AppArmor ou autres.
Si vous ne souhaitez pas utiliser une implémentation/bibliothèque réseau plus lourde dans l'espace utilisateur et que d'autres primitives d'évasion de syscalls comme io_uring ne sont pas disponibles, TFO pourrait être utile. Encore une fois, ceci n'est qu'un simple PoC et non une pile TFO robuste.
Build portable :
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build test.go
Références :