Listado de la etiqueta: auditoría

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.

Sueño cumplido, profesor en Máster de Seguridad

Corría el año 2.007 cuando participé como ponente en el evento CodeCamp de Microsoft como reciente ganador del premio Imagine Cup (también de la compañía de Bill Gates). Allí tuve el placer de asistir a una charla de un chaval con gorro a rayas que salió disfrazado de rock star (con la guitarra de Guitar Hero) y que encendió mi curiosidad por la Seguridad de la Información.

Sí, era Chema Alonso antes de ser estrella del rock

Desde ese momento empecé a leer blogs, a practicar cosillas por mi cuenta y a buscar la forma en la que poder formarme o incluso orientar mi vida laboral hacia ese mundo tan interesante que me habían mostrado.

Finalmente me decidí por realizar un Máster de Seguridad con el que me metí de lleno en ese campo, lo que me abrió las puertas a poder trabajar en el sector para ir creciendo y aprendiendo hasta llegar a ser el Responsable de Seguridad de una startup que será bombazo a corto/medio plazo.

Sin embargo, la lista de deseos para una vida no se queda sólo en trabajar en aquello que realmente te apasiona. Tambien fui tachando los deseos cumplidos relaticos a escribir un libro, grabar un disco, tener hijas, ver en directo «The Wall» de Pink Floyd, tener una banda de R&R, … pero faltaba algo importante para mi: Ser profesor de un Máster. Y ahora lo he conseguido, ¿te lo vendo? A ver qué tal se me da…

¿Eres un apasionado de la seguridad? ¿Trabajas en el sector tecnológico? ¿Quieres seguir formándote? Es probable que, en algún momento, te hagas una pregunta importante…

¿Debería hacer un Máster en Seguridad de la Información?

En este campo, toda la formación que recibas es una inversión de futuro. El sector IT forma parte cada vez más de nuestras vidas y su avance nos obliga a mantener un estado de formación continua si no queremos quedarnos obsoletos en unos meses.

Por suerte o desgracia, la seguridad toma un papel vital en todo esto y tener una formación especializada es un elemento diferenciador ahora, pero puede que obligatorio en un futuro cercano.

Hacer un Máster en Seguridad de la Información es un paso muy importante en tu carrera profesional, deja que te de tres motivos que influyeron positivamente en mi decisión para hacerlo:

  • Obtendrás conocimientos de primera mano gracias a los profesionales que lo imparten: los profesores suelen ser personas destacadas del sector, con amplia experiencia en aquello que te van a contar. No sólo aprenderás la teoría, también recibirás un valioso conocimiento de su experiencia práctica que te servirá para estar preparado para lo que te puedes encontrar.
  • Te centrarás en aquello que realmente te interesa: en la Universidad estudiamos un abanico de opciones relacionadas con nuestra carrera, algunas de ellas nos gustan y otras nos resultan irrelevantes. En un Máster, todo lo que ves está relacionado con tu pasión.
  • Forjarás nuevos y duraderos contactos: las personas que te encontrarás en el camino tienen tus mismos intereses y es muy habitual que surjan grandes amistades y hasta proyectos profesionales.

Como te digo, en mi caso particular, la elección fue afirmativa. No hay un día en el que no me alegre de aquella decisión. Desde entonces, he orientado mi vida laboral y continúo formándome para estar preparado ante los nuevos retos de seguridad que aparecen casi a diario.

Ojo, no lo hagas si …

Si tu única motivación es encontrar trabajo porque has leído que se necesitan cientos de miles de millones de especialistas por todo el mundo, no lo hagas. Si, he dicho no lo hagas. Un Máster es una especialización que necesita pasión, si no te resulta atractivo lo que vas a aprender, te aburrirás, nuncas serás un buen profesional y terminarás cambiando de campo habiendo tirado tu tiempo y dinero a la basura.

Echa un ojo a los perfiles más demandados

Dentro del mundo de la seguridad, hay diferentes caminos que puedes seguir:

  • Operación.
  • Hacking ético.
  • Arquitectura de seguridad.
  • Desarrollo de seguridad.
  • Auditor 27.001, LOPD, …
  • Continuidad de negocio.
  • Gestión de incidentes.

