GOTO VIII: LOPD a “coste cero” (¿y?)

Leía ayer en el blog de Jesús Pérez Serna que finalmente la Fundación Tripartita va a poner coto a las empresas que con las ayudas a la formación se dedican a realizar la adaptación de las empresas a la LOPD “a coste cero” [enlace directo], y al parecer hay bastante regocijo en el sector por ello. Esta situación me trae a la cabeza algo que leí o me contaron sobre la prohibición de vender foie de oca en algunos estados de los USA. Al parecer, los dueños de los restaurantes habían evitado esta prohibición regalando el preciado alimento, y cobrando una barbaridad por el pan. No sé si ven por dónde voy. Es difícil evitar que dentro de unas sesiones de formación una empresa “regale” un proyecto de adaptación a la LOPD. Pero ya lo veremos.

Quizá estén preguntándose: ¿cuál es el problema de las LOPD “a coste cero”? Pues el problema tiene principalmente dos vertientes: una más fácil de vender, y otra menos. La primera es evitar el fraude, palabra que en estos tiempos suena peor que nunca; si las subvenciones de la Fundación Tripartita son para la formación de los trabajadores, no es de recibo, ni ética ni legalmente que ese dinero se utilice para adaptar la empresa a la LOPD, porque es obvio que el beneficiario de las ayudas en ese caso no es el trabajador. La segunda, y aquí es donde viene la parte que es posible que levante algunas ampollas, es evitar el intrusismo por la vía del corporativismo y el “sindicalismo” mal entendido. El mismo propósito persiguen las certificaciones que se están promoviendo recientemente relacionadas con la protección de datos, pero de eso les prometo que hablaré otro día. Volvamos a lo nuestro.

Parece lógico pensar que buscar apoyos para proteger el nicho de mercado de la protección de datos por la vía de la simpatía no resulta sencillo, y menos si la otra parte da el producto “por tu cara bonita” (o mejor, por la de los trabajadores) por lo que, como muchos colectivos y asociaciones han hecho en el pasado, se recurre a la amenaza de un trabajo mal hecho, lo que en este caso puede desembocar en significativas sanciones a la empresa cliente que ha cometido el error de contratar a una de esas empresas LOPD-a-coste-cero. Dicho de otra forma, al estilo de la DGT, el mensaje es el siguiente: las imprudencias se pagan, y con la LOPD, cada vez más; no se arriesgue y evite la LOPD “a coste cero”. El problema es que no existe, en realidad, una relación de implicación entre el coste de un proyecto y el nombre de la empresa que lo ejecuta, y la calidad del trabajo hecho. Por supuesto, existe cierta relación, pero he tenido el placer de ver informes de grandes empresas cuyo precio fue probablemente inversamente proporcional a la calidad que dichos informes atesoraban. A veces un KIA da mejores resultados que un Mercedes, y depende mucho del profesional encargado del proyecto.

Pero, ¿saben qué? La adaptación a la LOPD no es, en la mayor parte de los casos, un proceso especialmente complejo. Excepto en el caso de grandes o grupos de empresas, u organizaciones con una gestión intensiva de datos de carácter personal (por ejemplo, mutuas de prevención de riesgos laborales, hospitales, empresas de trabajo temporal, y esas grandes desconocidas: las ONGs), la adaptación a la LOPD es algo relativamente sencillo; quizá laborioso, pero sencillo. No requiere grandes conocimientos legales ni técnicos, y en muchos casos la agencia está lista para contestar, a su forma (es decir, manteniendo un adecuado nivel de ambigüedad), a las preguntas y dudas que se le plantean. Expresado de otra forma, me atrevo a decir que prácticamente cualquier empresa dispone de personal que con la necesaria preparación sería capaz de abordar su propia adaptación a la LOPD; excepto en casos particulares (que no son muchos, en los millones de empresas que tenemos en este país), en una organización sencilla, la adaptación será sencilla y podrá llevarla a cabo personal sin grandes conocimientos, y en una organización compleja, será compleja pero también habrá perfiles profesionales de calidad, legal e informático más cualificados.

El mensaje que les estoy intentando transmitir es el siguiente: la LOPD y su Reglamento de Desarrollo no son mecánica cuántica, y el que diga lo contrario, miente. Después de todo, aunque no sea totalmente significativo, la LOPD son 12 páginas y el RDLOPD 34 páginas (aunque contiene mucha “paja”).

