Select Page
Dark waters

Dark waters

Un ciberatacante intentó envenenar el agua de una planta de distribución en Florida interceptando Teamviewer.

La noticia sobre un hecho con el que hace rato se viene fantasando pero hasta ahora no se había concretado es del 8 de Febrero pasado. Un ciberatacante, aparentemente tratando simplemente de probar una vulnerabilidad, incrementó los niveles de Hidróxido de Sodio (para los del barrio, soda cáustica), de 100 partes por millón (100 ppm) a 11.100 partes por millón.

La acción fue descubierta por un operador que veía azorado cómo el cursor de la pantalla se movía “solo”. El sistema atacado fue el de control de los productos químicos que se les agrega al agua para mantener su nivel de potabilidad. En este caso, el Hidróxido de Sodio en bajas cantidades se utiliza para estabilizar el pH del agua a distribuir. Sin embargo, en las proporciones con las que el atacante configuró el sistema, en 24 a 36 hs hubiera llegado a la población produciendo serias lesiones en quienes estuvieran en contacto.

Sobre este incidente me parece oportuno hacer algunos comentarios. Uno de ellos es que de la lectura de la información, estoy de acuerdo con los analistas que coinciden en que fue alguien que simplemente se encontró con un sistema abierto y jugando pasó un valor de 100 a 11.100. Esto lo debe haber hecho simplemente agregando algunos unos delante del valor preseteado. Por esto me inclino a pensar (quiero creer) que no tenía idea de lo que estaba haciendo.

Por el otro lado, oooootra vez tenemos que hablar de TeamViewer. Es obvio que siempre hay un balance entre seguridad y facilidad de uso. A los que trabajamos en seguridad muchas veces nos odian por exagerar en las medidas de seguridad que hace que algunas aplicaciones sean engorrosas de utilizar. TeamViewer viene a facilitar la operación de una máquina que tenemos en la LAN de nuestra empresa, desde nuestra casa, sin usar VPN’s… Hay empresas en las que se utilizan sistemas de control de contenido o sistemas de protección de endpoints (EDR’s) para bloquear los accesos a herramientas de este tipo. Pero lo que más llama la atención es que sea la propia empresa la que haya decidido utilizar esta peligrosísima herramienta para una aplicación tan crítica como la distribución de agua.

Los responsables de la planta de distribución de agua de la ciudad de Oldsmar, indicaron que ya habían dejado de utilizar la aplicación. Sin embargo, al parecer, una máquina habia permanecido conectada y un atacante logró hacerse del acceso para ingresar a la misma.Y ¿cómo lo hizo?, bueno, no hacía falta ser un 1337 para esto. Hace poco, una enorme lista publicada de usuarios y contraseñas conocida como COMB incluía usuarios de la planta de Oldsmar. Eso significa que si el atacante tuvo acceso a la lista, le fue muy fácil probar contraseñas hasta entrar.

Para probarlo, lo que se puede hacer es usar (por ejemplo) theHarvester para buscar correos electrónicos de la planta de Oldsmar de esta forma:

$ theHarvester -d oldsmar.fl.us -l 500 -b all

Esto va a traer, entre otras, direcciones de email del dominio que se pasó como parámetro.  Esas direcciones se pueden ingresar en el sitio que cybernews creó para verificar si la dirección de email se encuentra dentro de los registros de COMB. En el caso de las direcciones obtenidas por theHarvester, el resultado es este:

 

Como puede verse, la dirección de email que se encontró con theHarvester, está en la base de datos ‘leakeados’ de COMB.

Cabe aclarar que otra falla muy común en las empresas, es la de dejar instalados sistemas legacies no inventariados, antiguos y vulnerables. Estos sistemas suelen ser fácilmente hallados por los atacantes y logran ingresar a los sistemas a través de ellos. En este caso en particular, se informó que la planta tiene instaladas versiones de Windows 7, sistema operativo vulnerable y obsoleto.

