Pages

Friday, May 8, 2015

Ciberataque a ICS frente a ataque tradicional IT - ICS Cyber Kill Chain

Recientemente ha sido publicado un informe, desarrollado conjuntamente por la empresa Norse y el American Enterprise Institute (AEI), que ha provocado, días después, una respuesta desde SANS ICS criticando la interpretación de los datos presentados y las conclusiones finales. Dejando completamente de lado el carácter político del informe y la controversia generada, y centrándome exclusivamente en el ámbito técnico, me ha llamado especialmente la atención del documento de SANS ICS la definición que se presenta de ciberataque a un Sistema de Automatización y Control Industrial comparándolo con el ataque tradicional a infraestructuras IT.

Los autores del documento de SANS ICS utilizan una definición de lo que constituye un ataque a un ICS a lo que técnicamente se acepta como impacto real sobre un ICS y en patrones conocidos seguidos por los atacantes como el presentado por Lockheed Martin en el paper “Cyber Kill Chain”.

Nota: El término “Kill Chain” es un concepto militar referido a un proceso sistemático para identificar, estudiar, atacar y neutralizar a un adversario.

ICS Cyber Kill Chain


En la siguiente imagen se puede ver las dos etapas del “ICS Cyber Kill Chain”, el patrón definido por Lockheed Martin y adaptado al mundo industrial por SANS ICS. Como se puede ver, describe perfectamente lo que hoy en día se conoce más habitualmente como APT (Advanced Persistent Threat) industrial.


Fig 1 - ICS Cyber Kill Chain - Fuente SANS ICS

Las fases de la primera etapa (Intrusión) de un ciberataque a ICS son:

  • Planificación: Reconocimiento para la obtención de información e identificación de objetivos, mediante el uso de técnicas OSINT, footprinting y, posiblemente, fingerprinting.
  • Preparación: Obtención de herramientas y técnicas necesarias que, posteriormente en la fase de intrusión, serán utilizadas contra los objetivos identificados en la fase de planificación.
  • Intrusión: Despliegue de las herramientas y técnicas, obtenidas en la fase de preparación, para conseguir la explotación de vulnerabilidades en los objetivos identificados y, posteriormente, instalación del malware en el activo que se desea controlar para conseguir persistencia a lo largo del tiempo.
  • Centro de Mando y Control (C2, del inglés Command & Control): Establecimiento de un canal de comunicaciones con un sistema externo, controlado por el atacante, que permita la manipulación remota de los activos de la víctima.
  • Ejecución de las acciones maliciosas: Acciones como localización de nuevos objetivos, extracción de información sensible, robo de propiedad intelectual, etc. 

Fig 2 - Etapa 1 - Fuente SANS ICS

Esta etapa ya supondría en el mundo IT un ataque APT completo, una intrusión con persistencia y acciones maliciosas que afectarían al negocio. En el mundo ICS, sin embargo, esta sería una primera etapa donde, por ejemplo, se darían operaciones de inteligencia y espionaje industrial mas que ciberataques reales contra el ICS.

La segunda etapa es donde se produciría el ciberataque real contra el ICS.

Fig 3 - Etapa 2 - Fuente SANS ICS

Las fases de esta segunda etapa (Ataque) son:

  • Planificación y desarrollo: Una vez el atacante se ha infiltrado y establecido en la red de la víctima, necesita estudiar y desarrollar el plan de ataque. Lo que hace tan diferente un ataque contra un ICS, frente a un ataque tradicional IT, es que, para atacar a un ICS, es necesario un conocimiento profundo por parte del atacante de la arquitectura y configuración del sistema para conseguir afectar al proceso o a los sensores y actuadores. Este es el motivo por el cual los equipos atacantes cuentan con expertos en seguridad lógica y también con ingenieros industriales o de control.

  • Validación: Es necesario comprobar y validar el plan desarrollado en la fase anterior. Normalmente el atacante contaría con un laboratorio donde poder realizar las pruebas necesarias antes de lanzar el ataque real contra las instalaciones de la víctima.

  • Ataque al ICS: Esta es la fase definitiva del ataque al ICS. Existen muchas formas de atacar un ICS, pero los impactos funcionales más comunes serían:

    • Denial of View (DoV): Los operadores no pueden acceder a los equipos de supervisión de la planta en un momento dado. Provocado, por ejemplo, por un ataque de denegación de servicio contra el SCADA o contra pantallas HMI, que consiguiera mantenerlos fuera de línea durante un periodo de tiempo.
    • Loss of View (LoV): Inutilización completa y persistente de los sistemas de supervisión, SCADA o pantallas HMI, consiguiendo colgar o bloquear estos equipos.
    • Manipulation of View (MoV): Los datos mostrados por el SCADA/HMI son falsos porque se ha comprometido al propio SCADA/HMI o porque mediante técnicas de Man-In-The-Middle se altera o bloquea los protocolos de comunicación con campo. Por ejemplo, datos manipulados de sensores, falsas alarmas o alarmas que no se activan cuando deberían, etc.

    • Denial of Control (DoC): Los operadores no pueden acceder a los equipos de control de la planta en un momento dado. Puede deberse a fallos no intencionados (fallos de hardware, fallos físicos o de congestión de red, manipulaciones manuales, etc) o ataques maliciosos que provoquen denegación de servicio.
    • Loss of Control (LoC): Perdida importante y continuada de los equipos de control de la planta, donde los operadores no serían capaces de ninguna acción alternativa que impidiera un fallo catastrófico.
    • Manipulation of Control (MoC): Reprogramación de la lógica, configuración o parametrización de los PLC o RTU. MoC no tiene porqué afectar a las comunicaciones con los equipos de campo o con supervisión, pero si puede modificar el efecto de las órdenes recibidas desde el SCADA.

    • Activation of Safety (AoS): Conseguir sobrepasar una condición de umbral de seguridad, afectar a un permisivo, etc, que consiga activar de forma intencionada y maliciosa un mecanismo de safety.
    • Denial of Safety (DoSF): Conseguir anular los sistemas de safety, bien engañando o consiguiendo desactivar el sistema de seguridad contra accidentes.
    • Manipulation of Safety (MoSF): Cambio de consignas límite de funcionamiento, modificación de la lógica del proceso, etc, de forma que no se activen las medidas de safety cuando deberían hacerlo.

    • Manipulation of Sensors & Instruments (MoSI): Consecución del control, directo o indirecto, de sensores y/o actuadores.

