Recolección Técnica de Información

Objetivo: Obtención de todo tipo de información mediante diversos métodos técnicos y empíricos en una muestra representativa de los sistemas y dispositivos de la organización.

Partiendo de la información recolectada en la fase anterior, se procederá a identificar los sistemas objeto de estudio para a continuación realizar una serie de análisis técnicos con el fin de conocer de forma precisa cuál es su estado real desde un punto de vista de seguridad técnica. Mediante estos análisis seremos capaces de detectar problemas de seguridad, existentes o potenciales, que puedan afectar a la integridad de los sistemas de la organización, además de a su funcionamiento o rendimiento.

A continuación se enumeran los distintos puntos que deberán ser abordados durante la recolección técnica de información.

Enumeración y Caracterización

Tomando como base la información general recopilada en la fase "Recolección General de Información", se identificarán los sistemas, dispositivos y aplicaciones sobre los que se realizará el estudio técnico, llevando a cabo una caracterización lo más exhaustiva posible de cada elemento puesto que esta información resultará de mucha utilidad a la hora de realizar los análisis técnicos y la interpretación de los resultados.

La información mínima que deberá recopilarse será la siguiente (aunque podrá ser ampliada con aquellos datos que el equipo de trabajo pueda considerar de interés):

Caracterización de Sistemas

• Sistema (nombre, tipo, fabricante)
• Ubicación
• Responsable
• Versiones software (SSOO, aplicaciones que corren en él)
• Estado de parches y/o actualizaciones

Caracterización de Aplicaciones

• Aplicación (nombre, fabricante, versión)
• Subsistemas asociados (sistemas en que corre)
• Interrelación con otras aplicaciones
• Responsable
• Estado de parches y/o actualizaciones

Análisis de Tráfico

Mediante el análisis de tráfico se intentará caracterizar el tipo de tráfico que discurre habitualmente por las redes de la organización, así como detectar posibles puntos de fallo o cuellos de botella en dichas redes.

Para un óptimo resultado del análisis, deberán identificarse cuáles son los puntos sensibles en los que deberán realizarse las medidas, entendiendo por sensibles aquellos puntos con representatividad en su tráfico. Dichos puntos, típicamente podrán ser:

• Interconexiones entre segmentos
• Segmentos de servidores/aplicaciones críticas
• Segmentos de usuarios
• Otros puntos de interés

Cada medida deberá realizarse durante un periodo de tiempo significativo de forma que se capture una cantidad de tráfico suficiente para su posterior análisis. El tiempo de medida dependerá de la cantidad tráfico que habitualmente soporte la red. En algunos entornos será suficiente mantener la medida durante unos pocos minutos, mientras que en otros será necesario realizar la medida a lo largo de un día completo o incluso, periodos más prolongados de tiempo.

También será necesario tener en cuenta las franjas temporales de utilización de la red. Por ejemplo, no será lo mismo la captura de tráfico en una red de oficina, que en una red de una fábrica en la que se realizan trabajos 24 horas al día. Por tanto, será importante conocer las pautas de utilización de la red con el fin de seleccionar los momentos de medida adecuados.

Las capturas, por norma general, se realizarán sin ningún tipo de filtrado, y se almacenarán en disco de forma que puedan ser reproducidas y tratadas en laboratorio con el fin de generar informes y estadísticas de uso. Para su realización se utilizará cualquier analizador de protocolos que permita la realización de las tareas anteriormente comentadas.

Análisis de Vulnerabilidades Sistemas y Aplicaciones

El análisis de vulnerabilidades de sistemas y aplicaciones tiene como objeto detectar puntos débiles en la seguridad de los sistemas y aplicaciones que éstos soportan. Entendemos por puntos débiles, errores de programación o de configuración en las aplicaciones y sistemas operativos que puedan ser causa de vulnerabilidades susceptibles de ser explotadas por potenciales atacantes. Por tanto, será importante conocer cuáles son estos puntos débiles con el fin de implantar los controles adecuados para eliminarlos o evitar su explotación.

