Select Page
Dia mundial de la contraseña

Dia mundial de la contraseña

En el marco del Día Mundial de la Contraseña 2025, resulta crucial reflexionar sobre dos desafíos persistentes en el ámbito de la ciberseguridad: la permanencia de las contraseñas como principal método de autenticación y el agotamiento de los usuarios frente a las crecientes exigencias de seguridad.

Primero, las contraseñas siguen siendo la norma. A pesar del empuje de nuevas tecnologías, más del 58% de los usuarios aún utiliza combinaciones de nombre de usuario y contraseña para sus cuentas personales, y el 54% en entornos corporativos, según el informe global de Yubico 2024. A esto se suma que el 60% de las personas admite reutilizar contraseñas en distintos servicios, y un preocupante 13% declara usar la misma en todas sus cuentas, como señala una encuesta de JumpCloud. Este patrón de comportamiento se mantiene a pesar de los reiterados avisos de seguridad y los incidentes de filtraciones masivas que afectan a millones de usuarios cada año.

Segundo, la mayoría de los usuarios comunes se ven superados por las exigencias y recomendaciones de seguridad. Pedirles que creen claves únicas, largas, alfanuméricas, que las cambien regularmente y activen factores múltiples de autenticación termina siendo, en muchos casos, contraproducente. La sobrecarga cognitiva los empuja a adoptar prácticas poco seguras como escribir contraseñas en papel o usar combinaciones fácilmente adivinables. Un estudio de Security.org muestra que el 70% de los estadounidenses se siente abrumado por la cantidad de contraseñas que debe gestionar, y apenas un 36% ha adoptado gestores de contraseñas, a pesar de su efectividad.

En medio de esta discusión, aparece como solución definitiva el salto al modelo passwordless, con tecnologías específicas como passkeys. Sin embargo, a pesar del creciente entusiasmo por esta tecnología como alternativa segura y sin contraseñas, la realidad actual muestra que su adopción aún está en etapas iniciales. Según un informe de la FIDO Alliance, aunque el 74% de los consumidores están familiarizados con las passkeys, solo el 38% las habilita siempre que es posible. Además, aunque el 93.43% de los dispositivos son técnicamente compatibles con passkeys, su implementación efectiva en plataformas y servicios sigue siendo limitada. ​

Por otro lado, en el ámbito empresarial, un estudio de HID Global revela que el 87% de las organizaciones han implementado o están en proceso de implementar passkeys. Sin embargo, este despliegue se centra principalmente en usuarios con acceso a datos sensibles, y solo el 21% de las empresas planea una implementación total. Las principales barreras incluyen la complejidad, los costos y la falta de claridad sobre cómo proceder. ​

Esto significa que, la implementación de mecanismos de passwordless como passkeys, depende de que los responsables de las aplicaciones lo adopten e implementen. Pero….

Desde el punto de vista de los usuarios, mientras tengan que acceder a sitios o aplicaciones que usen las contraseñas tradicionales están obligados a utilizar el antiguo método.

En resumen, aunque las passkeys representan un avance significativo hacia una autenticación más segura y conveniente, su adopción masiva aún enfrenta desafíos técnicos y de usabilidad. Por lo tanto, en los próximos cinco años, es probable que las contraseñas sigan siendo una parte integral de la autenticación digital.

Por eso, se considera que durante el período de transición hacia el “passwordless total”, la solución de compromiso más efectiva hoy consiste la utilización de gestores de contraseñas pero pensados para usuarios finales. Es decir, con un alto nivel de seguridad pero lo más transparente posibles. Estos sistemas alivian la carga del usuario, permiten generar claves robustas y únicas, y pueden integrarse fácilmente con navegadores y dispositivos móviles. Lo importante es que cuenten con altos estándares de seguridad, como cifrado de extremo a extremo, autenticación biométrica y arquitectura de conocimiento cero y almacenamiento seguro que evite un único punto de falla. En un contexto donde las amenazas se automatizan y la fatiga del usuario es cada vez mayor, hacer de la seguridad algo invisible pero robusto es el mejor camino posible.

