Angreifer nutzen BadHost, um sensible Endpunkte von KI-Agenten-Servern zu kompromittieren

Die Ursache liegt darin, wie Starlette Anforderungs-URLs erstellt, indem es den Host-Header mit dem Anforderungspfad aneinanderhängt, um request.url zu bilden. BadHost exponiert Endpunkte für KI-Agenten. Entdeckt von X41 D-Sec während einer örderten Prüfung, entsteht das Problem durch eine unsichere Verarbeitung des HTTP-Host-Headers.

Da der Host-Header nicht ordnungsgemäß bereinigt wird, können Angreifer bösartige Werte injizieren, die beeinflussen, wie die Anwendung den Anforderungsweg interpretiert.

Beispielsweise kann eine speziell gestaltete Anfrage wie „GET /protected" mit einem „Host: example.com/health?x=" Header dazu führen, dass die Anwendung die Anfrage so behandelt, als würde sie auf „/health" statt auf „/protected" zielen.

Technischer Hintergrund

Wenn Authentifizierungs-Middleware auf request.url.path zur Durchsetzung, ermöglicht diese Diskrepanz Angreifern, Schutzmaßnahmen vollständig zu umgehen.

Diese Schwachstelle betrifft insbesondere Middleware, die pfadebasierte Logik für Authentifizierungs- und Autorisierungsprüfungen, Whitelist- oder Blacklist-Filterung, Rate-Limiting oder Abrechnungsgatter sowie CSRF-Schutzmechanismen verwendet.

Das Problem erstreckt sich über mehrere Ebenen: ASGI-Server, URL-Verarbeitung Starlette und, was eine Erkennung durch konventionelle automatisierte Analysen erschwert. BadHost stellt eine erhebliche Bedrohung für KI-Ökosysteme dar, da viele moderne KI-Dienste auf FastAPI und Starlette als Grundlage setzen.

Technischer Hintergrund

Gefährdete Plattformen umfassen vLLM und LiteLLM-Inferenz- sowie Proxy-Server, KI-Agenten-Frameworks und Orchestrierungs-Backends, MCP (Model Context Protocol)-Server und Gateways sowie Tools wie Ray Serve, BentoML und Google ADK-Python, sofern diese benutzerdefinierte Middleware verwenden.

MCP-Server sind besonders anfällig, da sie aus Designgründen nicht authentifizierte OAuth-Entdeckungs-Endpunkte aussetzen und damit Angreifern einen vorhersehbaren und zuverlässigen Einstiegspunkt für Ausnutzung bieten.

Bei erfolgreicher Ausnutzung kann BadHost Angreifern ermöglichen, auf eingeschränkte LLM-Endpunkte zuzugreifen, API-Schlüssel und Zugangsdaten zu extrahieren, mit internen Agenten-Tools zu interagieren und KI-Rechenressourcen ohne legitime Berechtigung zu missbrauchen. Organisationen werden dringend aufgefordert, ohne Verzögerung Gegenmaßnahmen umzusetzen.

Sicherheitslage und Risiko

Das Aktualisieren 1.0.1 oder höher stellt sicher, dass fehlerhafte Host-Header sicher verarbeitet werden und damit den primären Angriffsvektor schließen.

Entwickler sollten request.url.path für Sicherheitsentscheidungen nicht verwenden, sondern sich auf robustere Mechanismen wie FastAPI's Depends() oder Security() für Authentifizierung und Autorisierung verlassen.

Der Einsatz, Caddy oder HAProxy vor ASGI-Servern hilft dabei, Host-Header zu validieren und zu normalisieren, bevor sie die Anwendung erreichen, was die Exposition weiter reduziert. Middleware Pfade inspizieren muss, bietet der Ersatz ["path"] eine sicherere Grundlage für die Logik.

Technik und Auswirkungen

Sicherheitsteams können ihre Umgebungen zudem mit spezialisierten Tools scannen, wie beispielsweise solchen der Nemesis-Automatisierungsplattform, um verwundbare Muster und exponierte Endpunkte in der KI-Infrastruktur zu erkennen.

Mit der beschleunigten Einführung zunehmende Komplexität der Absicherung vernetzter Systeme und hebt die Notwendigkeit gründlicher Überprüfungen der Middleware-Logik sowie strenger Eingabevalidierung hervor, um ähnliche Angriffsvektoren Zukunft zu verhindern. Abi ist Sicherheitsredakteurin und weitere Reporterin bei