Censys destapó más de 2.000 dispositivos cuya finalidad principal es gestionar y supervisar a distancia las tomas eléctricas de un sistema. En muchos casos, lo único que se interpone entre el botón de apagado físico de un servidor y un usuario malintencionado es un simple formulario de inicio de sesión y, en un puñado de casos, ninguna autenticación o seguridad en absoluto.
Como ingenieros, a menudo hablamos de los métodos y medios utilizados para ejecutar y frustrar un ataque. Cuestionamos nuestros productos, ejecutamos escáneres de seguridad contra nuestro software y sometemos nuestros servicios a pruebas de carga. Dedicamos una cantidad extraordinaria de tiempo a planificar lo peor y esperar lo mejor; nos llenamos la cabeza con preguntas como "¿tenemos redundancia?", "¿cómo gestionamos la autenticación?" y "¿está nuestro borde suficientemente protegido de un ataque a la red?".
Pero a menudo nos olvidamos de hacernos preguntas elementales como: "¿puede un atacante accionar el interruptor de encendido?". Podrías tener toda la seguridad y las mitigaciones DDoS del mundo, y no importaría si una persona cualquiera pudiera entrar en tu centro de datos y apagar tus servidores. Puede parecer ridículo, pero la amenaza es real.
Tanto si quieres acceder a un dispositivo de red que ha perdido la conectividad externa como si estás sentado en el sofá deseando que las luces tengan otro tono de rojo, probablemente exista un dispositivo asequible para conseguirlo. La clase de estos dispositivos va desde "Fuera de banda" (OOB), "Luces apagadas integradas" (iLO), hasta el simple "Interruptor de alimentación de red". Aun así, todos comparten el objetivo común de conectar en red dispositivos desconectados para fines administrativos de emergencia.
Aunque no son intrínsecamente inseguros, el principal riesgo es que este tipo de dispositivos pueden olvidarse fácilmente o pasarse por alto debido a su formato. En el mejor de los casos, un atacante podría utilizar la información obtenida de estos dispositivos para comprender la infraestructura de un objetivo potencial. En el peor de los casos, un atacante podría encontrar una vulnerabilidad en uno de estos dispositivos para ejecutar un ataque más sofisticado o una denegación de servicio. Un posible atacante podría encontrar un fallo explotable remotamente en el software de un dispositivo y utilizarlo como punto de salto para atacar a otros hosts de la red local.
Análisis
A partir de una simple búsqueda de productos en un sitio web de venta al por menor para "IP Remote Power", Censys empezó a buscar identificadores que devolvieran de forma fiable resultados que contuvieran hosts accesibles desde Internet que gestionaran tomas de corriente físicas. Censys encontró un puñado de soluciones de alimentación en red de consumo para responder a esta amplia pregunta sobre posibles superficies de ataque. Estos productos iban desde hardware profesional montado en bastidor hasta pequeñas cajas negras discretas con un panel de administración basado en web.
Para conocer mejor el hardware que ejecuta estos servicios, Censys descargó el firmware y la documentación disponibles de varios proveedores para identificar cualquier dato que pudiera ayudar en la búsqueda.
Fabricantes como Dataprobe, que utilizaba la familia de procesadores ARM (concretamente un Beagleboard), guardaba sus configuraciones iniciales de servidor, incluidos los certificados SSL en el directorio "/etc/ibootbar2", mientras que el software PHP de soporte se podía encontrar en "/var/iBB2-WebPages". En el otro extremo del espectro, dispositivos como Megatec, usando un procesador MIPS de gama baja, almacenaban certificados SSL en el archivo "/etc_ro/1024_RSA_(KEY|CERT).pem" y mantenían todos los CGI asociados como objetos ELF compilados en "/etc_ro/web/cgi-bin".
Empezando por los certificados SSL predeterminados que vienen precargados en estos dispositivos como término de búsqueda inicial, encontramos otras características únicas que los dispositivos utilizaban para identificarse. Muchos dispositivos que incluían un panel de administración web anunciaban su cabecera WWW-Authenticate como nombre del dispositivo. En cambio, otros colocaban la información exacta de su versión en el título de una página web:
Los dispositivos gestionados a través de una consola remota, como un servidor telnet, tenían una seguridad más débil y, en algunos casos, ¡no estaban autenticados en absoluto! Uno de estos proveedores tenía 73 puertos accesibles por Internet, 50 de los cuales te dejaban en un intérprete de comandos de gestión al conectarte.
En total, Censys encontró 2.617 conmutadores de alimentación activos en red que escuchaban direcciones IPv4 enrutables utilizando un conjunto rudimentario de términos de búsqueda. El siguiente gráfico muestra el proveedor junto con el número de puertos encontrados para servir paneles administrativos.
La mayor parte de la información del sistema operativo que descubrimos de estos hosts con acceso a Internet no coincidía con el sistema operativo subyacente del dispositivo sospechoso. Esta discrepancia común se debe probablemente a que los dispositivos físicos se encuentran detrás de un router o de algún tipo de servicio proxy. Lo más probable es que estos hosts estuvieran expuestos accidentalmente por una configuración incorrecta, el reenvío automático de puertos con UPnP, la reutilización de puertos o incluso listas de acceso "allow-HTTP" poco estrictas.
¿Qué puedo hacer al respecto?
- Supervise continuamente su infraestructura manualmente con Censys Search, o automáticamente utilizando Censys ASM para identificar puertos y servicios expuestos involuntariamente.
- Desactive permanentemente UPnP en sus dispositivos de puerta de enlace.
- Ajuste las reglas del cortafuegos para que sólo permitan la conexión de hosts de confianza.
- Desactivar o restringir los servicios de administración para cualquier dispositivo conectado a la red.