(Impactos funcionales - Fuente Cybersecurity for Industrial Control Systems (Tyson Macaulay, Bryan L. Singer) y SANS ICS)

Diferencias entre ataque a IT frente a ciberataque contra un ICS


Diferencias según el alcance del ataque


Un ataque contra la infraestructura IT de una organización se limitará exclusivamente a la primera etapa de la “Kill Chain” descrita anteriormente. Es decir, esta etapa ya supondría en el mundo IT un ataque APT completo, una intrusión con persistencia y acciones maliciosas que afectarían al negocio.

En el caso de los ICS, según los objetivos que persiga el atacante, puede limitarse también a la primera etapa o, sin embargo, pasar a la segunda.
  • ICS, primera etapa: Atacantes que se limiten a esta primera etapa, serían aquellos que estuvieran interesados en operaciones de inteligencia y espionaje industrial. Hay que tener en cuenta que, en muchos casos, el ataque no pasa de esta etapa ya que puede tener más valor, por ejemplo, el robo de propiedad intelectual mediante la extracción silenciosa de información clasificada, que un ataque real contra las instalaciones físicas del ICS.

  • ICS, segunda etapa: Los atacantes que llegaran a esta segunda etapa, serían aquellos interesados en afectar a las instalaciones del ICS en si, a los sistemas de supervisión y/o control, a las medidas de safety, al propio proceso industrial o, incluso, conseguir ataques masivos causando el mayor daño posible más allá del ámbito geográfico de la instalación industrial.

Más información sobre ataques al proceso industrial en la entrada APT dirigido al proceso industrial

Diferencias según el impacto de los diferentes ataques


En el mundo IT un ataque de denegación de servicio puede llegar a ser uno de los peores escenarios. En este caso, el que los servicios básicos e imprescindibles no estén disponibles, aún durante un periodo de tiempo relativamente corto, puede afectar muy seriamente al negocio. Dentro de las implicaciones negativas que supondría un ataque de este tipo estarían:
  • Usuarios y/o clientes sin servicio, lo cual supondría una parada de la marcha natural del negocio.
  • Graves daños a la reputación de la empresa. La imagen pública quedarían seriamente dañada si la parada en el negocio no es adecuadamente gestionada.
  • Pérdida de la confianza de los clientes. Si el servicio no se recupera en un tiempo razonable o se llegara a producir perdida de los datos de los usuarios o clientes, cabría muchas posibilidades de que una importante masa de clientes migrara a la competencia.
  • Pérdida de ingresos durante la ventana de tiempo de inactividad.
  • Coste extra en técnicos, contra medidas, abogados, etc.
  • Multas desde la administración pública o demandas por parte de clientes.

En el caso de los ICS, un ataque de denegación de servicio contra, por ejemplo, los sistemas de supervisión u otros no tiene porqué suponer graves consecuencias si únicamente impide a los operadores actuar o supervisar el proceso durante un tiempo relativamente corto.

Si las intenciones del atacante fueran afectar, de alguna forma, a las instalaciones de la planta industrial o causar daño a las personas, cualquiera de los impactos funcionales descritos anteriormente en la etapa dos puede llegar a ser grave pero especialmente, los casos de Loss of Control (LoC), Loss of View (LoV), manipulación o deshabilitación de las medidas de safety (AoS, DoSF, MoSF) y, finalmente, el que el atacante consiga tomar el control de los actuadores de la planta industrial.

Si las intenciones del atacante fueran afectar al proceso industrial, manteniendo persistencia durante un tiempo prolongado, no ser descubierto y conseguir causar un daño masivo más allá incluso del ámbito geográfico de la instalación industrial, los impactos funcionales más importantes serían los casos de Manipulation of View (MoV) y Manipulation of Control (MoC).

Ejemplos del impacto que puede suponer estos ataques si, de forma silenciosa, se pudiera controlar el proceso sería provocar la contaminación de las aguas en una planta desalinizadora; o la alteración de las recetas de fabricación en la industria alimentaria o farmacéutica, de forma que se distribuyan productos con propiedades peligrosas; o la liberación de gases tóxicos en la industria química; o incluso la intervención en el proceso de fabricación de mecanismos de seguridad (“safety”) que luego se utilizarían en instalaciones críticas.

Más información en APT dirigido al proceso industrial

Conclusiones


Es fundamental reconocer las diferencias entre las infraestructuras IT (Information Technology) y las OT (Operation Technology) en cuanto a la operación, las necesidades, los perfiles de los usuarios, las particularidades de los sistemas, el entorno, etc. Al mismo tiempo, hay que también ser capaz de identificar los posibles riesgos de cada tipo de infraestructura y la forma más adecuada de implementar las medidas de seguridad, tanto física como lógica, que se requieran.

Para finalizar, algunas recomendaciones importantes a tener en cuenta para asegurar un ICS, serian:
  • Diseñar una buena arquitectura de red, que incluya segmentación y separación.
  • Implementar medidas de defensa en profundidad (Defense In Depth)
  • Implantar prácticas de Network Security Monitoring.
  • Invertir tiempo y recursos en formación y concienciación de los usuarios, de forma que estos sean capaces de identificar ataques de ingeniería social, de conocer los riesgos de ciertas prácticas muy extendidas (p.ej: uso de discos USB externos en los equipos SCADA), etc.
  • Crear un laboratorio de pruebas, donde sea posible comprobar la fiabilidad y el posible impacto de las medidas de seguridad a implantar. Por ejemplo, cómo un antivirus puede afectar al funcionamiento de un SCADA, cómo un canal cifrado puede afectar a un protocolo o equipo industrial, etc.
 

