Device Whitelisting

Today I would like to start by apologizing because this is my first post in English. English is not my mother tongue so be sure that I can make some grammar, vocabulary or expression mistakes. Last year I finished with more than 52000 visitors and I decided for this 2018 try to write some articles in this language, in particular to come to English-speaking people. Having said this, let’s make a start!

A lot has been written about if USB ports have to be turned on in industrial environments and the threat that they might suppose for them. In particular, pen drives and other storage devices. Obviously, this is true and somebody may think “Ok, block them and the problem will disappear”. Yes, but depending on the scenarios it cannot be possible to do. The theory crashes with the reality, once again. Why? Few questions…

  1. How do you access to data stored in systems located on isolated facilities?
  2. What do you do if recover a system without network connection is needed?
  3. How do you install a new software version if the network is not routed and cannot access to other like DMZ?
  4. What happens if the software requires a license USB device?
  5. If you have a backup system, what do you do if you have to recover a system and the network connection is not available? And if this is possible, are you going to download several gigabytes from that server across the OT network?
  6. If you have a software distribution system, how do you deploy software that cannot be packetized?
  7. Are you going to trust totally on these backup systems and do not have an Emergency Plan to storage configurations, programs, software or firmware in an external USB Hard Disc Drive?

For these and further questions are that the USB devices have, can and must be used at industrial environments with multiple purposes. However, we must take measures to prevent any incorrect use and be the source of incidents by negligence, spread up malware, steal information, infect a system, and so on. In consequence, the USB port in the majority of cases have to be switched on.

Obviously, the first step should be raise awareness to all the personnel involved, or related, with OT tasks, but everybody knows that this is not enough. We need technical tools.

Consequently, as we must live with our “enemy” because we need him, we have to decide how to control him, and reduce the risk that somebody, or something, cause damages in our facilities.

One measure is to decide which USB device we will use for maintenance, operational, recovery or any other justified reason to be plugged on to own systems. For example, HMI, engineering workstations, programming laptops, etc. Others, or any similar as mobile phones, pen drives, are forbidden. Then, either via software or endpoint security solution, permit or deny mount them on these systems.

Today I will talk about how to do this using Symantec Embeeded Security : Critical System Solution” in 7.1 version. In other posts, I mentioned how USB Control and Application Whitelisting works.

On this occasion I have created the following scenario.

USB Whitelisting Scenario v1

As you can see, we have “Management Console” installed on a PC with Windows XP OS. From there, we connect to the SES:CSP Server to set up Application Whitelistng Policies. Finally, a Programming Laptop used to connect to PLCs and other devices located in OT environments.

We connect to the server from XP PC and open the selected policy named “AUTH_USB_win_whitelisting_sbp v7.1.0 r136 – Whitelisitng”

USB_POLICY_01

Open “Device Control Rules” we are able to block, or not.

USB_POLICY_02

If we check “Block USB devices” a new window is opened.

USB_POLICY_03

From there we can “whitelist” the devices. Clicking on “Add” we can choose between those we have connected or if we want to specify them manually.

USB_POLICY_04

In this case our device appears as follow:

USB_POLICY_05

Now we are ready to save changes and apply onto the programming station.

USB_POLICY_06

As you can see the device can be mounted and the files be accessed in function on the application policies.

USB_POLICY_07

But if other USB stored devices are plugged, they will not be mounted and visible on the explorer. A log will be created as follow.

USB_POLICY_08

The green “information” logs are related to the right device.

The use of USB devices as pen or hard disc drives sometimes are not only useful, are necessary. All depends on the activity, the context or the criticality of the systems. They give us the flexibility to transfer files, configurations or any information, especially in those moments when we cannot do it across the network. For example, have a second repository to storage a copy of everything we need to recover an equipment, something important in the context of Emergency or Disaster Recovery Plans. Furthermore, the data transfer using USB can be higher than network interface cards, probably 10/100 Mbps, so we can do our tasks faster than if we wait to download everything from a server.