El futuro indudablemente va a ser passwordless, pero en el presente, gestionar bien las contraseñas sigue siendo esencial.

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.
Instalar QRadar CE en Proxmox

Instalar QRadar CE en Proxmox

Esta vez les cuento cómo instalar QRadar CE en Proxmox usando el archivo .ova provisto por IBM. El formato OVA se importa directamente en VMWare o en Virtualbox, pero no en Proxmox, y por eso este tutorial.

Si bien la instalación la hice con QRadar CE versión 7.3.3, estimo que estos pasos funcionan también en las demás versiones. 

 

Condiciones iniciales

Para aquellos que tengan ganas de jugar o experimentar con el SIEM QRadar de IBM, sepan que existe una versión gratuita denominada QRadar CE (Community Edition). Tiene el 90% de las funcionalidades de la versión paga y sólo está limitada a 50 EPS / 5000 FPM.

Este tuto tiene por objetivo expicar cómo instalar QRadar CE versión 7.3.3 sobre el ambiente de virtualización open source Proxmox versión 6.1-7.

Para escribirlo, me basé en un trabajo del año pasado de Tobias Hoffman, en varios documentos de IBM y en esta publicación de docplayer.

Instalar QRadar CE

Si bien es posible crear una máquina virtual en Proxmox e instalar QRadar CE desde cero, esto requiere bastante trabajo ya que QRadar se instala sobre CentOS por lo que hay que instalar CentOS primero, y después correr el setup de QRadar. Por eso, para hacerlo más rápido, vamos a usar la imagen .ova que provee IBM. El formato OVA se importa directamente en VMWare o en Virtualbox, sin embargo no es así en Proxmox.

Los pasos para importar el .ova de QRadar CE y luego instalar la aplicación son los siguientes:

 

1- Crear la VM en Proxmox.

Doy por sobrentendido que quien vaya a seguir de aquí en adelante tiene un Proxmox 6 instalado y funcionando. Entonces empecemos. Una vez logueado en el Proxmox:

  • Hacer clic en el botón Creare VM:

En la solapa General:

  • Seleccionar el Nodo donde se va a crear la VM (en este caso: pve1).
  • Elejir un ID (por ejemplo: 3000)
  • Definir un nombre (por ejemplo: qradarce-733)
  • Hacer clic en Next.

En la solapa OS:

  • Seleeccionar Do not use any media.
  • Para el tipo de sistema operarivo seleccionar Linux.
  • Para el kernel seleccionar 5.x – 2.6
  • Hacer clic en Next.

En la solapa System:

  • Dejar todo por default.
  • Hacer clic en Next.

En la solapa Hard Disk:

  • Dejar todo por default (no importa lo que se seleccione, ya que ese disco lo vamos a borrar luego).
  • Hacer clic en Next.

En la solapa CPU:

  • Seleccionar 2 Sockets y 2 Cores (si se usa la versión free de Proxmox, no es posible seleccionar más de 4 CPUs).
  • Hacer clic en Next.

En la solapa Memory:

  • Seleccionar un mínimo de 16GB de RAM.
  • Hacer clic en Next.

En la solapa Network:

  • Dejar todo por default.
  • Hacer clic en Next.

En la solapa Confirm:

  • Verificar que todo esté correcto.
  • Hacer clic en Finish.

 

 

2- Eliminar el disco que creamos.

  • En el menú de VMs de Proxmox, ubicar la VM que acabamos de crear (por ejemplo: VMID= 3000, Nombre= qradrarce-733) y hacer clic en Hardware.

 

  • Hacer clic en Detach.

 

  • Hacer clic en Yes.

Ahora el disco aparecerá como “Unused Disk“.

  • Seleccionar el disco.
  • Hacer clic en Remove.
  • Hacer clic en Yes.

Ya eliminamos el disco que nos creó Proxmox para poder incorporar el que viene en el .ova de QRadar.

 