Referencias y más información


[1] https://www.aei.org/wp-content/uploads/2015/04/Growing-Cyberthreat-From-Iran-final.pdf
[2] http://ics.sans.org/media/SANSICS-DUC3-Norse-Iran-Report.pdf
[3] http://www.lockheedmartin.com/us/what-we-do/information-technology/cyber-security/cyber-kill-chain.html

Sunday, April 5, 2015

LUKS: Cifrado de disco en GNU/Linux

Una parte muy importante de la seguridad informática es el cifrado, el cual nos permite poder garantizar la confidencialidad de los datos mediante la codificación de la información de forma que únicamente las partes autorizadas puedan leerlo. El cifrado en si no previene la interceptación o robo de los datos, pero consigue que quién intercepte esos datos no pueda tener acceso a ellos en claro.

En esta entrada hablaré del cifrado de disco que, aunque parezca no estar relacionado directamente con la temática del blog, es algo que debe estar siempre presente el todos los ámbitos, incluyendo por supuesto la seguridad industrial, donde se pretenda, por ejemplo, impedir el acceso a datos confidenciales en caso de robo de servidores con datos de producción, portátiles de ingenieros de control, copias de seguridad en discos externos, etc.

Existen muchas opciones para cifrar un volumen de datos, un sistema de archivos, o parte de los ficheros contenidos en él, pero principalmente, existen dos formas:

Cifrado a nivel de archivos, donde por ejemplo tendríamos:
  • EncFS, utilidad de cifrado de archivos basada en FUSE, trabajando en espacio de usuario y que, por lo tanto, no requiere permisos de administrador.
  • eCryptfs, similar a EncFS, pero trabajando en espacio del kernel. Es usado para implementar el cifrado del directorio home en Ubuntu y en ChromeOS, entre otros.
Cifrado de un sistema de archivos completo:

LUKS


LUKS permite, de una forma fácil y cómoda, trabajar con cifrado a nivel de disco basado en el módulo del kernel Linux DMCrypt.




En las FAQ del proyecto podremos encontrar mucha información sobre cómo trabajar con volúmenes LUKS. Como introducción, para ayudar a entender el resto de la entrada del blog, indicaré los conceptos básicos.

Principales componentes:
  • dm-crypt: Subsistema de cifrado de disco del kernel Linux.
  • cryptsetup: Frontend de línea de comandos, de bajo nivel, para trabajar con dm-crypt. También implementa la especificación LUKS.
  • LUKS: LUKS es una especificación de cifrado de discos, implementada en la utilidad cryptsetup.
  • cryptmount: Frontend alternativo para trabajar con dm-crypt. Los volúmenes no son compatibles con LUKS por lo que no se tratará en esta entrada.

Principales tipos de volúmenes cifrados:
  • plain dm-crypt: Es un volumen cifrado simple, sin ningún tipo de metadata que contenga información sobre el cifrado. Para abrir un volumen de este tipo será necesario indicar todos los parámetros necesarios en la llamada a cryptsetup desde la línea de comandos. Normalmente no se recomienda utilizar este tipo, pero se puede consultar las FAQ para posibles casos de uso.
  • LUKS: Es el tipo que utilizaremos en la mayoría de los casos, por su facilidad de uso así como por características adicionales, muy interesantes, sobre el tipo plain dm-crypt:
    • Un formato en disco bien documentado, multiplataforma, que permite que un volumen pueda ser transportado y manejado por distintos programas. Existen utilidades para trabajar con volúmenes LUKS en Android y Windows, además de Linux.
    • Múltiples contraseñas, que es posible cambiar, empleadas para desbloquear una única clave maestra usada para descifrar el volumen.
    • Propiedades específicas para evitar técnicas forenses.
    • Mayor usabilidad, ya que el volumen contiene todo el metadata necesario y, por lo tanto, cryptsetup no necesita que le indiquemos los parámetros para trabajar con él.

Adicionalmente a la página del proyecto, para obtener más información, es muy recomendable visitar la wiki del proyecto Arch Linux, así como el manual de instalación de Ubuntu Server.

Trabajando con LUKS


Voy a describir la preparación de una máquina, que ejecutará Ubuntu 14.04.2 LTS Server (amd64), cuyo volumen principal estará cifrado, así como la partición de swap, y que además contará con otros dos discos adicionales para datos, también cifrados.

Como nota de interés de este sistema cabría resaltar:
  • Los volúmenes cifrados adicionales se desbloquearán automáticamente al desbloquear el de sistema, teniendo que introducir únicamente la contraseña del volumen de sistema.
  • Será posible introducir la contraseña para LUKS de forma remota, vía SSH, lo cual permitirá tener esta configuración en un equipo al que no tengamos acceso físico o que simplemente no tenga conectado un teclado y monitor.

Nota: No describiré la propia instalación, así como la preparación del disco de sistema, ya que el instalador de Ubuntu es capaz de hacer gran parte del trabajo por nosotros, centrándome en los discos adicionales de datos. Simplemente decir que se utilizó un particionado automático, empleando para ello LVM cifrado, quedando el disco de sistema (/dev/sda) como sigue:
  • /dev/sda1 es /boot, sin cifrar, y /dev/sda5 es el volumen LUKS de sistema.
  • /dev/mapper/sda5_crypt es usado como volumen físico para LVM.
  • Dos volúmenes LVM lógicos, uno para root (/) y otro para swap.

Ver más detalles en el manual de instalación de Ubuntu Server.

Creación de los volúmenes LUKS


Particionado de los dos discos de datos, sin usar RAID ni LVM, mediante la utilidad parted:

// Creación de las particiones primarias (sdb1 and sdc1)
(parted) select /dev/sdb
(parted) mklabel gpt
(parted) mkpart primary 0% 100%
(parted) print
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  2000GB  2000GB  ext4         primary

(parted) align-check optimal 1
1 aligned

... Lo mismo con el otro disco: /dev/sdc
 