Tomando en cuenta esto último, vaya uno a saber cuántos de nuestros sistemas críticos están montados sobre sistemas vulnerables… Y cuántos de ellos son accedidos remotamente por los operadores via TeamViewer… Y cuánto falta para que un atacante genere un verdadero desastre a través de estos sistemas….

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
La suma de todos los miedos

La suma de todos los miedos

Según una reciente nota de sky.com, un grupo de hackers logró obtener información clasificada de un contratista que brinda soporte técnico crítico a una flota de misiles nucleares de EEUU.

La empresa ciberatacada es Westech International, una pequeña compañía que posee contratos con el Departamento de Defensa de Estados Unidos. Entre sus servicios, se encuentra un contrato con Northrup Grumman para dar soporte al sistema de misiles balísticos intercontinentales Minuteman III, brindando mantenimiento e ingeniería para sus operaciones en tierra. Estos misiles se encuentran almacenados en cientos de instalaciones de lanzamiento subterráneas protegidas, operadas por la Fuerza Aérea de EEUU.

Según ellos mismos informan en su sitio, “WESTECH también proporciona apoyo logístico y de mantenimiento para 18 estaciones de prueba de los Sistemas de Pruebas Automatizadas de los Minutema de Tierra (GMATS) ubicadas en seis bases. WESTECH opera el Depósito de GMATS en Hill AFB, UT almacenando más de 1500 artículos valorados en 18,8 millones de dólares, apoyando a toda la flota de GMATS.

La nota de sky.news, posee además un comentario localmente escalofriante. Mencionan, a modo de ejemplo, que cada misil “…es capaz de lanzar múltiples ojivas termonucleares a más de 6.000 millas, o la distancia entre Londres y Buenos Aires.

Lo cierto es que es una empresa muy pequeña, pero con la responsabilidad de manejar sistemas críticos y peligrosos.

Semejante responsabilidad viene con un gran poder (o al revés…). El asunto aquí es que las redes de Westech fueron infiltradas y fueron infectadas con un ransomware. Lo que sigue es conocido, una gran cantidad de archivos sensibles fueron cifrados y los ciberdelincuentes solicitaron rescate a la empresa para devolverlos sanos y salvos…

Ahora más técnicamente, el ransomware que los atacó fue MAZE, una conocida pieza de malware que tiene algunas características particulares y preocupantes.

La primera es que es un ransomware-for-rent. Es decir, los desarrolladores lo alquilan por un porcentaje de las ganancias del usuario final.

La segunda es que está asociado a grupos de cibercriminales rusos, y es aquí donde el objetivo del ataque empieza a hacer ruido.

El tercero y peor, es que adicionalmente a otros ransomware que sólo cifran los archivos y destruyen los originales, el MAZE tiene la habilidad de exfiltrar la información que ataca.

Por este motivo existe gran preocupación, porque más allá de la recuperación de los archivos originales (¿¡y el esquema de backup!?), existe la posibilidad que información crítica sobre este sistema de misiles se encuentre ahora en manos peligrosas.

Los responsables de Westech confirmaron el incidente en el que sus archivos fueron cifrados (¿¡y el EDR!?) y que están trabajando con una empresa de ciberseguridad local para efectuar el análisis forense e investigar qué y cómo sucedió (¿¡y los procesos!?).

Hace algún tiempo hablábamos de los peligros que atacantes pudiesen tomar control de sistemas militares, en ese caso de drones artillados. Aquí las posibilidades son mucho mayores y peores. El sistema de misiles Minuteman III es enorme, mortal y con un rango de distancia de acción de 1/4 del planeta.

Hoy en día es imposible pensar que haya organizaciones que manejan información tan crítica que puedan habr sido blanco de ransomware; y de un ransomware conocido. Es muy probable que los responsables de Westech, siendo tan chicos, se hayan planteado en algun momento el famoso “¿y a mí qué me van a sacar…?”

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
FEARWARE!

FEARWARE!

