Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

Gran parte de los esfuerzos del área de seguridad a la hora de establecer medidas de protección se basan en el aprendizaje de las técnicas utilizadas por los atacantes. Con este propósito, uno de los pilares fundamentales del personal dedicado a la seguridad está enfocado a la recopilación de información para su posterior análisis, para poder aplicar y reforzar las medidas de seguridad en la organización en función de las conclusiones obtenidas.

Pero, ¿qué información se recopila en este proceso y de qué forma? Existen muchas fuentes de información conocidas como pueden ser los informes de nuevas vulnerabilidades de aplicaciones concretas, estudios de analistas independientes, nuevas técnicas de ataque, o incluso información obtenida del último ataque sufrido sobre un recurso corporativo. Igual que en las novelas de contraespionaje o en las películas de “James Bond”, no es difícil imaginar técnicas de obtención de información que estén basadas en la implantación de señuelos o trampas en forma de aplicaciones, cuyo propósito es registrar la actividad sospechosa de los potenciales atacantes, para que éstos actúen sin darse cuenta de que su comportamiento está siendo realmente estudiado. Así nos lo cuenta Clifford Stoll en su libro “The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” (N.d.E. Un libro que nadie interesado en seguridad debería dejar de leer).

A la hora de realizar una auditoría de seguridad lógica, uno de los primeros pasos a dar es la recopilación de la mayor cantidad de información “útil” del objetivo a auditar, lo que en el ámbito de la seguridad denominamos como “information gathering”. Dentro de esta fase, podemos incluir el análisis de metadatos obtenidos a partir de ficheros contenedores como pueden ser de tipo pdf, odt, jpg, etc…

Antes de entrar en materia, me gustaría definir lo que son los metadatos de una manera más formal. Curiosamente, si consultamos el diccionario de la real academia española no encontramos este término, pero para ello tenemos la referencia de la wikipedia:

Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad “for educational purposes only” aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. Esta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).

Dejando los detalles técnicos para más adelante, este ataque se basa en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo) para hacer llegar a la base de datos consultas SQL manipuladas, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection“, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.