Es posible que piensen que una empresa especializada puede detectar más salvedades que una persona “de la casa” sin demasiada experiencia en protección de datos. No les quepa la menor duda de ello. Pero tampoco de que su organización no estará dispuesta a cubrir todas esas no conformidades por el coste que implican. Por mi experiencia personal, al final la mayoría de organizaciones buscan tapar los “agujeros grandes”, llámense Documento de Seguridad, consentimiento informado, contratos con proveedores, o inscripción de ficheros, porque el coste de tapar los pequeños, llámense registro de acceso a aplicaciones con datos de nivel alto, registro de E/S de soportes, Documento de Seguridad como Encargado del Tratamiento, o copia de equipos personales, acostumbra a ser demasiado alto. Que hay organizaciones que persiguen ambos, cierto, pero como en toda organización, existen prioridades. En definitiva, que la intención de una empresa es tapar los “agujeros grandes”, el resultado de un externo y un interno puede ser sin muchos problemas el mismo.

Entonces, ¿cuál es la razón para contratar a una empresa especializada? Por supuesto, hay muchas, como en cualquier proyecto de consultoría: experiencia, capacidad de adaptación, respaldo de dirección, etc. Pero en mi opinión, la primera y principal es exactamente la misma por la que una empresa contrata un servicios de limpieza o un electricista: la LOPD no es su negocio, y “sacar” a alguien de sus tareas habituales para realizar la adaptación a la LOPD durante dos o tres meses (en el mejor de los casos) no es rentable, porque alguien deberá hacer su trabajo. Piensen, por ejemplo, en una gran empresa que se dedica a fabricar tornillos a nivel mundial. Probablemente dispone de un departamento de calidad, un departamento informático y un departamento legal. ¿Tienen alguna duda de que una persona de cualquiera de estos departamentos (o mejor, un comité formado por personas de cualquiera de ellos), cualificada y con experiencia tendría problemas para adaptar su organización a la LOPD si se le da el tiempo necesario? Si la respuesta es que sí, piénsenlo de nuevo. Si vuelve a ser afirmativa, es que se han tomado la LOPD (y quizá a si mismos) demasiado en serio. Por suerte, la LOPD no es ingeniería aeroespacial.

Cuando oigo historias como estas, no puedo evitar acordarme de las discográficas. Todos estamos dispuestos a criticar esa particular forma de proteger su negocio por la vía judicial y política, pero la realidad es que a nadie le gusta que le pisen el césped. No se dejen engañar; es necesario erradicar las LOPD “a coste cero” porque son un fraude que perjudica directamente a los trabajadores, no a las consultoras. Nosotros ya nos buscaremos la vida.

Introducción a la esteganografía (I)

La esteganografía —del griego steganos (oculto) y graphos (escritura)—, en términos informáticos, es la disciplina que estudia el conjunto de técnicas cuyo fin es la ocultación de información sensible, mensajes u objetos, dentro de otros denominados ficheros contenedores, normalmente multimedia: imágenes digitales, vídeos o archivos de audio, con el objetivo de que la información pueda pasar inadvertida a terceros y sólo pueda ser recuperada por un usuario legítimo.

A lo largo de la historia, se ha demostrado que la esteganografía ha estado presente desde antes del siglo XV y se encuentra en constante evolución. Ejemplos tales como la escritura con “tinta invisible” fabricada con vinagre, zumo de limón, leche, etc., o la ocultación de mensajes en libros como Sueño de Polífilo escrito por Francesco Colonna en el 1499, en el que se puede obtener la frase ‘Poliam frater Franciscus Columna peramavit‘ (‘El hermano Francesco Colonna ama apasionadamente a Polia’) si se toma la primera letra de los treinta y ocho capítulos, ponen de manifiesto la presencia de la esteganografía en nuestro entorno desde tiempos antiguos.

Las técnicas esteganográficas han ido evolucionando de manera acorde al desarrollo tecnológico, y así por ejemplo durante la Segunda Guerra Mundial se utilizaban los periódicos para el envío de señales ocultas mediante la realización de marcas en ciertas letras, que aunque por si solas pasaban inadvertidas en conjunto trasmitían una información. Este ejemplo es una muestra de los sectores en los que habitualmente la esteganografía ha estado más presente, y que como podéis imaginar son el entorno militar, agencias de inteligencia o espionaje entre otros.

