4n4s4zi/tfo-connect-bypassBypassing von connect()-basierten Syscall-Regeln mittels TCP Fast Open (CVE-2026-63828 PoC)
connect()-basierten Syscall-Regeln mithilfe von TCP Fast Open (CVE-2026-63828 PoC)TCP Fast Open (TFO) ist eine Methode zur Initialisierung einer TCP-Verbindung, bei der der Client Daten im ersten an den Server gesendeten SYN-Paket übertragen kann. Das ist gut für die Geschwindigkeit, da das Hin und Her des anfänglichen TCP-Handshakes übersprungen werden kann. Es gibt mehr Implementierungsdetails, wenn man es in einer Produktionsumgebung einsetzen möchte, aber es ist nützlich, um einige syscall-basierte Regel-Engines zu umgehen, da es eine Möglichkeit ist, TCP-Verbindungen zu öffnen, ohne explizit den Syscall connect zu verwenden.
Aus Sicht der Syscalls sieht eine grundlegende TCP-Verbindung im Allgemeinen so aus:
socket() -> connect() -> write()/read()
Eine TFO-Verbindung wird jedoch mithilfe eines sendto-Syscalls mit dem Flag MSG_FASTOPEN initialisiert:
socket() -> sendto(...,MSG_FASTOPEN,...) -> write()/read()
Ich habe das eher als Nebenquest für etwas anderes erkundet, an dem ich gearbeitet habe, aber bei weiterer Recherche zu TFO tauchte CVE-2026-63828 als (kürzlich) bekannter Bypass speziell für netzwerkbeschränkte Prozesse in AppArmor auf. Es betrifft jedoch mehr als nur AppArmor, daher dachte ich, ich poste hier einen einfachen PoC.
Angenommen, du möchtest im Rahmen einer Post-Exploitation-Aufklärung einen Kubernetes-API-Server aus einem Container heraus abfragen, aber es gelten eBPF-, AppArmor- oder andere syscall-basierte Überwachungs-/Blockierungsregeln.
Wenn du keine schwergewichtige Netzwerk-Implementierung/Bibliothek im Userland verwenden möchtest und andere Syscall-Evasions-Primitive wie io_uring nicht verfügbar sind, könnte TFO nützlich sein. Auch hier gilt: Dies ist nur ein einfacher PoC und kein robuster TFO-Stack.
Portabler Build:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build test.go
Referenzen: