(N.d.E. Para aquellos que no pueden vivir sin Internet durante las vacaciones —aquellos que las tengan—, aquí va una entrada sobre la securización de DMZ)

Generalmente, la arquitectura de seguridad de red en pequeñas empresas se basa en un elemento central de filtrado, habitualmente un firewall, y distintos segmentos de red conectados a él, principalmente, un segmento de red interna y un segmento DMZ para alojar servidores corporativos. En el caso de una empresa de tamaño medio o grande, la situación es bastante similar: uno o varios firewalls en alta disponibilidad separando distintos segmentos de red, aunque disponen de otros controles como NIDS, IPS, sistemas de monitorizacion, etc, y técnicos dedicados a la gestion de la seguridad.

Como vimos en la entrada anterior, el uso de scripts con el bit suid presenta grandes problemas de seguridad. Por eso se recomienda siempre el uso del comando sudo, para la ejecución de scripts con privilegios mayores que el usuario que los ejecute. Como pregunta final del artículo, se comentaba si existía la opción de permitir ejecutar un script con el uso del bit suid activado. La respuesta es que sí, hay una forma de conseguir ejecutar un script como si de root se tratará mediante la ejecución de un programa sencillo en C. No se trata en si de la ejecución de un script suid, pero su resultado sería el mismo.

Vamos a explicarlo con un ejemplo, que se va a desarrollar sobre el directorio /tmp/prueba. Comenzaremos creando el script que queremos ejecutar como root de nombre shell.sh:

#!/bin/bash
grep -c "*" /etc/shadow

En esta ocasión, el cuarto artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como referencia directa a objetos insegura. Anteriormente ya vimos los ataques relacionados con las vulnerabilidades XSS, de Inyección y de Robo de sesiones web.

La vulnerabilidad que les presentamos hoy no aparecía recogida en la lista del año 2004 puesto que se encontraba agrupada dentro de la categoría “Error de Controles de Acceso”, sin embargo en 2007 se tomó la decisión de separar dicha categoría por la importancia detectada en este tipo de vulnerabilidades, pasando a ocupar el cuarto lugar en la clasificación. En la nueva clasificación que estamos presentando continua siendo una de las vulnerabilidades más encontradas permaneciendo en la misma posición que en 2007, es decir, en cuarta posición.

Cuando planificamos y realizamos copias de seguridad de datos y servidores de nuestro negocio, no es raro que a menudo nos olvidemos de una parte no menos importante que la información alojada en los propios servidores y, a veces, vital: las bases de datos PIM (Personal Information Management) .

Sólo en el caso que dispongamos de terminales móviles tipo Blackberry, y que éstos estén sincronizados con un servidor BES (Blackberry Enterprise Manager), podemos sentirnos medianamente seguros que nuestros datos están replicados. Dependiendo de nuestra instalación, este servidor de sincronización puede estar compartido por la compañía telefónica que nos provee el servicio, o podemos tener uno propio dentro de nuestra infraestructura. Por esta razón, este sistema es uno de los más usados en las grandes organizaciones. Los terminales móviles tienen conexión permanente con el servidor BES, y la aplicación directamente absorbe los datos del propio servidor de correo/PIM (que puede ser un Microsoft Exchange o IBM Lotus Domino). Una de las opciones más interesantes de esta infraestructura es que, en el caso de pérdida de un terminal, el administrador del sistema puede borrar en remoto el contenido del dispositivo e incluso dejarlo inutilizable, aspecto que para empleados que gestionan información sensible puede ser tremendamente útil.

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).

Siguiendo la línea de entradas sobre el I Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC (Centro Nacional para la Protección de las Infraestructuras Críticas) y realizado en Madrid los días 18 y 19 de febrero, vamos a comentar los resultados del Taller II, “Gestión de Riesgos: identificación y clasificación de riesgos, amenazas y vulnerabilidades”, coordinado por José Antonio Mañas. Más allá de anécdotas, comentarios y discusiones, todos los asistentes al taller coincidimos en plantear, como resumen del trabajo, las siguientes conclusiones:

Muy importantes

• Hay que profundizar más en la seguridad de sistemas de control, electrónica industrial, SCADAs y similar… Con demasiada frecuencia desconocemos los riesgos que introducen en nuestras organizaciones, algo que en el caso de la infraestructura crítica nacional es más que preocupante.
• La comunidad de inteligencia debería “bajar” al mundo real de vez en cuando. Suele haber una importante diferencia entre lo que se plantea desde un centro de seguridad, incluso en ocasiones muy estratégico y poco operativo, y la realidad del día a día en una presa, un banco o un puerto, por poner ejemplos concretos.
• Existen incoherencias entre el deber de transparencia y el deber de secreto que existe en las infraestructuras críticas nacionales, y dichas incoherencias deben ser resueltas. A modo de ejemplo, una central nuclear debe facilitar su análisis de riesgos al ayuntamiento del municipio en el que se encuentra, pero esa obligación… ¿no puede suponer en sí misma un peligro para la seguridad de la central? ¿no debería considerarse secreto dicho análisis? ¡Aclarémonos!
• Se deben gestionar correctamente las expectativas con todos los ciudadanos. La protección de infraestructura crítica nacional está muy en boga, pero ¿hasta qué punto es crítica, importante, muy importante… o una tontería? Sin duda, el grueso de la ciudadanía lo desconoce, y puede llegar a ver esto como un gasto innecesario, y más en estos tiempos.

Tras los dos artículos previos sobre el TOP 10 de OWASP, en esta ocasión el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como pérdida de autenticación y gestión de sesiones. Esta vulnerabilidad, desde mi punto de vista, demuestra lo poco que suele preocupar la seguridad a los usuarios. Aunque en la primera clasificación del año 2004 estaba situada como la tercera más encontrada, en la clasificación el año 2007 destacaba por haber descendido hasta el séptimo puesto. Sin embargo, tres años después, en esta nueva clasificación, se vuelve a observar un repunte en la localización de este tipo de vulnerabilidades que la vuelve a colocar en la tercera posición dejando como anécdota la anterior mejora.

Las vulnerabilidades relacionadas con la pérdida de autenticación y gestión de sesiones son críticas en la seguridad de las aplicaciones y en especial de las aplicaciones WEB, ya que permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos.

Hace unos días, después de realizar una instalación de una red de detección de intrusos dedicada, nos quedamos unos cuantos compañeros hablando sobre temas de seguridad. Durante la charla, hubo un apartado acerca de los scripts con bit suid y cómo, mientras en Solaris con la shell ksh se permitía la ejecución de un script suidado, el núcleo de Linux evitaba la ejecución de un script con suid. Antes de continuar con la entrada en el blog, es recomendable conocer el funcionamiento del bit suid. Veámoslo brevemente:

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar “la escena del crimen”, casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Hace algunos días mientras un amigo y compañero de trabajo revisaba el estándar ISO27002, se dio cuenta y comentó un detalle que cuanto menos nos pareció a todos curioso. El apartado “i” del control 9.2.1 sobre Emplazamiento y protección de equipos, dice:

Como habréis pensado el comentario vino a raíz de esa última palabra: “emanación”, la cual nos hizo pensar en si realmente la habían utilizado de forma correcta bajo el contexto en el que estábamos hablando. Dándole vueltas alguien recordó que había leído algo sobre la posibilidad de la captación de datos mediante el análisis de señales por emanación electromagnética, un fenómeno que desde luego parece más bien sacado de una serie de ciencia ficción, pero que no está para nada desencaminado de la realidad. Hoy vamos a hablar de los ataques TEMPEST.