Listado de la etiqueta: vulnerabilidad

De una credencial olvidada al control total: cómo se materializan los ataques en cloud

Existe una percepción errónea en muchos entornos cloud: que las brechas graves requieren técnicas avanzadas o vulnerabilidades complejas. La realidad es mucho más incómoda.

En numerosos incidentes recientes, el punto de entrada no ha sido un exploit sofisticado, sino un fallo básico de higiene de seguridad. Un ejemplo claro: una simple credencial expuesta terminó permitiendo el control completo de una cuenta en Amazon Web Services en cuestión de minutos. Este tipo de escenarios pone de manifiesto una característica clave del cloud moderno: la velocidad a la que los errores escalan.

El problema no fue el acceso inicial, sino lo que permitió

Todo comenzó con unas claves accesibles públicamente en un recurso de almacenamiento de Amazon S3.

A primera vista, el impacto parecía limitado. Sin embargo, incluso permisos aparentemente inofensivos pueden proporcionar suficiente información para iniciar un reconocimiento efectivo del entorno.

Una vez dentro, el atacante no necesitó explotar vulnerabilidades adicionales. Simplemente aprovechó lo que ya estaba disponible:

  • Capacidades existentes en funciones de AWS Lambda
  • Configuración de identidades en AWS Identity and Access Management
  • Permisos mal ajustados entre roles

El resultado fue una escalada progresiva hasta privilegios administrativos.

El verdadero riesgo: credenciales persistentes fuera de control

El uso indebido de claves de acceso sigue siendo uno de los vectores más recurrentes en incidentes cloud.

No se trata de un problema técnico complejo, sino de procesos:

  • Credenciales que se mantienen más tiempo del necesario
  • Uso de claves en automatizaciones sin controles adecuados
  • Exposición accidental en repositorios o entornos compartidos
  • Almacenamiento temporal que nunca se limpia

En paralelo, los atacantes han automatizado completamente la detección de este tipo de errores. No buscan activamente a una organización concreta: escanean de forma continua hasta encontrar algo utilizable.

Y cuando lo encuentran, el tiempo de reacción es mínimo.

De visibilidad a explotación en minutos

Uno de los aspectos más críticos en este tipo de incidentes es la rapidez con la que se encadenan los eventos.

El acceso inicial rara vez es el objetivo final. Es solo el punto de partida.

A partir de ahí, el atacante suele:

  • Identificar relaciones entre identidades
  • Detectar permisos indirectos o heredados
  • Aprovechar servicios existentes para ampliar capacidades
  • Expandirse lateralmente dentro del entorno

En plataformas como Amazon Web Services, donde todo está diseñado para ser flexible y escalable, esta progresión puede producirse sin fricción.

Cuando los límites entre identidades no están bien definidos, la infraestructura juega a favor del atacante.

Cuando la cuenta deja de ser un objetivo y se convierte en un recurso

Una vez conseguido el control administrativo, el impacto va más allá del acceso a datos.

En muchos casos, el atacante reutiliza la propia infraestructura comprometida:

  • Despliegue de recursos de computación intensiva
  • Uso de servicios avanzados como Amazon Bedrock
  • Ejecución de cargas con fines económicos

Esto refleja un cambio importante en el panorama de amenazas: el cloud ya no es solo un repositorio de información, sino un activo explotable en sí mismo.

El valor está tanto en los datos como en la capacidad de cómputo.

Por qué los errores simples ya no pasan desapercibidos

En entornos tradicionales, muchas configuraciones inseguras permanecían ocultas durante largos periodos.

Hoy, eso prácticamente no existe.

Los atacantes operan con herramientas que analizan continuamente:

  • Recursos expuestos
  • Políticas permisivas
  • Credenciales activas
  • Configuraciones inconsistentes

Esto convierte cualquier fallo en una superficie de ataque activa desde el momento en que aparece.

El problema no es solo cometer el error, sino el tiempo que permanece sin detectarse.

La seguridad cloud necesita cambiar de enfoque

Los modelos basados en revisiones periódicas o auditorías puntuales ya no son suficientes.

La defensa efectiva en cloud requiere:

  • Evaluación continua del estado de seguridad
  • Control estricto sobre identidades y permisos
  • Monitorización en tiempo real
  • Capacidad de detectar comportamientos anómalos rápidamente

Especialmente relevante es entender qué ocurre después del acceso inicial. Muchas organizaciones siguen centradas en prevenir la entrada, pero no en detectar el abuso una vez dentro.

Recomendaciones clave para reducir el riesgo

Aunque cada entorno es distinto, hay principios que se repiten en todos los incidentes de este tipo:

  • Evitar completamente el uso de credenciales en recursos públicos
  • Sustituir claves persistentes por credenciales temporales
  • Revisar continuamente los permisos efectivos de cada identidad
  • Implementar monitorización activa del uso de credenciales
  • Detectar cambios inesperados en roles y políticas
  • Tratar las identidades como el principal perímetro de seguridad

