domingo, 22 de febrero de 2009

Usabilidad y seguridad. SSLStrip


Hace unos días terminaron las BlackHat DC, y ya están listas para descarga las presentaciones, videos, etc. Entre ellas, la presentación "New techniques for defeating SSL/TLS", de M. MarlinSpike. El autor de la presentación implementa estas técnicas en una herramienta llamada sslstrip (cuyo código fuente estará disponible pronto). Sin embargo, para mí la noticia no es la existencia de esta herramienta, sino lo que nos cuenta la presentación.

La demostración es interesante, porque nos recuerda que la usabilidad de una aplicación y su seguridad también están relacionadas. Así, se introduce el concepto de "feedback positivo" y de "feedback negativo" hacia el usuario en una aplicación web, y cómo es más fácil engañar al usuario si se consigue no sólo eliminar el feedback negativo al realizar el ataque, sino además proporcionar feedback positivo.

Así, el feedback negativo es la presentación de un error "gordo y peludo" en caso de que se sospeche que el sitio podría ser falso. Es la solución que los navegadores modernos están implantando, un ejemplo es la pantalla que se ve cuando el certificado de una página no puede ser verificado. El feedback positivo, por el contrario, consiste en proporcionar mensajes que dicen que todo está bien, como puede ser el icono verde que presenta Firefox en la barra de direcciones cuando sí se ha determinado que el certificado es auténtico.

El funcionamiento de las técnicas presentadas se basa en tres puntos:
  1. cuando un sitio web quiere pasar de HTTP a HTTPS (por ejemplo, al autenticarte), se "captura" este paso mediante un proxy SSL (ataque man-in-the-middle o MITM). Hasta aquí nada nuevo. Después, se proporciona algo de feedback positivo al usuario, por ejemplo sustituyendo el icono "favicon" (el que sale en la barra de direcciones) por un candado cerrado
  2. hay muchos sitios web (bancos online, etc) que presentan un formulario cuya petición irá bajo https, en una página http. Cuando el usuario pulse en el botón correspondiente, se intercepta mediante el MITM. Generalizando, el usuario llega a SSL a partir de HTTP: a través de redirecciones, o pulsando en un enlace o un botón. Pero nunca escribiendo la url directamente, por lo que siempre hay una ocasión para el MITM
  3. Un atacante puede utilizar nombres de domino internacionales (IDN: international domain names) para crear una url que incluya los caracteres "." y "/" escritos con juegos de caracteres internacionales (por ejemplo el cirílico). A esto se le denomina homograph attack. La técnica presentada reutiliza de forma ingeniosa este "homograph attack", para conseguir una url similar a la del sitio web víctima, pero controlada por el atacante. Esto es lo novedoso. Así, en realidad, el usuario está solicitando un sitio web distinto, pero no lo percibe: es posible incluso que el sitio esté bajo HTTPS y que el usuario reciba feedback positivo pues verá un certificado SSL que es válido
La solución al problema pasaría, según comentarios, por el uso de certificados de validación extendida. También por la concienciación del usuario para que conozca el problema, qué son estos certificados, etc.

Algo más de información:
Man in the middle attacks sidestep SSL (Securityfocus)
Leetness not actually required for pwnage (DoxPara)
sslsniff (mencionada en la presentación)


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

martes, 17 de febrero de 2009

fist conference


En un par de días son las conferencias FIST, organizadas por ISSA España y el Consejo Superior de Investigaciones científicas, y que tienen el propósito de difundir nuevos conocimientos sobre seguridad de la información, de forma gratuita. Una cita obligada en Madrid (más si hay que ganar créditos CPE para certificados varios).

Ver el programa: seguridad en wifi, seguridad en Windows Mobile, y Network Access Control.


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

lunes, 16 de febrero de 2009

Redes sociales y hackers


Nos cuentan hoy en Snosoft la historia que todo aquél “sabedor” sobre seguridad en la Red sabe, pero la gente no se cree: que las redes sociales (facebook, en particular, supongo que por ser la más popular), se pueden utilizar para hacer ingeniería social, en este caso a los empleados de una empresa.

Dicen que para hacer un test de intrusión a uno de sus clientes, crearon un perfil en facebook como una empleada ficticia (por supuesto muy guapa), y después de entrar en el grupo de la empresa y hacer vida social (que para eso está la Red Social) unos cuantos días, pues pusieron un enlace a uno de los sitios de la empresa, explotando un XSS. El texto del enlace decía que les habían hackeado, y por lo visto, muchísima gente se lanzó a probar sus credenciales, incluida la misma persona que les había contratado (¿de verdad?).

