Vulnerabilidades en Controladores Lógico-Programables (PLC)

Pura vida gente!

El post de hoy, continúa el tema industrial que comenzamos con el tema de los antivirus hace unos días atrás.

Según la IEEE, en su normativa respecto a subestaciones de distribución de energía eléctrica, pero aplicable al resto de sistemas de automatización, la intrusión electrónica se define como la entrada en una subestación por vía electrónica (teléfono, radio, etc.) para manipular o interferir el equipamiento electrónico tales como controladores, autómatas, etc.

En el momento en que un sistema de control presenta la posibilidad de ser accedido de forma remota, su área de riesgo crece en forma alarmante. Cualquier punto de conexión es susceptible de ser utilizado por personas con aviesas intenciones.

Ejemplo de ello son los PLC. Cuando se dieron los ataques de Stuxnet , este reemplazaba comandos legítimos del software Siemens Simatic Step7 al PLC (uno tipo de dispositivo de los que se componen los sistemas SCADA). Además, había que tener en cuenta que los PLCs no son configurables para restringir su acceso a determinadas direcciones IP y, aunque el PLC sea configurado para aceptar únicamente paquetes autenticados, la medida de seguridad se puede deshabilitar mediante ataques de repetición.

Hay varias técnicas de penetración y varios tipos de remediación a dichas técnicas, pero van a depender del escenario, componentes que se deseen vulnerar y las interfaces que los PLC tengan. La siguiente es una lista de posibles metodologías y técnicas de ataque utilizadas contra sistemas de control y automatización:

• Análisis de vectores de ataque habituales (activo/pasivo), enumeración de vulnerabilidades, explotación de puertos disponibles y escalado de privilegios, harvesting, puertas traseras, copias de seguridad, eliminación del rastro/evidencias.
• Salto entre segmentos de red para alcanzar los objetivos de un sistema de control y automatización.
• Se recomiendan las siguientes técnicas de Pentest:
• Labores de inteligencia para dar con datos sobre protocolos usados y así vectorizar lenguajes de programación para inyección de scripts: Whois, Samspade, Maltego, Google hacking, Shodan.
• Ataques DNS en el caso de los sistemas bados en PC: DNS lookup, Netblock, transferencia de zona.
• Ataques en comunicaciones basadas en Ethernet/IP: ARP spoofing, IP spoofing, SYN flood, ICMP flood, Pinf of Death, etc.
• Ataques contra equipamiento de red periférico: STP spoofing, VLAN hopping, FW bypass, port knocking, fragmentación, etc.
• De los más importantes están los ataques a bajo nivel en infraestructuras de comunicaciones cableadas: PLC, PRIME; RS/232, RS/422, RS/485; MPLS, etc.
• Ataques en comunicaciones inalámbricas: Zigbee/IEC 802.15.4, Wifi/IEC 802.11. Por ejemplo ataques a PLC's marca Wireless Wire SW 1008. Pueden probar unos jammers geniales para wifi como el WB12.
• Ataques a nivel de aplicación: bypassing, desbordamientos de buffer, inyecciones de código, ataques CGI, RFI, etc.
• Ataques dirigidos y automatización de ataques: suite metasploit, autoPWN, Fast-Track, aspectos básicos de la creación de exploits basados en lenguajes como Ladder.

Otros aspectos básicos, como los pasos más comunes a seguir una vez que se ha alcanzado el acceso al PLC son (no necesariamente en ese orden):

1. Denegación de servicio en comunicaciones serie.
2. Captura, modificación e inyección de tráfico Modbus serie.
3. Captura y análisis de protocolo Modbus/TCP.
4. Captura, modificación e inyección de tráfico Zigbee.
5. Intrusión a un sistema SCADA desde el exterior: peligros asociados con un mal diseño.
6. Intrusión interna a un sistema SCADA.
7. Ataque a servidor web de una RTU y de un HMI en un aplicativo SCADA.

Descrito lo anterior, procedo a mencionar las remediaciones más comunes a los problemas de seguridad ya descritos:

• Métodos, modelos, técnicas y tecnologías de seguridad utilizadas en sistemas de control y automatización:
• Cortafuegos, diodos de datos, IPS, segmentación por encriptación y redes virtuales.
• Autenticación y autorización de entidades.
• Cifrado de comunicaciones: túneles/VPN, seguridad inalámbrica, etc.
• Registradores de eventos y SIEMs.
• Escáneres de vulnerabilidades.
• Antivirus y listas blancas.
• Tecnologías de gestión de parches.
• DLPs.
• Honeypots y honeynets.
• Segmentación en sistemas de control y automatización:
• Diseño de DMZs y de zonas/segmentos.
• Recomendaciones del IEC 643443/ISA99 y la RG 5.71.
• Buenas prácticas en el despliegue de cortafuegos: arquitecturas y reglas de filtrado.
• Monitorización de seguridad en sistemas de control y automatización: 
• Despliegue, configuración y mantenimiento de IDS/IPS de red y de host.
• Despliegue de sistemas de monitorización y gestión de eventos: SNMP-to-OPC, Syslog, agregación de logs, arquitecturas.
• Gestión de alertas, etc.
• Honeynets y honeypots.

Por supuesto, los pasos más comunes a seguir para implementar lo anterior sería:

1. Configuración de firewall perimetral.
2. Segmentación basada en VLAN.
3. Instalación y configuración de un diodo de datos.
4. Instalación y configuración de un IDS Modbus/TCP.

Nos vemos!

Shell-Shock y cómo parchearlo!

Hola, espero estén alertas con esta vulnerabilidad que se viene hablando desde el 24-09-2014.

Primero un poco de contexto, para que la gente que no sabe pueda entender. Bash es un utilitario cuya función consiste en interpretar órdenes. Está basado en la shell de Unix y es compatible con POSIX. Su nombre es un acrónimo de Bourne-Again Shell (otro shell bourne), haciendo un juego de palabras: born-again = renacimiento. Fue uno de los primeros intérpretes importantes de Unix. Listo, hasta acá la historia. A lo que vinimos:

Y ahora... cuál es el problema?

En muchos SO's las variables de entorno proporcionan una forma ágil de influir en el comportamiento de los programas instalados en este. Estas variables, por lo general, se componen de un nombre y un valor asignado. En la shell Bash se pueden ejecutar dichas variables por medio de funciones. En estos ambientes, es común que una gran cantidad de programas ejecuten shell Bash en background y a menudo, se utiliza para proporcionar acceso remoto a un usuario (a través de ssh, telnet, etcétera), proporcionar un analizador de secuencias de comandos CGI (Apache) o incluso apoyar la ejecución de comandos.

El día miércoles 24 de este mes, se anunció la vulnerabilidad y se publicó con el CVE-2014-7169 originalmente encontrada por el hacker francés Stephane Schazelas. Más tarde el experto en ciberseguridad Travis Ormandy lanzó un segundo exploit que funcionaba en sistemas ya parcheados, debido que los primeros parches eran incompletos. El Shell-Shock (como también le llaman) tiene una nota de gravedad 10, lo que significa que tiene un impacto máximo, y una calificación baja en complejidad de explotación, que significa que es relativamente fácil de utilizar por cibercriminales para lanzar ataques.

Podemos crear una función en el intérprete, exportarla e invocarla, por ejemplo:

$function prueba { echo "hola"; }
$ export –f prueba
$ bash
$ prueba
  hola

El problema radica en el mecanismo de exportación y cómo se interpreta el código que se inyecta en el entorno donde es exportada la función.

Para conseguir lo anterior, el bash recurre a un pequeño truco. No exporta la función como tal, sino que lo hace en una variable de entorno donde se interpreta su valor como el cuerpo de una función. Usando el ejemplo anterior, en vez de una función creemos una variable de entorno:

$ prueba = '() { echo "hola"; }'

Y exportamos la variable...

$ export prueba
$ bash
$ prueba
  hola