3- Incorporar el disco de QRadar CE que viene dentro del archivo .ova en la VM que acabamos de crear.

 

IMPORTANTE: Para poder bajar los archivos de QRadar CE se debe ser un usuario registrado, asi que si no lo son, deben darse de alta.

Si bien se pueden bajar el .ova a sus máquinas y después transferirlo al Proxmox, en mi caso era mucho más ventajoso hacerlo directamente en el Proxmox. La razón es que estamos en Cuarentena, el Proxmox lo tengo a 20 km de casa, y mi ancho de banda de subida es horrible. Así que usé este truco:

Una vez logueados en el sitio de IBM:

 

  • Hacer clic en Download QRadar Community Edition V7.3.3. El sitio los redirige a esta página:

Ahora pueden bajar el .ova a sus máquinas como les dije antes, o bajarlo directamente en el Proxmox. Voy a explicar esta segunda opción:

  • Hacer clic derecho en la pantalla anterior en: Download.
  • En el menú contextual del browse, hacer clic en Copy Link Location o Copy link address (según sea el navegador).
  • Pegar el link en un archivo de texto para no perderlo. El link tendrá la forma:

hxxps://iwm.dhe.ibm.com/sdfrl/1v2/regs2/qrce/Xa.2/X….q/Xc.QRadarCE733GA_v1_0.ova/Xd./Xf.LPr.D1jk/Xg.1…2/Xi.swg-qradarcom/XY.regsrvs/XZ.4…n/QRadarCE733GA_v1_0.ova

  • Conectarse por ssh al Proxmox.

# ssh -l root <ip_del_proxmox>

  • Posicionarse en un directorio que tenga un espacio libre de al menos 4.1GB.

# cd /tmp

  • Bajar el QRadarCE733GA_v1_0.ova con el comando wget y el link que copiaron en el archivo de texto.

# wget -bqc hxxps://iwm.dhe.ibm.com/sdfrl/1v2/regs2/qrce/Xa.2/X….q/Xc.QRadarCE733GA_v1_0.ova/Xd./Xf.LPr.D1jk/Xg.1…2/Xi.swg-qradarcom/XY.regsrvs/XZ.4…n/QRadarCE733GA_v1_0.ova

Una vez que termine la bajada, y dado que el archivo .ova que nos bajamos no es más que un .tar:

# file QRadarCE733GA_v1_0.ova
QRadarCE733GA_v1_0.ova: POSIX tar archive

  • Destarearlo

# tar xfv QRadarCE733GA_v1_0.ova

Se destarean 4 archivos:

-rw-r–r– someone/someone 7381 2020-01-22 08:32 QCE-jan22.ovf
-rw-r–r– someone/someone 277 2020-01-22 08:32 QCE-jan22.mf
-rw-r–r– someone/someone 950009856 2020-01-22 08:32 QCE-jan22-file1.iso
-rw-r–r– someone/someone 3441993728 2020-01-22 08:36 QCE-jan22-disk1.vmdk

El que nos interesa es el disco virtual, es decir el QCE-jan22-disk1.vmdk.

  • Importar el disco en la VM con el siguiente comando en la consola de Proxmox.

# qm importdisk <ID> QCE-jan22-disk1.vmdk <store> -format qcow2

ID: es el VMID que definimos al crear la VM, en este caso: 3000.

store: es el repositorio de almacenamiento de las VMs en el caso de tener más de uno, en nuestro caso PVE-1.

En nuestro ejemplo, el comando quedaría:

# qm importdisk 3000 QCE-jan22-disk1.vmdk PVE-1 -format qcow2

Este comando importa el vmdk, lo convierte en qcow2 y lo asigna a la VM 3000.

  • En la interfase web de Proxmox, seleccionar la VM de QRadar que creamos:

Nos aparece el disco importado como “Unused Disk 0“.

  • Seleccionamos el disco.

  • Hacemos clic en Edit:

IMPORTANTE: El formato del disco que bajamos de IBM es IDE, así que en Bus/Device hay que seleccionar: IDE.

  • Hacemos clic en Add.

 

 

4- Instalar QRadar CE dentro de la VM

La VM ya está lista con el disco importado desde el .ova de IBM, pero QRadar todavía no está instalado. Estos son los pasos para hacerlo:

  • Bootear la VM.
  • Conectarse a la consola de Proxmox de la VM.
  • Cuando lo pida, definir una password para el root de la consola de QRadar.

Hay un mínimo de dos usuarios que necesitamos para que funcione, el root de la consola y el admin de la GUI.

Hay que tener en cuenta que al instalar QRadar, la dirección IP de la consola queda almacenanda por todos lados y cambiar la IP no es fácil. Por eso es importante asegurarse si la dirección IP que tiene la VM antes de instalar es la correcta.

  • Verificar la dirección IP de la VM

# ip a

  • Si la dirección IP no es la correcta, ejecutar el NetworkManager Tex User Interface (horrible, pero es lo que hay…):

# nmtui

  • Configurar los parámetros de red que correspondan.

Una vez definidos los parámetros de red, ya se puede configurar QRadar.

  • Ejecutar /root/setup

# cd

# ./setup

Armarse de paciencia porque tarda mucho. A mi me tardó como 1 hora.

Ojo que si se duermen, hay un momento en el que el setup pide la password de admin. Si no la ponen en un tiempo (que no se cuál es), el instalador sale por timeout y la instalación sigue. De esta forma, la password de admin queda desconfigurada.

Si todo funciona, una vez que el instalador termine, levantarán todos los servicios y se podrá acceder a la consola de QRadar apuntando el browser a:

https://<IP_de_la_VM_de_QRadar_CE>/

Si no lograron configurar la password de admin y ya están en este estado, lo mejor es:

Entrar a la consola por ssh.

# ssh -l root <IP_de_la_VM_de_QRadar_CE>

# /opt/qradar/support/changePasswd.sh

Cambian la contraseña y ya pueden entrar.

Si todo funciona, les recomiendo hacer un snapshot de la VM en este estado, porque si son como yo, seguro instalando cosas la van a romper y volver a este punto cuesta trabajo. Para eso:

Se conectan a la consola de QRadar via ssh y le dan:

# shutdown now

Proxmox permite hacer snapshots de las VMs vivas, pero como en cualquier otro sistema de virtualización, es mucho más limpio hacer un snapshot con la VM apagada.

  • Van a la interfase de Proxmox.
  • Seleccionan la VM
  • Van “Snapshots

  • Y hacen clic en “Take Snapshot“.

Ahora si, QRadarCE ya está listo para jugar, experimentar y romper. Que lo disfruten!!!

Hasta la próxima!

 

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Cada vez más cerca

Cada vez más cerca

Un informe publicado el día de hoy, señala que es posible para un atacante alterar datos de sensores en aviones, que podrían desencadenar en desastres aéreos.

El informe de la empresa Rapid7, presenta el resultado del análisis de investigadores de dicha empresa sobre dos implementaciones de redes CAN populares en el mercado.

El bus de redes CAN (Controller Area Network) en un avión, es un medio de transmisión de datos donde viaja la información de todos los sensores del avión. Estos sensores miden parámetros físicos vitales para la operación de la aeronave, tales como los datos de parámetros del motor, o del mismo avión como: actitud, altitud, dirección, etc. Esa información se envía por un bus CAN hacia los diferentes sistemas y panel de instrumentos de la cabina del avión.

Es evidente que los pilotos necesitan esa información para navegar. En medio de la noche y a 10 mil metros de altura, el piloto no tiene idea de si está a 10 mil, 11 mil u 8 mil metros y si se está dirigiendo al Norte o al Nor-Noroeste si no fuera por sus instrumentos.

¿Qué pasaría entonces, si alguien pudiese alterar esa información?, ¿si alguien pudiera hacer que los instrumentos indiquen que está a 8 mil metros cuando en realidad está a sólo mil…? ¿..y con el avión descendiendo..?