En la actualidad, cuando hablamos de esteganografía nos referimos principalmente a la ocultación de información dentro de un entorno de canales digitales: protocolos de comunicaciones, archivos ejecutables, documentos de texto, audio digital, imágenes, etc. En la mayoría de los casos, el fichero contenedor es conocido pero lo que se ignora es el algoritmo o técnica de inserción de la información en dicho objeto contenedor. En tiempos recientes, la esteganografia ha adquirido un gran interés porque ya no sólo se usa para enviar mensajes de amor ocultos en libros como Sueño de Polífilo, sino que dichas técnicas se presupone que han sido y son utilizadas con fines muy diferentes por organizaciones terroristas y criminales, y están muy relacionadas con técnicas de anonimato como el voto o el dinero electronico entre otras. Según el diario USA Today, el FBI y la CIA descubrieron que Bin Laden empleaba imágenes esteganografiadas colgadas en paginas web públicas para comunicarse con sus oficiales.

En relación con este campo de estudio, podemos distinguir los siguientes actores implicados:

  • El objeto contenedor o encubridor, que en la mayoría de los casos suele ser una imagen y que es utilizado para ocultar la información,
  • el estego-objeto, que se trata del fichero contenedor mas el mensaje encubierto,
  • el adversario, que serian todos aquellos entes sean pasivos, activos o maliciosos a los que se les quiere ocultar la información, y
  • el estegoanálisis, que es la ciencia que estudia la detección de información oculta.

Es importante no confundir criptografía con esteganografía, puesto que el objetivo de cada uno de estos dos campos es diferente. En el caso de la criptografía el objetivo es asegurar la confidencialidad de la información ante un interceptor que es capaz de ver el criptograma. En cambio, la esteganografia busca ocultar la presencia del mensaje en sí. Sin embargo, aunque persigan objetivos diversos, para que la esteganografía sea de mayor utilidad se debe combinar con la criptografía, de modo que el mensaje a ocultar debe cifrarse robustamente y luego ser introducido en el objeto contenedor. De este modo, aunque un interceptor descubriese el patrón esteganográfico, no podría llegar a conocer el mensaje intercambiado.

En la siguiente entrada daremos un vistazo a las técnicas de esteganografía, pero pueden encontrar información en la Wikipedia y en el artículo que el Inteco le dedicó, aparte de los numerosos recursos que existen en Internet.

(El estereograma en tamaño real se encuentra en el Blog AFT Escuela Básica “Los Navíos”)

Claves del pasado para una web del futuro

Existe una regla no escrita de la seguridad (como todas las demás) que dice que no se deben repetir contraseñas en diferentes sitios, servicios, cuentas de correo y demás. Es una de esas “normas” que nos gusta recordar de vez en cuando, y que hasta hace unos años era relativamente sencilla de cumplir.

Con poca memoria que tengan en esto de la informática, recordarán que hace menos de una década el número de claves que un usuario normal tenía que recordar se limitaba a una cuenta de correo o a lo sumo dos, y algún foro. Poco más; no hacía falta demasiada memoria para ello. Pero un buen día empezaron a surgir los foros, la web 2.0, y hoy en día cualquier persona que haga un uso habitual de Internet dispone de usuario en más de una docena de servicios y sitios diferentes: Facebook, Google, Hotmail, Tuenti, Delicious, Twitter, Ebay, Amazon, LinkedIn, Xing, WordPress, GoDaddy, Meetic, Menéame, Flickr, etc. Ahora súmenle dos o tres foros, páginas de descarga de contenidos digitales, páginas de venta online, y sitios a los que acabamos accediendo un puñado de veces pero para los que solemos crear una cuenta de usuario, y tenemos una veintena de cuentas diferentes, y bastantes más en el caso de personas que hagan un uso “intensivo” de la red.

Dicho de otra forma, actualmente el número de claves que debemos recordar excede la capacidad de memorización de la mayor parte de nosotros si queremos utilizar claves diferentes y cumplir esa otra norma que dice que éstas no deben ser deducidas unas de otras y tener unos requisitos mínimos de sintaxis, longitud y complejidad, por muchas reglas nemotécnicas que utilicemos. De caducidad de contraseñas ni hablamos, porque si cada uno de nosotros tuviese que ponerse a cambiar veinte claves cada dos o tres meses, iba a ser para volverse loco.

¿Qué provoca esta situación? Que el número de claves que los usuarios utilizamos sea limitado y se repita entre diferentes servicios, sin diferenciar a menudo ni siquiera entre sitios “seguros” (o relativamente seguros) y sitios “menos seguros”. Para colmo de males, a esto hay que añadirle la reticencia de la mayor parte de las personas (incluido un servidor) a variar las contraseñas “habituales” que lleva utilizando desde tiempos inmemoriales, o en todo caso a cambiar de nemotécnico, por dos razones básicas: el pánico a olvidar una clave (y no poder acceder al correo exactamente en el momento que lo “necesitamos”, y no cinco o diez minutos después, una vez la hemos recuperado) y el estrés que nos provoca tener que recordar nuevas contraseñas totalmente diferentes de las habituales y con las que todavía no estamos familiarizados (¿soy el único que retrasa hasta el último momento el cambio de la clave de acceso al correo corporativo cuando ésta caduca?).

