sistema embebido industrial autónomo de...
TRANSCRIPT
UNIVERSIDAD DE BUENOS AIRES
FACULTAD DE INGENIERÍA
CARRERA DE ESPECIALIZACIÓN EN SISTEMAS
EMBEBIDOS
MEMORIA DEL TRABAJO FINAL
Sistema embebido industrial autónomode monitoreo e intrusión remoto
Autor:Ing. Pablo Almada
Director:Esp. Ing. Nicolas Alvarez (UNSAM, FIUBA)
Jurados:Esp. Ing. Pedro Ignacio Martos (FIUBA)
Dr. Ing. Pablo Gomez (FIUBA)Dr. Ing. Juan Augusto Maya (FIUBA)
Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre marzode 2018 y julio de 2018.
III
Resumen
La presente memoria describe el diseño de un hardware autónomoenergéticamente eficiente, sin medios externos de alimentación eléctrica, creadocon el objetivo de ejecutar intrusiones remotas en procesos de control industrial.
El sistema consta de distintos módulos que permiten aprender elcomportamiento de la red, desde la perspectiva de la comunicación entre los
equipos, generar una conexión inalámbrica remota reversa hacia el actor de laintrusión y permitir al actor remoto emitir comandos a los equipos de la red.
Este trabajo será utilizado como una herramienta del equipo de Red Team de lacompañía KPMG, sponsor del proyecto, para conseguir un acceso remoto al
sistema de control de la compañía cliente y ejecutar una simulación de ataque.
V
Agradecimientos
A mi familia por darme el soporte y entender mis largas horas de estudio.
A mi director por ayudarme en el presente trabajo.
VII
Índice general
Resumen III
1. Introducción General 11.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivo y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introducción Específica 52.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Principales productos del mercado . . . . . . . . . . . . . . . 52.1.2. Diferencias entre los productos del mercado y el desarrollado 7
2.2. Estructura módular adoptada . . . . . . . . . . . . . . . . . . . . . . 7
3. Diseño e Implementación 113.1. Diseño e implementación . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Selección de plataforma embebida . . . . . . . . . . . . . . . 11Dongle de comunicación remota . . . . . . . . . . . . . . . . 13
3.1.2. Software embebido . . . . . . . . . . . . . . . . . . . . . . . . 15Módulo de eficiencia energetica . . . . . . . . . . . . . . . . 15Módulo de comunicaciones . . . . . . . . . . . . . . . . . . . 15Módulo de protocolos industriales . . . . . . . . . . . . . . . 16Módulo de baseline . . . . . . . . . . . . . . . . . . . . . . . . 17Módulo de comandos . . . . . . . . . . . . . . . . . . . . . . 17
4. Ensayos y Resultados 194.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Ensayos de integración leyendo datos de una dirección delPLC . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Ensayos de integración escribiendo datos en una direccióndel PLC . . . . . . . . . . . . . . . . . . . . . . . . . 25
Ensayos de integración atacando el PLC por medio de lamemoria del PLC . . . . . . . . . . . . . . . . . . . 25
4.3. Pruebas de validación . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Conclusiones 275.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IX
Índice de figuras
1.1. Estructura módular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Lan turtle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. Squirrel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Estructura módular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Raspberry Pi 2B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2. Beaglebone Black . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3. WIFI dongle TL-WN725N . . . . . . . . . . . . . . . . . . . . . . . . 143.4. Información capturada del tráfico de la red industrial . . . . . . . . 173.5. Menu del módulo de comandos . . . . . . . . . . . . . . . . . . . . . 18
4.1. HMI PC-1 PC operador . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Programa Ladder implementado en PLC . . . . . . . . . . . . . . . 214.3. Programa Ladder implementado en PLC . . . . . . . . . . . . . . . 224.4. Programa Ladder implementado en PLC . . . . . . . . . . . . . . . 234.5. PLC utilizado para las pruebas . . . . . . . . . . . . . . . . . . . . . 244.6. Despliegue de baseline de comunicaciones donde se observa lectu-
ras de la posición 4005 . . . . . . . . . . . . . . . . . . . . . . . . . . 254.7. Despliegue de baseline de comunicaciones donde se observa escri-
turas en la posición 4005 . . . . . . . . . . . . . . . . . . . . . . . . . 254.8. Ejecución de escritura desde el dispositivo de acceso remoto . . . . 264.9. PLC con el testigo encendido . . . . . . . . . . . . . . . . . . . . . . 26
XI
Índice de Tablas
3.1. Comparación entre opciones de plataforma embebida . . . . . . . . 133.2. Características técnicas TL-WN725N . . . . . . . . . . . . . . . . . . 14
XIII
Dedicado a mi familia
1
Capítulo 1
Introducción General
En este capítulo se presenta el campo de aplicación del producto y, por ende,el producto desarrollado; luego se describe la motivación que da origen a estedesarrollo y finalmente se define en qué consiste el trabajo realizado.
1.1. Introducción
Red Team sobre sistemas de control industrial
El concepto de red team proviene del ambiente militar en donde existen dos gru-pos, el red team y el blue team, que buscan atacar y defender, respectivamente, unobjetivo que podría ser una instalación militar o infraestructura. Este concepto, estomado desde la perspectiva de la ciberseguridad con el objetivo de instanciar lapráctica a los ambientes cibernéticos.
Dicha práctica busca evaluar las defensas cibernéticas y las capacidades de lasrecursos humanos de las compañías a través de metodologías y escenarios realesde ataques con el objetivo de determinar, de forma precisa, el nivel de riesgo yabordar una gestión más adecuada respecto a la infraestructura a proteger.
El ejercicio de un red team incluye una serie de prácticas dentro del ambiente dela ciberseguridad. Estas incluyen:
Análisis de vulnerabilidades
Ejercicios de inteligencia sobre el objetivo
Manipulación de las personas (social engineering)
Escenarios sobre un atacante interno
Intrusiones físicas
Entre otras
Para el presente trabajo se destacará la intrusión física y la simulación de un ata-que interno. Estas dos, son clave para la utilización del producto creado y des-cripto en la presente memoria. Principalmente es necesario lograr acceder a unainstalación objetivo e instalar el dispositivo de acceso remoto, para luego acce-der a los sistemas de control que residen dentro del objetivo de forma remota ysigilosa. Esta idea será desarrolla en los siguientes capítulos.
2 Capítulo 1. Introducción General
1.2. Motivación
En la actualidad, los ejercicios de red team sobre sistemas de control industrial sonllevados a cabo con dispositivos diseñados para el ambiente de la tecnología dela información. De esta manera, se crea una brecha de acciones y/u operacionesen las simulaciones de los ataques que no son posibles de explotar, por la mis-ma naturaleza de los ambientes industriales. Por ejemplo, el entendimiento de lared por parte del ejecutor del red team y la ejecución remota de comandos en lossistemas de control.
Así mismo, los equipos de la compañía cliente que ejecutaban este tipo de ejer-cicios encontraban trabas que no les permitía llevar a cabo sus trabajos de unaforma eficiente y efectiva.
En base a experiencias pasadas, surgió la necesidad de crear un dispositivo espe-cialmente creado para ambientes industriales que permita a un ejecutor de un redteam, una vez ganado el acceso físico a una instalación, implementar un dispositi-vo en la red industrial que sea inalámbrico, autónomo en lo que respecta energíay de simple uso.
1.3. Objetivo y alcance
El propósito de este proyecto es desarrollar un prototipo de un hardware autó-nomo para la intrusión remota en sistemas de control industrial de simple ins-talación, independiente de fuentes de alimentación externa e inalámbrico. Comouna primera iteración del desarrollo, el cliente propuso enfocarse primero en undispositivo de pequeñas dimensiones con baterías que tenga capacidad de conec-tarse de forma reversa a un access point por el protocolo IEEE 802.11.
El prototipo consiste a nivel hardware en una placa con un pack de baterías y unmódulo para gestionar las comunicaciones por el protocolo IEEE 802.11. Por otrolado, a nivel software, posee cinco módulos que le permiten lograr: conexiones re-versa, entendimiento y aprendizaje del comportamiento de la red industrial res-pecto a las comunicaciones entre compontes, eficiencia energética y la ejecuciónde mandos remotos hacia los componentes del sistema industrial.
En la Figura 1.1 se puede observar un diagrama en bloques donde se explicitanlas interacciones del prototipo. A alto nivel se observa como el módulo de comu-nicaciones interacciona con el módulo de protocolos industriales para interpretarla información por este recabada para luego generar baselines de comportamien-tos, los cuales son gestionados por el módulo de baseline. Asimismo, el módulode comandos se debe comunicar con el módulo de protocolos industriales paraque entre otros pueda comunicarse con los equipos que son parte de la red indus-trial, objetivo del red team. Por último, se destaca que los módulos se encuentrancondicionados por las ordenes emitidas por el módulo de gestión de energía.
1.3. Objetivo y alcance 3
FIGURA 1.1: Estructura módular
El proyecto desarrollado incluyó:
Selección de la plataforma de hardware.
Desarrollo de un prototipo preliminar en lo que refiere a hardware.
Analisis de opciones de mercado respecto a eficiencia energetica versus di-mensiones del módulo de baterias.
Seleccion y adaptación del sistema operativo embebido.
Selección de lenguaje de implementación para dicho software.
Desarrollo del software embebido.
Implementación de mecanismos de comunicacion con el access point.
El proyecto desarrollado no incluyó:
Módulo integrado para contener el producto.
Diseño del circuito impreso.
5
Capítulo 2
Introducción Específica
En este capítulo se presenta el contexto en el cual se inscribe el diseño realizado yuna introducción del producto final.
2.1. Antecedentes
El mercado de red team es considerado como un mercado de nicho, ya que el mis-mo apunta a un segmento muy especializado. Esto no quiere decir que no hayaun mercado interesado en adquirir productos de esta naturaleza sino mas bien,que la oferta de este producto es limitada y requerida principalmente en paísesdesarrollados. Es importante considerar que esta clase de productos poseen unaamplia aceptación en el mercado de la ciberseguridad.
Para realizar un red team, minimamente se debe contar con:
1. Un equipo de personas altamente especializadas.
2. Software de intrusión.
3. hardware especialmente diseñado para ejecutar ataques físicos/lógicos.
En el tercer punto, es en donde el trabajo hará énfasis. En el mercado existen pro-ductos que son utilizados para la realización de ataques lógicos con soporte físico.Esto se refiere a que primero, se debe realizar un ataque físico con el objetivo deimplantar un hardware, para luego ejecutar un ataque lógico. A continuación sedescribirán los principales productos del mercado.
2.1.1. Principales productos del mercado
Antes de desarrollar la presente sección se debe destacar que los productos queestán ofreciéndose en el mercado están orientados al desarrollo de red team sobreambientes de tecnología de la información. Lan Turtle https://www.hak5.org/gear/lan-turtle, es un hardware especialmente diseñado para ser introducido enun rack de comunicaciones con una alimentación de energía continua brindadapor medio de una conexión USB. Este dispositivo, permite generar una conexiónreversa por medio del protocolo SSH utilizando la misma red ethernet de la com-pañía objetivo del red team. Actualmente, existe una re-versión de este modeloque incluye un módulo de comunicación reversa por medio de un chip 3G.
6 Capítulo 2. Introducción Específica
FIGURA 2.1: Lan turtle
Otro producto mas nuevo en el mercado es el Squirrel https://hakshop.com/collections/network-implants/products/packet-squirrel, su funcionamiento essimilar al anterior permitiendo una conexión reversa pero con el agregado depermitir capturar tráfico de red. La conexión reversa es realizada a través de unaVPN utilizando la misma red de datos en la cual se implantó el squirrel.
FIGURA 2.2: Squirrel
2.2. Estructura módular adoptada 7
2.1.2. Diferencias entre los productos del mercado y el desarrollado
Tal como se mencionó anteriormente, los productos de mercado están orientadosa los ambientes de la tecnología de la información. Esto quiere decir, que utilizanprotocolos, comunes de este tipo de ambientes, para llevar a cabo sus objetivos.Por ejemplo, los mismos utilizan protocolos como DNS, para llevar a cabo ataquesde spoofing e interpretan protocolos como SSH, Telnet, HTTP, entre otros.
El producto desarrollado en el presente trabajo utiliza protocolos propios del am-biente de la tecnología industrial mas protocolos que son compartidos por ambosambientes. Por ejemplo, se puede destacar la interpretación del protocolo indus-trial Modbus TCP, el cual es un cuasi standard de mercado. Técnicamente se pue-de decir que en todos los ambientes industriales el mismo se encuentra presente.
Otra importante diferencia del producto creado, es su capacidad de autonomíaen lo que respecta a la alimentación eléctrica. Actualmente, los productos que seofrecen en el mercado no poseen la capacidad de contar con una fuente indepen-diente de la red de eléctrica, o bien son alimentados por medio de una conexiónUSB.
Así mismo, cabe destacar que los productos de mercado no son open source, loque implica que si se desea generar una re-versión o modificación no es posible.El producto creado es open source y esta diseñado de manera tal que la inclusiónde capacidades, como ser, la interpretación de nuevos protocolos industriales re-quiera un esfuerzo menor. Los mismo es aplicado al hardware, el producto tienela capacidad de agregar nuevos módulos de hardware, como ser, un modulo 4Gaplicando un esfuerzo menor.
Sumado a lo anteriormente expuesto, el producto creado no es dependiente de laplataforma de hardware, tal como lo son los çomparables"del mercado. Bajo estapremisa es factible implementar el presente producto en otra plataforma comoser una Raspberry Pi o similar.
2.2. Estructura módular adoptada
Bajo la premisa de desarrollar una solución escalable, el sistema ha sido desarro-llado en módulos integrables y con interfaces bien definidas como se mostró enla Figura 1.1. Para mayor comodidad del lector se presenta nuevamente el diseñode la estructura del sistema en la Figura 2.3.
8 Capítulo 2. Introducción Específica
FIGURA 2.3: Estructura módular
Lo anteriormente expuesto permitirá, en un futuro, que el código sea fácilmentemodificable por la comunidad dedicada a la ciberseguridad industrial. No solo,para agregar funcionalidad, sino también para ser usado como una herramientaante escenarios reales de ataques a sitios industriales.
A continuación se listan los módulos diseñados:
1. Módulo de eficiencia energética.
2. Módulo de comunicaciones.
3. Módulo de protocolos industriales.
4. Módulo de comandos.
5. Módulo de baseline.
Módulo de eficiencia energética
Siendo que el sistema es totalmente autónomo de la red eléctrica, su pack debaterías debe ser maximizado con el objetivo de lograr un mayor tiempo de per-manencia operativa en la red industrial. Es por ello, que se analizó que módulospodrían eficientizarse en lo que respecta al consumo eléctrico. En base a un aná-lisis de los datasheets de los hardwares utilizados, se determinó que el hardwarede wifi era el primer vector de consumo. En base a esto, se creó una pieza desoftware especialmente diseñada para minimizar el consumo de energía de estehardware.
El hardware de comunicaciones wifi es controlado por el módulo de software deeficiencia energética. Dicha pieza de software, permite lograr una mayor duraciónde vida del pack de baterías de hasta casi un 20 % de eficiencia. Por otro lado, elmódulo de software es configurable a través de la definición de un ciclo de tiempode encendido.
Módulo de comunicaciones
El presente módulo posee dos funciones. La primera, es la comunicación entre elsistema embebido y el ejecutor del red team y la segunda, es la captura de tráfico
2.2. Estructura módular adoptada 9
de red, la cual esta pensada para un posterior análisis por parte del equipo detrabajo.
La primera función es instanciada a través de una comunicación reversa haciauna access point IEEE 802.11 pre-definido al momento de ejecutar el red team.
La segunda funcionalidad esta especialmente diseñada para capturar y almace-nar el tráfico presente en la red industrial a través de un encapsulado estándarPCAP.
Módulo de protocolos industriales
El presente módulo esta especialmente diseñado para adquirir los empaquetadosPCAP, que fueron capturados por el módulo de comunicaciones, interpretarlosy realizar un disecting de los protocolos industriales. En la primera versión delprototipo desarrollado por el presente trabajo, el protocolo industrial implemen-tado es Modbus TCP. Sin embargo, el módulo esta diseñado para interpretar losprotocolos industriales mas populares.
Módulo de comandos
El presente módulo posee una fuerte dependencia del módulo de comunicacio-nes, ya que utiliza el canal generado por la comunicación reversa para ofrecerleal ejecutor de red team una interface montada sobre el protocolo telnet. En estainterface de comandos, el ejecutor de red team es capaz de seleccionar la acción atomar abstrayéndose de las cuestiones técnicas de implementación. Por ejemplolistar los baselines de los activos de la red industrial.
Módulo de baseline
El presente módulo utiliza el resultado del procesamiento del módulo de pro-tocolos industriales generando una base de datos en la cual se registra el com-portamiento de la red industrial. Por ejemplo, los comandos ejecutados por unaestación de ingeniería hacia un PLC.
El módulo es capaz de almacenar, entre otros datos, los siguientes campos:
Origen y destino de la comunicación (entre componentes de la red indus-trial).
Operación (comandos, lecturas, escrituras, datos).
11
Capítulo 3
Diseño e Implementación
En este capítulo se detallan los criterios de selección de tecnologías y una descrip-ción técnica de la arquitectura de los módulos del sistema embebido producto delpresente trabajo.
3.1. Diseño e implementación
3.1.1. Hardware
Selección de plataforma embebida
El requerimiento de crear un sistema altamente portable entre las distintas ne-cesidades y realidades de la compañía cliente alrededor del mundo, implicó laelección de una plataforma embebida para simplificar el software a desarrollar.
Por otro lado, requerimientos de menor prioridad que serán implementados enlas siguientes iteraciones, y las modificaciones ad-hoc propias de las distintas fi-liales de la compañía cliente, impactarán no solo en la complejidad del softwaresino en la carga sobre el procesador y el espacio de memoria.
Bajo estas condiciones se analizaron dos microcomputadoras comerciales: Rasp-berry Pi 2B (Figura 3.1.) y Beaglebone Black (Figura 3.2.). Se trata de dos plata-formas relativamente muy similares, ambas capaces de soportar la ejecución dedistribuciones Linux embebido.
Si bien existen múltiples plataforma open hardware y altamente compatibles, lautilización de estas populares microcomputadoras reducen el riesgo de falta dedisponibilidad de hardware en los distintos países en donde se encuentra presen-te la compañía cliente.
Por otra parte, grandes comunidades del open source han proliferado en torno aellos, facilitando la resolución de errores, detección de bugs y una alta cantidadde códigos ejemplos que podrían guiar a un implementador o desarrollador desoftware embebido modificar la versión realizada.
En la Tabla 3.1 se puede observar una comparación simplificada de las caracterís-ticas de cada opción.
12 Capítulo 3. Diseño e Implementación
FIGURA 3.1: Raspberry Pi 2B
FIGURA 3.2: Beaglebone Black
3.1. Diseño e implementación 13
TABLA 3.1: Comparación entre opciones de plataforma embebida
Concepto Raspberry Pi 2B Beaglebone Black
Procesador Broadcom BCM2836 AM3358/9Núcleo CPU 4x Cortex-A7 Cortex-A8 + Dual PRU (200Mhz)Frecuencia CPU 900MHz 1GHzGPU Broadcom VideoCore IV PowerVR SGX 530RAM 1GB 512MBMemoria FLASH No 4GBAlmacenamiento microSD microSDEthernet 100Mbit 100MbitUSB 4x 2.0 Host 1x 2.0 Host, 1x 2.0 DeviceSalida de video HDMI, compuesto HDMI
Expansión 40 pines: GPIO,I2C, SPI, UART2x46 pines: GPIO, ADCI2C, SPI, UART, CAN
Dimensiones 85x56mm 86x53mm
En importante destacar que la Beaglebone Black posee una gran cantidad de co-nexiones I/O y estandares de comunicación respecto de la Raspberry Pi. Sumadoa lo anterior, un elemento fundamental para la elección de la plataforma es la ca-pacidad de almacenamiento interno disminuyendo la cantidad de partes móvilesy la dificultad, o al menos trabas, para adquirir el contenido de la memoria porparte de un análisis forense.
Asi mismo, en vistas de nuevos requerimientos y fundamentalmente a las nuevasiteraciones ya pactadas con la compañia cliente, se optó por la elección de la pla-taforma Beaglebone Black. Esto no quiere decir que la solución a futuro no puedaser instanciada en otra placa con un esfuerzo menor.
Dongle de comunicación remota
Un elemento clave para el desarrollo del producto es la capacidad de estableceruna conexion reversa remota hacia el ejecutor del red team de un forma simpley sin usar el mismo medio en el cual se esta ejecutando la prueba. Este punto,fue un requerimiento de la compañia cliente ya que usualmente desde las redesindustriales no se deberia poder, teóricamente, crear un tunel hacia internet.
Es por ello que la compañia solicitó, en una primera versión, que se utilice unaconexión IEEE 802.11 para luego, en una segunda versión agregar un módulo dehardware 4G.
En la Figura 3.3 se presenta el hardware dongle seleccionado para el prototipo.
14 Capítulo 3. Diseño e Implementación
FIGURA 3.3: WIFI dongle TL-WN725N
En la Tabla 3.2 se presentan las características técnicas del dongle.
TABLA 3.2: Características técnicas TL-WN725N
Hardware DetalleInterfaz USB 2.0Testigo LedDimensiones 18.6mm x 15mm x 7.1mmAntena InternaWireless Standard IEEE 802.11 b/g/n/eVelocidad 150 MbpsSeguridad WEP WPA WPA2 [PSK]Frecuencia 2.4 ∼2.4835 GHz
La elección del dongle esta basada principalmente en el tamaño y en el suite crip-tográfico. Se entiende como suite criptográfico al conjunto de algoritmos cripto-gráficos que son gestionados por el hardware. El tamaño del dongle es clave yaque se tiene como objetivo esconder el producto final en un rack de comunica-ciones de un sistema industrial. Es por ello, que mientras mas pequeño resulte elproducto, mas fácil será esconderlo.
Por otro lado, el suite criptográfico es fundamental, ya que siendo que el red teames una práctica que esta enfocada en la emulación de un ataque real, podría exis-tir la posibilidad de que cuando se este ejecutando el mismo, una tercera partepueda aprovecharse de la ejecución del ejercicio para perpetrar un ataque real.De esta manera es importante utilizar una suite criptográfica que asegure la con-fidencialidad e integridad de las comunicaciones.
3.1. Diseño e implementación 15
3.1.2. Software embebido
Módulo de eficiencia energetica
El presente módulo se diseñó con el objetivo de maximizar la fuente autónomade energía. Es por ello, que en base a un análisis de los datasheets de los compo-nentes que hacen al producto final, se tomó la decisión de administrar la corrienteeléctrica consumida por el hardware de comunicaciones, dongle IEEE 802.11.
Con el afán de no perder el espíritu del producto, su característica de ser auto su-ficiente y remoto, se determinó que el mismo posea la capacidad de apagarse porperíodos de tiempos cíclicos. Esto quiere decir, que la pieza de software embebidaes capaz de ordenarle al dongle de comunicaciones que se apague por períodospredeterminados, para luego reconectarse al access point definido por el ejecutordel red team.
Por medio del archivo de parámetros del software embebido, config.cfg, se puededeterminar el ciclo de encendido y apagado del dongle de comunicaciones.
El primer problema que se presentó al momento del diseño del módulo fue:
1. ¿Qué hacer sí el ejecutor esta conectado al sistema?
2. ¿Qué hacer sí es necesario ejecutar una orden al sistema cuando el mismose encuentra desactivado?
El punto uno se solucionó con una pieza de software embebida que reside en elhost del ejecutor del red team. La responsabilidad de la misma recae en almacenartemporalmente los comandos emitidos por el ejecutor para luego, al momento dela reconexión del dongle de comunicaciones, se ejecuten los comandos almacena-dos.
El punto dos no ha podido ser solucionado ya que la conexión es remota y rever-sa. Sí se implementase otro mecanismo para solucionar la situación planteada,tendríamos que eliminar las características de la comunicacion remota y reversa.Es por ello, que se determinó que el único mecanismo que podría salvaguardarla comunicación sea el software que reside en el host del ejecutor.
Módulo de comunicaciones
El presente módulo tiene como responsabilidades:
1. Gestionar la interface de escucha.
2. Capturar tráfico que es alcanzado en la interface de escucha.
3. Gestionar los distintos dissectors de los protocolos industriales.
La materialización de estas responsabilidades pueden ser descriptas de la si-guiente manera:
El ejecutor del red team determina qué interface de red será la definida parala escucha. Cabe destacar que la interface, en la primera versión del prototi-po, es la interface ethernet. Como futuro requerimiento se esta actualmentetrabajando en una segunda versión que podrá utilizar otras interfaces comoser Zigbee IEEE 802.15.4. Este punto fue solicitado por la empresa cliente ya
16 Capítulo 3. Diseño e Implementación
que dicho protocolo es ampliamente aceptado en industrias del petroleo,específicamente, upstream.
Se abre la interface de escucha en modo promiscuo. En este modo, la inter-face captura todos los paquetes, que normalmente desecharía, incluyendolos paquetes destinados a ella misma y al resto de los componentes de la redindustrial. El tráfico obtenido es almacenado en archivos de formato PCAP.Este formato es un estándar de mercado basado en las librerías Libpcap.
Los PCAPs son almacenados temporalmente en la memoria interna de laplaca para su procesamiento. El tamaño de los PCAPs es configurable através del archivo de parámetros del software embebido, config.cfg. Por de-fecto, se definió que los archivos sean paquetizados cada 20 megasbytes.
Cada vez que se agrupa un conjunto de paquetes en un archivo PCAP, el sis-tema es capaz de determinar los dissectors que posee. Actualmente el proto-tipo posee solo el dissector del protocolo Modbus TCP, a futuro se agregaránotros protocolos como ser Ethernet/IP y OPC. El software embebido creaun hilo de ejecución por cada dissector con el objetivo de realizar un proce-samiento en paralelo al proceso principal. Esto quiere decir, que teniendoconfigurado Modbus TCP y Ethernet/IP, el software embebido crea un hilopara procesar el PCAP en busca de conversaciones bajo el protocolo Mod-bus TCP y otro hilo análogo en busca de conversaciones bajo el protocoloEthernet/IP.
Cuando el dissector del protocolo industrial encuentra información relacio-nada a conversaciones entre activos industriales, bajo el protocolo del dissec-tor, por ejemplo Modbus TCP, es almacenado en una base de datos propiadel baseline de comunicaciones. El concepto de baseline será ampliado enla descripción del modulo baseline.
Si el dissector del protocolo determina la existencia de conversaciones in-dustriales podrá guardar ese archivo en la memoria del sistema o podráeliminar el mismo. Esto estará determinado por el ejecutor del red team através del archivo config.cfg. La idea de guardar el PCAPs con conversacio-nes industrial está orientado a un posible análisis posterior a bajo nivel porparte del equipo ejecutor del red team.
Módulo de protocolos industriales
El módulo de protocolos industriales es el encargado de gestionar a los distintosdissectors que se encuentran presentes en el software embebido. En esta primeraversión se desarrolló el dissector del protocolo industrial Modbus TCP.
Este dissector recibe un PCAP, lo abre y realiza un análisis de las conversacionesque existan en este PCAP relativas a el protocolo Modbus TCP.
Para la construcción de este dissector fue necesario realizar una ingeniería inversadel protocolo con el objetivo de materializar al mismo en una librería que luegosería utilizada por el software embebido.
3.1. Diseño e implementación 17
Módulo de baseline
El módulo de baseline es el encargo de almacenar las conversaciones, que pudie-ron extraer los dissectors de los protocolos industriales, en una base de datos.
La idea de la base de datos, exactamente base de baselines, es entender el com-portamiento de la red industrial en lo que respecta comunicaciones, comandos,consultas, rangos de valores de los distintos componentes que forman la red in-dustrial. Estos componentes podrían ser por ejemplo, excitadores de turbinas degeneración eléctrica, equipos de almacenamientos de datos vibratorios de unaturbina, módulos POFF de un pozo de gas y/o petroleo, un PLC o RTU, una es-tación de ingeniería, un OPC server, entre otros.
Los campos almacenados por cada interacción son:
Marca de tiempo.
IP origen.
IP destino.
Puerto TCP destino.
rol(master / slave).
Código e interpretación del la operación.
valores relacionados a la operación.
A continuacion en la Figura 3.4 se muestra un ejemplo de datos que han sidoextraidos de un PCAP, durante las pruebas del sistema embebido.
FIGURA 3.4: Información capturada del tráfico de la red industrial
Módulo de comandos
El módulo de comandos pretende ser una interface entre el ejecutor de red teamy el sistema embebido. Esta interface logra una abstracción en lo que respectaimplementaciones técnicas de código permitiendo que el ejecutor del red team nose involucre directamente con el hardware que soporta al sistema embebido.
Esta capa de abstracción es creada a través de un servidor telnet que brinda alejecutor una serie de comandos para ejecutar en la placa. Simplemente el ejecutorelige opciones y el sistema embebido será el responsable de llevar a cabo la tarea.
A continuación en la Figura 3.5 se presenta el menu del módulo de comandos.
18 Capítulo 3. Diseño e Implementación
FIGURA 3.5: Menu del módulo de comandos
19
Capítulo 4
Ensayos y Resultados
Durante el desarrollo de la implementación se llevaron a cabo pruebas a partir demúltiples enfoques. En este capítulo se presentan dichas pruebas.
4.1. Pruebas unitarias
Durante el desarrollo del prototipo de software se realizaron test unitarios sobrelos elementos críticos del software. Para esto se utilizó unittest versión 2.1 apro-vechando la integración con librerías nativas de Python.
La implementación del sistema embebido utilizó librerías de terceros que no fue-ron sujetas a pruebas, pero sí se realizaron pruebas sobre la lógica específica ne-cesaria para la interacción con los distintos elementos del sistema (módulo decomandos y módulo de comunicaciones).
Para el caso del módulo de comandos se realizaron pruebas simulando la interac-ción del sistema embebido con un ejecutor de un red team a través de una clientegenérico de telnet. Se caracterizó el comportamiento de dicho elemento durantelas distintas etapas de operación y almacenando los mensajes que intercambia-ban. Estos mensajes fueron los utilizados para realizar un mockup durante lostest.
Los tests más relevantes ejecutados sobre dicha unidad fueron:
Conexión al servidor de comandos: donde se comprueba la rutina para es-tablecer la conexión con el dispositivo.
Desconexión al servidor de comandos: donde se comprueba la rutina com-plementaria a la anterior.
Consultas: donde se comprueba el listado de baselines
Ejecución de comandos: donde se comprueba la interferencia hacia la redindustrial por medio de la interface de comandos.
Por otro lado, para el módulo de comunicaciones se realizaron pruebas simu-lando tráfico de red usando la herramienta tcpreplay con archivos PCAPs realescapturados de una red industrial.
Se caracterizó el comportamiento de dicho elemento durante las distintas etapas,apertura de la interface de red en modo promiscuo, captura de tráfico de la redindustrial, dissecting del tráfico buscando conversaciones sobre el protocolo in-dustrial Modbus TCP.
20 Capítulo 4. Ensayos y Resultados
Los tests más relevantes ejecutados sobre dicha unidad fueron:
Conexión reversa al access point: donde se comprueba la conexión autóno-ma desde la placa hacia el access point definido por el ejecutor del red team.
Definición de una interface: donde se comprueba la apertura en modo pro-miscuo de la interface nativa del hardware embebido ethernet.
Captura: donde se comprueba la captura de tráfico raw de la red industrialy almacenamiento en la memoria interna del hardware embebido.
Dissectors: donde se comprueba la capacidad del dissecting de dissector Mod-bus TCP.
Tanto para la implementación de la lógica de la aplicación como de los test quecomprobaron el funcionamiento de la misma se realizaron conforme al documen-to de requerimientos establecido por la empresa cliente.
4.2. Pruebas de integración
Para el caso de las pruebas de integración se creó un laboratorio con dos PC, unPLC, un switch, un access point y el dispositivo de intrusión remoto, fruto de estetrabajo.
A continuación se detallan cada uno de las funciones de los componentes dellaboratorio:
PC-1: actuando en un rol de estación de operaciones. La misma emitía or-denes al PLC a través del protocolo modbus TCP.
PC-2: actuando como computadora del líder del ejercicio de red team.
PLC: la computadora industrial, PLC, poseía una lógica especialmente pro-gramada para responder a acciones emitidas desde la estación de ingenie-ría.
Switch: se propuso utilizar un switch Cisco 2960 para la intercomunicaciónentre la estación de ingeniería, el PLC y el dispositivo de intrusión remoto.
Detalles de la PC-1
La PC-1 poseía instalado el software IGSS 12 de la empresa de automatizaciónSchneider Electric. Este software tenía instalado un proyecto que era utilizado enmodo demo para que el operador, objeto de la prueba de integración, pudieraejecutar comandos hacia el PLC.
En la Figura 4.1 se expone el HMI parte del proyecto instalado en el softwareIGSS12.
4.2. Pruebas de integración 21
FIGURA 4.1: HMI PC-1 PC operador
Detalles de la PC-2
La PC-2 se utilizó para comunicarse con el dispositivo de intrusión remota a tra-vés de un cliente de Telnet. Las configuraciones de la presente PC-2 no incluyócaracterísticas especiales mas allá de un sistema operativo Linux Ubuntu instala-do por defecto.
Detalles del switch
Con el objetivo de analizar todo el tráfico de la red, sin la necesidad de realizarun ataque del tipo flooding, se configuró la interface 1 del switch en mirroring delas demás interfaces.
Detalles del PLC
El PLC fue programado con una lógica que permita demostrar físicamente lasacciones ejecutadas desde el sistema de intrusión remoto. En las Figuras 4.2, 4.3y 4.4 se expone el programa diseñado e implementado en lenguaje Ladder en elPLC de laboratorio.
FIGURA 4.2: Programa Ladder implementado en PLC
22 Capítulo 4. Ensayos y Resultados
FIGURA 4.3: Programa Ladder implementado en PLC
4.2. Pruebas de integración 23
FIGURA 4.4: Programa Ladder implementado en PLC
24 Capítulo 4. Ensayos y Resultados
En la Figura 4.5 se expone el PLC utilizado con testigos lumínicos para visualizarlas acciones ejecutadas en la prueba.
FIGURA 4.5: PLC utilizado para las pruebas
Bajo estas condiciones de laboratorio se plantearon los siguientes escenarios a serprobados en la herramienta de intrusión remota.
1. Ensayos de integración leyendo datos de una dirección del PLC.
2. Ensayos de integración escribiendo datos en una dirección del PLC.
3. Ensayos de integración atacando el PLC por medio de la memoria del PLC.
Ensayos de integración leyendo datos de una dirección del PLC
Por naturaleza propia de un sistema de control la lectura de los coils del PLC sonejecutados ciclicamente por el software IGSS 12 instalado en la PC-1 con el obje-tivo de representar esos valores en su HMI. En base a esto el sistema de intrusiónremoto capturó el tráfico de la red, realizó su dissecting y almacenó los valores enel baseline del sistema industrial.
El operador del red team logró la conexión remota al dispositivo y obtuvo el ba-seline de la comunicación entre los componentes de la red de forma exitosa. Enla Figura 4.6 se expone el baseline de comunicaciones obtenido a tráves de lapresente prueba.
4.2. Pruebas de integración 25
FIGURA 4.6: Despliegue de baseline de comunicaciones donde seobserva lecturas de la posición 4005
Ensayos de integración escribiendo datos en una dirección del PLC
En un rol de ingeniero del sistema de control, se ejecutó una orden de escrituraen un coil del PLC. La instrucción fue ejecutada desde el HMI de la PC-1 haciael PLC. El sistema de intrusión remoto, capturó el tráfico, realizó el dissecting yalmacenó los valores escritos en el baseline del sistema industrial.
Por naturaleza propia de un sistema de control la lectura de los coils del PLC sonejecutados ciclicamente por el software IGSS 12 instalado en la PC-1 con el obje-tivo de representar esos valores en su HMI. En base a esto el sistema de intrusiónremoto capturó el tráfico de la red, realizó su dissecting y almacenó los valores enel baseline del sistema.
El operador del red team logró la conexión remota al dispositivo y obtuvo el ba-seline de la comunicación entre los componentes de la red de forma exitosa. Enla Figura 4.7 se expone el baseline de comunicaciones obtenido a tráves de lapresente prueba.
FIGURA 4.7: Despliegue de baseline de comunicaciones donde seobserva escrituras en la posición 4005
Ensayos de integración atacando el PLC por medio de la memoria del PLC
El ejecutor del red team se conectó con el canal reverso al sistema de intrusión re-mota y a través de su menú ordenó escribir una posición determinada en el PLC.El PLC en esa posición de memoria tenía determinado en su programa interno,activar un relay que estaba conectado a una luz testigo.
De esta manera se determinó que el PLC había sido afectado por la orden ejecu-tada desde el sistema de intrusión remoto.
En la Figura 4.8 se observa la orden de ejecución de una escritura en la direcciónmodbus 4005.
26 Capítulo 4. Ensayos y Resultados
FIGURA 4.8: Ejecución de escritura desde el dispositivo de accesoremoto
En la figura 4.9 se observa el PLC afectado por la orden de escritura ejecutada enla posicion 4005.
FIGURA 4.9: PLC con el testigo encendido
4.3. Pruebas de validación
Finalmente, se realizaron los ensayos de validación para el prototipo. En dichosensayos participó un representante de la empresa cliente, a quién se le adjudicóel rol de operador, produciendo un número de acciones de lectura, escritura ymanipulación de la red industrial.
Adjudicándole ese rol al representante se permitió realizar, a la vez, un test deusabilidad de la interfaz usuario-maquina implementada.
Todos los ensayos fueron aprobados exitosamente.
27
Capítulo 5
Conclusiones
5.1. Conclusiones generales
Durante el desarrollo de este proyecto se alcanzaron los objetivos planteados paralos requerimientos prioritarios convenidos con el cliente pero además se le dotó aéste de una herramienta para el desarrollo y puesta a punto de su producto de redteam. El prototipo obtenido no solo representa una versión inicial para estudiar lausabilidad del producto por parte de los usuarios, sino que incluye un nexo entreel sistema y el desarrollador.
La utilización del lenguaje Python para la implementación de la solución ha sidoacertada ya que la comunidad de la ciberseguridad utiliza ampliamente dicholenguaje. Por otro lado, el cliente exigió como requerimiento clave la utilizaciónde dicho lenguaje ya que sus equipos poseen un amplio conocimiento del mismo.De esta manera el cliente podrá adaptar a futuro el producto fruto de este trabajo.
5.2. Próximos pasos
Se procederá a ampliar los protocolos implementados en el módulo de protocolosindustriales. Como fase uno, se definió agregar OPC y Ehernet/IP. Este ultimo esmuy utilizado en ambientes de tecnología Allen-Bradley - Rockwell Automation.
Por otro lado, actualmente se esta ampliando la interfaz humano-maquina delmódulo de comandos con el objetivo de brindar nuevas opciones. Entre ellas:
Listar baselines por dispositivo de la red industrial.
Ejecutar escrituras de registros del protocolo Modbus TCP.
Ejecutar escrituras masivas de coils del protocolo Modbus TCP.
Ejecutar lecturas a pedido de coils y registros de la tabla modbus del PLC.
Integrar herramientas de hacking dentro de la imagen del producto creado.
De esta manera el cliente espera ampliar su catálogo de opciones en el desarro-llo de los red team. Se procederá a iniciar una nueva iteración con los requisitosque fueron excluidos de la primera versión, para aumentar las capacidades delprototipo.
Esta última iteracción estará patrocinada por la compañía con una asignación dehoras de 1200 horas que duplicará la primera versión del prototipo.