Creación de los volúmenes LUKS de datos:

// Creación del volumen:
# cryptsetup --key-size=512 --verify-passphrase luksFormat /dev/sdb1

// Verificar la correcta creación:
# cryptsetup luksDump /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        512
...

... Lo mismo con el otro disco: /dev/sdc
 
Creación del sistema de archivos ext4 dentro de los volúmenes LUKS cifrados:

// Abrir el volumen LUKS y crear el sistema de archivos:
# cryptsetup open --type luks /dev/sdb1 data1
# mkfs -t ext4 -m 0 /dev/mapper/data1

// Montar el volumen:
# mkdir /media/data1
# mount -t ext4 /dev/mapper/data1 /media/data1

... Lo mismo con el otro disco: /dev/sdc para data2

Desbloqueo y montaje automático de los volúmenes de datos


Al crear los volúmenes de datos habremos utilizado una contraseña distinta para cada uno, así como para el volumen de sistema. Esto es lo correcto pero, a no ser que consideremos el sistema tan crítico como para tener que introducir cada contraseña individualmente, normalmente querremos desbloquear todos los volúmenes introduciendo una única contraseña. Es uno de esos compromisos, entre la seguridad y la usabilidad, que cada uno tendrá que considerar según cada caso.

La forma de implementar este sistema es desbloquear los volúmenes de datos a partir de una clave derivada del volumen LUKS de sistema, que será añadida a los volúmenes de datos como segunda clave alternativa. Posteriormente se configurará en el fichero /etc/crypttab el uso de la clave derivada del volumen de sistema para desbloquear los volúmenes de datos.

Se utilizará para ello una serie de scripts disponibles en distribuciones Debian y derivadas, como Ubuntu, situados en /lib/cryptsetup/scripts.

Desbloqueo y montaje automático de los volúmenes de datos al desbloquear el de sistema:

// Obtención del UUID de cada partición, necesario más adelante:
# blkid /dev/sdb1
/dev/sdb1: UUID="d38e4789-33e2-43dc-9991-f28221918390" TYPE="crypto_LUKS"

// Generar una clave derivada del volumen LUKS de sistema.
# cd /root
# /lib/cryptsetup/scripts/decrypt_derived sda5_crypt > sda5_derived_key_file

// Añadir esta clave como una contraseña adicional al volumen de datos:
# cryptsetup luksAddKey /dev/sdb1 sda5_derived_key_file

// Comprobación:
# cryptsetup luksDump /dev/sdb1
...
Key Slot 0: ENABLED      <---- Contraseña principal del volumen de datos
...
Key Slot 1: ENABLED      <---- sda5_derived_key_file
...
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

... Lo mismo con el otro disco: /dev/sdc

// Borrado seguro del fichero con la clave:
# shred -u /root/sda5_derived_key_file

// Configuración en /etc/crypttab:
sda5_crypt UUID=0bc29f0c-7892-f426-b9b8-9f7d82b10fbb none luks
data1 UUID=d38e4789-33e2-43dc-9991-f28221918390 sda5_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
data2 UUID=bb016fa9-0b6f-4c12-aef4-7dd6ae8fca15 sda5_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived

// Configuración en /etc/fstab
/dev/mapper/data1  /media/data1  ext4  noatime,errors=remount-ro  0  0
/dev/mapper/data2  /media/data2  ext4  noatime,errors=remount-ro  0  0

// Actualizar /boot
# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.13.0-43-generic
 
Como último paso, pero muy importante y altamente aconsejable, es realizar una copia de seguridad de la cabecera de los volúmenes LUKS y guardarla en un lugar seguro, por supuesto fuera de este equipo:

# cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /root/sda5-luks-header.img
# cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/sdb1-luks-header.img
# cryptsetup luksHeaderBackup /dev/sdc1 --header-backup-file /root/sdc1-luks-header.img

Con estos pasos tendremos un sistema que al arranque nos solicitará la contraseña del volumen LUKS de sistema y, a continuación, se desbloquearán de forma automática los otros dos discos cifrados sin necesidad de introducir otras dos contraseñas.

Montando remotamente volúmenes LUKS


Ahora que ya hemos conseguido desbloquear los tres discos con una única contraseña, vamos a ver cómo configurar el sistema para poder realizar este desbloqueo de forma remota, utilizando para ello SSH.

Nota: Para las instrucciones que siguen a continuación, se parte del hecho que OpenSSH Server ya está instalado previamente.

Instalamos Dropbear, un servidor SSH especialmente diseñado para sistemas con recursos limitados, que será al que nos conectaremos para desbloquear los volúmenes LUKS.

Nota: También es necesario contar en el sistema con el paquete busybox que, al menos en una instalación estándar de Ubuntu, ya debería estar instalado.

# aptitude install dropbear
 
Esta instalación también realizará las siguientes acciones:
  • Convertirá las claves OpenSSH del host a formato Dropbear: /etc/dropbear/dropbear_rsa_host_key y /etc/dropbear/dropbear_dss_host_key. Para ello se emplea la utilidad /usr/lib/dropbear/dropbearconvert.
  • Desactivará el arranque de Dropbear, al ya estar instalado previamente OpenSSH: NO_START=1 en /etc/default/dropbear.
  • Se añadirá Dropbear a initramfs, lo cual permitirá acceder via SSH al equipo antes de que el kernel intente montar el sistema de archivos raíz.
  • Se generará un conjunto nuevo de claves de host para Dropbear, en /etc/initramfs-tools/etc/dropbear, y un par de claves RSA pública/privada para el usuario root de initramfs (el cual es distinto del usuario root del sistema ya que, cabe recordar, initramfs carga antes que el sistema de archivos raíz) en /etc/initramfs-tools/root/.ssh/id_rsa.

Ahora deberemos tomar la decisión de utilizar las claves generadas en la instalación de Dropbear para initramfs o bien, como es el caso descrito aquí, decidimos cambiar las claves por las que ya tenía el equipo y por nuestra propia clave de usuario.