In any case, we must control the USB ports because they can be our allied or our enemy. We must do not forget that in case of unauthorized USB is plugged, the execution, read or write can be submitted to application whitelist policies.

That´s all, Thanks a lot, see you again!

Edorta

Terminamos 2017, empezamos 2018

Por estas fechas, hace un año, veía cómo las expectativas acerca del número a visitas para 2016 se había superado con creces. Había alcanzado las 32.379. Como era lógico para este 2017 el planteamiento era aumentar esa cifra lo que supondría haber llegado a una mayor cantidad de público. Decidí invertir algo de dinero en mejorar el plan de hosting e incluir mejoras que repercutieran en el posicionamiento, plantillas editables para un aspecto más atractivo, nuevos apartados, entre otros. Aparte claro está, la publicación de nuevo contenido.

El 2017 ha llegado a su fin y toca mirar los números finales para ver cuáles han sido los resultados. Si bien, ya veía que iban a ser buenos por el seguimiento semanal, no han podido ser mejores. Cuesta creerlo, la verdad, pero hemos alcanzado….

 ¡¡¡ 52.169 !!!

Cuando empecé 5 años atrás no pensé que esto pudiera suceder. Pero sí, ha sucedido. El sitio parece que tiene el suficiente interés tanto para ser visitado como referenciado Y claro, como no podía ser de otra manera, me llena de orgullo. Sólo hay que ver la tendencia anual.

Captura de pantalla 2018-01-01 a las 11.51.59

En este camino quisiera agradecer a todos los que han accedido, encontrado o leído algunos de los artículos y dedicarle parte de su tiempo. Sin ellos, estas cifras no serían posibles. También, dar las gracias a las personas y empresas que han colaborado y ayudado de una forma u otra.

Por un lado, a Fortinet España por tener acceso a sus productos y descubrir las funcionalidades que ofrecen para OT,  pudiéndose hacer frente desde un solo fabricante las muchas de las necesidades que tanto entornos industriales como infraestructuras críticas requieren sea el que sea su sector. Sin olvidarnos, además, de su integración con otros distintos de terceros para aportar unos mejores niveles de seguridad sobre distintos escenarios. A Jose Luis Laguna y Antonio Navarrete, muchas gracias.

Fortinet-01

Al Centro de Ciberseguridad Industrial, por no sólo darme la oportunidad y confianza de ser su Coordinador del País Vasco, sino de incluirme en muchos de sus boletines semanales haciendo referencia a los artículos publicados. A José Valiente, Miguel García-Menéndez y Susana Asensio, muchas gracias.

Coordinadores

XI Jornadas CCN-CERT, de derecha a izquierda, Oscar Bou (Coordinador Valencia), J. Valiente (Director CCI); M. Pulpillo (Coordinador Andalucía); J. Figueras (Coordinador Cataluña) y yo, Edorta Echave (Coordinador País Vasco)

A mis compañeros de profesión, de trabajo, y amigos por darme su opinión sincera sobre su visión tanto del blog, del contenido, ideas o recomendaciones en redes sociales. Saber de sus comentarios, ayuda a mejorar, seguir en la misma línea o corregir errores. A Jon Bueno, Unai Gomez, Borja Lanseros, Jose Luis Flores, Aaron Flecha, Jose Luis Jimenez, Ana González, Joan Figueras, Guido Nahuel Ygounet, Belén Pérez Rodriguez, David Marco Freire, Enrique Dominguez, Jose Manuel Sacristán, Edgard Capdevielle, Luis Ochoa, Carlos Navares, Walter Heffel, Elyoenai Egozcue, David Imizcoz, Mikel Diaz de Arcaya, Diego Gil, Alvaro Rivas ZuazoAdriel Regueira, entre muchos otros más. Disculparme si alguno no está en la lista.

Con todo ello, ponemos rumbo a 2018. Con nuevas ideas, con nuevos propósitos. Lo malo va a ser que el día sólo seguirá teniendo 24 horas… pero creo que esto es algo que los que estamos metidos en muchos “fregaos”, “historias”, “compromisos” y otras tantas responsabilidades. Y es que ¡hay que ver lo fácil que nos liamos… 😉