….o cómo usar el miedo como vector para ciberataques…
Pasaron ya 2 meses y medio desde el inicio de la pandemia del COVID-19, y ya se han producido numerosos eventos de ciberseguridad relacionados con el brote que afecta a la salud mundial.
Dicen que “a río revuelto, ganancia de pescador”. Hoy en día está claro que el río está muy revuelto y los pescadores, aún en nuestro ámbito, están a la orden del día. Estos son 3 de los casos de ciberseguridad que han resonado últimamente relacionados con el coronavirus:
 

Ataques de phishing:

Ya a principios de febrero habíamos contado en la sección de noticias de Platinumciber, que investigadores de KnowBe4 y de Mimecast, habían descubierto campañas de phishing utilizando al Coronavirus como excusa.
Las campañas consistían en enviar emails falsos, donde se prometía brindar tanto una lista de infecciones activas en el área circundante de la víctima, como recomendaciones para la prevención de las infecciones. En estos emails se invitaba a los usuarios a  hacer clic en un enlace que los llevaba a una página de login falsa donde se capturaban sus credenciales.

 

Spyware:

Otro de los casos fue detectado por la empresa Reason Security el 2 de marzo pasado. En ella detallan que se está distribuyendo un malware disfrazado de un mapa de infecciones de Coronavirus o “Coronavirus map”. La aplicación que se distribuye es muy convincente mostrando un mapa en tiempo real de la evolución de la pandemia. De hecho, el malware copia los datos reales del sitio verdadero de la Universidad Johns Hopkins y los presenta con una GUI muy parecida a la aplicación original. Lo que además hace el Corona-virus-Map.com.exe, es robar datos del browser del usuario que lo ejecutó, entre ellos las credenciales almacenadas. En publicaciones más recientes, este malware fue atribuido a hackers rusos y se cree que está relacionado con la familia de malware AZORult descubierta en el año 2016.

 

Ciberataques:

Para completar esta triada, en el día de hoy se informó que un hospital de República Checa que atiende pacientes con COVID-19 sufrió un ciberataque que obligó a apagar todos sus sistemas informáticos. Se trata del hospital de la Universidad de Brno en la ciudad del mismo nombre. Uno de los elementos que más llama la atención a los investigadores, es que en dicho hospital, el segundo en tamaño en el país, es donde se realiza la mayor parte de los análisis para verificar los casos de Coronavirus en República Checa. No se informó el daño causado por el ciberataque ni tampoco si llegó a penetrar los sistemas donde se realizan y almacenan los análisis de COVID-19.

 

Tal como se comenta en esta nota del medio de noticias británico Independent, la situación mundial causada por el Coronavirus es una excelente oportunidad para generar ciberataques. Los cibercriminales juegan entonces con dos elementos relacionados con esta situación.

El primero es que el miedo (en inglés: fear) genera en la población una necesidad imperiosa y a veces compulsiva de conocer detalles sobre lo que sucede. Esto implica que cualquier oferta que les llegue a los usuarios con información sobre la pandemia sea aceptada sin demasiado análisis.

El segundo es que tanto gobiernos, empresas o la población misma, están en estos días enfocando toda la atención a un solo objetivo: la contención de la enfermedad. Esto lleva irremediablemente, a bajar la guardia en todos los otros frentes, como por ejemplo en la ciberprotección.

Es explotando este factor miedo que los cibercriminales se aprovechan de la situación.

El caso del Coronavirus dio la oportunidad de acuñar un nuevo término: “Fearware“, para distinguir entre otros,  al ‘miedo’ como vector para ciberataques.

 

Actualización del 15-mar-2020, 21:45

Worldometer:

El sitio https://www.worldometers.info donde se publican estadísticas mundiales de diferentes temas, tomó el caso del Coronavirus para hacer el seguimiento de los casos. En el día de hoy (hace media hora) se pudo observar que los valores de casos en el mundo se habían incrementado de forma ridícula. Era posible ver estos números a las 21:25 (AR):

 

Y en el detalle por país:

Donde se ve el ingreso de 567.999 casos y 892.045 muertos en la Ciudad de Vaticano!

