El post que buscas se encuentra eliminado, pero este también te puede interesar

Siemens fue atacado por Stuxnet pero desarrollo defensas

Los sistemas SCADA y su exposición ante ataques informáticos
http://www.magazcitum.com.mx/?p=1605#.Vm35hSt53K8
by Esteban San Román. CISSP, CISA y CEH. • 08/11/2011 • 0 Comments

A mayor integración de redes de información, mayores necesidades de protección

Siemens fue atacado por Stuxnet pero desarrollo defensas

Los medios de comunicación, a través de noticieros, periódicos y redes sociales dedican una buena cantidad de sus espacios a tratar temas de seguridad local e internacional. Por ejemplo, este año nos enteramos de los efectos del Tsunami en Japón, el macrosismo que provocó y cómo aún sufrimos las consecuencias de la desafortunada irradiación que se originó en Fukushima; este año también se produjeron movimientos rebeldes en diversos países de Medio Oriente, caracterizados por manifestaciones, un caos en el flujo de información por la censura, enfrentamientos entre civiles y fuerzas militares del orden; finalmente en esta temporada se han presentado fenómenos meteorológicos que han afectado los sistemas eléctricos y de suministro de agua en los Estados Unidos o en localidades de México y Centroamérica.

Una buena cantidad de estos eventos tienen un origen natural e incontrolable en ocasiones, pero existen otros que se producen por la acción concertada de una o varias personas bajo las realidades que hoy experimentamos a través de la ciberguerra, el cibercrimen o el ciberterrorismo. Los gobiernos hoy enfrentan acciones de sabotaje perpetrado por grupos radicales o el crimen organizado y estas amenazas se cristalizan cada vez con un mayor grado de sofisticación, buscando blancos en otros recursos de las organizaciones que hasta ahora habían sido simplemente ignorados.

.
El papel de los sistemas SCADA

Los sistemas SCADA (software de adquisición de datos y control de supervisión) se encargan de controlar sistemas industriales, por ejemplo aquellos que filtran y distribuyen el agua, los que controlan el flujo en las tuberías de gas y petróleo, algunos controlan medios de transporte suburbano como el metro y otros más participan en una amplia variedad de sistemas que apoyan los procesos de manufactura. Muchos de los sistemas en funcionamiento fueron desarrollados por empresas como ABB, Siemens y Rockwell, entre otros, y podemos decir que la gran mayoría tiene
varios años de operar en un entorno donde estos sistemas se encontraban totalmente aislados de la red de la organización.

Este paradigma ha cambiado en los últimos años, la convergencia de las redes de voz y datos ha integrado en la misma infraestructura física de transporte todos los sistemas que generan información de la organización incluyendo, desde luego, los sistemas SCADA. En consecuencia, esto ha provocado que desde hace no mucho se hayan vuelto el blanco de ataques informáticos.

Así pues, podríamos citar el caso de Vitek Boden en Australia, que en el año 2000, tras ser despedido de una planta de aguas residuales, accedió de manera remota a los sistemas de su antiguo lugar de trabajo para verter lodo tóxico en ríos y parques con la idea de que por la gravedad del problema lo volverían a llamar y recuperaría su empleo.

Existen otros casos en los que la incursión de un virus informático también se ha traducido en un impacto en la disponibilidad de los sistemas SCADA. Por ejemplo, el gusano Slammer fue de las amenazas más recordadas de 2003 y entre sus efectos podemos citar el apagado de los sistemas de una central eléctrica de Ohio; ese mismo año parece que otro virus provocó una pérdida de potencia en una planta que electrificaba secciones de Nueva York, aunque el informe oficial de la Comisión Regulatoria de Energía Nuclear indica que no se tiene evidencia de tal hecho..

El tema de la vulnerabilidad de SCADA volvió a salir a la luz tras la aparición de Stuxnet, un gusano informático descubierto en junio de 2010, caracterizado por espiar y reprogramar sistemas industriales SCADA y con el potencial de afectar infraestructuras críticas como las centrales nucleares de generación de energía. Stuxnet tiene la capacidad de reprogramar controladores lógicos programables (PLC, por sus siglas en inglés) y ocultar los cambios con el apoyo de un rootkit. El primer blanco de este gusano fueron los sistemas de la planta nuclear de Bushehr en Irán y, por ciertas peculiaridades de su código, se ha especulado que los autores pudieran ser los Estados Unidos e Israel.

.
¿Cómo se explota la vulnerabilidad de los sistemas SCADA?

En una colaboración anterior en Magazitum hablamos acerca de los fuzzers; mediante el uso de esta técnica se pueden enviar múltiples variantes de datos para averiguar con qué secuencia se puede provocar una falla y acto seguido permitir el acceso de hackers, que desde ese momento son capaces de ejecutar sus propios comandos. En eventos de la industria, como DefCon, expertos han presentado demostraciones de cómo es este un riesgo latente. Como en todo caso de desarrollo de software, se puede hablar de la existencia de bugs, pero las consecuencias de su explotación pueden tener repercusiones mucho más drásticas.

Muchas de las compañías que desarrollan software SCADA hacen difícil la instalación de parches o, en ocasiones ante el temor de que este código adicional afecte el software de operación, no ofrecen una estrategia de soporte para sistemas parchados. Por lo anterior, y como suele suceder en sistemas legados, se deja toda la estrategia de seguridad a la inclusión de firewalls y dispositivos de detección de intrusos que aíslen la infraestructura SCADA del resto de la red. Los sistemas SCADA fueron desarrollados pensando en redes que siempre estarían aisladas.

Por otro lado el protocolo base de muchos de los sistemas SCADA que hoy están en producción es Modbus, cuyo diseño está pensado para operar sobre líneas de transmisión en serie. El modo bajo el cual se da la comunicación de estas redes es un primitivo esquema “petición-respuesta”, que dificulta la identificación de un eventual ataque pues los sistemas no podrían distinguir entre peticiones legítimas o peticiones provenientes de sistemas infectados. El protocolo Modbus está montado sobre TCP y ese protocolo no realiza autenticación ni tiene funcionalidades de confidencialidad de manera nativa, de forma tal que una vez que el hacker logra entrar a la red puede tomar el control de una sesión.

El éxito de ataques como el Stuxnet y otros similares se debe también a la explotación de vulnerabilidades típicas de sistemas como los viejos conmutadores que tienen poca interacción con los usuarios comunes, lo predecible de sus rutinas de mantenimiento y que los sistemas usualmente conservan sus contraseñas de fábrica facilitando en
consecuencia el trabajo de quien busca accederlos.

Dado que la integración de redes ya no tiene vuelta atrás, pues las consideraciones económicas nos llevaron a un esquema donde no existe una separación física entre las redes de TI y las redes SCADA, lo único que se puede hacer es crear separaciones lógicas a través de tecnologías de switcheo y complementarlas con dispositivos como firewalls y detectores de intrusos.

.
Valoración del estado actual del ambiente SCADA en mi industria

Con el fin de tener un panorama que cubra de manera integral el aspecto regulatorio, la seguridad y las operaciones, se recomienda incluir métodos para seleccionar los estándares, guías, mejores prácticas, evaluaciones de seguridad (a nivel físico, de las instalaciones, de sistemas y de operaciones), análisis de brechas, análisis de riesgos, modelo organizacional de amenazas, estrategias de mitigación y remediación, sustento legal y programas de gestión y mantenimiento.

Bajo este modelo se proponen las siguientes etapas:

1. Etapa de evaluación.- Para identificar vulnerabilidades y brechas en el ambiente SCADA. En esta fase los
pasos principales son:

Identificación y selección de estándares– Buscando aquellos que se apeguen a lo que requiere la industria vertical sobre la cual estoy regido.
Análisis de políticas y procedimientos– Una vez seleccionada la regulación a la que se dará cumplimiento, se debe realizar una matriz comparativa contra las políticas y procedimientos que están definidos en mi organización a fin de verificar su adecuado cumplimiento.
Identificación y clasificación de activos críticos– De acuerdo a las definiciones de muchos mercados verticales, se requiere clasificar los activos de acuerdo a una serie específica de atributos. Dentro de estos puede estar definida también la confidencialidad y el manejo de información.
Evaluación de seguridad– Que usualmente reemplaza a algún ejercicio anterior. Es importante que este paso evolucione y sea cada vez más completo e incluyente. Una visión holística en las pruebas incluirá aspectos de seguridad de sistemas, seguridad física, operativa y el factor humano.
Validación de la evaluación– El análisis y los resultados deben ser validados, apoyados en pruebas adicionales, entrevistas o pruebas de penetración, de otra manera podrían estarse obteniendo falsos positivos u omitirse hallazgos sustanciales.
Análisis de riesgos– Todos los datos obtenidos deben analizarse de manera integral para tener un panorama claro de los niveles de seguridad, cumplimiento y riesgo. Esto usualmente implica la realización de modelos matemáticos de análisis de riesgos y modelado de amenazas.

2. Etapa de mitigación y remediación.- Con un ejercicio exhaustivo y bien ejecutado, las acciones derivadas para la mitigación y remediación deberán fincar los elementos necesarios para reforzar los recursos existentes e incorporar aquellos que hagan falta.

