No hace mucho hablaba con una persona sobre la realización de auditorías en entornos industriales y de sus peculiaridades con respecto a los de IT. Aunque la metodología puede ser similar, no podemos considerarla igual.

Veamos porqué. El ciclo de vida de los dispositivos de Control y Automatización Industrial, y los equipos asociados como PCs, HMI, etc. es mucho mayor que los de IT. En concreto sobre estos últimos, provoca que nos encontremos con hardware con menos recursos que en los actuales, y Sistemas Operativos fuera de soporte como Windows 2000 o XP. Vulnerables y muy golosos para explotar alguna de ellas.

Para el caso de los PLCs, éstos disponen de muy pocos recursos en sí mismos. Podemos hablar de unos pocos Megas de memoria, véase el siguiente enlace el punto 8.1.4 página 148. Hablamos de expansiones de 4 y 2 Megas como máximo para el modelo de Siemens S7-300. A menudo podremos ver tarjetas dedicadas para las comunicaciones tanto de bus de campo como basados en Ethernet y así liberar a la CPU de este tipo de tareas. Un ejemplo de ello es la CP-343 de Siemens.

Uno de los aspectos que está permitiendo el desarrollo de la Cuarta Revolución Industrial, la llamada Industria 4.0, es la integración de protocolos de comunicaciones basados en Ethernet en lugar de los clásicos de campo bajo RS-485 o RS-422, entre otros. Esto no sólo permite su incorporación a las redes IT tradicionales, siempre y cuando las latencias en los procesos sean asumibles, sino su acceso por medio de servicios basados en TCP/IP y uso de protocolos como HTTP, NTP, SNMP o DNS.

Si unimos ambos puntos, hardware limitado y protocolos TCP/IP, un mal empleo de los mismos, o excesivo, podría llegar a colapsar o provocar un mal funcionamiento, comprometiendo así la disponibilidad que se requiere. Esto provoca que un DoS sea fácil de llevar a cabo si no se adoptan medidas adicionales que lo mitiguen.

Por ello es especialmente importante tener en cuenta, cuando llevemos a cabo una auditoría o pentesting contra este tipo de equipos y entornos, ser muy cautos en todos los pasos que llevemos a cabo. Sin pretenderlo, podremos dejar fuera de servicio una instalación al completo si bloqueamos el autómata que lo gobierna. He visto esta situación frente a un escaneo de la herramienta Qualys. Sobre esto también hay que puntualizar que depende también, cómo esté conectado a la red, pero eso es otro cantar.

Dentro de los primeros pasos en una auditoría es la detección de host, servicios, versiones, etc. dentro de la fase de Recolección de Información. La herramienta estrella es Nmap (he aquí una Guía muy buena), la cual podremos emplear tanto por línea de comandos como por medio de su GUI, Zenmap. En cualquiera de los casos deberemos tomar ciertas precauciones, especialmente en pruebas de Pentesting de Caja Negra donde no sabemos ni lo que nos vamos a encontrar. Por ello resulta necesario ser cauto y emplear Nmap con una serie de parámetros para que las “sondas” que envía no dañen nuestro equipo final.

Veamos pues:

1.- No es aconsejable emplear las opciones -O de detección de Sistema Operativo. Esto genera una gran cantidad de tráfico. Mucho menos -A (Aggressive) que además de lo anterior incluye detección de servicios, –sV; ejecuta scipts de escaneo, –sC y traceroute, –traceroute.

2.- Emplear templates -T0, -T1 y -T2. Estos plantillas introducen ciertos cambios en los escaneos con las opciones más comunes. Por defecto nmap utiliza el equivalente  a -T3. Sobre todo lo hacen esperando más tiempo entre sonda y sonda. Es muy común emplearlo para evadir controles de Firewall e IDS/IPS.

3.- No utilizar el escaneo –sU, ya que no contiene payload y al no cumplir con el estándar podría tenerse un comportamiento inesperado.

4.- Si vamos a detectar equipos activos en nuestra misma subred, emplear la opción  -PR con la que realizaremos escaneo empleando peticiones ARP.

5- Emplear modificaciones en los temporizadores:

Importante señalar -scan-delay > 1 segundo y -max-parallelism  = 1

6.- No seleccionar gran cantidad de puertos, mejor especificar uno por uno aunque lleve mayor cantidad de tiempo.

7.- Si empleamos scripts, lanzar de uno en uno aunque podamos ejecutar varios a la vez.

Como podemos comprobar no tiene mucho misterio las pautas a seguir, basta con ser un poco cuidadoso y no lanzar la herramienta a lo bruto. Demás está decir que todas estas pruebas habremos de hacerlas sobre un entorno de laboratorio o de pruebas. Si lo hacemos en “producción” las consecuencias pueden ser impredecibles y catastróficas. No es un tema para jugar…

Como siempre, mucho cuidado.

Un saludo!