abraxas/sonic-gnmi-noauthDocumenta y reproduce una falla de autenticación fail-open en SONiC gNMI donde un mapa UserAuth vacío permite escrituras gNMI Set y gNOI sin autenticación, con un entorno de laboratorio en loopback.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sonic-gnmi-noauth
Análisis: https://abraxaslabs.tech/research/sonic-gnmi-noauth
SONiC gNMI f13a08e0440f - SONiC Foundation / sonic-net
NOS comunitario de SONiC. No es Dell Enterprise SONiC. No es SonicWall SonicOS. El comité no emite CVE. gnmi-native.sh sabe que omitir --client_auth deshabilitaba la autenticación por completo, así que cuando falta user_auth fuerza el modo de certificado. Fail-closed. Pero luego nunca pasa --ca_crt cuando los certificados están ausentes. setupFlags desactiva el certificado porque no hay CA. authenticate() trata el mapa vacío como éxito. Las escrituras nativas y de translib siguen compiladas (ENABLE_NATIVE_WRITE=y). Dos conjuntos de flags de producción, mismo fallo: ToR por defecto --noTLS --bind_address 127.0.0.1; SmartSwitch DPU --insecure --allow_no_client_auth, bind vacío, todas las interfaces, puerto 8080.
Un UserAuth vacío tras desactivar el certificado equivale a escrituras gNMI Set y gNOI sin autenticación. La DPU sin certificados queda expuesta remotamente en :8080.
| ID | aún sin CVE |
| CWE | CWE-306, CWE-287 |
| CVSS | Crítica: 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (DPU sin certificado). El ToR por defecto tiene el mismo fallo en 127.0.0.1:8080 (Alta, local). |
| Producto | sonic-gnmi / sonic-buildimage |
| Afectado | sonic-gnmi hasta master f13a08e0440f; lanzador 9495839742e4 |
| Autenticación | sin autenticación |
| Licencia | GNU Affero GPL v3.0 |
| Laboratorio | solo 127.0.0.1 |
En una SmartSwitch DPU sin certificados gNMI: desde la red, TCP :8080, sin JWT, sin PAM, sin certificado de cliente. Invocar gnmi.gNMI/Set (CONFIG_DB nativo / translib). Invocar gnoi.debug.Debug. Reiniciar. Restablecer de fábrica. File.Put bajo /tmp, /var/tmp, /host.
En un ToR/leaf por defecto sin certificados: cualquier proceso que pueda alcanzar 127.0.0.1:8080 hace lo mismo. El contenedor gnmi usa la red del host, así que ese loopback es el del host.
Eso significa reescritura de la configuración del switch y ejecución de comandos en el host como admin, sin autenticarse. La lista blanca de Debug incluye docker, config, redis-cli, sonic-installer, reboot. El admin por defecto está en docker y en %sudo. No es la contraseña admin documentada por defecto. KillProcess sigue devolviendo Unauthenticated con UserAuth vacío. No lo uses como oráculo de éxito.
Primero leí SECURITY.md. sonic-net/SONiC es la wiki. El código está en los árboles hermanos sonic-net/*. Luego diez búsquedas sobre esos pins: inyección en CLI, autenticación REST, gNMI Set, PAM de hostcfgd, RESTCONF, ZTP, imagen Redis/sshd/sudo, valores por defecto de FEATURE, GCU/SSTI, DHCP/LLDP/SNMP. Sin switch en vivo. El umbral era Crítica/Alta.
La mayor parte de esa barra ya está cerrada o no es predeterminada. sonic-restapi es INCLUDE_RESTAPI ?= n. El lanzador de producción de RESTCONF fuerza PAM. El Redis del host es 127.0.0.1 sin requirepass, lo cual es un primer salto, no un hallazgo. El contenedor gnmi no es opcional. INCLUDE_SYSTEM_GNMI = y. La FEATURE gnmi está habilitada. Host net, host pid, host userns.
No levanté una imagen sonic-vs completa. El laboratorio es un fino envoltorio gRPC de extractos verificados con SHA256 de setupFlags y authenticate() del pin f13a08e0440f. Ambos listeners devolvieron SONIC-GNMI-NOAUTH-WITNESS con auth_enabled=false y enable_native_write=true. UserAuth con contraseña y sin credenciales es Unauthenticated. Ese es el salto real, no un stub que siempre tiene éxito.
Falsos caminos ya registrados: KillProcess Unauthenticated (ese RPC ya rechaza UserAuth vacío - el laboratorio requiere el salto de authenticate() en la ruta Set); Probe OK cuando UserAuth con contraseña está activado y no hay credenciales (entonces el oráculo es un stub); un gadget docker de gNOI Debug, payload de nsenter, reverse shell. Teatro. Apuntar esto a una caja Dell Enterprise SONiC, o a un SonicWall. Producto equivocado.
cd lab
./run.sh
Dirígete solo a 127.0.0.1:18080 (ToR en texto plano) y 127.0.0.1:18081 (DPU TLS-inseguro). gRPC ligero, no una imagen DPU completa. Los extractos de Pin se hashean en el build contra sonic-gnmi f13a08e0440f.
IOC tor-connect 127.0.0.1:18080 plaintext no-metadata
IOC tor-check witness=SONIC-GNMI-NOAUTH-WITNESS auth_enabled=false enable_native_write=true user_auth_any=false mode=tor
IOC dpu-connect 127.0.0.1:18081 tls-insecure no-client-cert no-metadata
IOC dpu-check witness=SONIC-GNMI-NOAUTH-WITNESS auth_enabled=false enable_native_write=true user_auth_any=false mode=dpu
IOC tor-negative status=UNAUTHENTICATED
IOC dpu-negative status=UNAUTHENTICATED
SUCCESS SONIC-GNMI-NOAUTH who=unauth tor=18080 dpu=18081 SONIC-GNMI-NOAUTH-WITNESS
Si UserAuth está vacío tras eliminar el certificado, no se debe servir la escritura Set/gNOI, o no se debe escuchar fuera de loopback. Copiar UserAuth también en la ruta --noTLS. Aprovisionar certificados de servidor y una CA para que --ca_crt esté configurado y el modo de certificado no quede sin establecer. No ejecutar SmartSwitch DPU sin certificado (--insecure --allow_no_client_auth con CA vacía) en un :8080 accesible. Ambos listeners deben devolver Unauthenticated para UserAuth vacío en la ruta de escritura.