Decidimos investigar la información relativa al puerto 135 de los sistemas que lo usan: Microsoft Windows. Esta fuente nos explica detalladamente para qué se usa. Éstas máquinas escuchan por el puerto 135 a peticiones de clientes que desean encontrar servicios DCOM (o RPC Endpoint Mapper). Si una máquina no ofrece servicios, lo más sensato sería bloquear ese puerto (o mejor aún el rango 135-139, entre otros), si tu PSI no lo ha hecho ya por ti. Me pregunto si Microsoft no pensó en mantener esos puertos cerrados en la instalación por defecto. Es mejor empezar con el software imprescindible, y luego ir instalando/configurando aquello adicional que se desee. Y debería ser así, con más razón, para Workstations. Si no queremos complicarnos o no somos muy diestros, normalmente si se tiene un router, por defecto no hay accesibilidad desde el exterior hacia el interior. Aún y así, si no lo sabemos, podemos hacer uso de un aplicativo de firewall para asegurarnos. Para los experimentados, la anteriormente citada web dispone de enlaces para deshabilitar ese servicio en nuestro sistema. Siguiendo con el mismo tema, son conocidos los 'bugs' de Microsoft con este servicio; gusanos como el Nachi y Blaster aprovecharon estos fallos y se expandieron en masa. Aún quedan restos de los estragos que fueron causados, en este caso, en la Universidad de Chicago. En el comunicado se proporciona un enlace hacia la solución del problema (pues por lo visto, en su momento, la solución al bug no fue incluida en el oportuno Service Pack). ¿Es posible que haya gente que aún no sea consciente de estos problemas y, por consiguiente, no esté a salvo de bugs tan viejos como este? En seguida lo comprobaremos. Vamos al Microsoft Security Bulletin MS03-026, apuntado por el último enlace mencionado, y en la FAQ encontramos una herramienta (+info) de la propia Microsoft para analizar qué equipos estan protegidos/desprotegidos contra esta vulnerabilidad, además de proporcionar otro tipo de información interesante (quién bloquea el servicio, quién lo tiene desactivado, etc...). Esto nos facilita sobremanera la investigación, aunque tendremos que usar un sistema Windows. En mi caso, uso un Windows 2000 que tengo virtualizado en Qemu (puedes ver cómo hacerlo aquí). Nos la bajamos, la instalamos y abrimos una 'consola' de MS-DOS, pues es una herramienta basada en línea de comandos. Escaneemos un rango de IP's para ver qué panorama hay: C:>KB824146Scan.exe /l:log.txt 80.29.10.1-80.29.10.254 El programa inicia su tarea, y va escribiendo varios logs. El que le hemos indicado (log.txt) lo engloba todo, mientras que para cada host que encuentre con la vulnerabilidad o que dude, nos creará otro mini-log, con la IP de la máquina dudosa. Como podemos apreciar, encontramos una máquina vulnerable, y el parche para este bug (que a muy seguro debe estar incluido en algún Service Pack - SP2 para Windows 2000 y SP6a para NT 4.0) fue publicado alrededor de Octubre del 2003 (!). Aunque también puede deberse a un error de detección de la herramienta de Microsoft, dado que en la información proporcionada con la herramienta se nos avisa que en sistemas 95, 98, 98SE y Me puede fallar. Casi prefiero que se trate del bug bien detectado en un NT 4.0, 2000 o XP, porque los otros sistemas dejan mucho que desear en multitud de aspectos. En cuanto al puerto 445 descubrimos que se trata de SMB sobre TCP, sin necesidad de tener la capa de Netbios sobre TCP/IP. Por defecto, este puerto está abierto para permitir el intercambio de ficheros entre redes Windows. Si bien esto no supone ningun riesgo para la seguridad del sistema, tener contraseñas adivinables o en blanco -acciones que el sistema permite hacer- supone dar acceso a los recursos compartidos. Esto unido a que algunos sistemas Windows permiten obtener un listado de recursos con sus descripciones, lo hacen especialmente peligroso (o al menos así lo cree el SANS en su top ten Security Threats, punto 7). Aquel que quiera tener una información más completa acerca de los bugs del RPC de Windows, puede mirar ésta página del CERT. Asimismo, también puede consultar la información relativa a otros bugs asociados a los puertos tratados. Y para cerrar esta mini-serie de artículos, unos cuantos enlaces para quien quiera profundizar en el arte del honeypotting:
Comentarios (3) |