Seguridad desde abajo: dispositivos finales a escena

Publicado el 30/06/2016, por INCIBE

 
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:
o Utilización de un material de blindaje o apantallamiento para reducir y
disminuir las emisiones electromagnéticas en la circuitería.
o 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.
o 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.
o 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.