Cuando el entorno recibe esta variable y el interprete detecta la siguiente cadena "() {" entiende que está ante una función y comienza a interpretar su código. El problema (y esto es lo diabólico ja ja ja...), es que NO para de interpretar cuando termina el cuerpo de la función y continua ejecutando el código que viene detrás del cuerpo.

Un par de ejemplos:

1. DoS casero! Conocido como la fork-bomb, le pide a tu sistema ejecutar una gran cantidad de procesos hasta que el sistema se bloquea: '() {echo "hola";}; :(){:|:&};:'
2. Este comando puede formatear o eliminar todos los archivos contenidos en un dispositivo: '() {echo "hola";}; mkfs.ext3 /dev/sda'

La función debería de terminar justo cuando encuentre el "};" correspondiente pero inexplicablemente no lo hace, y peor aún, ejecuta directamente ese código anexado al cuerpo de la función.

Entonces, qué alcance tiene la vulnerabilidad?

Como resultado de esta vulnerabilidad muchos contextos están expuestos, por ejemplo:

• El ForceCommand es usado en configuraciones sshd, para proveer capacidades de ejecución de comandos a usuarios remotos. Este fallo puede ser usado para hacer bypass de comandos arbitrarios. Algunos deployments en Git o en Subversion pueden ser afectado por medio de estas inyecciones de código. 
• Los servidores Apache usan el mod_cgi o el mod_cgid, y estos pueden ser afectados con CGI scripts que sean escritos en bash.
• Otra falla se da mediante clientes DHCP, que en algunos casos ejecutan Bash scripts y utilizan variables de entorno suministradas por el servidor. Por ejemplo vean esta PoC para lograr Remote Code Execution (RCE).

OK... que hay del parche?

Debes comprender que va a arreglar sólo algunos de los aspectos de la vulnerabilidad y que al ser tan reciente, aún se desconocen los efectos secundarios del parche, además de las distintas opciones de ataques que podrían existir.

Puedes utilizar este >>>script<<< para prevenir y mitigar el impacto. En última instancia ya hay instrucciones para parchear el Bash.

Para acabar con el cuento, hay una serie de scripts para probar tanto la vulnerabilidad como el parche. Acá les dejo el post de la gente de RedHat al respecto.

Nos vemos y mucha suerte!

Xenotix XSS Exploit Framework v5.0 de OWASP

Hola! Recibí la noticia que OWASP liberó la quinta versión de Xenotix. Excelente noticia para tod@s aquell@s travies@s que estaban esperando esta jugosa actualización.

Para los que no lo conocen este framework es considerado el segundo repositorio de XSS Payloads del mundo, con aproximadamente 1630 distintos XSS Payloads efectivos para hacer detección de vulnerabilidades XSS y hacer WAF Bypass. Este engine te permite crear tests personalizados con la Xenotix API. Además incorpora una característica muy útil con el módulo de Information Gathering para la etapa de enumeración. Sin mencionar también los módulos de explotación ofensiva de XSS para Penetration Testing y uno especial llamado: Proof of Concept Creation.

Puedes bajártela de aquí.

Estos son los cambios que trae la versión 5:

• Xenotix Scripting Engine
• Xenotix API
• V4.5 Bug Fixes
• GET Network IP (Information Gathering)
• QR Code Generator for Xenotix xook
• HTML5 WebCam Screenshot(Exploitation Module)
• HTML5 Get Page Screenshot (Exploitation Module)
• Find Feature in View Source.
• Improved Payload Count to 1630
• Name Changes

Necesitarás tener preinstalado Microsoft .NET Framework 4.0 y IronPython 2.7.3 para que funcione. El año pasado Xenotix fue de las herramientas más votadas como una de las mejores "Top Security Tools", ya que se caracteriza por dar una baja tasa de falsos positivos utilizando tres motores de los navegadores conocidos, Trident, WebKit y Gecko.

Acá les comparto información adicional de la herramienta en sus versiones anteriores:

• OWASP Xenotix XSS Exploit Framework v4
• OWASP Xenotix XSS Exploit Framework v3
• OWASP Xenotix XSS Exploit Framework v3
• OWASP Xenotix XSS Exploit Framework v2