Pentesting: debilidades propias y con las que "te relacionas"

miércoles, 9 de julio de 2014

En algún momento de la vida de cualquier organización (que se preocupa por lo que expone en la red) se pasa por auditorías técnicas de seguridad con el fin de encontrar fallos de seguridad. Pero lo que el día a día nos enseña es que los atacantes que quieren comprometer los sistemas de una empresa buscan diversos vectores de ataque para conseguir sus propósitos, y no solo ya la vulnerabilidad-del-momento-que-explotar.

En un mundo "clásico" de seguridad (hoy en cierta manera anticuado o cuando menos, en revisión), el atacante se nutre de los fallos de la organización objetivo sobre sus propios sistemas. Si nos centramos en la web, se buscan los típicos SQL injection, cross-site-scripting, local file inclusion, etcétera. Continúan siendo vectores perfectamente válidos (se siguen encontrando con relativa facilidad), pero ya sabemos que detectarlos y solucionarlos no es suficiente para proteger estratégicamente una organización. Los ataques de seguridad se han vuelto más avanzados. Es bastante más que probable que el mayor agujero de seguridad de una empresa se encuentre en un lugar distinto a su perímetro.

¿Qué es una debilidad?

Las debilidades son situaciones que presentan los sistemas de información, las aplicaciones web... un entorno cualquiera en el que se proporciona una ventaja al atacante. En otras palabras: el atacante consigue información que puede convertir (a través de la inteligencia aplicada a lo ya conseguido por otros medios) en una clara ventaja durante el ataque y que podría concluir con la organización comprometida.

Las debilidades y las vulnerabilidades son los elementos que las organizaciones deben buscar activamente, porque con la búsqueda exclusiva de vulnerabilidades no se consigue un estado de seguridad aceptable. Esto, junto al hecho de que el pentesting debe ser persistente en el tiempo, son dos de las premisas que se deben tener en cuenta para acortar los tiempos de respuesta en la detección de situaciones comprometedoras.

¿Son tan importantes las debilidades? A lo largo de los años se ha visto como una gran cantidad de ataques se han realizado basándose en debilidades y no tanto en vulnerabilidades, o al menos a través de una combinación donde las debilidades se mostraron decisivas. Encontrar un XSS o un SQLi "clásico" en sitios altamente atacados, como Microsoft o Apple, puede ser complejo y bastante improbable. Pero, ¿y si cargan contenido de otro sitio web que no está tan fortificado? ¿Y si los empleados del sitio desde donde se carga algún recurso no tienen formación ni concienciación en temas de seguridad?

Un auditor de seguridad no suele notificar en su informe las debilidades porque su misión es centrarse en encontrar vulnerabilidades sobre los sistemas de la organización, corriendo el riesgo de dejar la auditoría "a medias". Para poder ilustrar este hecho mejor, veamos el primer caso del ciclo de debilidades.

Caso 1: RSA Conference y la SEA

Este primer caso expone el peligro de la carga de código de dominios externos que no se encuentran bajo la supervisión del auditado. Ira Winkler insultó al grupo "Syrian Electronic Army" (también conocidos como SEA) en una charla de la RSA Conference. Les llamó cucarachas" (cockroachs). Además, dijo que a los ataques que realizaba este grupo les faltaba calidad y no eran elaborados. Los SEA decidieron vengarse.

Contaban con el siguiente escenario:

Esquema de los implicados en el ataque a rsaconference.com

En el esquema se parte de rsaconference.com, objetivo final del ataque. Los SEA se dieron cuenta de que en el código fuente del sitio web se cargaba un dominio externo, un (en principio aparentemente inocente) Javascript para el seguimiento de visitas (estadísticas). Con esta información decidieron que la forma más fácil de atacar a la RSA Conference era a través de ese dominio externo con el que se relacionaban. Así que:

  • Averiguaron el registrador de dominio que se usó para registrar livestatserver.com.
  • Realizaron una campaña de phishing muy concreta contra los empleados de la compañía registradora de dominio. En el correo falso que los empleados recibían, se mostraba un supuesto mensaje en nombre del CEO de la organización. En cuanto un empleado introdujo sus credenciales en el sitio web falso, los SEA pudieron acceder a los datos de administración del dominio, entre otros muchos.
  • La idea era sencilla: cambiar la dirección IP a la que apuntaba el registro w1 en el servidor DNS. De este modo, cuando un usuario entrase en el sitio web y se descargase la web, el Javascript especificado en el dominio w1.livestatserver.com se resolvería a la dirección IP bajo control de los SEA. Ellos montaron un servidor web en el que simplemente se mostraba el siguiente mensaje:

Mensaje mostrado por la SEA en la página de la rsaconference.com

Parece que los SEA no quisieron realizar daño más allá de un insulto y una reivindicación, porque las posibilidades abiertas una vez se habían hecho con el poder administrativo del registrador de dominio eran numerosas. Y todo parte de un pequeño código Javascript al que una web referencia y que se encuentra fuera totalmente de los sistemas auditados, aunque no de sus relaciones. Muy pocos anunciarían esto en una auditoría de seguridad como "vulnerabilidad", pero es necesario tenerlo siempre en cuenta porque estas debilidades pueden provocar ataques contra la organización.

Faast permite evaluar todas esas debilidades que pueden hacer que una organización quede comprometida. Las evaluaciones continuas de seguridad deben centrarse en las vulnerabilidades y debilidades propias y externas. Se puede pensar en Faast como en un pentester estratégico con el que es posible obtener una visión global persistente del estado de seguridad de una empresa. El mundo digital está cambiando, tanto como los sistemas, aplicaciones y conocimientos de una empresa. Junto al pentesting persistente, las debilidades de las que estamos rodeados dejan de ser anécdotas para convertirse en centro de fallos potencialmente mucho más peligrosos.

Pablo González
pablo.gonzalez@11paths.com

2 comentarios: