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

1 comment:

  1. hola muy buen articulo, queria saber un poco mas si es posible pues tengo el codigo de la implementacion de FreeOpcUa que esta en GitHub, y ya tengo ejecutandose el servidor y el cliente de ejemplo, quisiera saber si me podria dar mas detalles o explicarme mejor como incluir en ese servidor mis datos personalizados, o sea me refiero a como seria el proceso de configuracion del servidor y del cliente, pues si tengo valores de variables de un PLC o de cualquier cosa como se configuraria en el servidor y como es la forma que desde el cliente pueda saber de estos datos nuevos, como enviar eventos y alarmas y como capturarlos en el cliente etc, gracias por adelantado

    ReplyDelete