OWASP TOP 10 (V): Falsificación de petición en sitios cruzados (CSRF)

Llegamos con esta entrada al ecuador de la lista de OWASP, tras el repaso a las cuatro primeras vistas en entradas anteriores (I, II, III, IV). En esta ocasión, el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en el riesgo conocido como Cross Site Request Forgery, CSRF, que en castellano tiene la difícil traducción que podemos leer en el título de esta entrada. Este riesgo no aparecía recogido en la lista del año 2004, sin embargo en 2007 apareció en quinto lugar, posición que mantiene en esta nueva clasificación de riesgos del año 2010.

Las vulnerabilidades relacionadas con la falsificación de petición en sitios cruzados permiten a un atacante la posibilidad de enviar una petición a una aplicación Web vulnerable ejecutando una acción a través de la víctima. Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web, en el que un usuario autenticado dispone de un conjunto de puntos bonificables que puede transferir a otros usuarios de la propia aplicación a través de un formulario que ejecuta una acción del siguiente tipo:

http://owasp.s2grupo.es/catalog/transfer.jsp?amount=4815&user=162342

Una vez recibida en el servidor, se le muestra la cantidad a transferir, el identificador del usuario y realiza el traspaso de puntos.
[Read more…]

GOTO VII: privacidad vs. todo lo demás

De vez en cuando surgen noticias -casi siempre, muy sensacionalistas- acerca de nuevas medidas de seguridad que suponen una “importante” violación de nuestra privacidad: desde la videovigilancia en las calles (un lugar especialmente privado por definición :) hasta la necesidad de descalzarnos en los aeropuertos (desde luego, una humillación a la que sólo unos pocos sobreviven). Qué quieren que les diga: frente a los que claman al cielo, yo suelo estar de acuerdo con estas medidas. ¡Toma GOTO! :)

Maticemos en primer lugar el “suelo estar”; mi opinión es que casi cualquier medida que aporte seguridad suele tener inconvenientes de uno u otro tipo, pero si “compensa” (es decir, si el incremento de seguridad efectivo es superior a las molestias causadas por esos inconvenientes) y entra dentro de lo “normal” (de lo razonable, aunque esto suela ser subjetivo), vale la pena implantarla. ¿Qué problema hay entonces? Bajo mi punto de vista, la discusión habría que trasladarla a tres asuntos: el primero, el de la eficacia -no me atrevo a hablar de eficiencia- (si la medida aporta realmente seguridad); el segundo, el del grado de abuso (el mal uso o abuso que se pueda hacer de la información recopilada con fines que nada tienen que ver con su objetivo principal, como espiar a tu pareja, curiosear, molestar al vecino, chantajear…) y, el tercero y último, el de la aceptabilidad, esa normalidad subjetiva a la que hacía referencia.

De esta forma, cuando surge una nueva salvaguarda de esas que son polémicas, debemos plantearnos en primer lugar si la medida es efectiva. ¿Evitan atentados los registros minuciosos en los aeropuertos? ¿Evita la delincuencia una videocámara en las calles? ¿Minimiza el riesgo un perfil psicológico de una persona? Yo creo que muchas de las medidas, por no decir todas, más impopulares de los últimos años (desde la videovigilancia en las calles a temas como ECHELON o CARNIVORE) sí que son relativamente efectivas, nos gusten o no, y por eso se implantan. No nos engañemos: a ningún gobierno, servicio de inteligencia, FFCCSE, etc. a título global les interesan, en general, nuestros correos electrónicos, nuestros paseos por el centro, o nuestras retiradas de efectivo para hacer la compra (eso no implica que a personas individuales, dentro de esas organizaciones, pueda interesarles, como se comenta en el punto siguiente). Así, mi opinión es que si un delincuente puede robar un coche en plena calle, y posteriormente una videocámara ayuda a identificarlo -o incluso antes de que se cometa el delito actúa de forma disuasoria-, bienvenida sea.

A continuación, pensemos en el uso o abuso de la información recopilada con estas técnicas “intrusivas”; por muchas precauciones que se tomen a la hora de elegir al personal, por mucho control interno, por mucha disuasión… no podemos evitar que, en última instancia, una persona con acceso a los registros guardados, pueda hacer un mal uso de ellos; contra esto, sin menoscabo de medidas de prevención y detección, yo creo que lo más efectivo es la respuesta contundente cuando se demuestra un mal uso de la información (este tema daría para un post entero :). Si se demuestra que un administrador de sistemas usa la información de seguridad para publicar debilidades de sus compañeros, que un vigilante de seguridad usa la videocámara de un cajero para controlar a su vecino o que un policía se dedica a espiar a su novia gracias a las cámaras en la calle, deberían ser automáticamente despedidos, para empezar, y establecer un marco legislativo duro que les haga pensarse más de dos veces el mal uso de las medidas de seguridad. Pero al final, una de las máximas de la seguridad, nos dice que tenemos que acabar confiando en alguien o algo -eso es indiscutible- y, sin ese mínimo confiable, todo lo demás se desmorona; por tanto, estamos obligados a confiar -la discusión podría ser “de quién me fío”-. También es importante la capacidad de abuso que tiene la información almacenada: no es lo mismo un video de nuestro paseo dominical, que un historial clínico completo o un perfil comercial realizado ad hoc, y por tanto la forma de acceso a los datos y los tipos de personas que pueden acceder en cada caso a esos registros deben ser diferentes.

Para acabar, el concepto más subjetivo: el de “normalidad” de las medidas, esto es, el del grado de intromisión en nuestra intimidad, el grado de aceptabilidad (muy ligado al grado de abuso al que hemos hecho referencia). Creo que ninguna de las medidas impopulares que saltan a los medios de comunicación es, para mí, especialmente inaceptable; ¿quitarme el cinturón o los zapatos en el aeropuerto? no me parece lo peor que me haya pasado en mi vida, ni de lejos. ¿Que el gobierno espía mi correo electrónico? Lo dudo, pero si lo hicieran, que se diviertan. ¿Que para entrar en Estados Unidos me exigen firmar nosecuántos documentos con pelos y señales de mi vida? Son libres de decidir quién entra en su territorio y cómo, y como a mí nadie me obliga a ir allí, si no estoy de acuerdo con sus medidas me voy de viaje a Salamanca, donde no me piden ningún dato, no violan mi privacidad ni mancillan mi honor y, sobre todo, seguro que es más bonita y tiene mejores tapas que cualquier ciudad de los USA :) Otra cosa sería que, como medida de seguridad, nos obligaran a todos los ciudadanos a presentarnos diariamente en un juzgado: aquí la aceptabilidad -insisto, subjetiva- me parece nula, por lo que una medida de este tipo para mí sería incorrecta (eso sin entrar en temas de eficacia).

En resumen, cuando leamos una noticia sensacionalista, y surjan las voces de siempre clamando por nuestra privacidad a toda costa y la violación de nuestros derechos y blablabla, creo que deberíamos plantearnos en frío, con respecto a la medida que se quiere aplicar, los tres puntos comentados aquí: su eficacia, su grado de abuso y su aceptabilidad -este más sujeto a discusión-. Y fijarnos dónde pone cada uno su nivel de aceptabilidad, que al final, nos guste o no, es el factor que decide en ocasiones la implantación de la salvaguarda en cuestión.

La inseguridad de los acortadores de URL

Si recuerdan el post sobre XSS de la serie que explica las vulnerabilidades TOP 10 en aplicaciones web de OWASP de este año, en éste les comentábamos los potenciales problemas de seguridad que podían enmascararse con el uso de los extendidos servicios de reducción de tamaño en las URL. Si todavía hoy alguien no los conoce, estos servicios se encargan de reducir el tamaño de una URL determinada a una nueva URL con una longitud predeterminada e inferior, en la que se mapea el enlace de forma que pueda ser utilizado en servicios como twitter que tienen un número limitado de caracteres; el incremento de popularidad de esta “nueva” red social ha hecho que este tipo de servicios se multipliquen como las setas. De esta manera, se facilita el incorporar enlaces largos en entradas de este tipo de servicios.

A modo de ejemplo, una url del tipo:

https://www.securityartwork.es/2010/03/10/owasp-top-10-ii-xss/

Se traduce con uno de estos servicios en:

http://tiny.cc/7rvdi

[Read more…]

Securizando nuestra DMZ

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