Estas prácticas no eliminan el riesgo, pero sí dificultan enormemente la escalada.

Reflexión final

Este tipo de incidentes no destacan por su sofisticación, sino por su previsibilidad.

Un pequeño descuido (una credencial olvidada, un permiso mal configurado) puede convertirse en la puerta de entrada a un compromiso total.

La diferencia entre un incidente menor y una brecha crítica no suele estar en el acceso inicial, sino en la capacidad de detectar y frenar lo que ocurre después.

En el contexto actual, donde la automatización juega tanto a favor de los equipos de seguridad como de los atacantes, el tiempo se ha convertido en el factor decisivo.

Y en cloud, ese tiempo se mide en minutos.

5 Mapas de ciberataques para impresionar «like a pro»

En una presentación ante público o en una reunión con la junta directiva de una empresa, no hay nada que llame tanto la atención como un mapa de ciberataques lleno de colores y «disparos» en todas direcciones.

Para los profesionales de seguridad es una forma visual muy potente de concienciar sobre el intenso tráfico de ataques que van y vienen por todas partes del mundo. Para nosotros, a veces, es complicado hacer entender que los recursos expuestos a Internet sin una debida protección son rápido objetivo de ataques indiscriminados, escaneos y todo tipo de malos tratos.

Cuando sacas uno de estos mapas, un ojo no acostumbrado a lo que «realmente se cuece» en las cloacas de Internet descubre de repente algo en lo que no había pensado y es una forma muy eficaz de comenzar a hablar de seguridad.

Es verdad que estamos «haciendo trampas», ya que es sencillo que el que escucha piense que lo que está viendo es en tiempo real, cuando la mayoría son representaciones de logs que muestran fotos en determinados instantes.

Hago una pausa para recomendar de nuevo el interesantísimo proyecto Honeystation y la crónica del Hackathon de CyberCamp 2015 en la que se mostraban despliegues de honeypots para crear un mapa en tiempo real.

Partiendo de todo esto y rebajando las pretensiones de tiempo real, os dejo enlaces a 5 páginas que ofrecen su servicio de mapa de ciberataques para que los podáis utilizar en vuestras charlas o presentaciones:

1 FireEye:

fireeye

 

2 Kaspersky:

 

3 Fortiguard:

 

4 Norse:

 

5 Checkpoint:

 

Cada mapa tiene sus datos de interés, sus curiosidades y particularidades por lo que unas veces te será más interesante uno que otro. Espero que te parezcan interesantes y que te sirvan para tus presentaciones.

Ojo, si tienes alguna favorita y no está en esta lista, dímelo en los comentarios, vale?

¡Saludos, te espero en la próxima entrada de SecurityInside.info!

primer_ataque_dos

¿El primer ataque DoS de la historia?

Estamos en 2017, lo que implica que el ataque DoS (Denegación de Servicio – Denial of Service) cumple 43 años. Lo que nació como la obra de un geek (o friki como decimos por aquí) se ha ido convirtiendo en algo muy elaborado que afecta a multitud de sistemas. Además, gracias a Internet, su variante DDoS (Distributed DoS) es sin duda uno de los quebraderos de cabeza de los que trabajamos en esto.

Un poco de historia

Cuenta la leyenda que el primer ataque DoS ocurrió en 1974 gracias a la curiosidad de David Dennis, un estudiante de 13 años de la Universidad de Illinois. David se percató de la existencia de un comando en los terminales PLATO (uno de los primeros sistemas computerizdos de aprendizaje compartido, antecesor de los sistemas multiusuario) llamado «ext».

Este comando permitía conectar dispositivos externos y suponía que cuando se lanzaba, el dispositivo estaría presente, avisando de que únicamente era útil usarlo en ese caso.

Sin embargo, no avisaba de lo que ocurriría si no había dispositivos conectados. Cuando el comando se ejecutaba en un terminal así, se bloqueaba requiriendo un reinicio para volver a funcionar.

En este escenario, David tuvo la curiosidad de comprobar si era capaz de bloquear a todos los usuarios a la vez, de forma que el laboratorio quedase colapsado. Con esto en mente, desarrolló un programa que enviaba el comando «ext» a todos los terminales PLATO al mismo tiempo.

Como podéis imaginar, la ejecución fue un éxito rotundo, ya que bloqueó los terminales de más de 30 usuarios ante el asombro general. Este movimiento terminó con el bloqueo de la ejecución del comando «ext» de forma remota.

Os dejo la historia contada por David Dennis:

As far as I know, I’m the first person to have created a DoS of a room full of PLATO terminals deliberately. Systems people could of course kick anyone out they wanted, and «operator wars» had existed for years, but those tended to be consensual attacks on each other. What I did was I heard about a new command called the «external» command in TUTOR, or ‘ext’. Specifically, one of the music kids was saying how if you didn’t have a device attached, an ext command would cause your terminal to lock up and have to be powered off. Remember that powering off was discouraged, due to always-concern over flaky power to the plasma panels.