De todos estos campos, tienes formación dentro del Máster de Seguridad de la Información y Continuidad de Negocio de Eadic, título propio de la Universidad Rey Juan Carlos.

Partiendo de esta base, he tratado de reunir todo mi conocimiento y experiencia en los dos temas relativos a la auditoría de la norma ISO 27.001 de la que espero ser tu profesor si te animas a participar.

Durante dos semanas, te contaré todo lo que necesitas saber para afrontar como auditor un proceso completo de auditoría. Recuerda que estoy cumpliendo un sueño, así que te aseguro que voy a dar lo mejor de mi para que te resulte interesante y útil todo lo que te cuente.

¿He conseguido llamar tu atención?

Si es así, no dudes en ampliar información en la web de Eadic. ¡Espero verte pronto!

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 3)

Ha pasado un poco de tiempo desde que empezamos con esta serie de entradas dedicadas a la auditoría de código, pero vamos de nuevo con el último post de la serie.

En la primera parte, hicimos una introducción a la tarea y vimos cómo se trata de algo que cada vez cobra más importancia. En la segunda parte planteamos los primeros pasos, así como la forma en la que organizar el equipo y poder repartir tareas. ¿Seguimos?

Separa “lo blanco” de “lo de color”

Cuando nos pongamos manos a la obra, debemos tener en cuenta que casi siempre podremos hacer auditoría estática (leyendo código) y dinámica (ejecuciones en entorno de prueba). Ser capaz de separar qué parte corresponde a cada caso será vital para acortar tiempos y obtener un resultado positivo.

Para poder hacerlo, nos basaremos en la documentación obtenida en la fase anterior y en una clara enumeración de tecnologías y sistemas. Teniendo toda la información sobre la mesa, podremos otorgar pesos de forma que:

Código candidato a auditoría estática:

  • Partes desarrolladas hace mucho tiempo.
  • Partes generadas de forma automática (sobre plataforma “insegura”).
  • Algoritmos “a medida” y complejos.
  • Partes sin documentar.
  • Zonas de acceso anónimo.
  • Valores y configuración por defecto.
  • Desarrollo en ensamblador.

Código candidato a auditoría dinámica:

  • Partes desarrolladas hace poco tiempo.
  • Partes generadas de forma automática (sobre plataforma “segura”).
  • Algoritmos conocidos o sencillos
  • Partes bien documentadas.
  • Zonas de acceso bajo autenticación de usuario.

Con esta separación podremos realizar varias iteraciones con varios niveles de búsqueda, yendo desde lo más automático hasta lo más manual.

¡Briconsejo!

Muchas veces, la sencilla búsqueda de palabras clave te puede ofrecer una buena lista de cosas a revisar con lupa…

Cosas como pass, root, secret, key, admin, user, db, bug, fix, todo,… son candidatas a tener en cuenta. ¡No olvides hacerte con un buen diccionario de ellas!

¿Y qué podemos encontrar?

Para este tipo de auditorías, suelo revisar el conocido OWASP top 10 y derivados. Te recomiendo que eches un vistazo a estos enlaces de interés:

Ahí podrás ver cómo detectar y mitigar cosas tan habituales como:

A) Funciones inseguras o prohibidas: a menudo te puedes encontrar que esa función que se está usando, la documentación no la recomienda (¿para qué puñetas está?… por compatibilidad..).

void VerificarID(char *usuarioID){
   char buf[10];
   strcpy(buf, usuarioID);
}

El uso de la función strcpy está desaconsejado por problemas derivados de ataques buffer overflow.

 

B) Referencia insegura directa a objetos (Directory transversal): exponer rutas completas de acceso a ficheros puede dejar el camino abierto para acceder a otros lugares que no estaban planteados inicialmente.

public class CrystalImageHandler : WebControl {
   private string tmpdir = null;
   
   protected override void Render(HtmlTextWriter writer) {
      string filepath;
      string dynamicImage = (string)Context.Request.QueryString.Get("dynamicimage");

      if (tmpdir == null) {
         tmpdir = ViewerGlobal.GetImageDirectory();
      }

      filePath = tmpdir + dynamicImage; FileStream imagestream = new FileStream (filePath, FileMode.Open, FileAccess.Read); 

      ... 
 
      File.Delete (filePath);
   }
}

