Guimms blog

Gusano infecta 8,9 millones de máquinas Windows

2009-01-20T04:16:00.000-08:00

El gusano, conocido por Conficker, Downadup o Kido, se extiende a través de una vulnerabilidad que Microsoft ya solucionó en octubre de 2008.

Investigadores de seguridad están advirtiendo de un gusano que en los últimos cuatro días ha sido capaz de infectar 8,9 millones de ordenadores basados en Windows. El gusano, conocido por Conficker, Downadup o Kido, se extiende a través de una vulnerabilidad que Microsoft ya solucionó en octubre de 2008, RPC (Remote Procedure Control).

Una vez en la máquina accede a un servidor HTTP y borra el punto de Restauración del Sistema de la máquina para impedir a los administradores que lo eliminen."El número de infecciones de Downadup se está disparando como un cohete, según nuestros cálculos", afirmaba F-Secure en su blog. El gusano incluye el paquete habitual de Troyano que permite al controlador descargar nuevos archivos en su propio servidor. Lo que no es normal es que el malware sea capaz de general lo que parecen cientos de nombres de dominios aleatorios para buscar actualizaciones, haciendo que sea mucho más difícil de seguir su pista hasta el escritor del malware.

Desde Sophos aconsejan bloquear todo el tráfico entrante y saliente del puerto 445 para asegurarse de que no se ven afectados por exploits de Internet y que, si lo está, no sea capaz de infectar al resto de la red a través de archivos compartidos.También se propaga por USBs.

fuente: vnunet

ISSI monitoring en forja

2009-01-15T12:23:00.000-08:00

En el campo de la seguridad SCADA, continuamos con el desarrollo del componente Joomla parte de ISSI Monitoring. Como muestra de ello ya disponemos de la v1.31 en la forja.

Ésta, es una aplicación para visualizar los incidentes ocurridos en nuestras redes industriales, mediante un componente en PHP.

Les recordamos que dicho componente se desarrolla sobre la licencia GPLv3, así que es de libre distribución.

GUIMMS y FLOSS

2009-01-11T12:16:00.000-08:00

Guimms se compromete a liberar el conocimiento siempre y cuando esto no haga peligrar sus objetivos. Estos serán los dos elementos que se tomaran en cuenta a la hora aplicar una licencia a nuestro software.

Se tendrán en cuenta, los beneficios que el respaldo de una comunidad aporte al liberar un código, y el riesgo que podría suponer poner un elemento estratégico en manos de los competidores. En el caso de liberar el código, se dará preferencia a la tercera versión de GLP (General Public License). Esta licencia está apoyada por FSF (Free software foundation) y OSI (Open Source Intiative) y es la versión mejor estructurada de ellas, lo que asegura la integridad de nuestros desarrollos FLOSS (Free/Libre/Open Source/Software).

Es por lo que preferiblemente adoptaremos una estrategia de licencia-dual, manteniendo los derechos sobre los elementos estratégicos y liberando las partes que precisen la aportación de una comunidad. Hemos observado casos de éxito como MySQL AB, cuyo modelo de negocio funcionó hasta la adquisición por parte de Sun Microsystems, que sustentan esta decisión.

Por ejemplo, ISSI Appliance es uno de nuestros productos estratégicos actualmente. Según lo descrito anteriormente no sería bueno para GUIMMS distribuir libremente este elemento diferenciador. Sin embargo, el componente Joomla distribuido dentro del suite ISSI monitoring, esta licenciado bajo GPLv3. Este hecho le dota de una transparencia y abre la posibilidad para mejorar colaborativamente sus prestaciones, junto con nuestros clientes, partners y aportaciones individuales.

Demo de ISSI

2009-01-09T14:19:00.001-08:00

Para ver el funcionamiento de nustro producto ISSI appliance, hemos realizado una captura de la aplicación describiendo su instalación y los servicios que ofrece.

Esperamos que sea de su agrado:

Guimms en Youtube

2009-01-09T12:21:00.000-08:00

Inaguramos nuestro canal de Youtube con la información y videos sobre la seguridad en resdes industriales.

Aqui les dejamos una pequeña demostración:

Seguridad en redes industriales

2009-01-09T11:36:00.000-08:00

Varias web presentan un roadmap a diez años vista sobre la seguridad en los sistemas de control del sector energético. La visión global del mismo es que en el año 2015, los sistemas de control propios del sector energético puedan superar un ciberataque sin dejar de prestar los servicios críticos.

Otras fuentes de información relacionadas con sistemas de control industriales (redes industriales) muestran el impacto y los incidentes surgidos en este tipo de redes los ultimos tiempos. Sin embargo, no está claro si hay más incidentes o simplemente están siendo detectadas y comunicadas más incidencias.

¿Tendremos que invertir en seguridad scada? A pesar de su función critica raramente las empresas, muchas de ellas en procesos de automatización, incorporan mecanismos de seguridad. Los protocolos están diseñados para ser eficientes y determinísticos, pero no seguros. Tradicionalmente la "seguridad por oscuridad" ha sido su mejor protección al ser protocolos muy especializados. Por consiguiente las organizaciones deberan adoptar ciertos mecanismos para hacer frente a ataques y amenazas.

Protocolos SCADA y seguridad

2009-01-02T09:04:00.000-08:00

Dedicaremos estas líneas a una de las partes mas vulnerables de las redes SCADA: los protocolos de comunicación.