Bueno, los investigadores descubrieron que esto es posible, al menos en aviones pequeños. Sin embargo, los buses CAN o variantes de ésta tecnología se utilizan también en aviones grandes y hasta en la industria automotriz. La popularidad de este sistema se debe a su bajo costo. En los buses CAN, TODOS los mensajes se transmiten por el mismo bus desde todos los sensores hacia todos los endpoints.  Esta característica es barata, pero como ya se habrán dado cuenta, no demasiado segura… En algunos casos se utiliza autenticación de mensajes, pero que puede saltearse fácilmente.

Otra condición para que un ataque de este tipo sea “existoso”, es que el atacante tenga acceso físico al avión…. (como por ejemplo… ¿¿¿un pasajero..???).

Por un lado, ya alguna vez hablamos sobre los pobres sistemas de seguridad que poseen las aerolíneas en sus sistemas de gestión de pasajes (1, 2). Por el otro, ya hace algunos años algunos investigadores descubrieron que los sistemas de entretenimiento de los aviones comerciales eran vulnerables. Uno de los defectos de seguridad de estos sistemas es que los dispositivos USB de los sistemas de entretenimiento, permiten conectar dispositivos como teclados o mice que son reconocidos por los sistemas. De esta forma, es posible interactuar tanto con las aplicaciones, como con los sistemas operativos.

Aquí se puede ver un ejemplo de cómo salir de la pantalla de control de un sistema de entretenimiento de un avión de una aerolínea internacional muy importante, simplemente conectando un teclado y probando diferentes combinaciones de teclas:

La pregunta entonces, es: ¿cuánto puede demorar alguien en saltar del sistema de entretenimiento a una red CAN y producir un desastre aéreo?

Tan grave fue el resultado de esta investigación y del informe publicado hoy, que el mismo US-CERT publicó hoy mismo una alerta en su página sobre infraestructuras críticas.

No por nada se están creando desde hace poco más de un año empresas de ciberseguridad que dedicarán sólo a desarrollar soluciones tendientes a mitigar potenciales ciberataques sobre aeronaves.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Malboard: Replicando patrones de tipeo

Malboard: Replicando patrones de tipeo

Encuentran la forma de engañar a los sistemas de autenticación por reconocimiento de patrones de tipeo.

 

El Si6:

Fue allá por el 2003 en el Si6 donde iniciamos un conjunto de proyectos relacionados con la identificación de comportamiento de intrusos. Uno de los temas de investigación sobre el que trabajamos durante años, fue el de Keystroke Patterns o Patrones de Tipeo. El objetivo era el de poder identificar a un intruso, que se logueaba de forma interactiva a una shell, analizando su comportamiento de tipeo.

Aprovecho esta nota para nombrar a todos los investigadores que formaron parte del Si6, equipo al que me enorgullezco de haber pertenecido: Sebastián García, Flavio Fernández, Georgina Halladjian, Alejandro Benaben, Maximiliano Bertacchini, Luciano Bello, Verónica Estrada, Pablo Fierens y Carlos Benitez.

El Si6 no existe más, pero como los que estamos en este negocio sabemos que los rastros no se borran nunca en Internet, por si a alguien le interesa:

Como parte de nuestro trabajo, publicamos varios trabajos relacionados con la dinámica de tipeo, como por ejemplo:

Keystroke Dynamics:

Respecto a Keystroke Dynamics, el concepto es sencillo. Todas las personas utilizan sus dedos para oprimir teclas en un teclado. Del mismo modo que cada una de nosotros camina, sonríe o habla de forma diferente, también tipeamos de forma diferente. Por este motivo es posible identificar personas determinando lo que se denomina su “patrón de tipeo” o keystroke pattern.
Además de los trabajos de investigación, también desarrollamos una aplicación para detectar estos patrones en aplicaciones la web. La aplicación se denominaba k-profiler y los resultados de la investigación fue publicada en el paper: User Clustering Based on Keystroke Dynamics

 