3. Etapa de validación.- Una vez implantados los controles de la etapa anterior, la acción subsecuente es validar que efectivamente están cumpliendo las funciones para las cuales fueron diseñados. Para esto se suele volver a realizar un análisis de vulnerabilidades y, en caso necesario, se determinará qué acciones de ajuste deberán realizarse.

4. Etapa de aseguramiento legal– Ejercicios poco fundamentados pueden traducirse en una responsabilidad legal por negligencia de quien tiene a su cargo la ejecución del análisis de vulnerabilidades o de la implementación y verificación de los controles que se requieran. Esta etapa en realidad está presente a lo largo del proceso con el fin de evitar que alguna de las etapas se realice sin el grado de detalle que se llegue a requerir.

5. Etapa de administración– Como en todo proceso de mejora continua, hay que dar seguimiento con un plan de largo plazo que tome en cuenta que todos los controles, políticas y procedimientos se mantengan al día con las tendencias que marque la industria.

6. Entrenamiento– La actualización es la base para que todos los responsables de la infraestructura sepan qué hacer con los recursos que tienen a su disposición, qué deben hacer en caso de un incidente y qué se espera de ellos.

.
Conclusiones

El empleo cada vez más generalizado de los sistemas SCADA constituye un nuevo reto y una realidad para los que la industria y la infraestructura de muchas ciudades debe estar preparada. La importancia de los sistemas SCADA en el control de servicios como la energía eléctrica y el suministro de agua potable hace que se conviertan en sistemas estratégicos o incluso en sistemas dignos de ser considerados como de seguridad nacional, ya que una falla en ellos puede acarrear consecuencias desastrosas (pienso, por ejemplo, en un reactor nuclear sin enfriar, bombas de agua potable estropeadas o contaminadas, generadores de energía eléctrica arruinados, etcétera). Recordemos que estamos en el umbral de una era de nuevos eventos de crimen cibernético y que con oportunas acciones preventivas se evitarán potenciales colapsos.

Esteban San Román. CISSP, CISA y CEH.

Se desempeña actualmente como Arquitecto de Soluciones en la Dirección de Arquitectura de Scitum, empresa de la cual forma parte desde 2008. Su experiencia en redes de comunicaciones y soluciones de TI de casi 20 años se ha forjado en empresas como IBM, Anixter, Delta Networks y Technidata, realizando funciones de ingeniero de sistemas, especialista en redes, director de servicios de TI y gerente de soporte preventa. Ha impartido cursos de entrenamiento México y varios países de Latinoamérica en tecnología de redes y certificaciones de seguridad.


Software
El virus Stuxnet es más antiguo de lo que se creía
https://www.fayerwayer.com/2013/02/stuxnet-el-virus-que-desactivo-una-planta-nuclear-en-iran-es-mas-antiguo-de-lo-que-se-creia/
por Cony Sturm26 febrero 2013hace 3 años

Investigadores descubrieron una versión "beta" del malware, cuyo código revela ataques alternativos y un parentesco seguro con Flame.

Investigadores de Symantec revelaron nueva información sobre el virus Stuxnet, un gusano que se hizo famoso por sabotear una planta de enriquecimiento de uranio en 2009, y que fue fabricado como arma de ciberguerra por Estados Unidos e Israel.

La version más antigua que se conoce es Stuxnet 0.5, que habría sido desarrollado en noviembre de 2005, casi dos años antes de lo que se pensaba, según Symantec. Esta primera versión, que comenzó a operar en 2007, contenía una estrategia de ataque alternativa que permitía cerrar de manera sigilosa las válvulas en la planta de enriquecimiento de uranio de Natanz. Las versiones posteriores eliminaron esa estrategia en favor de otra, que causaba que las centrífugas giraran de forma errática.

Para ejecutar este ataque, el virus inyectaba código malicioso en las instrucciones enviadas a 417 controladores lógicos programables (PLC) fabricados por Siemens, que eran utilizados por la planta para abrir y cerrar las válvulas que alimentaban de hexafluoruro de uranio a las centrífugas. Stuxnet 0.5 cerraba válvulas específicas antes de tiempo, haciendo que la presión subiera cinco veces más de lo normal, lo que provocaría la solidificación del hexafluoruro de uranio gaseoso y la destrucción de las centrífugas.

