¿Tienes fantasmas en tu red?
Las malas configuraciones te pueden jugar malas pasadas y la responsabilidad siempre es de “nadie”.
En ocasiones llegas a pensar que existen fenómenos paranormales, cuando en realidad todo tiene una explicación lógica y sencilla.
¿Un caso de poltergeist?
Hace unos días me llamó un buen cliente y amigo para decirme que en la red de su empresa le pasaban unas cosas muy extrañas. Tan extraña como que las impresoras imprimían “solas” (sin que nadie enviara nada a imprimir) textos sin sentido, lo que diríamos en argot informático “basura”. Lo que habían impreso no era poco. En alguna ocasión podían haber sido 80 hojas o más, y otras veces no sacaron más hojas por que se había quedado la bandeja de papel vacía.
Lo habían comentado con el fabricante de las impresoras, había pasado un técnico y dijo que las impresoras estaban bien, que todo provenía de la red o de fuera, del ISP, que además de dar acceso a internet gestionaba la centralita de VoIP. El ISP dijo que estaba todo bien, y tenía que ser “algo” que el cliente tuviera dentro de su red.
Tras ver una de las hojas que me mostró, lo primero que me vino a la mente es que era una cola de trabajo que quedó pendiente, a medio enviar en algún ordenador, que alguien paró la impresora, y al volverla a encender retomó el trabajo a medias.
Pero el cliente me dijo que no, que le había pasado incluso estando todos los equipos de la red parados. La impresora había impreso de noche, y lo único que estaba encendido era el servidor, las impresoras y los dispositivos de la telefonía IP.
Planificando un análisis de la red
Ante esto, le dije que la única opción era monitorizar la actividad de la red y ver qué pasaba. No podía acceder al router por que estaba gestionado por el proveedor de telefonía (no voy a dar nombres) pues no dejaban que nadie, ni el mismo cliente pudiera ver o cambiar configuraciones de éste porque podía afectar al funcionamiento de la centralita de VoIP.
Tras acordar diferentes puntos con el cliente, y explicarle lo que iba a hacer, ya que era una red que yo no administraba y no había tocado nunca, me dispuse a usar mi dispositivo preferido en este momento, el Firewalla Blue (si quieres leer más sobre él aquí explico algunas cosas), que me permitía conectarlo a la red sin una compleja intervención y me brindaba la posibilidad de administrarlo remotamente.
Dejé conectado el Firewalla y quedó listo para monitorizar y ver el tráfico de red durante unos días. En pocos minutos ya tenía todos los equipos de la red identificados, y las IPs y las MACs de las impresoras en el punto de mira. Me fui y solo me quedaba esperar hasta la primera incidencia.
Primeros resultados
No hubo que esperar mucho. En un par de días una de las impresoras recibió actividad del exterior fuera del horario de trabajo habitual. ¿Una impresora recibiendo datos de ubicaciones remotas? Pues sí.
Llamé al cliente para verificar si se habían impreso hojas, y efectivamente, así era.
De hecho, las IPs eran de diferentes países, en diferentes horarios, de orígenes tan diversos como Rumanía, Moldavia o Hong Kong. 😒
Se desmontaba la opción de que algo hubiera dentro de la red, aunque no podía descartar nada. El servidor estuvo encendido igualmente estos días, los demás equipos no. Llegué a pensar que el servidor no tuviera algún malware e incluso que la propia impresora tuviera el firmware modificado o infectado por malware. Nada de esto, se me estaba pasando por alto lo más evidente, pero ya lo explicaré más adelante.
Lo primero que hice fue obtener información de dichas IPs, y todas eran sospechosas de tener actividades poco lícitas y algunas estaban en listas negras.
Segunda fase
Ya que el Firewalla solo me mostraba un resumen de la actividad, no disponía de tramas de paquetes ni otra actividad. Tras constatar esta actividad, se me ocurrió hacer algo más, que en realidad tendría que haber hecho ya desde el principio. Me conecté por SSH y preparé un script para lanzar en segundo plano un proceso que hiciera una captura de paquetes que solo afectara a la actividad de las impresoras y lo fuera guardando en diferentes paquetes en formato pcap. Y por otro lado prepare otros scripts para hacer un análisis de la red con NMAP.
Pasados dos días, y con nueva actividad en las impresoras ya tenía más información para intentar sacar algo en claro.
El análisis con NMAP me reveló bastantes puertos abiertos en algunos casos, quizás demasiados e innecesarios, pero seguía sin mirar en el lugar adecuado.
A veces te ofuscas mirando hacia un lado y lo que buscas está en dirección opuesta. 😑
Pero ahora, sabiendo que la impresora había tenido de nuevo actividad y había impreso nuevas hojas, tenía la alternativa de inspeccionar la captura de las tramas de datos que estaban guardadas en varios ficheros. Con lo que me copié los ficheros y los empecé a analizar con Wireshark.
La verdad es que la actividad de red con la impresora era mucha más de la que me esperaba, pues se genera una conversación constante con todos los dispositivos de la red con muchos mensajes multicast, icmp, netbios y otros. Por suerte, como sabía que estas tramas no eran útiles, las podía ir discriminando añadiendo filtros.
Tras ir discriminando paso a paso todos estos paquetes de red que no aportaban ninguna información, quedaron algunos pocos paquetes que quizá podían ayudar más. De hecho, podía haber hecho un filtro inicial que incluyera solo los protocolos que me interesaban, pero no quería dar por hecho de un principio que los otros paquetes de datos no me iban a aportar ninguna información, así que preferí verificarlos previamente antes de descartarlos.
Ya solo tenía un el grupo de paquetes que realmente me interesaban, y todos con actividad con direcciones IP de fuera de la red. Iba por buen camino, o al menos esta era la sensación que tenía. Y había una trama que destacaba entre todas. ¡¡¡ Una petición HTTP !!! 🙄
Una petición HTTP al puerto 9100
¿Qué hacia una petición HTTP GET al puerto 9100?
No me cuadraba nada. El puerto 9100, normalmente se utiliza para los protocolos lpr, smb, jetdirect , utilizados para el envío de datos para imprimir, pero no en peticiones http.
Lo bueno de esto es que la petición GET me reveló una URL que me llevó a mirar en la dirección adecuada.
La url era un IP, y tras verificar la información, descubrí que la IP era del mismo ISP del cliente, y que era una IP ESTÁTICA.
Get Gabriel Martí’s stories in your inbox
Join Medium for free to get updates from this writer.
En realidad, era la IP WAN del cliente, por lo tanto, la única explicación es que el router del cliente tenía el puerto 9100 abierto y redirigido mediante NAT a la IP interna de la impresora.
No te fíes NUNCA de las verificaciones que te hayan dicho que han hecho otros técnicos. Mi error inicial fue suponer que la afirmación de mi cliente, que le dijeron los técnicos del ISP de que su conexión era toda correcta, y que su router no tenía ningún puerto abierto.
No hay que suponer, ni dar nada por hecho, si no hay mentiras hay medias verdades.
Escaneo externo
Así que hice un escaneo externo con NMAP y efectivamente me reveló que tenía el puerto 9100 abierto. Voy a obviar que también tenía abierto el puerto 53, puesto que tengo mis dudas de que fuera necesario.
Confirmado este hecho, hice una prueba rápida desde un ordenador y desde mi smartphone, abriendo esta url, y posteriormente llamando a mi cliente para que me dijera si había salido algo impreso en la impresora afectada.
Y esta es la prueba. Se imprimió todo lo que había enviado el navegador solicitando una página inexistente a la impresora. 😮
¿Por qué sacaba, en ocasiones, hojas con texto ilegible o símbolos extraños?
A estas alturas, a nadie le debe de sorprender que internet está plagado de robots que rastrean las redes. Algunos, los de los buscadores (son muchos, no los voy a citar) con intención de indexar todas las páginas web. Pero existen muchos otros que rastrean buscando todo el rango de puertos (que para quien no lo sepa son 65535).
Normalmente cada puerto suele tener asignados unos protocolos, pero estos buscadores también prueban protocolos asignados a unos puertos sobre otros para detectar servicios que se intentan ocultar al no utilizar los puertos por defecto.
Este es el motivo por el que la impresora puede haber recibido tramas de datos destinadas a probar otros protocolos y la impresora lo único que hizo fue pasar a papel lo que recibió ignorando si era verdadero contenido para imprimir.
Problema resuelto, ¿o no?
Habiendo encontrado el origen del problema era fácilmente solucionable. Mi primer paso fue cerrar dicho puerto mediante las reglas en mi Firewalla, pero era algo provisional. Había que llamar al ISP y solicitar que revisaran el router y eliminaran cualquier regla NAT que diera acceso desde el exterior a la impresora en la red interna. Simplificando; que cerraran el puerto 9100, que ya no tendría que haber estado abierto de un principio.
Aquí terminó mi parte, previa a escribir un informe con todo detalle para el cliente, y este se puso en contacto con su ISP para explicar lo ocurrido y solicitar el cierre del puerto.
Al día siguiente me llamó mi cliente y me dijo que le confirmaban que el puerto ya estaba cerrado y me pidió que hiciera una nueva prueba para verificarlo. En esta ocasión utilicé un script mío en python (que ya había usado en pruebas anteriores), simplemente por no usar nmap y probar algunas cosas propias, y le forcé el envío del texto “VULNERABLE” a la impresora, y parece ser que si llegó. 🙄
Hacer notar, que en realidad NO ES UNA VULNERABILIDAD. El problema no pasa de ser simplemente un puerto abierto para imprimir, pero es la primera palabra que me vino a la cabeza y demostraba al cliente que podía imprimir lo que yo quisiera. 😏
Mientras mi cliente volvía a ponerse en contacto con su ISP, y yo hacía lo mismo por otros canales para advertirles de esto, se me ocurrió pensar que si no era solo un problema puntual o aislado y pasaba en más usuarios de esta misma red. Y así era.
No es un problema de un cliente en concreto, hay muchas conexiones a internet de e̶s̶t̶e̶ varios ISP, con los puertos relacionados con impresión jetdirect abiertos, del 9100 al 9105. Solo hay que elegir unos rangos adecuados de conexiones de fibra o xDSL y se obtiene respuesta de unas cuantas impresoras.
Y estoy hablando de uno puertos concretos. Si nos ponemos a mirar otros puertos habituales, seguro que salen más dispositivos.
¿Saben esto los usuarios? Puedo afirmar categóricamente que no.
¿Saben esto las operadoras? Pues tengo mis dudas de si es dejadez, desconocimiento, malas prácticas, personal aburrido, o directrices de alguna instancia superior. Pero ahí está el problema.
Así que, si tus dispositivos hacen “cosas raras”, no descartes el hecho de que tu proveedor esté abriendo una puerta (o una ventana 😏) del exterior hacia el interior de tu red.
Herramientas de escaneo
Faltaría a la verdad si no dijera que NMAP es quizás la herramienta por excelencia para escaneo de red y análisis de vulnerabilidades. Es la herramienta básica, que luego puedes complementar con otras, pero el conocimiento y uso de esta es imprescindible.
No obstante, como programador, siempre te queda la opción de crearte tus propias herramientas, que pueden servir para poder llevar a cabo tareas muy específicas, o bien para ayudarte a entender otros procesos, porque siempre puedes modificar la programación y adaptarla a unos requerimientos específicos sobre los que puedes tener un mayor control.
Es por eso que para este análisis recurrí a una herramienta que ya había creado para otro proyecto (un escáner para un poc de un keylogger) y revisé algunas partes del código además de añadir nuevas funcionalidades y corregir otros errores que no vi en su momento.
Así que, tras hacer los cambios y arreglos, decidí subir el código a un repositorio de GitHub y ofrecerla como código abierto con licencia GPL3 como ya he hecho en otras ocasiones.
Aquí tienes el repositorio de “pscan (Python Multithread Network Scanner)”
Artículo relacionado
Análisis de dispositivos de Ciberseguridad “personal” & Home Office.
Otros artículos que te pueden interesar
Te dejo a continuación otros artículos míos relacionados con la Ciberseguridad que a lo mejor te pueden interesar:
- La privacidad está en manos de todos
- ¡¡¡Validad los datos en el lado del servidor, maldita sea!!!
- ¿Por qué tu amigo abogado se cree informaciones falsas?
- ¡¡¡No caigas en la trampa!!!
- WordPress, la zona de juego de los Ciberdelincuentes (Parte I)
- Intentando analizar (sin mucho éxito) un documento Word Malicioso