Claves de host:

# cp /etc/dropbear/dropbear_* /etc/initramfs-tools/etc/dropbear/

Clave para el usuario root de initramfs:
 
// Añadimos nuestra propia clave pública al fichero `authorized_keys` y
// quitamos la generada durante la instalación.
// Hay muchas formas de realizar este paso y copiar nuestro propio
// fichero es una de ellas.
# cp ~/.ssh/authorized_keys /etc/initramfs-tools/root/.ssh/

// Borramos las claves generadas durante la instalación ya que no van a
// ser usadas para nada.
# rm /etc/initramfs-tools/root/.ssh/id_rsa*

Importante: A tener en cuenta que Dropbear no soporta actualmente claves ECDSA, que son precisamente las que OpenSSH prefiere utilizar como primera opción. Por ello, si hemos conectado previamente con este equipo, deberemos eliminar su entrada ECDSA de nuestro fichero .ssh/known_hosts y conectar de nuevo con ssh -o HostKeyAlgorithms=ssh-rsa para forzar el uso de la clave RSA. Una vez que que la clave RSA haya sido registrada, ya no será necesario utilizar el parámetro HostKeyAlgorithm de nuevo. (Fuente)

A continuación configuraremos initramfs. Para ello editaremos el fichero

/etc/initramfs-tools/initramfs.conf:
  • Debe contener BUSYBOX=y
  • No debe contener DROPBEAR=n
  • Configuración IP (de nuevo debemos recordar que el sistema de archivos raíz todavía no está disponible):
    • Asignación por DHCP: Debe contener DEVICE=eth0 (o la interfaz que corresponda).
    • Dirección IP estática: Añadir encima de DEVICE= la línea: IP=192.168.10.100::192.168.10.1:255.255.255.0::eth0:off, donde:
      • Sintaxis: [host ip]::[gateway ip]:[netmask]:[hostname]:[device]:[autoconf]
      • Notar que en el ejemplo se ha omitido el hostname.
      • Notar que IP= está en mayúsculas, muy importante.

Ahora deberemos generar el script que nos permitirá desbloquear los volúmenes LUKS durante el arranque.

Para ello crearemos el script /etc/initramfs-tools/hooks/crypt_unlock.sh disponible en este gist y activaremos el bit de ejecución:
 
# chmod +x /etc/initramfs-tools/hooks/crypt_unlock.sh

Finalmente, ya sólo nos quedará actualizar initramfs y reiniciar el equipo.
 
// Actualizamos initramfs y reiniciamos:
# update-initramfs -u
# reboot

Al iniciar el equipo, nos conectaremos indicando el usuario root en nuestro cliente SSH. De nuevo, a tener en cuenta que este usuario no es el de sistema, sino el usuario root de initramfs.

Una vez conectados, el script que creamos anteriormente nos indicará que debemos ejecutar el comando unlock para desbloquear el volumen de sistema.
 
$ ssh root@server
To unlock root-partition run unlock

BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# unlock
Unlocking the disk /dev/disk/by-uuid/0bc29f0c-7892-f426-b9b8-9f7d82b10fbb (sda5_crypt)
Enter passphrase:

Reading all physical volumes.  This may take a while...
  Found volume group "server-vg" using metadata type lvm2
  2 logical volume(s) in volume group "server-vg" now active
cryptsetup: sda5_crypt set up successfully
Connection to localhost closed.

Solución de problemas


Estas instrucciones las he probado primero en una máquina virtual VirtualBox y, a continuación, en un HP ProLiant MicroServer N36L, ambos corriendo una Ubuntu 14.04.2 LTS Server (amd64). En ambos casos no he tenido ningún tipo de problema pero en este blog y en este otro, que me han servido muy bien como referencia, se puede encontrar soluciones a posibles problemas que nos podríamos encontrar.

Referencias y más información


[1] https://gitlab.com/cryptsetup/cryptsetup
[2] https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
[3] https://wiki.archlinux.org/index.php/Dm-crypt
[4] http://stinkyparkia.wordpress.com/2014/10/14/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu-server-14-04-1-with-static-ipst/
[5] https://projectgus.com/2013/05/encrypted-rootfs-over-ssh-with-debian-wheezy/
[6] https://gist.github.com/mariodpros/3129b40038be5fbca0e4

Friday, March 20, 2015

OPC UA (OPC Unified Architecture)

En esta entrada se presenta un análisis del protocolo OPC UA, realizado desde el punto de vista de la seguridad, comparándolo con uno de los protocolos más ampliamente utilizados en el mundo industrial, Modbus/TCP.

OPC UA


OPC UA (OPC Unified Architecture) es un protocolo de comunicaciones industrial, desarrollado para facilitar la comunicación entre equipos de distintos fabricantes que, de forma nativa, sólo soportan protocolos no compatibles entre si.

OPC UA es una evolución del protocolo OPC (OLE for Process Control), que pretende subsanar diversas limitaciones del original (problemas de configuración y control sobre DCOM, funcionamiento exclusivamente sobre Windows, seguridad, etc) mediante un nuevo diseño partiendo de cero.

Fig 1 - Comparativa OPC clásico vs OPC UA
Fig 1 - Comparativa OPC clásico vs OPC UA

Características de OPC UA, relativas a este trabajo:
  • Se abandona el uso de COM/DCOM, base del anterior estándar OPC, y se pasa a utilizar una arquitectura basada en SOA, multi plataforma y que es posible implementar y usar en todos los niveles de ISA 95.
  • El estándar define dos protocolos: uno TCP binario, optimizado para conseguir un alto rendimiento y/o para soportar dispositivos embebidos, y otro de tipo Web Service (usando los puertos estándar http/https), más apropiado para salvar entornos con firewalls.
  • Incluye nuevas medidas de seguridad, consistentes en el uso de certificados X.509, para firma y cifrado a nivel de protocolo, y autenticación a nivel de aplicación mediante usuario y contraseña.
 