Espero pues en los próximos 365 días que se nos presentan pueda seguir manteniendo este blog los suficientemente interesante como para que dentro de unos meses pueda deciros de nuevo que hemos superado los objetivos.

Un abrazo!

Triton/Trisis/Hatman; un malware para SIS.

Hace pocos días atrás saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.

Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.

Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.

Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.

Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.

TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.

Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.

El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.

Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “library.zip”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:

Triton Trisis Hatman

Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.

Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.

Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.

Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.

Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:

  1. Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
  2. Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
  3. Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
  4. Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.

Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.

Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:

  1. Aplica a equipos concretos de un determinado fabricante, no a todos.
  2. Debe darse la condición de que un conmutador físico debe estar en cierta posición.
  3. Alto conocimiento de esta tecnología.
  4. Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
  5. No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.

Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.

  1. Establecer una red físicamente independiente para los sistemas SIS.
  2. Implementar NGFW que filtren el tráfico de gestión hacia ellos.
  3. Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
  4. Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1], [2]; Control de dispositivos USB [1]
  5. Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
  6. Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
  7. Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.

Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.

Un saludo, nos vemos en la próxima.

Referencias:

Más información:

¡ Estrenamos cuenta en Twitter !

Con el objetivo cumplido para este 2017 y con ánimo de seguir llegando a más y más público, a partir de hoy está disponible bajo @enredandoconred nuestra cuenta en Twitter.

Diariamente se producen una buena cantidad de noticias, artículos, eventos, informes,  o textos relacionados con la Ciberseguridad en sistemas ICS/SCADA, Infraestructuras Críticas y demás Tecnologías de Operación. Por ello hemos visto que una buena iniciativa es redistribuir de forma rápida cualquier contenido interesante.

Así pues, os animamos a que nos sigáis y comencéis a recibir los tweets que vayamos publicando.

¡Un abrazo!

Edorta

¡Objetivo cumplido, muchas gracias!

No pensaba que a esta altura del año iba a escribir una entrada como la de hoy, pero para mi alegría así es. Y es que estoy de celebración.

Allá por el mes de diciembre del 2016 os contaba cómo, no sólo había superado las 30.000 visitas, sino que se había alcanzado la cifra de 32.378. A partir de ahí, el deseo de superar esa cifra para 2017.  Y con esa idea arrancamos el año.

Pues bien, hoy a punto de comenzar setiembre… ¡ya la hemos alcanzado!

Estadísiticas agosto 2017_01

Esto supone una gran alegría y estímulo ya que revela cómo año tras año este número crece, poniendo de manifiesto la cantidad de internautas, profesionales, investigadores y demás público, buscan, requieren o interesa el contenido relacionado con la Ciberseguridad Industrial.

Y como no podía ser de otra manera, me gustaría dar las gracias. Gracias a todos aquellos contactos y miembros de redes sociales como LinkedIn o Twitter por haber “recomendado”, “compartido” o “retuiteado” alguno de los artículos que por esas vías he ido anunciando. Por supuesto, también a los visitantes que a través de sus búsquedas han dado con el blog parándose a leer lo que allí había. A todos aquellos que de una manera u otra lo han hecho posible, ¡GRACIAS!

Representación 2017_01

Por otro lado también quisiera, además de agradecer, reconocer. Por un lado al Centro de Ciberseguridad Industrial por contribuir a la difusión de artículos haciendo referencias en su Boletín Semanal de todos los lunes. A José Valiente y Miguel García-Menéndez, muchas gracias.  Por otro, al blog Fortixpert, por incluir en su web posts donde se hablaba de funcionalidades de equipos Fortinet para cubrir las necesidades de protección en entornos industriales.  A Jose Luis Laguna, muchas gracias. A mi compañero Antonio Navarrete por abrirme las puertas a eventos y profesionales que han contribuido la difusión del blog. Como no, a Jon Bueno por las oportunidad de trabajar y aprender con él y de él, en el desarrollo del proyecto de Ciberseguridad Industrial en la fábrica de Mercedes-Benz sita en Vitoria-Gasteiz. Por último a Unai Gómez, quien con sus comentarios y aportes me han hecho ver algunos aspectos del blog en los que no había parado. A todos, ¡MUCHAS GRACIAS!