Un problema habitual en este tipo de arquitecturas hace que siempre nos preguntemos: ¿que sucede si comprometen uno de mis servidores ubicados en la DMZ? Bien sea por un Zero-day, una mala configuracion del sistema, un exploit sin firma actualizada en nuestro IDS, etc., la respuesta suele ser siempre la misma: una vez comprometido un servidor del segmento, el atacante podria comprometernos el resto de los servidores puesto que la comunicacion entre los servidores ya no atraviesa el firewall central.

Para resolver este problema existen distintas soluciones, las cuales se basan entre otras en implantar HIDS o firewalls en los propios servidores, con el problema añadido de la complejidad de la gestion de la seguridad para los administradores o del consumo de recursos, aunque mínimo, de los sistemas implicados.

Un control de seguridad adicional para este tipo de situaciones es posible configurarlo a nivel de red, en concreto en los propios switches, y es lo que se conoce como Private Virtual Lan (PVLAN), una tecnologia (al parecer) ideada por Cisco Systems, aunque soportada por distintos fabricantes.

Habitualmente, una VLAN forma un unico dominio de broadcast donde todos los hosts conectados a ella pueden conectarse entre sí. Por el contrario, una Private VLAN permite una segmentacion en la capa 2 del modelo OSI, limitando el dominio de broadcast, de forma que es posible permitir conexiones de cada host con su gateway, denegando la comunicacion entre hosts, obteniendo el resultado deseado, de modo que si un host se ve comprometido, el resto de equipos podría mantenerse a salvo.

En arquitecturas basadas en PVLAN, cada puerto del switch puede configurarse de tres maneras distintas:

  • Promiscuous: el puerto es capaz de enviar y recibir tráfico a cualquier puerto de la misma PVLAN.
  • Community: el puerto puede enviar y recibir tráfico a un puerto configurado como promiscuo o a otros puertos de la misma comunidad.
  • Isolated: el puerto solo puede enviar y recibir tráfico a un puerto configurado como promiscuo.

De esta forma, una PVLAN solo puede tener un puerto configurado como promiscuous (primary vlan) pero varios declarados como community o isolated (secondary vlan).

En la red DMZ que usamos como ejemplo, el puerto conectado al firewall seria declarado como promiscuous y los puertos que conectan los servidores serian declarados como isolated, siempre que no necesiten conectividad entre ellos, o community en caso de que la requieran. Por ejemplo, un servidor de aplicaciones que accede a un servidor de base de datos.

De esta forma, conseguiríamos un nivel de seguridad más para nuestras redes, en la línea de lo exigido por la ISO 27002 (A.10.6.1, Controles de red), y reduciendo los riesgos para un segmento especialmente expuesto a ataques y amenazas.

(Diagrama de Tech Republic. Pasen un buen y largo fin de semana y nos vemos el martes que viene, en el mismo sitio. Tengan cuidado con la carretera.)

Bit SUID en shell script (II)

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

[Read more…]

OWASP TOP 10 (IV): Referencia directa a objetos insegura

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.

Las vulnerabilidades relacionadas con la referencia directa a objetos permiten a un atacante la posibilidad de obtener manipular referencias internas de la aplicación para acceder a objetos sin autorización. Es decir, la aplicación desarrollada que es vulnerable a este tipo de ataques permite el acceso a ficheros, directorios o registros de la base de datos a partir, entre otros, de un enlace a una URL o a un parámetro en un formulario.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Desde la página de cada artículo puede acceder a un documento en el que se encuentra un enlace para descargar las especificaciones de éste con una URL del tipo:

http://owasp.s2grupo.es/catalog/download.jsp?dir=articles&file=815.pdf

Una vez recibida en el servidor, obtiene el documento componiendo la ruta al fichero a partir de los parámetros enviados y se lo devuelve el fichero para que el usuario lo pueda descargar a su ordenador.
Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase cualquier fichero de configuración de la aplicación o del sistema operativo, por ejemplo, el fichero de conexión con la base de datos o el fichero de usuarios y contraseñas de la máquina que aloja este servicio (por utilizar un ejemplo clásico):

http://owasp.s2grupo.es/catalog/download.jsp?dir=../../../../../../etc&file=passwd