Para empeorar aún más esta situación, la mayoría de usuarios acabamos tirando del recurso fácil que son los navegadores y la funcionalidad habitual de “recordar contraseña”, olvidando en la gran mayoría de casos que las claves se guardan en texto plano, y que cualquier persona con acceso al navegador dispone de acceso inmediato a nuestras cuentas de correo, foros, y servicios 2.0 de todo tipo. Si esto no fuese suficiente, para acabar de rematar la faena, DragonJar indica que es posible robar contraseñas del gestor de claves de Firefox por XSS.

Afortunadamente, poco a poco empiezan a surgir soluciones para este problema, aunque mucho me temo que actualmente son accesibles, como muchas otras funcionalidades “avanzadas”, a usuarios con determinada experiencia y soltura en el uso de Internet (o dicho de otra forma, no esperen que el usuario básico —de los que hay muchos millones— los utilice o siquiera los entienda). Aparte de los habituales KeePass o Password Gorilla, cuyo ámbito es mucho mayor que el de los servicios de Internet, en primer lugar tenemos (vía DragonJar) a LastPass, que parece prometedor aunque no he tenido ocasión de probar. Por otra parte, Mozilla está experimentando con un gestor de cuentas que está pensado para revolucionar el acceso a las webs, y que se encuentra aún en fase de prototipo.

No obstante, incluso con los gestores “seguros” de contraseñas como los que les comentaba hay un aspecto preocupante y bastante frecuente: aquellas webs o servicios que no te dejan introducir carácteres “extraños” en la contraseña (léase !, ?, #, $, %, &, /, (, ), o los propios signos de puntuación) o esas otras que te remiten la clave en texto plano cuando la “recuperas”, indicando que no utilizan cifrado para el almacenamiento de las claves de los usuarios (entre ellas, la web de ISACA). Esto puede provocar, debido a las malas prácticas que hemos indicado, que las cuentas de muchos usuarios en otros sitios web se vean comprometidas en caso de robo de información. Claro que uno puede asumir que con los sistemas que les comentaba, lo razonable es utilizar una cuenta diferente por servicio, pero ya saben que lo razonable no es siempre lo común.

Para ir acabando, entre todas las cuentas diferentes que un usuario puede manejar en Internet, a pesar de la (relativa) marginalidad cada vez mayor que va adquiriendo frente a las redes sociales y servicios más populares y colectivos y su inseguridad intrínseca, el correo electrónico sigue manteniendo una importancia crítica, al ser el repositorio virtual de recordatorios o cambios de clave de otros muchos servicios; procuren mantener su cuenta a salvo y no compartan la clave de acceso con foros y servicios 2.0 de escasa (o desconocida) reputación.

En definitiva, a pesar de que en la última década el funcionamiento de Internet ha avanzado de manera muy significativa, y su utilización se ha extendido a sectores de la población muy alejados de los ámbitos especializados y universitarios, los sistemas de autenticación siguen siendo los mismos de los comienzos: un usuario y una contraseña. ¿No es hora ya de que vayamos pensando en algo diferente y sobre todo, más seguro?

ACL en GNU/Linux

Hoy vamos a introducirnos en el fascinante mundo de las ACL (Access Control List) en Linux. En este punto ya habrá alguien que piense que eso es más viejo que el mismo Unix, pero mucha gente, entre que los que me incluyo, no tenia ni idea de que existían las ACL en Linux, y menos cómo usarlas. Empecemos, como siempre, con un poco de teoría cortesía de la Wikipedia:

Una Lista de Control de Acceso o ACL (del inglés, Access Control List) es un concepto de seguridad informática usado para fomentar la separación de privilegios. Es una forma de determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de ciertos aspectos del proceso que hace el pedido.

Así pues, las ACL nos permiten determinar si una entidad puede acceder o no a un objeto, y qué acciones puede realizar contra dicho objeto. Bien, hasta aquí suena exactamente igual que los típicos controles de acceso de Linux, y es normal, dado que la instancia mas simple de una ACL son los permisos habituales de propietario/grupo/otros que tan bien conocemos. La diferencia radica en que con las ACL se puede hilar mucho más fino, especificando varios grupos y usuarios y detallando para cada uno sus permisos específicos.

[Read more…]

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.