Con esta meta alcanzada, ahora queda ir pensado en los objetivos para el 2018. Quizás sea un poco pronto, pero ya estamos poniendo a echar a andar la maquinaria de cómo introducir novedades y otros apartados de interés.

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos tambieén en @enredandoconred .

¡Un abrazo!

Edorta

EuskalHack Security Congress II

Allá por junio del año pasado escribí una crónica de lo que fue el primer Congreso de Seguridad del País Vasco, el “EuskalHack Security Congress”. Este año, la asociación se ha puesto manos a la obra para no sólo organizar el segundo sino además, traer consigo algunas novedades para consolidarse como un evento obligado para investigadores, profesionales, amantes o interesados en estos temas.

Logo EuskalHack

Si bien algunos de los ponentes del 2016 repiten en esta edición, habrá muchos nuevos tanto a  nivel nacional como internacional y que seguro van a hacer las delicias de todos los que estemos allí. Los primeros en confirmarse fueron Halvar Flake, Alex Ionescu, Steve Lord y Joxean Koret, a los que han seguido Javier Marcos, Pedro Candel, Andoni Valverde, David Sancho, Pedro Sánches, Félix Brezo, Yaiza Rubio, Mikel Iturbe, Borja Martínez, Josep Albors, Eloi Sanfelix y Cristofaro Mune. 

Si bien la mayoría de ellos se desempeñan como profesionales en empresas como CounterCraft, Telefónica, TrendMicro, ESET, Riscure, Innotec, entre otros, también hay profesores e investigadores como por ejemplo de la Universidad de Mondragón.

Agenda_Día_1

Como miembro de la Asociación, puedo decir con conocimiento de causa que la elección de los ponentes ha sido muy dura, dejándonos con mal sabor de boca  dejar fuera de agenda otros con excelentes propuestas a la par que interesantes. A los que no podrán estar, cualquier agradecimiento es poco por querer compartir con nosotros sus trabajos y hacer crecer este evento.

Otras de las novedades será la impartición de 3 “Trainings” para los días previos. Los mismos serán:

  1. Hacking IPv6 Networks v4.0
  2. Bug hunting bootcamp Discovering 0day
  3. OSINT Tools and Techniques: A Practical Approach

Sin duda una gran oportunidad para formarse y ampliar conocimientos en estas materias.

Agenda_Día_2

El evento además cuenta con descuentos para los asistentes tanto en alojamiento como en transporte. Gesto que es de agradecer teniendo en cuenta aquellos que vienen de lejos  y que, como muchos, no se quieren perder la oportunidad de ver a estos “cracks” dando a conocer el resultado de la inversión de tantas horas de lecturas, práctica e investigación.

Todo esto, y más, lo podéis encontrar en la Web del Congreso . De más está decir que el aforo es limitado y que el precio de las entradas incrementará a medida que estemos más sobre la fecha. Dicho sea de paso, incluyen la comida para ambos días.

Por último agradecer a patrocinadores y colaboradores que con sus aportaciones económicas y contribuciones, hacen posible que este proyecto salga adelante. Sin duda se ha hecho mucho trabajo, pero queda otro tanto por hacer. Sin embargo estamos seguros que la recompensa será el mismo nivel de satisfacción y gratitud en todos los asistentes que se animen a venir y comprobarlo por ellos mismos. No te quedes con las ganas y disfruta con nosotros de Hacking, Pentesting, Reversing, Ciberseguridad Industrial, Exploiting en un lugar de excepción. Y es que, aunque San Sebastián sea nuestro “Centro de Operaciones”, Euskadi también está deseando darte la bienvenida.

Nos vemos el 23 y 24 de junio!

Un saludo.

Edorta