pavanchow/cve-2026-33234SSRF über smtplib-Raw-TCP-Sockets zur Umgehung der HTTP-Blocklist in AutoGPT SendEmailBlock
CVE-2026-33234 | Mittel 5.0 | GHSA-4jwj-6mg5-wrwf Autor: Pavan Nallamothu
Ich kartierte jede benutzergesteuerte Eingabe, die in der AutoGPT-Plattform das Netzwerk berührte. Die HTTP-Ebene war dicht abgeriegelt. Private IP-Bereiche (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), Loopback, Cloud-Metadaten-Endpunkte – alles blocklistiert. Ich bestätigte das HTTP-Gate aus mehreren Blickwinkeln. Nichts kam durch.
Dann öffnete ich das Konfigurationsschema des SendEmailBlock.
Das SMTP-Serverfeld war eine Freitexteingabe. Keine Admin-Anmeldedaten. Keine bei der Bereitstellung einmalig festgelegte, abgesicherte Konfiguration. Ein Feld, das jeder authentifizierte Benutzer nach Belieben ausfüllen konnte. Ich verfolgte den Codepfad und fand heraus, dass smtplib.SMTP() einen rohen TCP-Socket öffnet. Diese Verbindung durchläuft nie den HTTP-Pfad, in dem die IP-Blocklist lebt. Es gab zwei ausgehende Pfade in der Plattform. Nur einer war geschützt.
Ich richtete den SMTP-Server auf localhost:22 aus.
Der SSH-Banner kam in der Fehlermeldung zurück. smtplib verbindet sich mit allem, was du ihm gibst, versucht, eine SMTP-220-Begrüßung zu lesen, und wenn es etwas anderes erhält, verpackt es die rohen Bytes in einen SMTPConnectError. Diese Ausnahme propagiert durch das Ausführungsframework von AutoGPT und erscheint sauber in der Blockausgabe. Ich sah die SSH-Versionszeichenkette des Ziels, ohne jemals die HTTP-Ebene zu berühren.
Das machte es interessant. smtplib ist nicht nur ein E-Mail-Client. Es ist ein TCP-Banner-Grabber mit strukturierter Fehlerberichterstattung. Richte es auf Port 6379 aus und du erhältst die Protokollsignatur von Redis. Richte es auf einen geschlossenen Port aus und ConnectionRefusedError sagt dir, dass der Host lebt, der Port aber geschlossen ist. Richte es auf 169.254.169.254:80 aus und du bestätigst, dass der Cloud-Metadaten-Endpunkt erreichbar ist. Jeder Verbindungsversuch gibt einen anderen, aufschlussreichen Fehler zurück. Nicht-blinde SSRF durch eine Funktion, die E-Mails senden sollte.
Das SMTPConfig-Design verschärft das Problem. In einer sicheren Architektur wäre die SMTP-Serveradresse eine von Admins kontrollierte Anmeldedaten – einmal festgelegt, gesperrt, niemals Benutzern ausgesetzt. Stattdessen ist sie eine Eingabe pro Ausführung. Jeder authentifizierte Benutzer kontrolliert, wohin die Plattform TCP-Verbindungen öffnet.
# SendEmailBlock-Konfiguration – SMTP-Server auf interne Ziele setzen
# SSH scannen
smtp_server = "10.0.0.5"
smtp_port = 22
# Fehler offenbart: "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6"
# Redis scannen
smtp_server = "10.0.0.5"
smtp_port = 6379
# Fehler offenbart: "-ERR unknown command ..."
# Geschlossenen Port scannen
smtp_server = "10.0.0.5"
smtp_port = 9999
# Fehler offenbart: "ConnectionRefusedError" (Port geschlossen, Host lebt)
# Cloud-Metadaten treffen
smtp_server = "169.254.169.254"
smtp_port = 80
# Bestätigt Erreichbarkeit des Metadaten-Endpunkts
Ich verifizierte die gesamte Kette über die Blockausführungs-API:
# Äquivalenter Direkttest gegen die Blockausführungs-API
curl -X POST https://autogpt-platform/api/blocks/execute \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{
"block_id": "send_email_block",
"inputs": {
"smtp_server": "10.0.0.5",
"smtp_port": 22,
"to": "[email protected]",
"subject": "test",
"body": "test"
}
}'
# Antwort enthält SMTPConnectError mit SSH-Banner
graph LR
A[Angreifer setzt SMTP-Server auf interne IP] --> B[SendEmailBlock ruft smtplib.SMTP auf]
B --> C[Rohe TCP-Verbindung zu Ziel:Port]
C --> D{Antwortet der Dienst?}
D -->|Ja| E[Banner wird als SMTP-Begrüßung gelesen]
E --> F[SMTPConnectError mit Bannerdaten]
F --> G[Fehler propagiert zur Blockausgabe]
D -->|Nein| H[ConnectionRefused = Port geschlossen]
G --> I[Angreifer liest Dienstversion]Die Angriffsfläche, die sich hier öffnet, ist erheblich. SSH-Banner offenbaren exakte Versionen (OpenSSH_8.9p1 Ubuntu-3ubuntu0.6). Redis gibt seine Protokollsignatur preis. MySQL sendet seine Versionszeichenkette. Jeder Banner ist ein CVE-Nachschlag, der nur darauf wartet, zu passieren. Ein Angreifer kartiert das interne Netzwerk, identifiziert jeden laufenden Dienst und seine exakte Version und zielt dann auf den schwächsten. Alles von einem Textfeld mit der Bezeichnung „SMTP-Server“.
Drei fehlende Prüfungen verursachten dies: keine IP-Validierung auf dem SMTP-Pfad, keine Portbeschränkung, keine Ausnahmebereinigung. Die Plattform schützte jede ausgehende Tür außer der mit der Bezeichnung „ausgehende Post“.
Ich meldete das Problem an Significant Gravitas. Sie verstanden die architektonische Lücke sofort.
Behoben in: autogpt-platform-backend 0.6.52 (SMTP-Servervalidierung zur Blocklist-Durchsetzung hinzugefügt, Portbeschränkungen angewendet)