Pages

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!