El concepto consiste en medir los tiempos de latencia entre diferentes acciones realizada en el teclado (como apretar o soltar una tecla). La medición suele realizarse sobre el tiempo entre dos teclas sucesivas o “digrafos”.

En esa época, habíamos imaginado una némesis para el concepto. Consistía en la posibilidad de que un intruso alterara artificialmente su patrón de tipeo. De esta forma sería identificado como otro atacante y no como él mismo.

 

Malboard:

Pasaron 16 años y nuestro némesis se volvió realidad. Un grupo de investigadores de la universidad Ben-Gurion, descubrió una forma de engañar a los sistemas que autentican a las personas usando sus patrones de tipeo. El ataque, denominado Malboard, fue publicado en mayo pasado. En este caso, no es un usuario que se impersona en otro para falsear su patrón de tipeo. Sino que se utilizan dispositivos USB que se reconocen como teclados para inyectar comandos desde un teclado. Existen varios dispositivos de este tipo en el mercado, tal como el RubberDucky. Lo novedoso de este ataque es que los comandos se inyectan tal como lo haría el usuario al que se trata de impersonar.

Para el ataque, se evaluaron los patrones de tipeo de 30 personas realizando 3 acciones diferentes. A partir de la copia del patrón de tipeo, se inyectaron comandos maliciosos mientras se era monitoreado por diferentes sistemas de detección como TypingDNA o KeyTrac. El resultado fue que se logró evadir los sistemas de detección más del 83% de los casos.
Pero el grupo no se quedó sólo en el ataque. Desarrolló además un sistema que permite su detección. Con esto lograron un 100% de efectividad en la detección, al menos en las pruebas realizadas por ellos.

El método de identificación por patrones de tipeo se utilizó por primera vez con el telégrafo durante la guerra de secesión de Estados Unidos allá por 1860. Es interesante ver cómo técnicas como estas no mueren, sino que se reciclan constantemente evolucionando una y otra vez.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Ciberataques a centrales eléctricas… o Godzilla vs King Kong

Ciberataques a centrales eléctricas… o Godzilla vs King Kong

Recientemente, una impactante noticia sobre ciberataques a redes eléctricas recorrió portales en todo el mundo. La posibilidad de atacar centrales eléctricas, paralizando ciudades, estados y hasta países enteros, sería ya una realidad.

Ya habíamos mencionado hace poco más de un año, que los principales blancos de ciberataques a las infraestructuras críticas, eran las centrales eléctricas. Diferentes grupos en todo el mundo vienen intentando ingresar a las redes que controlan los sistemas de producción y distribución de electricidad.

Los principales blancos de ciberataques a las infraestructuras críticas, son desde hace mucho tiempo, las centrales eléctricas.

Estos grupos estuvieron tan activos, que hasta desarrollaron malware específico. Hace algunos años, investigadores de ESET descubrieron  malware como el Crashoverride (también llamado Industroyer), diseñado específicamente para atacar centrales eléctricas. El código fue descubierto dentro de una planta de distribución de energía eléctrica de Ucrania. El halllazgo se produjo luego de la interrupción del suministro eléctrico en la zona norte de la ciudad de Kiev, a varias decenas de miles de usuarios y por poco más de una hora. En ese momento la repercusión mundial fue enorme. La empresa Dragos analizó técnicamente al Crashoverride y los resultados del análisis se pueden ver en su sitio web, o en la charla que dieron en BlackHat en 2016.

 

Godzilla

Si bien esta actividad lleva años, esta semana ocurrió algo nuevo. El New York Times, publicó una serie de notas, que hacen referencia a un informe en el que se deja expuesto otro aspecto del problema. Según el informe, el gobierno de Estados Unidos, desarrolló e implantó un elaborado sistema de malware dentro de las redes del sistema de producción y distribución de energía eléctrica de Rusia. El objetivo parecería ser el de atacar la red eléctrica rusa en caso de que se produjera un conflicto importante entre Moscú y Washington.

 