Fig 2 - Protocolos y seguridad en OPC UA
Fig 2 - Protocolos y seguridad en OPC UA (Fuente: Wikipedia)
 
Nota: Únicamente se va a presentar el estudio del protocolo TCP binario, debido a ser el único soportado por el servidor OPC UA utilizado [2]. Tampoco se analizará el protocolo Modbus/TCP, del cual se puede encontrar múltiples estudios.

Laboratorio de pruebas


Para analizar el tráfico OPC UA, he preparado la siguiente arquitectura:
  1. VM Windows 7, ejecutando un simulador Modbus/TCP (mod_RSsim) al que se conecta localmente un servidor OPC UA (Kepware Modbus Ethernet OPC Server) corriendo en esta misma máquina.
  2. VM Windows XP, ejecutando un cliente OPC UA (UaExpert) que se conecta al servidor OPC UA corriendo en la VM Windows 7.
  3. VM Kali Linux, capturando el tráfico con Wireshark, redirigiéndolo mediante arpspoof.
Fig 3 - Arquitectura del laboratorio
Fig 3 - Arquitectura del laboratorio

Instalación del servidor y cliente OPC UA


Kepware Modbus Ethernet OPC Server:
  • De todos los drivers disponibles, se ha instalado exclusivamente el “Modicon Modbus TCP/IP Ethernet”.
  • Genera silenciosamente, durante la instalación, el certificado X.509 para el servidor OPC UA.
  • Es interesante ver que, en la instalación, por defecto esté seleccionado “Permitir el acceso anónimo para clientes UA”.
  • Configuración del servidor OPC UA:
    • Endpoint del servidor: opc.tcp://IP:PUERTO
    • SecurityPolicy
    • Exportación/importación de certificados del servidor y de los clientes.
  • Configuración global OPC: Sin entrar en detalle, permite definir los parámetros de comunicación con el servidor Modbus/TCP y mapear variables OPC a direcciones Modbus.
Unified Automation UaExpert (Cliente OPC UA):
  • Al finalizar la instalación, se notifica al usuario que debe generar el certificado cliente. Para ello, se lanza automáticamente una utilidad donde es posible indicar los datos del certificado así como el tamaño y caducidad de clave RSA. Considero que esta política es mucho mejor, desde el punto de vista de la seguridad, que la implementada en el instalador de Kepware, donde el certificado se genera silenciosamente.
  • Configuración cliente OPC UA:
    • Dirección del servidor OPC UA: opc.tcp://win7:49320
    • SecurityPolicy, que debe coincidir obligatoriamente con alguna de las configuradas en el servidor.
    • Usuario y contraseña (o clave privada), si el servidor lo requiere.
    • Exportación/importación de certificados del cliente y de los servidores.

Análisis del protocolo


Wireshark:
  • Filtro de captura: port 49320
  • Filtro de visualización: (opcua) && !(eth.src==MAC_KALI)
  • Protocolo: OpcUa
Ejemplo de una conversación OPC UA capturada con Wireshark. En ella se puede ver:
  • Negociación inicial, fase 1 (endpoints): 01-07.
  • Negociación inicial, fase 2 (session): 08-15
  • Lectura, suscripción y recepción de variables: 16-25.
  • Cierre de sesión y canal: 26-28.
#   src  dst  info
-------------------------------------------------------------------------
01  cli  srv  Hello message
02  srv  cli  Acknowledge message
03  cli  srv  OpenSecureChannel message
04  srv  cli  OpenSecureChannel message
05  cli  srv  UA Secure Conversation Message: GetEndpointsRequest
06  srv  cli  UA Secure Conversation Message: GetEndpointsResponse
07  cli  srv  CloseSecureChannel message
08  cli  srv  Hello message
09  srv  cli  Acknowledge message
10  cli  srv  OpenSecureChannel message
11  srv  cli  OpenSecureChannel message
12  cli  srv  UA Secure Conversation Message: CreateSessionRequest
13  srv  cli  UA Secure Conversation Message: CreateSessionResponse
14  cli  srv  UA Secure Conversation Message: ActivateSessionRequest
15  srv  cli  UA Secure Conversation Message: ActivateSessionResponse
16  cli  srv  UA Secure Conversation Message: ReadRequest
17  srv  cli  UA Secure Conversation Message: ReadResponse
18  cli  srv  UA Secure Conversation Message: BrowseRequest
19  srv  cli  UA Secure Conversation Message: BrowseResponse
20  cli  srv  UA Secure Conversation Message: CreateSubscriptionRequest
21  srv  cli  UA Secure Conversation Message: CreateSubscriptionResponse
22  cli  srv  UA Secure Conversation Message: CreateMonitoredItemsRequest
23  srv  cli  UA Secure Conversation Message: CreateMonitoredItemsResponse
24  cli  srv  UA Secure Conversation Message: PublishRequest
25  srv  cli  UA Secure Conversation Message: PublishResponse
26  cli  srv  UA Secure Conversation Message: CloseSessionRequest
27  srv  cli  UA Secure Conversation Message: CloseSessionResponse
28  cli  srv  CloseSecureChannel message
  • Rápidamente se puede observar que el protocolo nada tiene que ver con Modbus/TCP (protocolo tipo pregunta/respuesta simple, sin autenticación, sin cifrado).
  • Los certificados son requeridos para asegurar la transmisión segura de los datos entre el servidor y el cliente. Ambos, tanto el servidor como el cliente, deben conocer y confiar en el certificado de la otra parte. De no ser así, la comunicación se abortará en la negociación inicial. La única excepción es si la “Security policy” se configura como “None”, donde no se requiere instalar el certificado del cliente en el servidor.
  • Security policy = “None”:
    • El cliente requiere que el certificado del servidor esté instalado y se marque como trusted.
    • No se requiere instalar el certificado del cliente en el servidor.
    • security.spu == “http://opcfoundation.org/UA/SecurityPolicy#None
    • El tráfico no va cifrado ni firmado.
  • Security policy = “Basic128Rsa15” o “Basic256”:
    • Se requiere ambos certificados instalados.
    • “Sign”, certificado cliente no instalado en el servidor o marcado como no confiable:
    • “Sign”, certificado cliente instalado en el servidor:
      • Tráfico firmado pero no cifrado.
    • “Sign and Encrypt”, certificado cliente instalado:
  • Adicional a la SecurityPolicy, también es posible activar “Allow anonymous logon = False” en el servidor. El cliente entonces requiere indicar un usuario y contraseña para autenticar contra una lista de usuarios definida en el servidor OPC.
 

