[HACK] vulnerabilidad en los 3com 812

[Roman Medina]

On Mon, 3 Mar 2003 10:27:39 +0100, you wrote:
> Vulnerabilidad en routers 3Com OfficeConnect Remote 812 ADSL
> ------------------------------------------------------------
>bien pues yo entendi que tenia que haver una "ruta estatica" en el router
>para poder explotar la vulnerabilidad y como no era el caso pues pase

 No se muy bien a qué te refieres con "ruta estática". Por lo que yo
he podido comprobar (lo exploté con éxito en su momento), el fallo
funciona de la siguiente forma:
1) Supongamos que el router tiene activado PAT, y mapea el puerto 80
del mismo hacia un servidor B, donde tenemos instalado un servidor
web. El router no tiene ningún mapeo más. El servidor B corre además
un servidor ftp, que en principio no es visible desde fuera, pq no
está hecho el mapping correspondiente en el router.
2) Ahora el atacante intenta conectar a la IP del router, puerto 21.
Resultado: puerto cerrado. Este es el funcionamiento correcto y
deseado, ya que no se ha habilitado el mapeo de este puerto.
3) Ahora el atacante conecta al puerto 80 del router. Debido al
mapping existente, se accederá al puerto 80 del servidor web (server
B). Este comportamiento tb es correcto. El problema está en que a
partir de ahora, *mientras esta conexión siga vigente*, el router se
encuentra de alguna forma ligado al server B *incluso para puertos no
mapeados expresamente*.
4) Atacante conecta a puerto 21 del router. Está vez la petición se
acepta y se establecerá una conexión con el servidor ftp (server B).
Este es el bug. El comportamiento correcto es el descrito en 2).
5) Atacante cierra conexión con puerto 80
6) Atacante intenta conectar con puerto 21 y esta vez el
comportamiento vuelve a ser correcto (el mismo del paso 2).

 Dicho de otra forma, existe una ventana de vulnerabilidad, que durará
mientras esté vigente una conexión debida al mapeo.

>bastante del tema pero el otro dia me llego otra noticia por la misma via
>sobre una nueva forma de spam utilizando el servicio de mensageria de
>windows y venia este enlaze http://www.mynetwatchman.com/winpopuptester.asp
>para comprobar si somos vulmerables y de hecho lo era lo que no me entraba
>demasiado en la cabeza, bueno que me enrollo, que no hace falta que exista
>esa "ruta estatica" si primero hemos hecho nosotros una peticion por ejemplo
>al servidor web del ejemplo.

 No lo he probado, pero parece lógico. Mi teoría:
1) Conectas desde server B -en tu LAN- (que podría ser tb tu ordenador
de trabajo o sobremesa) hacia el server C -una web en Internet-. Tu
router hace NAT para que esto sea posible y añade una entrada a su
tabla NAT que dice: "server B ha conectado con puerto 80 de server C,
así que debo hacer traslación de direcciones".
2) El navegador suele usar conexiones persistentes, esto es, mantiene
abierta la conexión al puerto 80 destino, aún habiendo recibido las
respuestas a las peticiones http que hizo. De ahí que la entrada NAT
anterior se mantenga vigente.
3) Alguien desde server C se conecta al puerto 21 de tu router. Debido
al bug del router, el mismo hace uso de la regla NAT anterior, y
forwardea el paquete al puerto 21 de server B.

 El bug parece ser que la regla NAT no se interpreta correctamente,
sino que se ignora la parte del puerto del router. De ahí que se
utilice el mismo "tunel" que en principio sólo debia valer para el
puerto 80, para otros puertos como el 21.

 Espero que haya quedado más claro.

 Saludos,
 --Roman

--
PGP Fingerprint:
09BB EFCD 21ED 4E79 25FB  29E1 E47F 8A7D EAD5 6742
[Key ID: 0xEAD56742. Available at KeyServ]