No todos los sistemas tienen la misma importancia dentro de la organización. Por esto, y porque el análisis de vulnerabilidades es una tarea que puede consumir mucho tiempo, deberá realizarse una selección de cuáles son los sistemas sobre los que se realizará el análisis. Objetivos típicos de este tipo de análisis serán los sistemas cuyo mal funcionamiento pueda causar un impacto importante en los procesos de la organización (e.g. Servidores principales) o aquellos que por su visibilidad están más expuestos a posibles ataques (e.g. Servidores con acceso público desde Internet). Deberá ser la organización objeto del análisis quien, con el asesoramiento del equipo de trabajo que efectúe el análisis, decida cuáles son los sistemas que deben ser analizados.

Análisis remoto

Se prestará especial atención a las vulnerabilidades que pueden ser explotadas remotamente, ya que éstas pueden suponer un mayor riesgo al no requerir de presencia física para su explotación. Dichas vulnerabilidades, habitualmente estarán asociadas a puertos de aplicación que esperan recibir conexiones remotas. El primer paso del análisis de vulnerabilidades, por tanto, será identificar cuáles son los puertos de los sistemas que son accesibles de forma remota. Un método para conseguir esta información será la realización de un escaneo de puertos.

El objetivo del escaneo de puertos será averiguar qué puertos (típicamente TCP o UDP) están a la escucha en un sistema determinado, y por tanto, pueden recibir conexiones remotas. Es esta una información de suma importancia, ya que una gran parte de las vulnerabilidades asociadas a aplicaciones, tienen que ver con las posibilidades de conexión remota de las mismas. La técnica básica para saber el estado de un puerto es tratar de realizar una conexión contra el mismo y analizar el resultado, pudiendo obtenerse tres valores para el estado de un puerto:

• Abierto: El puerto está a la escucha y listo para recibir conexiones.
• Cerrado: El puerto no está a la escucha
• Filtrado: Existe algún dispositivo (típicamente un cortafuegos/firewall) que no permite realizar conexiones contra el puerto

Existen diferentes técnicas de escaneo de puertos, muchas de ellas orientadas a tratar de evitar métodos de detección y seguridad de los sistemas objetivo, pero en el caso que nos ocupa pueden no ser relevantes, ya que deberá contarse con la aprobación y el permiso por escrito del propietario de los sistemas para realizar el escaneo y las acciones correspondientes, pudiendo realizar los escaneos y análisis sin necesidad de utilizar técnicas de camuflaje (stealth), salvo en el caso en que existan dispositivos de seguridad (como sistemas de prevención de intrusiones) que puedan invalidar los resultados de dichas pruebas.

Una vez establecido el alcance de los sistemas sobre los que se realizará el análisis, se deberá elegir la profundidad del mismo, es decir, deberá decidirse sobre qué puertos se realizarán las posteriores comprobaciones. Evidentemente, para que el análisis sea completo, debería comprobarse el estado de todos los puertos (tanto TCP como UDP ), pero dado que en ocasiones esto puede llevar más tiempo del que se tendrá disponible, en ciertos casos será posible reducir el número de puertos a analizar, bien porque se tenga la certeza de que el sistema sólo escucha en ciertos puertos, o porque existan dispositivos de filtrado que sólo permitan la conexión a puertos determinados. De esta forma, la complejidad del escaneo de puertos y el consiguiente análisis de vulnerabilidades se reducirá haciéndose mucho más manejable.

Tras realizar el escaneo de puertos, dispondremos de la información referente a qué puertos tiene disponibles cada sistema para aceptar conexiones remotas. Cada uno de estos puertos estará asociado a un servicio y por tanto a una aplicación. El siguiente paso será averiguar cuáles son dichas aplicaciones y, si es posible, la versión de las mismas.

Conocer el software específico que está instalado en un sistema es una de las primeras labores que intentará abordar un potencial atacante, ya que con esta información, se pueden conocer cuáles son las vulnerabilidades que presentan las aplicaciones remotamente accesibles, y de esta forma acceder a los métodos de explotación de la vulnerabilidad (o exploits). El resultado de la ejecución de un exploit se materializa habitualmente en un compromiso del sistema, que puede ir desde la eventual destrucción de sus datos al acceso no lícito de sus recursos.

La identificación de software a partir de los puertos por los que escucha puede realizarse mediante las respuestas (banners) que proporciona el servicio ante una conexión entrante. No obstante, dado que los banners pueden (y deben) ser modificados por motivos de seguridad, esta no es una manera adecuada de realizar esta tarea. Existen multitud de aplicaciones, muchas de ellas de código libre (open source), que automatizan la tarea de identificar las aplicaciones asociadas a un puerto. Estas aplicaciones no se limitan a reconocer los banners de respuesta, sino que analizan las respuestas de la aplicación ante ciertas entradas, y en base a diferencias de implementación conocidas, son capaces de deducir, eso sí, con un grado de precisión variable, la aplicación y versión que está proporcionando el servicio en cuestión.

Este proceso (escaneo + identificación), es la forma en la que un posible atacante trabajaría, y es importante llevarlo a cabo con el fin de crear consciencia de qué información podría ser obtenida con estos medios. No obstante, desde el punto de vista del análisis de seguridad, y con el fin de tener certeza sobre la veracidad de los resultados obtenidos, la identificación de aplicaciones y sus versiones debería ser abordada adicionalmente mediante el análisis local de los sistemas en cuestión.

En este punto, a un posible atacante le bastaría consultar alguno de los múltiples servicios disponibles en Internet que permiten conocer las vulnerabilidades (y los exploits) de una versión de aplicativo determinada. Por el contrario, la labor del equipo de trabajo será averiguar cuáles son los parches o actualizaciones adecuadas para solucionar los problemas de dicho aplicativo. En caso de que no existiesen o no se pudiesen aplicar dichos parches o actualizaciones, deberán buscarse alternativas que disminuyan el nivel de riesgo de exposición de estas aplicaciones.

Actualmente, las redes de comunicaciones en las que se ubican los sistemas analizados, son rara vez planas. Es habitual la existencia de diferentes segmentos, separados por diferentes dispositivos y con distintas políticas de acceso. Por tanto, el análisis de vulnerabilidades ofrecerá diferentes resultados dependiendo desde qué origen se realice. Teniendo esto en cuenta, para que los resultados de los análisis sean válidos, éstos deberán ser realizados desde todas las posibles ubicaciones que puedan ocupar los potenciales atacantes, ofreciendo así distintos perfiles de visibilidad (y de exposición al riesgo) del sistema analizado.

De forma típica, se realizarán análisis desde las siguientes ubicaciones:

• Internet: Desde Internet se tendrá acceso a los servicios públicamente accesibles de la organización. Mediante este análisis se verificará que sólo estos servicios son accesibles de forma pública.
• DMZ: Si en la organización existen segmentos de DMZ, deberán realizarse los escaneos hacia los servidores internos desde esta ubicación, ya que es un punto de entrada habitual una vez que ha sido comprometido alguno de los servidores públicos. De esta forma podrá conocerse qué grado de visibilidad tendrán los servidores internos para un atacante que ya ha conseguido comprometer algún sistema de la organización.
• Mismo segmento: El escaneo desde el mismo segmento de red permite conocer sin acceder físicamente al sistema cuáles son los servicios que tiene configurados, tanto los que se están utilizando como los que están en funcionamiento sin ser utilizados debido a malas prácticas de administración o instalaciones por defecto.
• Red Interna: Dado que una gran parte de los incidentes de seguridad en los sistemas de las organizaciones proviene de la propia organización, es importante conocer qué servicios son accesibles (y por tanto posibles causas de vulnerabilidad) desde las redes de usuarios internos.

Análisis local

Mediante el análisis local pretendemos obtener un conocimiento preciso del estado de seguridad del sistema. Este análisis no suele estar al alcance de los posibles atacantes, pero puede resultar de suma utilidad para conocer el estado del sistema desde el punto de vista de la seguridad. De forma resumida, lo que se trata de conseguir es la caracterización más completa posible del sistema en cuestión.

En este sentido, deberá recolectarse al menos la siguiente información de forma general:

Nombre
Responsable
Tipo de sistema
Sistemas de ficheros
Utilización de Memoria
Parches o Actualizaciones
Software o Aplicativos instalados
Puertos a la escucha y conexiones activas
Banners de servicios
Servicios y Scripts de arranque
Listas de procesos en ejecución
Usuarios y contraseñas
Configuración de red
Tareas de ejecución periódica