Para que esta vulnerabilidad sea efectiva, es necesario que la composición de la ruta al fichero se realice en el servidor sin realizar ningún tipo de comprobación respecto al nombre del documento que se desea descargar o la ruta a la cual se está accediendo.

Existe una variante de este tipo de vulnerabilidad que puede comprometer los mecanismos de seguridad de acceso a los datos de nuestra aplicación. Supongamos que nuestra aplicación de catálogo tiene definidos diferentes fabricantes que sólo permiten el acceso a sus especificaciones a los usuarios autenticados de su propia empresa. Estas especificaciones se muestran en modo de lista y se puede descargar cada una de ellas pulsando sobre su nombre obteniendo el fichero a partir de una URL semejante a la siguiente:

http://owasp.s2grupo.es/catalog/securityartwork/23.pdf

Un atacante de nuestra plataforma podría averiguar esta petición y obtener el fichero en cuestión independientemente de sus permisos puesto que este fichero se está publicando directamente en el servidor de aplicaciones, y únicamente la lógica de negocio es la que protege la disponibilidad de acceso a la información. Del mismo modo, supongamos que nuestra aplicación permite acceder a una pantalla en la que se visualizan los datos personales del usuario y desde ahí es posible la realización de modificaciones de esta información a través de una URL del tipo:

https://owasp.s2grupo.es/catalog/userdetail.jsp?id=4815162342

Una vez recibida en el servidor, obtiene la información del usuario y la presenta para su consulta y modificación en caso de ser necesario. Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que retornase la información de cualquier otro usuario de la aplicación, vulnerando de esta manera la privacidad de la información y las reglas de negocio de la aplicación.

Con el fin de evitar que nuestras aplicaciones sean vulnerables a este tipo de ataque se debe evitar, en la medida de lo posible, la presentación al usuario de referencias directas a estos objetos. En caso de que no sea posible realizar esta modificación se deberán incorporar los mecanismos de seguridad necesarios para garantizar que dicho usuario dispone de permisos para acceder al recurso solicitado.
De esta forma, si se desea ofrecer acceso a un fichero, será más seguro realizarlo a través de una clave intermedia que permita garantizar que el usuario que intenta acceder al recurso dispone de los permisos suficientes, así como evitar la publicación directa de recursos a través del acceso directo mediante una URL que pueda ser predicha.

Y hasta aquí todo lo referente a las vulnerabilidades de referencia directa a objetos insegura, de momento. Como les hemos insistido en entradas anteriores, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no les ha quedado clara la explicación, o les gustaría que entrásemos más en profundidad, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Sincronizarse es de sabios

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.

Dejando atrás las ventajas de Blackberry (les aseguro que no me llevo comisión), la mayoría de ustedes seguro que usan algún cliente de correo en sus ordenadores personales, que además integra una libreta de contactos, una agenda, gestión de tareas, etc. Y seguro que también habrán sido víctimas de una pérdida de datos de este tipo de información, lo que suele ser un auténtico desastre para el que la sufre. Es ya un clásico esa típica reinstalación del sistema operativo por razones de actualización del SO, o simple reubicación del equipo, en la que siempre solemos olvidar copiar la ruta escondida que alberga estos datos.

Uno de los recursos más usados para replicar esta información y evitar de esta manera la pérdida de datos es la sincronización con nuestros dispositivos móviles. Hoy en día, casi todos los móviles sincronizan con la mayoría de las aplicaciones a las que hacíamos referencia. Es una buena manera de tener siempre los datos disponibles estemos donde estemos y además, replicados.

Para esta replicación se usan múltiples vías. Lo más fácil y rápido es mediante la conexión USB, otros mantienen la réplica siempre activa por Bluetooth, y los más avezados usan sincronizaciones OTA (Over The Air). Por supuesto, lo más recomendable desde el punto de vista de la seguridad es instalar nuestro propio servidor de sincronización, pero la mayoría opta por soluciones Cloud Computing en servidores de terceros, que añaden la ventaja de una sincronización automática. No hay lugar para el olvido ni el descuido por nuestra parte, ya que nuestro terminal móvil sincroniza cada cierto tiempo con el servidor.