Bien podría ser posible, aunque igualmente fácil es inventárselo, vamos a dar un voto de confianza y buena fe, y nos lo vamos a creer. La conclusión es interesante en cualquier caso. Es cierto que hoy día de muchas empresas hay grupos en redes sociales, no sé si bajo auspicio y tutela de la empresa o no (¿cuáles son las consecuencias de un ataque así si es que no? ¿y si es que sí?), y desde luego la concienciación en seguridad que se da a los empleados, por parte de la empresa, es de cero… . La gente es así… ¡si funcionan cosas como el timo nigeriano!. Otra razón más para educar en seguridad informática, aunque la solución más fácil es prohibir por contrato.


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

miércoles, 11 de febrero de 2009

Reconocer el fracaso en seguridad


Leo en VariableNotFound dos entradas buenísimas sobre los programadores con producción neta negativa, y sobre las 101 formas de saber que tu proyecto está condenado al fracaso (proyecto de desarrollo, claro está). Si hacemos una lista parecida sobre fracaso en seguridad, yo pondría las siguientes.
  • Agregar características generales al final del proyecto. Por ejemplo, en seguridad: pensar que se puede securizar al final.
  • No concienciar al equipo de desarrollo sobre aspectos fundamentales (por ejemplo seguridad)
  • No formar al equipo de desarrollo en técnicas de desarrollo seguro que han de utilizar al escribir código, o en las decisiones de diseño que puede ser necesario tomar
  • No proporcionar tiempo al equipo de desarrollo para que se forme él solito sobre los temas que les competen, por ejemplo seguridad
  • Considerar inaceptable el coste en tiempo (y por tanto dinero) que supone el repaso del código, la implantación de medidas de seguridad, o la realización de pruebas de hacking al final, viéndolo como un gasto superfluo en todos los casos, en vez de una inversión
  • No seguir un verdadero ciclo de desarrollo seguro, que contemple la seguridad como uno de los aspectos fundamentales en cada una de sus fases
Además de tener razones por las que se fracasa en seguridad por no hacer cosas, se me ocurren ahora mismo razones por las que se fracasa en seguridad precisamente por hacer cosas:
  • Considerar que sabemos más que los expertos del mundo mundial, reinventando la rueda. Hay mil ejemplos: usar algoritmos de cifrado de nuestra invención que "nadie puede romper porque sólo los conozco yo", crear identificadores de sesión con formato propio, no usar las funciones de la API para validar entradas porque ya tenemos nosotros las nuestras, etc...
  • Hacer un sistema que siendo seguro, molesta constantemente al usuario (de esto, todo el mundo menciona el mismo ejemplo, para qué repetir)
  • Hacer un sistema tan seguro que penaliza otros aspectos, haciéndolo menos atractivo o útil al usuario, que por tanto comprará otro producto (¿para qué hacer un producto súper seguro que no comprará nadie?. Aunque de esto, no se me ocurre ningún ejemplo ahora mismo)
¿Se os ocurren otras formas?

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

sábado, 7 de febrero de 2009

el blogger summit


Como sabeis el día 3 tuvo lugar el Security Blogger Summit, un nuevo evento sobre seguridad informática, en Madrid, al que me apunté para escuchar a algunos blogueros clase-A lo que decían sobre el tema. La charla buscaba presentar, más o menos, el panorama actual sobre seguridad informática, desde el punto de vista del usuario final (usuario doméstico u organización de cualquier tipo): si estamos mejor o no, y qué se puede hacer para mejorar.

El listado de conferenciantes se puede encontrar en la web del evento. Destacaba por encima de todos, por supuesto, Bruce Schneier, que tiene fama mundial. Por cierto que he leído una entrevista que le han hecho en El Mundo, en el que curiosamente mencionaban cierta similitud con Chuck Norris (me llama la atención que un enlace a esto salga en un periódico de toda la vida). Y de hecho, su discurso de apertura fue de lo que más me gustó del evento, se nota muchísimo que tiene muchas tablas y que es un gran comunicador (aunque yo mismo critique un poco su forma de escribir en su sitio web). También hablan directamente del debate.