Refrescando la página a las 21:30 (AR) se podía ver otra modificación de los números:

 

Es muy probable que alguien haya tomado control de parte de la aplicación y haya ingresado esos datos de forma manual. Es muy poco probable que haya sido un error del sistema, ya que la Ciudad del Vaticano no figura dentro de la lista de países que admite el sistema.

Es un momento en que la humanidad necesita de la colaboración de todos y que se tome esto en serio.

Y acciones como estas, realmente causan indignación.

 

Actualización del 15-mar-2020, 22:33

La noticia de la intrusión fue también levantada por este sitio italiano.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
NetCAT: otro side-channel de Intel

NetCAT: otro side-channel de Intel

Otra vulnerabilidad de side-channel en procesadores Intel, permite reconstruir sesiones SSH usando Keystroke Dynamics.

Ya habíamos hablado hace tiempo de las vulnerabilidades de side-channels (o Canales laterales). Meltdown y Spectre son los más resonantes ejemplos de dichas vulnerabilidades que afectan a los procesadores Intel.
En ese sentido, investigadores de la universidad de Vrije de Amsterdan publicaron un paper donde presentan un nuevo ataque a procesadores Intel modernos explotando canales laterales.

A partir del descubrimiento, el grupo inició un proceso de publicación de la vulnerabilidad acordado con Intel y el CERT Alemán el 23 de Junio pasado. A la vulnerabilidad se le asignó el código CVE-2019-11184 y además Intel, le asignó el suyo propio: INTEL-SA-00290.

 

Fundamentos:

El grupo de 5 investigadores del Departamento de Ciencias de la Computación de la universidad, señala la dificultad que poseen los procesadores modernos para sostener la alta tasa de transferencia de placas de red modernas. En lugar de transferir esos datos desde y hacia la DRAM, los procesadores Intel modernos realizan operaciones de E/S directamente en la LLC. Esta función se denomina DCA (Direct Cache Access) y se utiliza en lugar de acceder a la memoria vía DMA (Direct Memory Access). La función para acelerar la transferencia de datos con esta técnica se denomina Data-Direct I/O (DDIO).

El problema de utilizar LLC es que esta memoria caché se comparte entre la CPU y el resto de los periféricos, y está implementada por diseño sin medidas de seguridad. Los investigadores de Vrije hicieron foco en uno de los dispositivos, las interfaces de red. De esta forma crearon un ataque denominado NetCAT (abreviatura de Network Cache ATtack) mediante el que explotan información sensible de tiempos en comunicaciones de redes. Particularmente, detectan las teclas oprimidas por otro usuario que comparta la misma CPU en una sesión SSH.

¿Pero cómo hacen para saber qué teclas oprimió un usuario? Esto sería imposible teniendo en cuenta que la vulnerabilidad descubierta es sobre el contenido de información de red (que quedan en la LLC) y a nivel de red, los paquetes SSH viajan cifrados. La forma de obtener esa información es adivinando las teclas que oprimen los usuarios. Y eso lo hacen mediante Keystroke Dynamics.

 

Prueba de concepto

Los investigadores publicaron el detalle de como construyeron el ataque. Éste empieza conectándose a un dispositivo que esté utilizando un procesador intel con DDIO y RDMA habilitados. Si hay un usuario que se conecta al mismo servidor y establece una sesión SSH, es posible registrar la llegada de cada paquete de dicha sesión. Dado que en SSH los caracteres que el usuario tipea se envían de a uno por vez, es posible adivinar los caracteres enviados por la latencia entre ellos. Esta técnica es bastante antigua. Esto ya lo hacía el viejo Chaosreader hace unos 15 años. El que, a su vez, había tomado el concepto de Song en su paper de 2001.
Podemos ver lo que hacía Chaosreader ya que milagrosamente ¡la página de Brendan Gregg sigue viva! La diferencia con NetCAT es que Chaosreader capturaba paquetes de red y trabajaba con ellos para obtener información diversa. Una de las funciones de la herramienta era “adivinar” el contenido de sesiones SSH mediante una herramienta denominada sshkeydata.
En esta página se pueden ver los resultados de procesar paquetes de sesiones SSH. Aquí se puede ver cómo se analizan los paquetes para tratar de reconstruir la sesión.