Como ejemplo, y por ser una de las soluciones más implantadas, podemos hacer referencia al protocolo SyncML, que es capaz de sincronizar casi todas las aplicaciones correo/PIM con la mayoría de dispositivos móviles. Hay todo tipo de aplicaciones que realizan esta función: Funambol, Anywr, Vufone, etc. Algunos son OpenSource y otras son soluciones comerciales; incluso Google o la propia Microsoft se han subido al carro, con su Microsoft Phone Data Manager aún en fase Beta.

Lo cierto es que cada vez más compañías telefónicas disponen de ofertas para conexiones 3G y ya se empiezan a encontrar tarifas planas (o casi) a precios antes impensables (o casi). Y si tenemos conexión permanente en nuestro terminal, ¿por qué no vamos a sincronizar su contenido? Y aquí llega la eterna disyuntiva. ¿Nos fiamos de por dónde pasan nuestros datos? ¿Nos fiamos de quien los aloja? Volvemos a poner en la balanza el dueto usabilidad vs. seguridad. ¿Son nuestras entradas de agenda y contactos lo bastante sensibles para no “volar” por servidores de terceros? ¿Qué pasa si perdemos nuestro móvil o se nos borra toda la información almacenada en él?

Para ustedes, ¿qué riesgo es más asumible?

Para aprender, perder… o no: Introducción

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

Este es el funcionamento básico de los denominados honeypots: aplicaciones que simulan, de una forma más o menos interactiva, servicios o aplicaciones que registran la actividad sospechosa que un atacante pueda realizar sobre ellos. Al conjunto de honeypots que presentan una arquitectura lógica de red simulando un conjunto de sistemas, servicios y aplicaciones relacionadas, se le denomina honeynet. Por supuesto, en este tipo de entornos simulados no existe información real sensible ni relativa a la organización, pero si información aparentemente interesante que motive al atacante y le haga “perder” tiempo, al mismo tiempo que proporciona información sobre técnicas y métodos de ataque.

En esta línea existe un proyecto dedicado a aunar esfuerzos y desarrollar pautas para la creación, gestión y divulgación de estos sistemas, denominado el HoneyNet Project. En su web es posible encontrar tanto papers con información técnica como referencias a los denominados chapters de cada país relacionados con el proyecto.

En cualquier caso, en este tipo de entornos es recomendable no olvidar que estamos tratando con sistemas que interactúan con potenciales intrusos, y que los clasificamos como honeypots porque tanto la información que se expone como los sistemas que puedan verse “comprometidos” no interfieren de forma negativa en el proceso de negocio de la organización. Como habrán supuesto, el interés de estos sistemas y entornos es doble.

Por una parte, el registro de la actividad del atacante que interactúa con el honeypot o la honeynet muestra nuevas técnicas o tendencias de ataques de los que podemos aprender, y por lo tanto, permite planificar e implantar las medidas de seguridad oportunas a corto, medio e incluso a largo plazo para paliar posibles futuros ataques sobre los sistemas productivos de la empresa. Al mismo tiempo, la existencia de sistemas intencionadamente vulnerables conviviendo con sistemas de producción convenientemente securizados (aunque como saben, nunca lo suficiente) proporciona una forma muy efectiva de dirigir la atención del atacante lejos de los sistemas de negocio. Es importante, no obstante, que el entorno vulnerable esté adecuadamente aislado, evitando que pueda servir de puente hacia otros sistemas internos, y por tanto convirtiendo una herramienta en un problema.

Una vez disponemos de toda la información, ¿cómo podemos recopilar, analizar y aprovechar todos los datos que se van generando? Para ello existen correladores de información que ofrecen una integración bastante sencilla con la mayoría de honeypots existentes, y que a su vez son lo suficientemente flexibles como para adaptarlos al sistema en el que deba implantarse. El resultado de este análisis puede plasmarse en una serie de informes de actividad periódicos que representen el histórico y evolución de la actividad registrada, algo que veremos más adelante en esta serie.

Existe un refrán que dice “Para aprender, perder…”. En la serie de posts que se publicarán más adelante veremos como es posible aprender mucho y perder poco.

(Entrada escrita en colaboración con Alberto Segovia, co-autor de la serie)

I Encuentro Internacional CIIP: Taller de gestión de riesgos

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.

[Read more…]

OWASP TOP 10 (III): Pérdida de autenticación y Gestión de Sesiones

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.

