y partiendo del esquema por capas
utilizado, se debe pensar en la reducción de riesgos en cada uno de los
posibles escenarios en los que nos movemos. Analizando los vectores, se
logra una mayor comprensión de la mirada de un potencial atacante.
 |
| Fuente cci-es.org |
Vectores de ataque
Muchos de los vectores relacionados con las dos capas inferiores son
fácilmente detectables o reconocibles, por la propia experiencia
intrínseca a la
seguridad en general:
a)
lograr acceso físico hasta donde están los sensores, los
actuadores o los PLC para alterar de alguna manera sus mediciones (en
caso de los sensores) o sus configuraciones de actuación en los
actuadores y los PLC.
b) Interceptar, interferir y/o manipular la información de las RTU vía
Wi-Fi o GPRS. Son comúnmente utilizadas para convertir señales
analógicas a información digital y por tanto como conversores de
protocolos, suelen ofrecer estos tipos de conectividades.
Al subir en el modelo por capas propuesto, nos vamos posicionando en
terrenos muy conocidos puesto que estamos hablando de aplicaciones...:
c) ...que corren en sistemas operativos comunes (es muy habitual Windows
XP) y que no llevan parches porque la aplicación en sí misma no los
soporta.
d) ...
que pueden tener fallos de seguridad como cualquier otra aplicación (incorrecta validación de parámetros, escasa o nula segmentación de roles y perfiles, precario manejo de sesión, etc.)
e) ...que utilizan protocolos (algunos conocidos y otros no tanto),
f) ...que son utilizadas por personas que pueden cometer errores en sus
procesos de monitorización o revisión, o bien tener información
incorrecta por no contar con un ERP que la centralice. Un caso típico es
el de los documentos Excel que cada persona involucrada tiene en su PC
con los datos y filtros que él considera importantes...
sin saber cuáles juzgaron importantes sus compañeros de trabajo.
Dado que las técnicas para comprometer la
seguridad utilizando vectores
de ataque a), b) y f) son muy conocidas (ingeniería social, wireless
hacking, GPRS hacking, etc.) nos centraremos en los casos:
sistemas operativos (c), aplicaciones (d), protocolos (e).
Sistemas Operativos
Cómo muchos pueden suponer ya, el sistema operativo más utilizado para
sistemas
industriales es Windows. La gran mayoría de los sistemas
SCADA que podemos encontrar están diseñados para ser ejecutados sobre
Windows, y muy particularmente sobre XP (ya sin soporte).
Curiosamente Microsoft no recomienda (ni ahora ni nunca lo ha hecho) este tipo de sistema operativo para sistemas críticos.
Sin embargo, al echar un rápido vistazo por los manuales de instalación
de muchos de los sistemas SCADA, es más que habitual encontrar
requerimientos como los siguientes:
- Instalar sobre Windows XP SP 2 o SP 3.
- Deshabilitar la instalación de parches.
- No implementar actualizaciones sin el visto bueno de nuestros ingenieros (los del sistema SCADA), de lo contrario no hay garantías de funcionalidad.
- Asegurarse de mantener el cortafuegos desactivado.
- No instalar ningún producto de antivirus ni antispyware.
- El usuario sobre el que se ejecuta la aplicación debe disponer de permisos administrativos.
En definitiva, ante el panorama propuesto, no tiene demasiado sentido
ahondar en cómo y por qué supone un (sencillo e) importante vector de
ataque el sistema operativo.
Aplicaciones
Probablemente muchos piensan que las soluciones de seguridad en los
sistemas industriales se basan en las aplicaciones, pero no.
Independientemente de todo el daño que se puede ocasionar a partir de
comprometer el sistema operativo, las aplicaciones por sí mismas
resultan (en muchos casos) perfectas para enseñar sobre hacking web:
- Es muy habitual encontrar problemas de cross site scripting (XSS).
- Sencillos problemas de inyección SQL.
- Carencia de cifrado.
- Separación de roles y funciones sin demasiados controles.
- Suplantación de identidades por medio de robo de cookies.
- Etc…
Es cierto que algunos fabricantes están modificando rápidamente su forma
de desarrollar aplicaciones para poder ofrecer una mejor seguridad. Sin
embargo, en los procesos industriales,
las actualizaciones reales de los sistemas tardan mucho tiempo en implementarse.
Estamos hablando de hasta años en algunos casos. Además, se sigue
dependiendo de personas que nunca trabajaron sobre el concepto de
security, por lo que, hoy por hoy, es posible encontrar muchísimos sistemas industriales expuestos a internet:
- Vía ADSL sin conocimiento del departamento de IT y mucho menos del de seguridad.
- Usuarios y claves por defecto con acceso por VNC sobre HTTP.
- Por supuesto, mayormente acceso sobre HTTP, no sobre HTTPS. Y varias
de las implementaciones sobre HTTPS sin certificados válidos.
En estas instancias, está claro que hay mucho por hacer aún en el mundo industrial, que básicamente
se encuentra unos diez años por detrás en términos de seguridad comparados con el mundo corporativo.
Esto puede resultar muy tentador para ciertos atacantes, pero como
advertencia general cabe recordar que no se debe olvidar el cuadro
completo. Al ejecutar una prueba (exploit o ataque manual) sobre un
sistema industrial, lo más grave ante un fallo no será que el sistema se
cuelgue o se caiga un servicio,
sino que algo del mundo físico puede fallar poniendo en peligro vidas humanas.
Muchos sistemas industriales poseen protecciones mecánicas ante un
cambio de parámetros sistematizado sin sentido o por reacción tardía de
un operador, actuando como control compensatorio.
Pero no todas las plantas ni procesos industriales los contemplan.
Los auditores con más experiencias recordarán que lanzar un simple
"nmap -sV" puede volver loco un viejo AS/400 sin actualizar, porque
"bindeará" todos sus puertos. Si esto puede detener las operaciones
críticas de un banco,
¿qué mal puede causar un sistema industrial que
controla algún sistema físico que se encarga de transportar personas,
por ejemplo?
Claudio Caracciolo
cludio.caracciolo@11paths.com