King Kong

Pero del otro lado, las cosas no parecen ser muy diferentes. Ya el Wall Street Journal informaba muy detalladamente a principio de este año, sobre las actividades de hackers rusos en la infraestructura crítica de Estados Unidos. Al parecer  se fueron detectando rastros de infiltraciones en compañías eléctricas de 24 estados de la Unión. Previamente a esto, el 15 de marzo del año pasado, el gobierno de Estados Unidos, publicó un detallado informe en el que declararon la existencia de una campaña de hacking por parte de Rusia, para infiltrar la infraestructura crítica de Estados Unidos.

 

El G-20

Tanto ha escalado este conflicto silencioso en estos últimos días, que en este momento se está hablando que Putin y Trump se reunirían en privado, durante el próximo capítulo del G-20, sólo para tratar este tema. Lo que está claro es que las redes de energía eléctrica se han convertido recientemente en un campo de batalla internacional. Un nuevo campo de batalla donde, al parecer, dos monstruos decidieron enfrentarse.

 

Las redes de energía eléctrica se han convertido recientemente en un campo de batalla internacional. Un nuevo campo de batalla donde, al parecer, Rusia y Estados Unidos decidieron enfrentarse.

 

La pelea

¿Fue o no fue un ciberataque? Cuando hoy en día se produce un gigantesco apagón, dadas las circunstancias expuestas, lo primero que pensamos es que fue un ciberataque. Si bien puede ocurrir que en algunos casos no lo sea, la verdad es que la probabilidad de que sí lo sea es alta. Las herramientas de ataque están desarrolladas y disponibles. El esfuerzo por protegerse es muy alto mientras que el esfuerzo para atacar es mucho menor.

Para usar términos futbolísticos, los que estamos de este lado, sabemos que estamos perdiendo por goleada. Más o menos 10 a 1. Es 10 veces más facil atacar que defenderse. Se paga a los especialistas en ciberseguridad 10 veces más en el lado oscuro. El costo de las herramientas de ataque es 10 (¿o cien? ¿o mil?) veces más barato que las de defensa. Genera 10 veces más adrenalina atacar que defenderse. Los que estamos de este lado, perdemos en todos los partidos, aunque eso no significa que vamos a darnos por vencidos 🙂 algún día los sistemas serán lo suficientemente robustos como para que estas cosas no ocurran. De todos modos, hay un partido que ganamos, de cada 100 intentos de ataque, sólo uno llega al blanco.

 

En ciberseguridad, es 10 veces más fácil atacar que defenderse. El costo de las herramientas de ataque es 10 (¿o cien? ¿o mil?) veces más barato que las de defensa.

 

La baticueva

Mientras tanto en la baticueva… los diseñadores y programadores de todo este malware, deben probar muy bien el funcionamiento de sus desarrollos. ¿Y dónde probar…? El laboratorio es el laboratorio…, tiene grandes limitaciones. Es imposible reproducir todas las condiciones, escenarios y variables de instalaciones reales. Habrá que probar entonces de otra forma, en un escenario más verdadero, pero sin atacar a Godzilla ni a King Kong. ¿Porqué no hacerlo entonces, en algún pequeño y remoto país, con mínimas o nulas medidas de ciberprotección, y donde no haya demasiadas repercusiones por interrumpir el suministro eléctrico por algunas horas a algunos miles (¿…millones…?) de habitantes?

 

Los diseñadores y programadores de malware para centrales eléctricas, deben probar muy bien el funcionamiento de sus desarrollos.

 

Los monstruos

Cuando de chico veía las películas de Godzilla, siempre me preguntaba sobre la suerte que corrían las personas que quedaban aplastadas cuando los edificios se derrumbaban durante las peleas. Es que cuando pelean gigantes, es imposible no quedar cubiertos por toneladas de escombros como efecto colateral de tan titánica batalla.

 

 

 

Nota por Carlos Benitez

 

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