Adicionalmente, dependiendo del sistema operativo del dispositivo analizado podrá ser necesaria la recopilación de otros datos que, en ese caso, deberán ser identificados por un experto en esa área. Un ejemplo para sistemas Unix podrían ser la recopilación de Tcp wrappers, Ficheros SUID y SGID, Servicios NFS o Servicios RPC, entre otros.

Revisión de configuraciones

Durante la recolección técnica de información se revisarán también las configuraciones de elementos clave de la red de la organización. Muchas veces, debido al volumen de elementos de red no será posible realizar una revisión exhaustiva, sin embargo, será necesario en este caso decidir de acuerdo con el interlocutor de la organización cuáles serán los dispositivos sobre los que se realizará el análisis.

Para la revisión de las configuraciones será necesaria la participación de expertos en los distintos dispositivos analizados que puedan identificar fallos en las mismas, formas más eficientes de implementar una determinada funcionalidad o mecanismos alternativos que mejoren la seguridad y eficiencia del dispositivo.

Típicamente deberán revisarse al menos dispositivos de electrónica de red (routers, switches, bridges, etc.), dispositivos de seguridad (cortafuegos/firewalls, IDS/IPS/dispositivos de prevención de intrusiones, servidores de autenticación, etc.), aplicaciones (servidores web, ftp, de correo, etc.) y en general cualquier dispositivo con una funcionalidad necesaria dentro de la organización que pueda suponer una posible fuente de vulnerabilidades y por tanto de elevación del nivel de riesgo asumido por la organización.

Visibilidad externa

Existe una gran cantidad de información relativa a las organizaciones accesible de forma pública desde Internet. Esta información puede ser una pieza clave para el diseño de un eventual plan de ataque contra la organización, ya que puede revelar interesantes detalles, tanto técnicos como organizativos, que utilizados de forma adecuada pueden facilitar la tarea de potenciales atacantes.

Es importante, por tanto, que la organización sea consciente de la existencia de esta información, por lo que deberá prestarse especial atención a los siguientes puntos.

Direccionamiento público

Mediante los servicios whois de los registradores regionales de Internet (e.g. RIPE en Europa, ARIN en Norteamérica) podemos conocer los rangos de direcciones públicas asignados a la organización, direcciones postales, de correo electrónico y números de teléfono, nombres de responsables y contactos dentro de la organización.

La organización deberá tener un conocimiento preciso de esta información con el fin de asegurarse que los datos son correctos y no proporciona más información de la debida.

Nombres de dominio y DNS

Deberán recopilarse todos los nombres de dominio pertenecientes a la organización, puesto que mediante las herramientas de consulta ofrecidas por los agentes registradores de dominio se pueden obtener datos de contactos técnicos, administrativos y de facturación.

Para cada dominio de la organización deberán realizarse búsquedas en el servicio DNS, prestando especial atención a:

• Servidores de Nombres (NS)
• Intercambiadores de correo (MX)
• Nombres conocidos (e.g. www, ftp)

Estos nombres, corresponderán a servidores susceptibles de ser atacados y por tanto deberán ser objeto de un cuidadoso proceso de asegurado.

Filtrado de documentación

Una mala configuración de los servidores web puede permitir la publicación en Internet de documentos que no deberían ser vistos fuera de la organización. Los actuales buscadores web (e.g. Google) permiten realizar sofisticadas búsquedas, por ejemplo restringidas por dominio y por tipo de fichero. Siempre resulta sorprendente la cantidad de información que puede ser hallada mediante estas búsquedas. Por tanto, dentro de la recolección técnica de información de la organización, deberán realizarse búsquedas de este tipo con el fin de conocer si la organización es vulnerable a este tipo de ataques e identificar cuál es la causa de esta publicación no autorizada.

Otros análisis técnicos

Adicionalmente, dependiendo de las características técnicas de la infraestructura de la organización, podrá ser necesaria la realización de otras pruebas para obtener información y datos adicionales. Estas pruebas deberán ser coordinadas e identificadas por el equipo de trabajo y los expertos en la tecnología, sistema o aplicativo objeto de las mismas.