Posibilidades de ataque


Comparándolo con el protocolo Modbus/TCP, las posibilidades de ataque se han reducido enormemente:
  • Ya no es posible suplantar al servidor ni al cliente, gracias a los certificados.
  • Si se utiliza cifrado y firma (SignAndEncrypt), ya no es posible capturar el tráfico en claro, alterarlo o retransmitirlo.
Suplantación del servidor:
  • El cliente necesita conocer la dirección del servidor, para ello es posible configurar ésta directamente en el cliente o, de forma dinámica, mediante un servicio de descubrimiento (OPC UA Server Discovery).
  • En el caso de configurar la dirección del servidor en el cliente, sería posible utilizar técnicas como ARP spoofing o DNS spoofing para realizar un ataque man-in-the-middle.
  • En el caso de utilizar Discovery, un atacante podría corromper la información del servidor de descubrimiento o incluso podría también intentar suplantar al mismo servidor de Discovery.
  • Por supuesto, todos estos ataques deberían poder detectarse mediante el uso de los certificados de cliente y servidor, siempre y cuando haya sido configurada la Security Policy de forma adecuada (SignAndEncrypt).
Infraestructura de certificados X.509:
  • Dependiendo de la implementación del servidor OPC UA, y de cómo esté configurado, podría llegar a ser posible que un cliente se conectara al servidor mediante un certificado auto firmado y que éste fuera aceptado por el servidor como válido.
  • Este escenario es factible si, por diversos motivos, se decidiera no desplegar una infraestructura de PKI o, ni siquiera, se dieran de alta de forma manual los certificados cliente autorizados en el servidor.
  • Otra posibilidad sería la instalación de certificados fraudulentos, bien en un servidor o cliente, por parte de un atacante. Estos certificados podrían corresponder al servidor o cliente autorizado o también a una entidad certificadora usada para firmar estos mismos certificados.
Actualizaciones de seguridad:
  • Es de esperar que, con el tiempo, vayan apareciendo vulnerabilidades bien en la especificación de OPC UA o en alguna implementación concreta. Esto, sin duda alguna, requerirá actualizar tanto servidores como clientes.
  • Aunque es una tendencia que va cambiando poco a poco, todavía hay muchas reticencias en actualizar software o firmware de equipos industriales, por parte de los ingenieros de control, si no es para corregir un fallo de funcionamiento detectado. Desgraciadamente debido al dicho “Si funciona, no lo toques”, importantes actualizaciones de seguridad pueden no ser aplicadas, dejando con ello dispositivos vulnerables a ataques conocidos con exploits públicos.
Dispositivos embebidos:
  • Gracias al nuevo diseño de OPC UA, que abandona Windows y DCOM, será posible que un pequeño dispositivo embebido lleve incorporado un servidor OPC UA.
  • Debido a que parte de estos dispositivos tendrán unas capacidades de cómputo limitadas, es muy posible que mecanismos de seguridad como el cifrado y firma puedan estar deshabilitados o directamente no soportados.
  • Por el mismo motivo, si el dispositivo incorpora un servicio para la generación de certificados, posiblemente vía web, es probable que incorpore un generador de números aleatorios débil que pueda comprometer la seguridad.
  • Otro escenario muy posible es que el firmware de estos dispositivos no se actualice nunca. Tal y como se ha comentado en el punto anterior sobre las actualizaciones de seguridad, en el mundo industrial todavía hay reticencias a actualizar pero, todavía más si cabe, cuando es un dispositivo de campo el que requiere una actualización de su firmware.
Vulnerabilidades en productos relacionados:
  • Denegación de servicio en el disector OpcUa de Wireshark [5].
  • Vulnerabilidad Heartbleed en OPC UA SDK V1.4.0 (Ansi C y C++, Windows) debido a la versión de OpenSSL vulnerable incluida [6].
 

Referencias y más información


[1] http://www.plcsimulator.org/
[2] http://www.kepware.com/Spec_Sheets/Modbus_Ethernet.asp
[3] http://www.unified-automation.com/downloads/opc-ua-clients.html
[4] https://www.digitalbond.com/scadapedia/protocols/opc-ua/
[5] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3241
[6] https://ics-cert.us-cert.gov/advisories/ICSA-14-135-04
[7] https://en.wikipedia.org/wiki/OPC_Unified_Architecture
[8] https://code.google.com/p/pymodbus/
[9] https://github.com/FreeOpcUa

Tuesday, March 17, 2015

Seguridad vs seguridad

Una corta entrada sólo para aclarar el término “seguridad” y los dos conceptos diferentes a los que se puede referir.

En el mundo industrial, al menos entre los ingenieros industriales y de control, la palabra “seguridad” siempre se ha referido al concepto, en inglés, de “safety”. Éste se define como todas aquellas medidas que ayudan a evitar la ocurrencia de un accidente, ya sea de forma no intencionada o maliciosa, que pueda suponer daño al equipamiento, instalaciones, personas o al propio proceso industrial. Es muy posible que por este motivo el término “ciberseguridad” haya sido adoptado, como estándar de facto, para referirse a la seguridad informática dentro de este mundo, al menos en los países hispano parlantes.

Por otro lado, en el mundo IT, la palabra “seguridad” se refiere habitualmente a la seguridad informática, o de forma más amplia a la seguridad de la información. El concepto de “safety” es algo que normalmente nunca aparece en el ámbito de IT.

Por tanto, y teniendo en cuenta el público al que creo puede ir dirigido este blog, usaré a partir de ahora la palabra “seguridad” para referirme a la seguridad informática y “safety” cuando me refiera a medidas para evitar accidentes o fallos en el proceso industrial.