The other piece of this was they had rolled out the external command for everyone in the fall of 1974, after it having been only in use by the Music project. This meant that every user account on PLATO was set to defalt «can accept ext commands.» Default on.

If you recognize default enabled from any firewall work you’ll immediately recognize the trouble…

Anyway, I heard this and immediately thought of how a room full of annoying users could be locked up at once. My little 13 year old brain wanted to see a room full of users all be locked up at once.

So, I wrote a little program that sent exts to everyone within a range of site numbers, waited til I was over at CERL one morning, and let er rip.

It worked as advertised, 31 users all had to power off at once, great mayhem in the classroom, site monitors notified. No logging of course, I was never detected. Quietly left the room, went back over to uni.

Accessed the site displays I knew of from author mode, and looked up other sites around town or the country, and tried sending them some ext’s too. Was delighted to see mass posting on notesfiles about a locking out they were experiencing.

Soon some systems guys figured it out, probably a combination of common sense and maybe looking in some sort of logs, though I was never prosecuted or even approached, so I have to think to this day it was undetected. A few weeks later the ext command was withdrawn from ‘open all’ and a while after that was redeployed, this time with the default set to OFF. As it should have been all along. 🙂

So was there ever a DoS on a networked system prior to 1974 ? Im sure there had to be, but at least for the moment I’m claiming it !

Y la moraleja es…

Al final, es la historia de siempre. Si hacemos algo pensando en que la situación perfecta es la única, lo más probable es que alguien se de cuenta de que, si esa situación no se da, ocurre algo indeterminado. A partir de ahí, encontrada la vulnerabilidad, lo demás es jugar y eso es precisamente lo que hizo David.

Como dijo Chema en alguno de sus posts:

Entendemos como Software Fiable aquel que hace lo que tiene que hacer y como Software Seguro aquel que hace lo que tiene que hacer y nada más. Ese algo más entre el software fiable y el software seguro son los bugs.

En este blog puedes encontrar algunas entradas que te pueden ayudar a desarrollar software seguro como las de las contraseñas (esta o esta) o las de auditoría de código (esta, esta o esta). Con estos consejos podrás lidiar en la medida de lo posible contra ataques DoS como el que hizo David. En cuanto a los DDoS, eso es otra historia…

27.001, un vistazo a la terminología antes de empezar

En los próximos meses voy a ir publicando diferentes entradas sobre la norma 27.001 y cómo aplicarla con ejemplos prácticos. Espero que sea un viaje productivo para mí y para vosotros, pero antes quiero sentar unas bases para que estemos todos alineados con lo que iré contando. En esta primera entrada hablaremos de…

Terminología de Seguridad

terminologia-2

27.001 – Seguridad de la información

Es un concepto abstracto, se trata de ofrecer una sensación de protección sobre la información, uno de los activos principales de las organizaciones.

 

terminologia-3

27.001 – Amenaza

Es una acción o evento que puede comprometer la seguridad de la información. Las consideramos como potenciales y su efecto dependerá del entorno en el que puedan convertirse en realidad.

 

terminologia-4

27.001 – Vulnerabilidad

Existencia de una debilidad en un diseño o implementación que puede derivar en un compromiso de seguridad en los sistemas.

 

terminologia-5

27.001 – Exploit

Una forma definida de burlar la seguridad de un sistema a través de una vulnerabilidad.

 

terminologia-6

27.001 – Evaluación del objetivo

Acción de identificar y evaluar un sistema, producto o componente en busca de vulnerabilidades que puedan ser explotadas.

 

terminologia-7

27.001 – Ataque

Un asalto a un sistema. Un ataque es una acción que viola la seguridad de la información.

 

Dominios de seguridad

Para gestionar la seguridad de la información, vamos a trabajar en cuatro pilares básicos que serán el objetivo a mantener:

dominio-2

27.001 – Confidencialidad

Es la propiedad que indica que la información sólo deber ser accedida por personal autorizado.

 

dominio-3

27.001 – Autenticidad

Es la propiedad que permite asegurar el origen de la información, validando al emisor de la misma.

 

dominio-4

27.001 – Integridad

Es la característica que hace que el contenido de la información permanezca inalterado, a menos que sea modificado por personal autorizado.

 

dominio-5

27.001 – Disponibilidad

Es la capacidad de la información de estar siempre disponible para ser procesada por las personas autorizadas.

 

Es muy importante estar familiarizado con estos conceptos para poder abordar las tareas que iré comentando relativas a la ISO 27.001. Si quieres conocer muchos más, no dudes en echar un vistazo a la entrada de «Seguridad de la información» en wikipedia.

En próximas semanas arrancamos, que ahora mismo estoy a punto de ser padre y no dispongo del tiempo suficiente para poder contaros en profundidad. ¡Pero en unas semanas estoy de nuevo con las pilas cargadas!

Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.