A pesar de su función crítica raramente incorporan mecanismos de seguridad. Los protocolos están diseñados para ser eficientes y determinísticos, pero no seguros. Tradicionalmente la “seguridad por oscuridad” ha sido su mejor protección al ser protocolos muy especializados. Esto nunca ha sido buena idea, menos aún hoy en día debido a la progresiva migración hacia protocolos estandarizados y bien documentados.

Casi ningún protocolo de comunicación industrial incorpora en su especificación mecanismos de seguridad. Esto hace que desde el punto de vista de la intrusión, la confidencialidad o la integridad, las redes SCADA sean inseguras por su propia naturaleza.

A esto hay que añadir que los protocolos SCADA están sujetos al mismo tipo de técnicas de ataque que por ejemplo SMTP, HTTP o FTP: DoS, buffer overflows, etc…. Ningún fabricante de dispositivos SCADA está exento de tener los mismos errores de programación que Cisco o Microsoft.

La robustez en la implementación del protocolo es esencial a la hora de implementar redes seguras, algo no siempre tenido en cuenta en el diseño de equipamiento SCADA. El tratamiento de los errores suele ser deficiente y ello deriva en reinicios o denegaciones de servicio como consecuencia de, por ejemplo, escaneos o auditorías.

Existe en la industria una gran variedad de protocolos que permiten comunicar los dispositivos SCADA entre sí y con los centros de control. A continuación comentaré cuatro de los mas usados actualmente y algunas consideraciones respecto de la seguridad:

DNP3: Es un protocolo diseñado específicamente para su uso en aplicaciones SCADA. Permite a las Unidades Centrales ó MTU (Master Terminal Unit) obtener datos de las RTU (Remote Terminal Unit) a través de comandos de control predefinidos. El protocolo no fue diseñado teniendo en cuenta mecanismos de seguridad, por tanto carece de cualquier forma de autenticación o cifrado. Puede ir encapsulado sobre TCP/IP.
Una nueva versión del protocolo llamada DNPSec ha sido diseñada para incluir confidencialidad, integridad y autenticación sin mucho impacto en las implementaciones DNP3 ya existentes. Para su implementación sería necesario establecer, a semejanza de IPSec, directivas de seguridad que identifiquen algoritmos criptográficos y de autenticación, así como parámetros comunes para la comunicación entre aplicaciones.

ICCP (IEC 60870-6): Este protocolo es uno de los mas usados en los sistemas SCADA/DCS de compañías de generación y distribución de energía. Es un protocolo especialmente adaptado a las necesidades de comunicación de las compañías eléctricas. Proporciona conectividad entre subestaciones y centros de control y supervisión. El intercambio de datos consiste típicamente en monitorización en tiempo real, datos de control, valores de medida, programación, contabilidad y mensajes de operador.
Tradicionalmente vulnerable a ataques DoS debido a deficiencias en el código de la pila ICCP de muchos servidores. Al igual que la mayoría de los protocolos actuales SCADA, también es atacable por spoofing.
Un servidor ICCP con una vulnerabilidad, permitiría a un atacante tomar control del servidor de la organización y de todos los servidores ICCP que se comunican con él.

Modbus: Protocolo de la capa de aplicación empleado sobre RS-232, RS-422, RS-485 o TCP/IP. La principal ventaja es su simplicidad y es ampliamente usado en procesos de control de sistemas SCADA.
Para el caso de redes Ethernet existen dos especificaciones: MODBUS Plus y MODBUS/TCP. A destacar en el modelo de arquitectura MODBUS/TCP el módulo ‘Access Control Module’, pensado para restringir el acceso a servidores desde determinados clientes en entornos críticos. Se basa en listas de IP autorizadas.
Una de las vulnerabilidades aprovechables por los atacantes es la posibilidad de hacer fingerprinting a través de su puerto standard TCP/502. Mediante la función 43 del protocolo puede leerse el registro de identificación de PLCs y conseguir información del tipo de dispositivo, fabricante, versión y otras informaciones útiles para posteriores ataques.

OPC (OLE for Process Control): Es una interfaz estándar de comunicación usada en la industria de control de procesos. Está pensada para garantizar la interoperabilidad entre equipamiento de distintos fabricantes. Permite la comunicación entre aplicaciones de control y de supervisión con independencia de la red que haya por medio. Requiere que cada fabricante proporcione un driver genérico OPC. La mayoría de los fabricantes de HMI incluyen soporte para OPC.
Se basa en los estandares de Microsoft OLE, DCOM y RPC. El problema viene porque estos componentes de Microsoft han sido tradicionalmente fuente de agujeros de seguridad. Aunque los actuales esfuerzos de estandarización tienden a protocolos basados en web independientes del Sistema Operativo, la mayor parte de lo ya instalado se basa en el original ‘OLE for Process Control’ de Microsoft.
Un atacante que sepa del uso de OPC intentará aprovecharse de alguna de las conocidas vulnerabilidades de los servicios DCON y RPC. Mas aún sabiendo de la dificultad de los sistemas de control industrial para implementar actualizaciones.

En conclusión, una red SCADA será tan segura como mecanismos de seguridad incorporen sus protocolos o puedan aplicarse a los mismos. De nada sirve un firewall si no puede actuar sobre un determinado protocolo; como tampoco querer autenticar o cifrar el intercambio de datos sin la existencia de mecanismos intrínsecos de intercambio de claves.

Aquí he hecho referencia solamente a una pequeña parte de los protocolos utilizados en infraestructuras críticas. Todos ellos con sus propias particularidades en cuanto a comunicación cliente/servidor, temporizaciones, codificación y formateo de datos. De aquí la complejidad a la hora de dar soluciones genéricas de seguridad a este tipo de redes.