SSRF in GQL asset mutation - incomplete IP denylist + post-fetch validation

Beschreibung

Die GraphQL-Mutation `saveAsset( file: { url: ... })` holt eine vom Angreifer bereitgestellte URL-Serverseite. Die Anti-SSRF-Logik, die von früheren Beratern (GHSA-gp2f-7wcm-5fhx, GHSA-v2gc-rm6g-wrw9, GHSA-3m9m-24vh-39wx) eingeführt wurde, ist unvollständig, so dass ein GraphQL-Token nur auf "Volumes" beschränkt ist.:create kann: 1. Lesen Sie interne HTTP-Antworten von jedem Ziel, dessen IP-Adresse "validateIp()" überschreitet, aber vom Angreifer nicht direkt erreichbar ist. `validateIp()` stützt sich auf `FILTER FLAG NO PRIV RANGE | FILTER FLAG NO RES RANGE`, was CGNAT `100.64.0.0/10` (RFC 6598) oder NAT64 `64:ff9b::/96` nicht abdeckt. Anfragen an diese Bereiche werden akzeptiert, und die Antwort wird als Asset gespeichert, und der Angreifer lädt sie herunter – vollständige Offenlegung des Inhalts. 2. Erzwingen Sie interne GET-Anfragen an jeden Host (RFC1918/Loopback/Metadaten enthalten). Der einzige IP-Check läuft in Guzzles "on stats"-Rückruf, der ausgelöst wird, nachdem cURL bereits den Response-Body angeschlossen und auf die Festplatte geschrieben hat. Die Ablehnung bricht das Asset Save ab, aber die Outbound-Anfrage wurde bereits ausgestellt. 3. Blinde Aufzählung interner Hosts/Ports. Die vier eindeutigen, Client-sicheren Fehler-/Erfolgsergebnisse (auch bei ausgeschaltetem `devMode`) plus Connect/Timeout-Timing von einem Orakel für Ziele, deren Körper zurückgehalten werden. Dies ist eine privilegierte Verletzung: Ein Token, das nur zum Erstellen von Assets in einem Volume autorisiert ist, sollte nicht in der Lage sein, willkürliche serverseitige HTTP-Anforderungen zu steuern oder interne Dienste zu lesen. Eine Autorisierung mit geringem Privileg, die nur für die Erstellung von Assets zuständig ist, wird in willkürliche ausgehende serverseitige Anfragen und die Offenlegung interner HTTP-Inhalte eskaliert - eine Verletzung von Privilegien / Vertrauensgrenzen im nativen Craft-Code.

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 5.10.6, 4.18.2.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Pixel & Tonic Craft CMS.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.