Existen multitud de situaciones en las que nos podemos encontrar ante una aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Además, debe prestarse especial atención a las procesos que permiten la recuperación de los valores del usuario de forma automática como pueden ser los servicios de pregunta secreta, de actualización de cuenta o de “Recordar contraseña”.

De nuevo, igual que ocurría en la vulnerabilidad explicada en el primer post de la serie de inyecciones, hay multitud de ejemplos que podrían demostrar el uso de esta vulnerabilidad, por lo que vamos a introducir únicamente un grupo reducido de ejemplos que permitan ilustrar la situación, y en caso de que sea necesaria alguna aclaración sobre cualquiera de los aspectos no considerados esperamos que nos lo hagan saber a través de los comentarios.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo: sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Navegando por cada uno de los artículos accede a uno que le interesa y que quiere compartir con sus amigos, por lo que accede a la url que tiene en su navegador del tipo:

http://owasp.s2grupo.es/catalog/product.jsp;jsessionid=c2VjdXJpdHlhcnR3b3Jr?article=815

A continuación cierra su navegador y postea en una red social este enlace para que todos puedan acceder a este curioso artículo. Como el servidor en el que se encuentra el artículo no cierra la sesión del usuario salvo que sea por petición de éste, cualquiera de sus “amigos” que acceda a dicho enlace aparecerá registrado en la aplicación como el usuario autenticado con el consecuente acceso a sus datos.

Del mismo modo, es posible encontrar un ejemplo de autenticación realizada a través de medios no confiables. Pensemos que esta misma aplicación utiliza un servicio de autenticación seguro a través de https. De esta forma, la comunicación viaja cifrada y no es posible interceptar el tráfico para capturar la contraseña del usuario. Como sucede en muchas páginas, el proceso de autenticación proporciona la posibilidad de “recordar” al usuario al marcar un check, de forma que se almacena en local una cookie de la página con el nombre de usuario y contraseña introducidos en el formulario de autenticación.

https://owasp.s2grupo.es/catalog/login.jsp?username=owasp&pass=owasp123

Aunque durante el proceso de autenticación manual el servicio utiliza una configuración segura a través de https, el proceso de autenticación automático utiliza una configuración a través de http.

http://owasp.s2grupo.es/catalog/authlogin.jsp?username=owasp&pass=OWASP&cookie=true

En este momento, cualquier atacante de la aplicación que se encuentre controlando el tráfico que intenta acceder la aplicación de catálogo dispondrá del nombre de usuario y su contraseña por no haber utilizado un sistema de comunicación seguro.

Existen diferentes formas de proteger la aplicación desarrollada de este tipo de vulnerabilidades, pero requieren decisiones a nivel de diseño. En primer lugar, la gestión de contraseñas nunca puede almacenarse en texto plano, aspecto que aunque a ustedes les parezca obvio, es más común de lo que piensan. Esto provocaría que un atacante que tuviese acceso a la tabla o al fichero en el que se almacena la información de los usuarios tendría automáticamente acceso a cualquier recurso de la aplicación que desease, independientemente de las medidas de control que pudiésemos plantear. Además, deben utilizarse los servicios que utilicen información sensible a través de canales seguros, como puede ser una conexión sobre SSL, de forma que se evite la posibilidad de que un atacante se interponga en la comunicación de esta información entre nuestro cliente y el servidor de la aplicación de datos.

Por último, una serie de indicaciones generales sobre la forma de gestionar las sesiones:

  • Añadir la comunicación cifrada en en el proceso de acceso a la aplicación.
  • Eliminar, en la medida de lo posible, la utilización de mecanismos de autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta contraseña se almacena para poder ser utilizada y la sustracción de ésta valor podría ocasionar la suplantación de usuarios. Por supuesto, en este punto entramos en el equilibrio entre seguridad y funcionalidad.
  • Ofrecer un enlace en todas las páginas de la aplicación para que el usuario pueda cerrar la sesión.
  • Gestionar de forma adecuada la caducidad de las sesiones ante un período de inactividad.
  • Gestionar de forma adecuada el tratamiento de la información cuando se introduzca un identificador de sesión caducado o no válido.

Y hasta aquí todo lo referente a las vulnerabilidades de pérdida de autenticación y gestión de Sesiones, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Como siempre, si tienen interés en que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.