¿Enrutador Netgear escuchando en el puerto 32764?

Tengo un Netgear DG834G con firmware V5.01.01. Desde el lado de la LAN, si lo escaneo en el puerto, está escuchando en el puerto tcp 32764. Intentar hacer telnet en este puerto me da la respuesta MMcS\xff\xff\xff\xff\0\0\0\0(en hexadecimal, obviamente).

Tengo UPnP deshabilitado, no es un puerto de administración remota y no está abierto en el lado de WAN. No puedo encontrar nada en la documentación de Netgear, y la búsqueda en línea tampoco encuentra nada. Algunas personas parecen haberse dado cuenta, pero en realidad nadie tiene una respuesta. También he creado una regla de firewall que bloquea el acceso saliente a ese puerto, y todavía está abierto, por lo que en realidad es el enrutador el que lo está escuchando.

¿Alguien sabe lo que esto podría ser?

Hmm, raro.

Hex ff = Decimal 255, por lo que lógicamente la respuesta que está recibiendo es equivalente a

MMcS 255.255.255.255 0.0.0.0 (puntos agregados para claridad de red) que para mí es básicamente una dirección de transmisión en su red. Podría estar indicando que cualquier ip en su red puede usar el servicio MMCS, es decir, 255.255.255.255 net mask 0.0.0.0.

MMCS podría ser una serie de cosas, como el MultiMedia Class Scheduler que Vista puede usar para obtener prioridad para el tráfico multimedia a través de la red. Explicaría por qué el puerto solo está abierto en su red local también.

También un poco de información sobre el punto 5 de la primera publicación de esta página

Dudo que tenga algo que ver con MIP-MANET Cell Switching, que parece tener algo que ver con las redes de telefonía móvil. Wow, hay algunas cosas extrañas que se devuelven cuando buscas en Google MMCS 255.255.255.255 . Al igual que este .

Por lo tanto, diría que es muy probable que sea un puerto que permita que el Programador de clases de Windows MultiMedia se comunique con el enrutador para priorizar el tráfico, pero podría ser algo extraño y extraño.

En realidad, esto parece ser una puerta trasera de software incluida por el fabricante como se describe aquí y explotable con este script .

Hasta ahora, personas no relacionadas con proveedores han informado que hay puertas traseras en los siguientes enrutadores: Linksys WAG200G, Linksys WAG320N (Firmware V1.00.12) y Netgear DM111P. Pero parece que los siguientes dispositivos (incluido el suyo) también pueden estar presentes, Netgear DG834, DG834G WPNT834 DG934, WG602, enrutador WGR614, Linksys WAG160N y DGN2000, WAG120N wireless-WRVS4400N. Parece probable que esta puerta trasera también esté presente en otros dispositivos.

Este es el puerto MIPS que está presente en SerComm, enrutadores y dispositivos de puertas de enlace para el hogar (Linksys, Netgear, Cisco) utilizados para las actualizaciones de firmware.

Esto se gestiona mediante un scfgmgrproceso que escucha en el puerto 32764.

Cuando se accede a través de Telnet, los datos con el prefijo ScMMo MMcS(dependiendo de la capacidad del sistema) parecen ser devueltos.

Es un protocolo binario muy simple con encabezado (0xC bytes) seguido de una carga útil.

Estructura del encabezado:

typedef struct scfgmgr_header_s {
    unsigned long   magic;
    int             cmd;
    unsigned long   len;
} scfgmgr_header;

Esto se basa en las fuentes de Cisco GPL (por ejemplo, wap4410n_v2.0.1.0_gpl.tgz en ftp-eng.cisco.com fuera de servicio).

Para obtener información real, consulte la descripción de elvanderb y el código de muestra de Python .

Actualmente es famoso por el desbordamiento del búfer basado en el montón que puede darle acceso completo al dispositivo ( una puerta trasera ). Esto fue descubierto por Eloi Vanderbeken en Navidad de 2013, sin embargo, probablemente fue conocido por piratas informáticos chinos en 2008 ( archivo cgi ).

Aquí es cómo funciona.

Desbordamiento de búfer basado en el montón:

Mensajes:

Por lo tanto, usar un mensaje desbordado simple puede dar muchos detalles interesantes:

Sin embargo, esto podría hacer que la configuración se reinicie, así que no lo hagas en casa.

