abraxas/sonic-gnmi-noauthDocumenta e riproduce una vulnerabilità di autenticazione fail-open in SONiC gNMI, dove una mappa UserAuth vuota consente scritture gNMI Set e gNOI non autenticate, con un ambiente di laboratorio su loopback.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · sonic-gnmi-noauth
Write-up: https://abraxaslabs.tech/research/sonic-gnmi-noauth
SONiC gNMI f13a08e0440f - SONiC Foundation / sonic-net
NOS SONiC della community. Non Dell Enterprise SONiC. Non SonicWall SonicOS. Il comitato non emette CVE. gnmi-native.sh sa che omettere --client_auth disabilitava completamente l'autenticazione, quindi quando manca user_auth forza la modalità cert. Fail-closed. Poi non passa mai --ca_crt quando i certificati sono assenti. setupFlags rimuove il cert perché non c'è una CA. authenticate() considera la mappa vuota come successo. Le scritture native e translib restano compilate (ENABLE_NATIVE_WRITE=y). Due set di flag di produzione, stesso salto: ToR predefinito --noTLS --bind_address 127.0.0.1; SmartSwitch DPU --insecure --allow_no_client_auth, bind vuoto, tutte le interfacce, porta 8080.
Un UserAuth vuoto dopo la rimozione del cert equivale a gNMI Set e scritture gNOI non autenticati. Un DPU senza certificati è remoto su :8080.
| ID | nessuna CVE al momento |
| CWE | CWE-306, CWE-287 |
| CVSS | Critico: 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (DPU senza cert). Il ToR predefinito presenta lo stesso salto su 127.0.0.1:8080 (Alto, locale). |
| Prodotto | sonic-gnmi / sonic-buildimage |
| Affetto | sonic-gnmi fino a master f13a08e0440f; launcher 9495839742e4 |
| Autenticazione | non autenticato |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Su uno SmartSwitch DPU senza certificati gNMI: dalla rete, TCP :8080, nessun JWT, nessun PAM, nessun certificato client. Chiamare gnmi.gNMI/Set (CONFIG_DB nativo / translib). Chiamare gnoi.debug.Debug. Riavviare. Ripristino di fabbrica. File.Put sotto /tmp, /var/tmp, /host.
Su un ToR/leaf predefinito senza certificati: qualsiasi processo in grado di raggiungere 127.0.0.1:8080 fa lo stesso. Il container gnmi è in host net, quindi quel loopback è quello dell'host.
Ciò significa riscrittura della configurazione dello switch ed esecuzione di comandi sull'host come admin, senza autenticarsi. La whitelist di Debug include docker, config, redis-cli, sonic-installer, reboot. L'admin predefinito è nei gruppi docker e %sudo. Non la password admin predefinita documentata. KillProcess restituisce comunque Unauthenticated con UserAuth vuoto. Non usarlo come oracolo di successo.
Ho letto prima SECURITY.md. sonic-net/SONiC è la wiki. Il codice sono gli alberi fratelli sonic-net/*. Poi dieci ricerche su quei pin: injection nella CLI, autenticazione REST, gNMI Set, PAM di hostcfgd, RESTCONF, ZTP, Redis/sshd/sudo nell'immagine, valori predefiniti FEATURE, GCU/SSTI, DHCP/LLDP/SNMP. Nessuno switch reale. La soglia era Critico/Alto.
La maggior parte di quella barra è già chiusa o non predefinita. sonic-restapi è INCLUDE_RESTAPI ?= n. Il launcher di produzione di RESTCONF forza PAM. L'host Redis è 127.0.0.1 senza requirepass, il che è un primo hop, non un finding. Il container gnmi non è opzionale. INCLUDE_SYSTEM_GNMI = y. FEATURE gnmi è abilitata. Host net, host pid, host userns.
Non ho creato un'immagine sonic-vs completa. Il lab è un sottile wrapper gRPC attorno a estratti verificati tramite SHA256 di setupFlags e authenticate() dal pin f13a08e0440f. Entrambi i listener hanno restituito SONIC-GNMI-NOAUTH-WITNESS con auth_enabled=false e enable_native_write=true. Password UserAuth senza credenziali è Unauthenticated. Questo è il vero skip, non uno stub che riesce sempre.
Vicoli ciechi già registrati: KillProcess Unauthenticated (quella RPC rifiuta già UserAuth vuoto - il lab richiede lo skip di authenticate() sul percorso Set); Probe OK quando password UserAuth è attivo e non ci sono credenziali (allora l'oracolo è uno stub); un gadget docker gNOI Debug, payload nsenter, reverse shell. Teatro. Puntare questo contro un box Dell Enterprise SONiC, o un SonicWall. Prodotto sbagliato.
cd lab
./run.sh
Punta solo a 127.0.0.1:18080 (ToR in chiaro) e 127.0.0.1:18081 (DPU TLS-insecure). gRPC leggero, non un'immagine DPU completa. I pin degli estratti sono sottoposti a hash in fase di build rispetto a 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
Se UserAuth è vuoto dopo la rimozione del certificato, non servire la scrittura Set/gNOI, oppure non ascoltare al di fuori del loopback. Copiare UserAuth anche nel percorso --noTLS. Effettuare il provisioning dei certificati del server e di una CA in modo che --ca_crt sia impostato e la modalità certificato non sia disattivata. Non eseguire SmartSwitch DPU senza certificato (--insecure --allow_no_client_auth con CA vuota) su una :8080 raggiungibile. Entrambi i listener devono restituire Unauthenticated per UserAuth vuoto nel percorso di scrittura.