Sunday, March 15, 2015

APT dirigido al proceso industrial

Recientemente una charla de Ralph Langner, a la que he llegado gracias a un mensaje de la lista SCADASEC, me ha hecho reflexionar sobre un tipo de amenaza que creo no se tiene normalmente en cuenta cuando se piensa en los posibles riesgos para una instalación industrial. Realmente, mientras veía el vídeo, fue una frase en concreto la que llamó mi atención: “No es lo que se puede hacer a los actuadores, sino lo que se puede hacer con ellos”, haciéndome considerar las implicaciones que pudiera llegar a suponer el que un atacante malicioso consiguiera tomar el control de una instalación industrial, más allá del simple daño físico a la propia instalación.

No es lo que se puede hacer a los actuadores, sino lo que se puede hacer con ellos.

Langner en su charla, altamente recomendable, comienza distinguiendo ataques a los sistemas IACS, como los SCADA, frente a los ataques físicos a los equipos y al proceso industrial en si. Continúa con los distintos vectores de ataque posibles así como el impacto físico que pudiera suponer estos ataques, bien localizados en la misma instalación o de forma más masiva afectando a un área geográfica más extensa.

Langner hace una afirmación importante, los ingenieros saben muy bien lo que hacen e implementan los sistemas teniendo en cuenta todas las medidas de seguridad (“safety“) necesarias para prevenir accidentes y controlar de forma adecuada el proceso industrial. Esto supone que una parametrización incorrecta de los equipos, ya sea de forma involuntaria o maliciosa, pueda ser detectada y controlada adecuadamente impidiendo un posible accidente o fallo en la producción. ¿Qué supone esto en la práctica? Que un ataque malicioso, cuyo fin sea causar daño directo a la instalación en si o al proceso industrial, tendrá pocas posibilidades de ser llevado a cabo con éxito. Si, será posible tomar el control de un SCADA o comprometer un protocolo de red industrial falseando incluso la lectura de un sensor, pero aún con ello será difícil causar daño físico porque en los controladores se habrá programado la lógica de seguridad (“safety“) necesaria para impedirlo.
¿Es posible llegar a modificar de forma maliciosa esta lógica de seguridad en los controladores? Por supuesto que si, de hecho es precisamente lo que hizo Stuxnet, pero esto implica un ataque mucho más elaborado y poder contar con más medios. Para comprometer el proceso industrial es necesario un equipo multidisciplinar compuesto por técnicos expertos en seguridad informática e industrial, así como ingenieros especializados en el sector al que se pretende atacar.
En cualquier caso, el mensaje que quiero hacer llegar, y que extraigo de la charla de Langner, es que más importante que el daño directo que pueda hacerse a una instalación industrial es el poder llegar a controlar de forma maliciosa el propio proceso industrial sin que los responsables de la instalación sean conscientes de ello. Es decir, aunque los ingenieros hayan implementado medidas de seguridad (“safety“) para prevenir situaciones anómalas, fuera del funcionamiento normal, no será posible detectar un compromiso malicioso del proceso si éste no se sale en ningún momento de los límites fijados como seguros, perdiendo sin saberlo el control de la propia instalación en favor del atacante.

El daño físico directo en una instalación industrial, ya sea a personas o equipamiento, que puede provocar un ataque malicioso tendrá un alcance relativamente limitado frente a un compromiso del proceso industrial no detectado. Es decir, va a tener un impacto mucho más grave y masivo si, de forma silenciosa, se pudiera controlar el proceso y provocar, por ejemplo, la contaminación de las aguas en una planta desalinizadora; o la alteración de las recetas de fabricación en la industria alimentaria o farmacéutica, de forma que se distribuyan productos con propiedades peligrosas; o la liberación de gases tóxicos en la industria química; o incluso la intervención en el proceso de fabricación de mecanismos de seguridad (“safety“) que luego se utilizarían en instalaciones críticas.


Esto me lleva a plantear la idea de un APT dirigido al proceso industrial. Una forma de APT clásico en IT pero aplicado al proceso industrial donde el objetivo no es, por ejemplo, la extracción silenciosa de información, aún estando muy de actualidad el robo de propiedad intelectual por parte de naciones y compañías rivales, sino que el objetivo es poder controlar, de forma silenciosa y continuada, el proceso y conseguir con ello ataques masivos causando el mayor daño posible más allá del ámbito geográfico de la instalación industrial. Y esto es así porque, como ya se ha explicado anteriormente, los sistemas industriales no han sido diseñados para detectar ligeras y silenciosas alteraciones del proceso que, en ningún momento, se salen de los límites de seguridad (“safety“).

Ya para acabar, sólo decir que hoy mi pretensión era reflexionar sobre esta amenaza, dejando para otro día, qué medidas se podrían adoptar para prevenir este riesgo.

Friday, March 13, 2015

Presentación

¡Bienvenidos!

Hace unos meses se dieron una serie de circunstancias que me animaron finalmente a embarcarme en una nueva aventura. Una aventura que me permitiría juntar mi labor profesional, en el mundo industrial, y una inquietud personal que me acompaña desde hace bastante tiempo, la seguridad informática.

Después de pensarlo durante un tiempo, he decidido seguir el consejo de escribir sobre lo que se está aprendiendo y para ello he creado este espacio. Mi intención es usar este blog como bitácora de esta aventura, donde poder compartir reflexiones y otros aspectos más técnicos sobre la seguridad en el mundo industrial.

Con el título del blog he querido manifestar claramente las intenciones de este espacio: Seguridad aplicada a los Sistemas Industriales de Automatización y Control, de las siglas IACS en inglés; refiriéndose el término Seguridad a dos conceptos diferentes, conocidos en el sector industrial como "Security" y "Safety".

Espero con ilusión que este espacio sea de utilidad y me permita contactar con gente que, al igual que a mi, le apasione este mundo.

¡Un saludo!