La gente de Vrije utilizó además que el de Song, otros trabajos más modernos que le permitieron aumentar la precisión. Por otro lado, leer los tiempos de llegada de los paquetes via DDIO es más preciso que usando libpcap por la red. Sin embargo, se enfrentaron con los mismos problemas que todos los que hicimos esto alguna vez: extraer las teclas tipeadas por usuarios no enrolados*. Teniendo en cuenta que todas las personas escriben sobre un teclado con patrones de tipeo diferentes, esta tarea es la más difícil de realizar.

 

Conclusiones

Por un lado, en la eterna pelea performance y usabilidad vs. seguridad, a veces ganan unos y a veces otros. Habilitar DDIO y RDMA sabemos que es poner a los procesadores en modo turbo. Pero el efecto secundario es que se pierde seguridad. En este caso, poder leer datos de la caché de los dispositivos va mucho más allá que reconstruir sesiones SSH. Hay mucha información sensible que puede estar siendo transferida entre dispositivos por un usuario y vista por otro que no tiene privilegios y sólo por estar en el mismo procesador.

Por el otro, ciberseguridad ya tiene tantos años que dejó de ser nueva. Otra vez side-channel attacks… otra vez Intel… otra vez keystroke dynamics.
Los problemas que se encuentran hoy ya no son nuevos, sino viejos que se reciclan.

 

 

*Usuarios no enrolados: usuarios de los cuales no se tiene la información de su patrón de tipeo.

 Usuarios enrolados: usuarios que se los somete a varias pruebas repetitivas, para que tipeen textos conocidos y controlados, y así se puede obtener su patrón de tipeo.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Búsqueda Implacable

Búsqueda Implacable

Alarma la escasez de profesionales en ciberseguridad en todo el mundo. Se estima que este año la diferencia entre demanda y oferta alcanzará a casi a 3 millones de profesionales.

 

No hace falta decir que a medida que pasa el tiempo el mundo se va informatizando exponencialmente. De más está decir también, que el efecto colateral es que la “ciberinseguridad” crece al mismo ritmo.

Empresas, gobiernos, ONGs, nuestras propias casas; en todos los ámbitos se deben tomar medidas adecuadas de ciberseguridad. La complejidad, la especificidad y la velocidad con la que aparecen las vulnerabilidades y las medidas de protección, hacen que sea irremediablemente necesaria la intervención de profesionales en el área. Esos profesionales, además, deben estar altamente calificados.

Del mismo modo que en otras disciplinas, existen estudios que analizan la necesidad de profesionales. En particular, la organización ISC(2) (International Information System Security Certification Consortium) viene realizando este tipo de análisis cada 2 años desde 2004.

El informe se denomina GISWS (Global Information Security Workforce Study). Su objetivo es hacer un seguimiento del impacto del clima económico en los miembros del consorcio. Se toman en cuenta salarios en ciberseguridad, perspectivas de contratación, presupuestos, amenazas y muchos otros aspectos.

Para tener una visión amplia del problema, y debido a que cada año las encuestas y los análisis fueron cambiando, armé este gráfico utilizando el GISWS y otras fuentes. La figura muestra la evolución de oferta y demanda laboral en el mundo en puestos relacionados con ciberseguridad desde 2003 hasta 2018.

 

 Oferta vs. demanda histórica de profesionales de ciberseguridad en el mundo

 

Para construir el gráfico, utilicé datos históricos del GISWS, datos del 2015, del 2016, del 2017 y del 2018.

Ya en el informe del GISWS de 2005, aparece en la página 8 una frase premonitoria. Menciona que si se les aumentara el presupuesto en ciberseguridad a las empresas, éstas incorporarían más profesionales. Pero que, por otro lado, “Anecdóticamente, muchos proveedores de servicios de seguridad están luchando por encontrar candidatos apropiados para cubrir vacantes dentro de su fuerza laboral de ciberseguridad.