Honestamente, como debate divulgativo me pareció bastante bien, aunque tampoco creo que se dijera nada no sabido ya. Yo me quedé como ideas que me gustaron las siguientes:

En primer lugar la necesidad de hacer campaña divulgativa con cuatro recomendaciones sencillas, idea que brilla por simple (¿por qué esto no se hace ya en plan masivo, con anuncios en la tele y esas cosas?). Sobre concienciación en privacidad salió la idea de que sí, que el que un crío suba sus fotos al facebook (por ejemplo) va en contra su privacidad, pero que es exagerado eso de que el día de mañana puede ser malo para encontrar trabajo: probablemente quien le contrate tiene ahora más o menos su edad y hace exactamente lo mismo. Idea básica por tanto: concienciación e información, pero sin paranoia. Se hizo mención a la campaña "sentido común" de Inteco en esta línea.

Se habló, por otro lado, de cibercrimen y de la lucha de las fuerzas del orden por combatirlo, con indicación especial de que el Código Penal actual no contempla las palabras "ciberdelito" o "cibercrimen", así como de lo complejo que resulta perseguir a un atacante más allá de la frontera. La pelea, por tanto, se centra hoy día en el ámbito tecnológico.

También se mencionó la economía de IT, indicando algo obvio: los números mandan. La gente no está dispuesta a pagar más por un producto más seguro, así que se obvia este aspecto. Se utiliza un software u otro no porque sea mejor, sino porque es más barato, teniendo en cuenta distintos costes: adquisición, implantación, operación, formación del personal, etc. A muchas empresas les supone muchísimo ese coste de cambio ("switch cost", según Schneier), por lo que continúa, e incluso se expande, es el producto más malo.

Me quedé, en último lugar, con los comentarios sobre la complejidad creciente del software actual y su relación con el aumento de problemas de seguridad, así como la responsabilidad de los desarrolladores y fabricantes en este aspecto. Conste también la mención de otro espectador que dejó caer que en nuestro país salen productos peores entre otras cosas porque ponen a diseñar y desarrollar a gente no cualificada.

Un debate muy bueno, digno de verse en otro entorno más orientado al gran público, quizás en un programa tipo 59''. La organización me pareció muy buena, destacando el audio, el sitio elegido y el buen gusto de los organizadores, que supieron publicitar sus productos sin llamar la atención más de lo necesario (lo dicen en otros sitios y es absolutamente cierto) y además nos regalaron una muestra.

Al final hubo canapés y esas cosas, para que la gente pudiera hablar de forma más cercana con los conferenciantes. Yo no me podía quedar, aunque me hubiera gustado poder conocer a algunas personas, además de a los conferenciantes, por ejemplo a los de SecurityByDefault (me gusta su sitio y además los contenidos de este blog forman parte de su SBD bot).

Slds!

Nota: nos ponen citas con lo que se fue diciendo en la web oficial, esperemos que también videos etc.

También hablan de esto:
Error500 (su autor fue uno de los conferenciantes)
SecurityByDefault
Incognitosis

Actualización 25/02/2009: en Blogger Summit Recap nos dejan enlaces a fotos y videos

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

martes, 3 de febrero de 2009

Entramos en el nuevo año por fin


Mejor tarde que nunca, supongo. Acabo de dejar una pequeña nota, como entrada en el año, después de mucho tiempo sin escribir nada. Y dentro de un rato acudo al teatro de Bellas Artes de Madrid, a escuchar a algunos de los mejores bloggers sobre seguridad informática, en el 1st Security Blogger Summit . A ver si nos cuentan sus secretos para conseguir un blog ameno y que guste a la gente.

Sólo decir a los que siguen leyendo este blog, a pesar del tiempo de inactividad: muchas gracias :)

P.D. Dicen en el sitio web que se pueden ver las charlas online.

Slds!


Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Introducción a las políticas de seguridad


Acabo de leer un artículo en la web de ISACA sobre redacción de políticas de seguridad. Una de las referencias que utiliza me ha parecido un recurso muy interesante, e igualmente útil para todos: es el material sobre políticas de seguridad de SANS.

Y dentro de este material, hay una presentación que realiza una introducción muy buena sobre qué es una política de seguridad y algunos conceptos relacionados (política, estándar, guía, procedimiento…), las relaciones que hay entre ellos, qué cosas deberían estar en una política, etc, que vale mucho la pena. Además de la presentación, hay algunos ejemplos hechos, que pueden servir como base.

Recomendable :)

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...