Para fabricar el virus, dice Symantec, los desarrolladores deben haber tenido un profundo conocimiento sobre cómo operaba la planta de Natanz. El malware venía con una instrucción de esperar entre 30 y 35 días antes de lanzar el ataque de las válvulas, que demoraría tres horas en completarse. La espera de un mes permitiría al virus recolectar información de mediciones en un día normal, las que serían reproducidas a los operadores mientras se ejecutaba el ataque, para que no fueran alertados sobre la irregularidad en las válvulas. El código también permitía bloquear la manipulación de las válvulas durante el ataque. Stuxnet 0.5 además estaba programado específicamente para afectar equipos con etiquetas de la planta de Natanz, posiblemente para evitar que otras plantas en el mundo se pudieran ver afectadas si el virus se esparcía por accidente.

El ataque de las válvulas, sin embargo, nunca se ha ejecutado (o no hay datos de que eso haya ocurrido). No está claro por qué este ataque fue retirado en versiones posteriores del virus.
Contagio

A diferencia de versiones posteriores, Stuxnet 0.5 sólo podía pasar de un computador a otro aprovechando una vulnerabilidad en el software Simatic Step7 de Siemens, usado para programar los controladores lógicos programables de la planta. Una vez que un computador estaba infectado, cualquier disco extraíble conectado al equipo que contuviera archivos Step7 sería infectado. Cuando esa unidad fuera conectada a otro PC, se contagiaría al abrir los archivos Step7 maliciosos.

Las versiones posteriores de Stuxnet aprovechaban cinco vulnerabilidades diferentes para auto replicarse, incluyendo algunas de día cero en Windows, con lo que las versiones 1.x terminaron con alrededor de 100.000 equipos infectados, donde la mayoría de ellos no tenía nada que ver con plantas de enriquecimiento de uranio.
Pariente de Flame

Symantec asegura también que los desarrolladores de la versión 0.5 son los mismos que crearon el virus Flame, un malware avanzado de espionaje. Aunque Kaspersky Lab ya había encontrado código compartido entre ambos virus en una versión más avanzada de Stuxnet, la versión 0.5 revelaría que el código compartido entre ambos malwares fue en algún momento tan amplio, que ambos proyectos estaban profundamente unidos.

"Con la versión 0.5 de Stuxnet podemos decir que los desarrolladores tenían acceso exactamente al mismo código. No eran sólo componentes compartidos. Estaban usando el mismo código exacto para construir los proyectos. Y entonces, en algún punto, el desarrollo (de Stuxnet y Flame) siguió dos direcciones diferentes", aseguró el gerente de operaciones de Symantec Security Response, Liam O'Murchu.
Los investigadores publicaron un paper con sus descubrimientos en PDF.



Siemens actualiza el firmware de S7-1200 para Stuxnet
http://www.distribuidor-oficial-siemens-productos-electricos.control-technics.com.ar/productos-siemens/es/Novedades%20Siemens/2869.htm

A pesar de las noticias recientes, la última de las vulnerabilidades del software de Siemens no son causados ​​por el malware (como Stuxnet), sino por una debilidad en las funciones de comunicación de su controlador lógico programable (PLC), llamado S7-1200. La vulnerabilidad fue descubierta por un investigador de NSS Labs y dio lugar a un aviso de seguridad ICS-CERT. El viernes, 10 de junio de Siemens ha publicado una actualización de firmware de su PLC S7-1200, que elimina las vulnerabilidades y mejorar la seguridad y la solidez de su familia de productos S7-1200.

En este momento, Siemens no tiene conocimiento de clientes afectados por los puntos débiles identificados en su PLC S7-1200. La empresa desea hacer hincapié en que está plenamente comprometida con el mantenimiento de los productos de mayor calidad con las normas de seguridad más estrictas. Los expertos de Siemens han estado trabajando estrechamente con ICS-CERT y diversas comunidades de usuarios para la mejora continua de los productos de controladores industriales Siemens Siemens sigue recomendando a todos sus clientes que apliquen las medidas de seguridad adecuadas (por ejemplo, cortafuegos, conmutadores seguros y puertas de enlace) en sus instalaciones que se suelen separar el PLC.

Como precaución adicional, los controladores de Siemens, incluyendo las familias S7-300/400, se están probando en contra de los escenarios de vulnerabilidad descubierta. En la actualidad, Siemens ya se puede excluir cualquier vulnerabilidad del S7-300/400 contra la "denegación de servicio". Nuevas pruebas exhaustivas de escenarios de seguridad adicionales están actualmente en curso en los laboratorios de investigación y desarrollo. Dependiendo de los resultados de esas pruebas, la empresa va a reaccionar en consecuencia. Si algún cliente tiene la preocupación de que una persona no autorizada ha sido capaz de grabar una línea de comunicación entre el PC de la ingeniería y el PLC, la compañía recomienda un cambio inmediato de la contraseña del PLC.

cyber

siemens

0 comentarios - Siemens fue atacado por Stuxnet pero desarrollo defensas