Lo que posteriormente se ve muy claro es que a partir del 2013 se empieza abrir una brecha entre la demanda de profesionales de ciberseguridad y la oferta. Esta escasez se fue ampliando con los años hasta llegar hoy a 2.9 millones de profesionales en todo el mundo.

Las razones que mencionan los diferentes informes son variadas. Una de las principales es la necesidad de especialización que es sensiblemente mayor que en otrar ramas de IT. Esto parece que no hace tan atractiva a la disciplina, a pesar que los salarios a nivel mundial son muy altos.

Otra, por ejemplo, es el desinterés de los Millenials o post-Millenials a trabajar en el área. Esto lleva a que la mayor parte de los puestos estén cubiertos por profesionales de más de 40 o 50 años, con una limitada capacidad de recambio.

La realidad es que la cantidad de ciberincidentes crece año a año, así como el costo de los fraudes o las intrusiones. Por otro lado, se sabe desde hace años que el punto clave para tener una buena ciberprotección en una organización es la gente. Sin embargo, algo pasa que no es posible cubrir esas necesidades y que las organizaciones hagan enormes e infructuosos esfuerzos en estas búsquedas. Este se convierte entonces, en otro ámbito en el que los malos de la película, parecen estar ganando.

Nota por Carlos Benitez

 

Carlos Benitez es un reconocido experto en seguridad de la información.
El día de DNS

El día de DNS

El próximo viernes 1 de febrero (el “DNS Flag Day”) cambia parte de la implementación del software de servidores DNS en todo el mundo y algunos dominios podrían dejar de funcionar.

Los componentes que cambiarán son algunas configuraciones y parches poco ortodoxos que vienen siendo instalados desde hace casi 30 años.

¿Porqué se instituyó el DNS Flag day?

Los detalles se encuentran descriptos en el sitio DNS flag day. Tal como allí se explica, el sistema para resolver nombres en Internet se ha vuelto innecesariamente lento. Esto se debe a implementaciones de algunos servidores que no cumplen con el protocolo EDNS (Extension Mechanisms for DNS). Si bien este protocolo fue creado a principio de los ’90, nunca se logró implementar completamente. Algunas de estas configuraciones corresponden al uso de balanceadores de carga o firewalls configurados de forma incompleta o incorrecta.

Esto hizo que el sistema global de DNS se haya vuelto lento y que deje la posibilidad de que se generen fácilmente algunos tipos de ataques de Denegación de Servicios (DoS). La comunidad y un conjunto de las principales empresas de tecnología decidieron poner un punto final a esta situación. Y le pusieron fecha.

¿Qué pasará ese día?

El 1 de febrero de 2019 todas estas configuraciones y parches que mencionamos anteriormente dejarán de funcionar. Esto significa que todos los servidores DNS que estén mal configurados podrán, desde funcionar mucho más lento, hasta directamente dejar de resolver algunos nombres de dominio.

Por otro lado, el uso completo de EDNS agrega funcionalidad nueva que incluye mecanismos de protección contra algunos tipos de DoS que no podía ser utilizada hasta ahora.

¿Qué tenemos que hacer?

Si tenemos registrados dominios de Internet, debemos verificar si los servidores que resuelven esos nombres de dominio cumplen con el estándar o si se verán afectados y en qué medida. Para ello debemos ingresar a:

https://dnsflagday.net/#domain-holders

o a:

https://ednscomp.isc.org/ednscomp/

Si en cambio somos administradores de servidores de dominio, deberemos ingresar al siguiente sitio:

https://dnsflagday.net/#dns-admins

 

Si estas herramientas automáticas detectan errores en las configuraciones, mostrarán los pasos a seguir o cambios a realizar para solucionarlos. Es importante realizar estas verificaciones y, de ser necesario, los cambios antes del 1 de febrero próximo.

De esta forma, y casi 30 años después, lograremos entre todos, poner el DNS en orden…

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.