Seguridad desde abajo: dispositivos finales a escena

Publicado el 30/06/2016, por INCIBE
Seguridad desde abajo: dispositivos finales a escena

 

Los dispositivos embebidos están cada vez más presentes en los sistemas actuales como dispositivos finales, ya sean coches, maquinaria industrial, en el área de la salud, robótica, etc. Además, con la llegada del Internet de las Cosas Industrial (IIoT), aún se expande más el uso de dispositivos comunicados e intercambiando información. Partiendo del principio de que la seguridad absoluta no existe, muchos problemas podrían evitarse con ciertas medidas, sobre todo si se incluyen desde el diseño, filosofía de operación denominada “Security by Design”. Muchos de los dispositivos finales actuales son practicamente pequeños ordenadores, con sistema operativo, software con diferentes aplicaciones y servicios (servidor web, SSH, FTP, etc.), firmware, conectividad (Wifi, bluetooth, cable…), etc. Estas características son susceptibles a problemas de seguridad y a que un atacante pueda llegar a obtener el control sobre los mismos. Todo esto hace que sea necesario realizar evaluaciones de ciberseguridad exhaustivas antes de instalar estos productos.

- Un dispositivo con sus diferentes interfaces. Fuente: http://sine.ni.com -

Seguridad en los dispositivos finales

A la hora de abordar las medidas de seguridad en estos dispositivos, las evaluaciones de ciberseguridad deben verificar que todas las partes que los componen son seguras.

  1. PROTOCOLOS: Se debe configurar el dispositivo para que utilice la versión segura del protocolo en caso de que exista, por ejemplo Secure DNP3 en lugar de DNP3. Es frecuente encontrar en las configuraciones por defecto que los protocolos habilitados son las versiones inseguras, que carecen de la posibilidad de autenticación y cifrado.
    A través de técnicas como el fuzzing, se puede probar la implementación de los protocolos para intentar descubrir vulnerabilidades de tipo desbordamiento de buffer, de enteros o bucles infinitos. El uso  de estas herramientas es útil para determinar por ejemplo, si para ciertos protocolos que operan en capas bajas de red pueden incluirse mecanismos de seguridad en los protocolos superiores o se hace necesario aislar las redes para evitar posibles ataques.

  2. PUERTOS E INTERFACES: Los dispositivos finales suelen contar con más de un interfaz de acceso físico (RJ45, WIFI, Zigbee, CAN, USB, etc.), y generalmente alguno de ellos proporciona acceso al firmware. Estos interfaces deben estar controlados tanto físicamente, protección anti-tampering; como lógicamente, deshabilitando aquellos que no son utilizados y proporcionando un mecanismo de control de acceso a usuarios unívocos.

  3. ACCESO AL HARDWARE: Uno de los grandes problemas de la seguridad de los dispositivos finales es el acceso físico al mismo, que permitiría a un atacante estudiar su funcionamiento al detalle. Para prevenir el acceso a las partes internas debe existir una protección anti-tampering que bloquee física y lógicamente la apertura del dispositivo.
    Además, existen ataques más sofisticados, que requieren de mucho conocimiento, denominados ataques de canal lateral (Side Channel Attacks). Estos ataques permiten modificar valores a través de alteraciones en la señal del reloj del sistema o de posiciones de memoria que están al lado de cierta circuitería. La modificación se consigue gracias a cambios de temperatura u otro tipo de alteraciones físicas externas como por ejemplo interferencias electromagnéticas.
    Para solucionar problemas derivados de estos ataques se deben seguir las siguientes contramedidas:
    • Utilización de un material de blindaje o apantallamiento para reducir y disminuir las emisiones electromagnéticas en la circuitería.
    • Emitir de forma controlada más ruido al canal para que las medidas que se puedan monitorizar sean menos rigurosas y más difíciles de presuponer.
    • En el caso de que los tiempos de computación se cuantifiquen en ciclos discretos del reloj, se puede prevenir un ataque a la señal de reloj mediante el diseño de software isócrono; es decir, que se ejecuta en un tiempo constante exacto.
    • Evitar la tabla de consulta de datos para que la cache no determine a qué parte de la tabla de búsqueda se tuvo acceso. Este hecho imposibilitaría que un atacante realice consultas contra la cache para realizar búsquedas de información usada en el dispositivo.

    Aparte de los posibles ataques directos, determinados dispositivos pueden ocultar accesos no documentados o desconocidos, conocidos como puertas traseras , para poder capturar a nivel hardware toda la información procesada y luego trasmitirla. Estas puertas traseras son, en ocasiones, introducidas por el propio fabricante como ayuda para la realización de tareas de mantenimiento de los dispositivos.

  4. FIRMWARE: Para valorar lo vulnerable que puede llegar a ser el hardware de los dispositivos, es necesario disponer de una infraestructura en la que poder valorar y certificar la seguridad e integridad a nivel hardware de toda la maquinaria, chips o sistemas.
    Hace años resultaba complicado obtener el firmware de un dispositivo, ya que había que extraerlo del propio dispositivo, pero hoy en día se puede encontrar en la página web del fabricante en muchos casos. Disponiendo del firmware es posible realizar ingeniería inversa en busca de contraseñas almacenadas en el código, algoritmos de cifrado débiles o mal implementados, desbordamientos de buffer u otras vulnerabilidades que permitan la posible ejecución de código malicioso.

     

    Para realizar el análisis es necesario un desensamblado del código. Es difícil proteger el firmware contra el desemsamblado, pero es posible cifrar el código y poner una pequeña rutina al inicio del firmware para que lo descifre cuando se ejecute lo que dificulta el proceso. Sin embargo, hoy en día existen herramientas, como IDA (Interactive DisAssembler), que permiten obtener el código original descifrado casi al instante. Estas herramientas permiten ejecutar el binario en un entorno de pruebas y hacer un volcado la memoria RAM con todo su contenido.
    Adicionalmente existen diferentes técnicas de ofuscación de código para impedir el análisis, que aunque en la práctica ninguna llega a imposibilitarlo, si logra que la tarea realizada para la extracción de información sea ardua y tediosa. Siempre es aconsejable que el firmware se cifre para dificultar la extracción del mismo y evitar dar información del sistema de ficheros, bootloader, kernel, etc.

  5. SOFTWARE: Los dispositivos industriales tienen la potencia de cálculo suficiente como para ejecutar muchas de las aplicaciones que trabajan en un servidor convencional, pero no de forma conjunta. Por esta razón, se requiere una evaluación del software instalado, ya que puede contener aplicaciones y servicios no necesarios.
    En otros casos, estos aplicativos están mal configurados o, al menos, no están configurados teniendo en cuenta la seguridad. Por ello es necesario revisar la configuración de todos los aplicativos, bases de datos, almacenes de contraseñas, accesos remotos, etc., para aplicar las medidas de seguridad adecuadas en cada caso. Asimismo, hay que revisar los avisos de seguridad publicados hasta el momento para no utilizar software o versiones de software vulnerables.

La seguridad de los dispositivos finales es uno de los pilares fundamentales en la protección integral de un sistema de control. Estos dispositivos son los que toman el control en muchas de las tareas que se hacen a diario, haciendo que la seguridad de estos dispositivos sea crítica y que se deban tomar medidas orientadas a garantizar la funcionalidad y disponibilidad de los mismos.