HTTP Terminator: AI znalazła desync i zero-day w Apache Traffic Server

HTTP Terminator to zaprojektowany przez Jamesa Kettle’a system do autonomicznego poszukiwania rozbieżności w implementacjach HTTP. Zamiast prosić model o „znalezienie podatności”, badacz dostarczył mu korpus specyfikacji, mechanizm generowania hipotez i kontrolowane środowisko pomiarowe. Wyniki objęły nowe wyzwalacze HTTP desync, techniki wzmacniające response queue poisoning oraz łańcuch, który z udziałem człowieka doprowadził do odkrycia błędu w Apache Traffic Server.

Najciekawsza lekcja nie brzmi „AI zastąpiła badacza”. System był produktywny dlatego, że ekspert zakodował w nim właściwe pytania, ograniczył przestrzeń eksperymentu i potrafił odróżnić anomalię od rzeczywistej granicy bezpieczeństwa.

Desynchronizacja to konflikt interpretacji

W architekturze reverse proxy co najmniej dwa komponenty odczytują ten sam strumień: front-end przyjmuje request, a back-end przetwarza przekazaną wiadomość. Jeśli inaczej ustalą jej długość lub semantykę nagłówków, fragment uznany przez jeden parser za ciało może stać się początkiem kolejnego żądania u drugiego parsera. Na współdzielonym połączeniu skutkiem może być przypisanie odpowiedzi do niewłaściwego użytkownika, obejście reguł routingu albo zatrucie kolejki odpowiedzi.

HTTP Terminator przetworzył 138 specyfikacji HTTP i SMTP, podzielonych na około 15 tysięcy fragmentów. Z połączeń reguł wygenerował około 30 tysięcy kandydatów i badał ich zachowanie na autoryzowanym zbiorze około 30 tysięcy witryn. Wstępny etap oznaczył blisko 700 systemów wymagających dalszej walidacji; ta liczba nie jest równoznaczna z 700 potwierdzonymi krytycznymi podatnościami.

Opis badań został przedstawiony w materiale PortSwigger „Can AI Do Novel Security Research? Meet the HTTP Terminator”. System odnalazł między innymi przypadki dwóch pasujących nagłówków Content-Length oraz technikę „dangling byte”, która pomagała zmienić niepozorną niezgodność parserów w response queue poisoning.

Dlaczego Apache Traffic Server wymagał człowieka

Autonomiczny skaner wykrywa korelacje: inne czasy odpowiedzi, niespodziewany status, nadmiarowe bajty albo zmianę kolejności. Nie rozumie automatycznie całej topologii celu. W przypadku Apache Traffic Server potrzebna była iteracyjna analiza badacza, aby z kilku pozornie niezależnych anomalii zbudować powtarzalny łańcuch i zgłosić błąd producentowi.

W publicznych relacjach problem jest wiązany z identyfikatorem CVE-2026-63078. Administrator powinien śledzić oficjalne advisory Apache Traffic Server dotyczące używanej linii, ponieważ samo powtórzenie numeru CVE z prezentacji nie zastępuje mapowania na konkretny build i pakiet dystrybucji.

System zaproponował także klasę nazwaną Shared-Parser Confusion. Człowiek musiał zweryfikować hipotezę, odrzucić fałszywe uogólnienia i określić, gdzie naprawdę przekraczana jest granica zaufania. To dobry model bezpiecznego użycia AI w badaniach: maszyna zwiększa przepustowość hipotez, ekspert odpowiada za dowód, wpływ i ujawnienie.

Jak bronić stos HTTP

1. Zmapuj każdą translację protokołu: CDN do load balancera, load balancer do proxy i proxy do aplikacji. Sama informacja „klient używa HTTP/2” jest niewystarczająca.
2. Preferuj HTTP/2 lub HTTP/3 end-to-end i eliminuj niepotrzebny upstream HTTP/1.1, gdzie to wspierane.
3. Ujednolić walidację metod i długości wiadomości na wszystkich warstwach. Odrzucaj sprzeczne, wielokrotne lub niejednoznaczne nagłówki zamiast je normalizować.
4. Jeżeli HTTP/1.1 pozostaje, allowlistuj metody na brzegu i back-endzie oraz ogranicz request body do metod, które faktycznie go potrzebują.
5. Wyłącz współdzielenie połączeń między kontekstami zaufania tam, gdzie nie można zagwarantować spójnego parsowania.
6. Testuj cały łańcuch produkcyjnych komponentów w autoryzowanym środowisku. Skan pojedynczego serwera nie odwzoruje desyncu tworzonego przez parę parserów.
7. Monitoruj serie odpowiedzi 400, rozjazdy długości, przedwczesne zamknięcia połączeń i odpowiedzi niepasujące do request ID użytkownika.

Fakty i analiza Breachroad

PortSwigger potwierdza skalę korpusu, kandydatów i odkryte klasy zachowań. Wstępne wskazanie przez automat nie jest równoważne potwierdzonej luce; przejście od anomalii do wpływu było pracą badawczą. Wniosek, że organizacje powinny traktować konfigurację proxy jako jeden kompozytowy parser, jest analizą Breachroad opartą na mechanice desynchronizacji.

Szkolenia AppSec pomagają deweloperom i operatorom rozumieć rozbieżności między warstwami. Pentest aplikacji webowej powinien obejmować prawdziwy łańcuch CDN–proxy–aplikacja, a nie wyłącznie bezpośredni port serwera.