Riesgos críticos en la Red son los que puede sufrir un proveedor de servicios esenciales a una infraestructura crítica. Para poder proveer de servicios a la Administración Pública el proveedor de servicios esenciales será sometido administrativamente a una batería de cuestiones para garantizar la seguridad de los usuarios destinatarios de esos servicios. A su vez, y como parte de una cadena de suministro de productos y servicios, el proveedor de servicios esenciales puede estar en “fallida” cuando no puede garantizar que el fabricante que le provee de sus propios componentes no han cometido errores lo suficientemente importantes que dejan sus propios servicios “al descubierto”?
Buscando en Shodan
Tomamos como ejemplo las posibilidades que tiene hoy día un investigador y curioso, para acceder a nuestros sistemas de información, entre ellos Shodan. Este buscador, creado por el informático suizo John Matherly, que en lugar de indexar contenidos a través de los puertos 80 (HTTP) o 443 (HTTPS), lo hace desde los puertos: 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 80, 443, 3389 (RDP) y 5900 (VNC). Puede localizar prácticamente cualquier dispositivos, vías, routers, firewalls, sistemas de circuito cerrado de televisión, sistemas de control industrial para plantas infraestructuras críticas, redes eléctricas, electrodomésticos y mucho más.
El riesgo de esta información captada por Shodan, se encuentra principalmente en que, estos dispositivos se encuentran conectados a Internet sin que sus legítimos propietarios sean conscientes de los peligros de, no solo sufrir un ataque, sino que éste tenga gravísimas consecuencias sobre los usuarios a los que están proveyendo de productos y servicios. La ignorancia acerca de la realidad de la accesibilidad a nuestros sistemas se puede traducir en responsabilidades penales y civiles de cuantías millonarias.
Si acudimos a la red con el buscador Shodan y le solicitamos una sola palabra, agua, encontramos que hay una máquina relacionada con un depósito de combustible, en España, y conectada a internet. Vid. Results at:
https://www.shodan.io/search?query=agua
Dado que nos está facilitando el buscador la dirección IP, activando un analizador de tráfico de red, podríamos averiguar qué tipo de información está enviando la máquina. Previamente habremos captado, con el analizador de paquetes de tráfico de red, a través de qué puerto se está efectuando ese intercambio de información. Una vez conocido, acudiríamos al manual del propio dispositivo. Muchos de los fabricantes ponen a disposición de los usuarios los manuales sobre el funcionamiento y actualización o reseteo de las máquinas e incluso cuál es la combinación de código que se podría implementar a fin de obtener la información de sus acciones en activo e incluso, cómo poder manipular el sistema.
Búsqueda de sistemas conectados a través de PLC’s
A internet hay conectados también unos sistemas llamados PLC’s (Sistemas de Lógica de Control Programable) con entradas y salidas y que son sistemas pensados para trabajar en entornos industriales con protocolos inseguros que controlan cosas tan importantes como un sistema de suministro de agua o de control de las calderas de un edificio.
Utilizando una conexión Ethernet nos conectamos a internet para encontrar máquinas interconectadas pero filtrando los mensajes que pasan por las máquina, como hace Shodan al escanear el espacio de direccionamiento público IPv4, encontraremos la base de datos mediante un escaneo pasivo. Elegiremos una máquina desde el PLC, veremos el puerto 80 que envía la información no cifrada, hacia un ordenador. Activaremos de nuevo un analizador de tráfico de red para ver qué información envía y buscaremos, a su vez, la versión de fábrica del dispositivo, más los conceptos “admin”, “pass” para comprobar si arroja algún resultado sobre esas máquinas. Sobre las contraseñas PLC’s diremos que existe una gran base de datos en la que se pueden ver las contraseñas por defecto y también de los sistemas SCADA. Sería una negligencia, por parte de un proveedor de servicios esenciales, encontrar un acceso a una máquina con la información por defecto, ya sea por acción o por omisión del responsable en implementar la solución.
Otros errores de riesgo desde la fábrica: la contraseña hardcodeada
Una contraseña hardcodeada supone hacer la vida más fácil al programador en el sentido de que, se establece la contraseña de manera estable dentro del desarrollo del código. Se preestablecen determinados datos dentro del código fuente. Hará el código menos flexible pero más rápido de desarrollar. ¿Qué ocurre cuando hablamos de una contraseña hardcondeada? Según OWASP en el control de las aplicaciones para móvil, uno de los errores principales de seguridad es el “Almacenamiento inseguro de datos” previendo la necesidad de efectuar controles en el manejo seguro de las credenciales de control de usuario, atendiendo sobre todo al no almacenaje de contraseñas hardcodeadas dentro del código fuente puesto que supone graves riesgos de acceso a información sensible de sistemas y aplicaciones.
“El Hardcodeo de credenciales supone, que la información sensible se encuentre directamente almacenada en el código fuente del programa como direcciones, nombres de usuario, contraseñas o accesos criptográficos, representando un gran agujero de seguridad y de fácil acceso mediante herramientas de ingeniería inversa por un atacante mal intencionado.
Para solucionar este problema es necesario tener toda la información sensible almacenada en archivos externos que, en el momento de ser necesario pueda leerse y, una vez no sea necesaria deba destruirise para evitar ser extraída de la memoria RAM en un análisis forense o mediante herramientas de “debug”. Si bien este mecanismo ayudará a evitar la fuga de información, en el sistema operativo Android podemos encontrar un método más eficiente que hará que evitemos, en las aplicaciones, el hardcodeado mediante el uso de los archivos strings.xml.
Concluyendo, en estos tiempos de exigencia de altos niveles de ciberseguridad es esencial conocer, desde su implementación, absolutamente todos los desarrollos software que van implicados en el funcionamiento de los productos y servicios. Nunca dar por hecho que el fabricante nos entrega el software correctamente configurado para proveer a nuestros propios clientes. Auditar el software o solicitar acreditación / certificación de haber sido auditado para, en caso de error como las contraseñas hardcodeadas, poder repercutir directamente al fabricante cualesquiera indemnizaciones por daños y perjuicios causados a terceros.
1] Pimienta García, R., Aguilar Torres, G, Ramírez Flores, M and Gallegos García,G.2013. Métodos de programación segura en Java para aplicaciones móviles en Android. Instituto politécnico nacional. México. Pág. 244 y ss.
[2] Alonso,Ch. 2015. Dorking & Pentesting con Tacyt: las API’s de terceros. Un informático en el lado del mal. Acceso al enlace el 1 de junio de 2018.
http://www.elladodelmal.com/2015/09/dorking-pentesting-con-tacyt-las-apis.html
[3] Así es Shodan, el buscador más peligroso de la red. Fundación Proydesa. Acceso al enlace el 2 de junio de 2018. https://www.proydesa.org/portal/index.php/noticias/1604-asi-es-shodan-el-buscador-mas-mas-peligroso-de-la-web
Deja tu comentario