Aquí hay algunos comandos invertidos realizados por el enrutador ejecutados a través de este puerto.

1. nvram - Configuración de volcado.

2. get var - Obtener configuración var

   posible desbordamiento de búfer basado en pila (si el usuario controla la variable)

3. set var - Establecer la configuración var

   desbordamiento del búfer basado en la pila, el búfer de salida (tamaño ≈ 0x10000) está en la pila.

4. commit nvram - Lea nvram / dev / mtdblock / 3 de / tmp / nvram y verifique CRC

   establecer nvram (/ dev / mtdblock / 3) desde / tmp / nvram; comprobar CRC

5. Active el modo puente (no estoy seguro, no tuve tiempo de probarlo)

   nvram_set(“wan_mode”, bridgedonly)
   nvram_set(“wan_encap”, 0)
   nvram_set(“wan_vpi”, 8)
   nvram_set(“wan_vci”, 81)
   system(“/usr/bin/killall br2684ctl”)
   system(“/usr/bin/killall udhcpd”)
   system(“/usr/bin/killall -9 atm_monitor”)
   system(“/usr/sbin/rc wan stop >/dev/null 2>&1”)
   system(“/usr/sbin/atm_monitor&”)
   

6. Mostrar la velocidad de internet medida (descarga / carga)

7. cmd (sí, es un caparazón ...)

   • comandos especiales:

     • salir, adiós, salir -> salir ... (vivo = 0)
     • cd: cambiar directorio (un poco WTF)

   • otros comandos:

     • desbordamiento de enteros en el manejo estándar (?) no explotable pero aún ...
     • desbordamiento de búfer en la salida de cmd (mismo búfer de nuevo) ...

8. escribir archivo

   • nombre de archivo en carga útil
   • directorio raíz = / tmp
   • el recorrido del directorio podría ser posible (no probado pero es abierto (sprintf ("/ tmp /% s", payload)) ...)

9. versión de retorno

10. retorno módem router ip

    • nvram_get ("lan_ipaddr")

11. restaurar la configuración predeterminada

    • nvram_set ("restore_default", 1)
    • nvram_commit

12. leer / dev / mtdblock / 0 [-4: -2]

    • no sé qué es, no tuve tiempo para probarlo

13. volcar nvram en el disco (/ tmp / nvram) y confirmar

Fuente: (presentación de diapositivas) ¡Cómo Linksys salvó mi Navidad!

Normalmente, ese tipo de puertos debería ser oficialmente de la IANA .

Esto es lo que unSpawn respondió en LinuxQuestions en 2007 relacionado con este puerto:

Si es un puerto oficialmente asignado por la IANA (con un número entre 0 y aproximadamente 30000), entonces su número debe corresponder con un servicio en / etc / services ('número de puerto de servicios getent'), el archivo de servicios de un escáner como Nmap o un en línea base de datos como el ISC de Sans.

Tenga en cuenta que el uso del puerto efímero se puede configurar localmente mediante /proc/sys/net/ipv4/ip_local_port_range sysctl. Un valor predeterminado anterior era 1024-5000, para los servidores se usa un valor de 32768-61000 y algunas aplicaciones quieren algo como 1025-65535.

También tenga en cuenta que estas son asignaciones estáticas de número a servicio y, por ejemplo, / etc / services dirá TCP/22coincidencias SSH que no tiene por qué ser el caso en una situación particular,

De lo contrario, si es un puerto en el que no sabe qué proceso se unió a él, entonces si tiene acceso al host, puede interrogarlo usando netstat -anp, lsof -w -n -i protocol:portnumbero fuser -n protocol portnumber. Este es el método más preciso,

De lo contrario, si no tiene acceso al host, puede interrogarlo, por ejemplo, por telnet. Este no es un método preciso y en el caso de un host comprometido puede alertar al intruso que está en su caso.

Ver también:

• (GitHub) La puerta trasera para Linksys WAG200G (TCP / 32764).
• (GitHub) Honeypot para Router Backdoor (TCP-32764)
• (presentación de diapositivas) ¡Cómo Linksys salvó mi Navidad!
• Actualización del firmware de WAG200G (FR) en el foro de Linksys
• TCP-32764 en wikidevi
• Quería saber sobre el exploit "SerComm Device Remote Code Execution" en Rapid7
• Google: "0x53634d4d" para más detalles.