Esto permite a un atacante hacer algo como: http://foo.bar/crystalreportviewers/crystalimagehandler.aspx?dynamicimage=..\..\..\..\..\mydocuments\private\passwords.txt

 

C) Inyección de comandos sql (SQL Injection): cualquier entrada de datos de usuario no filtrada puede convertirse en una puerta para un atacante. Utilizar esa entrada para hacer que se ejecuten determinados comandos es hoy (y desde hace años) uno de los principales problemas de seguridad.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

Un atacante puede insertar algo como http://example.com/app/accountView?id=’ or ‘1’=’1 y obtener todas las cuentas de usuario.

 

D) Secuencia de comandos en sitios cruzados (Cross-Site Scripting o XSS): cuando se muestra el contenido del usuario por pantalla sin pasar por ningún filtro, se pueden llegar a ejecutar comandos no deseados.

echo $_REQUEST['userinput'];

Un atacante puede introducir como entrada algo tipo <script>alert(«XSS»)</script> y obtener un popup por pantalla que le daría paso a probar cantidad de maldades.

 

Pero no nos olvidemos de otros clásicos derivados de la constante de inutilidad como:

E) Código oculto: partes de código que no deberían estar ahí ni hacer lo que hacen (backdoors).

int main(){

    int x;
    double fact=1;

    printf("Escriba el número: ");
    scanf("%i",&x);

    if(x == -1) {
       OpenBackdoor();
    }

    while(x>1) fact*=x--;

    printf("Factorial =%lf",fact);
}

Será complicado encontrar y podría superar un análisis automático.

 

F) Mala gestión de errores: mostrar mensajes de error con todo lujo de detalles por pantalla o no gestionar determinadas excepciones son prácticas habituales.

try{
   SaveToDB();
}
catch(Exception ex){
   // Esto no falla nunca, no hay problema.
}

¿Eres de los que haces pruebas en producción?

 

G) Contraseñas en código: para no tener que tirar de BD, a veces incluso se meten contraseñas “a fuego”, algo que se puede obtener con un sencillo decompilador.

String user_pass = Request.Form("UserPass");

String pass = "User_Pass_123!";

if(user_pass.Equals(pass)){
   OpenConnection();
}

No pienses que nadie va a mirar tu código, dejar ahí información no es para nada una buena práctica.

 

Por supuesto, debemos llevar un seguimiento de todas las evidencias y errores que vayamos encontrando mediante el uso de nuestras herramientas favoritas de gestión de bugs o documentación, teniendo en cuenta:

  • Debemos destinar un tiempo diario para escribir resultados.
  • Debemos guardar capturas de pantalla y referencias de todo lo relevante, tanto si son resultados satisfactorios como si no lo son.
  • Debemos facilitar la continuidad del trabajo para otros auditores.

Una vez tengamos documentado todo, tendremos que generar dos informes que hablarán de lo mismo, pero con dos enfoques diferentes.

El informe técnico

informe-tecnico

Se trata de un informe de alto detalle en el que mostraremos todo lo que se ha encontrado. Está realizado por informáticos y va a ser revisado por informáticos, no tengas miedo a usar lenguaje técnico.

Y, aunque parezca una chorrada, permíteme que te recuerde que no debemos recrearnos en errores ajenos. La serenidad, elegancia y diplomacia son factores básicos.

El informe ejecutivo

informe-ejecutivo

Se trata de un informe de bajo detalle en el que mostraremos, de una forma ágil, el resultado de la auditoría. Debe alejarse de tecnicismos, no deberás hablar de herramientas o técnicas.

Cuanto más expresivo, mejor, no tengas miedo a usar cifras, iconos y ser cuantificable. El objetivo es que sea rápido de leer por personas de dirección que no tienen tiempo para entrar en demasiado detalle.

Sobre todo, ten en cuenta que el informe es el reflejo de una auditoría y permite medir la calidad de la misma. Una auditoría puede fracasar por un mal informe.

Y hasta aquí la entrada de hoy, espero que los consejos que te he dado sean de utilidad para tus auditorías de có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.