jueves, 24 de diciembre de 2009
Seguridad web por ley?
Hace unos días se celebraban las conferencias IBWAS'09, las primeras conferencias conjuntas de OWASP Spain y OWASP Portugal. La última de las mesas-coloquio, al parecer (no estuve, por desgracia), trató sobre lo que deberían hacer los gobiernos en el 2010 para mejorar la seguridad en aplicaciones de web. Se emitió este comunicado, del que me gustaría hacerme eco. (Lo cuenta mejor SecurityByDefault en Seguridad en aplicaciones web y gobiernos).
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 17 de diciembre de 2009
apuntes de CSRF
Veo hoy un par de blogs que hablan de CSRF, recordemos, una de las categorías de ataques listadas en Owasp Top Ten por lo menos seis años.
En CSRF isn't just for access, mckt nos explica cómo aprovechar un CSRF para realizar ataques de denegación de servicio distribuida, de múltiples maneras. Y en Cross-Site Request Forgery For POST Requests With An XML Body, el problema de ejecutar un CSRF en una petición SOAP o XMLRPC.
Muy claros e instructivos :)
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 10 de diciembre de 2009
Mapa de ISOs
El "mapa" de las normas de seguridad a tener en cuenta cambia despacio, pero constantemente. Hace poco me enteraba de que se ha planteado la creación de una ISO sobre cómo presentar al público una vulnerabilidad, la ISO 29147. Por eso, quería tener una recopilación de las normas ISO orientadas a seguridad informática, tanto las que están en curso, como las que se publicarán a corto y medio plazo (un año más o menos). Aquí van las que tengo hasta la fecha:
- ISO/IEC 15408: Evaluation criteria for IT security (esto es, el Common Criteria)
- ISO/IEC 27000: Information security management systems - Overview and vocabulary
- ISO/IEC 27001: Information security management systems - Requirements
- ISO/IEC 27002: Code of practice for information security management
- ISO/IEC 27004: Information security management measurements
- ISO/IEC 27005: Information security risk management (reemplaza a la ISO/IEC 13335)
- ISO/IEC 27006: International accreditation guidelines for the accreditation of bodies operating certification / Registration of information security management systems
- ISO/IEC 27007: Guidelines for information security management systems auditing
- ISO/IEC 27008: Guidance for auditors on ISMS controls
- ISO/IEC 27010: Information security management for inter-sector communications (for critical infrastructure)
- ISO/IEC 27011: Information security management guidelines for telecommunications organizations based on ISO/IEC 27002
- ISO/IEC 27013: Guidelines for integration implementation of ISO/IEC 20000-1 & ISO/IEC 27001
- ISO/IEC 27014: Information security governance framework
- ISO/IEC 27031: ICT readiness for business continuity
- ISO/IEC 27032: Guidelines for CyberSecurity
- ISO/IEC 27033: Network security (reemplaza a ISO/IEC 18028)
- ISO/IEC 27034: Application security
- ISO/IEC 24760: A framework for identity management
- ISO/IEC 29100: A privacy framework
- ISO/IEC 29101: A privacy reference architecture
- ISO/IEC 29146: A framework for access management
- ISO/IEC 29147: Responsible vulnerability disclosure
- ISO/IEC 29149: Best practice on the provision of timestamping
services
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
domingo, 22 de noviembre de 2009
Responsible disclosure - cosas nuevas
Leo con interés este post en OSVDB Blog: "Responsible disclosure - Old debate, fresh aspects?!", del que me quiero hacer eco aquí por instructivo. Este se centra en torno a una nueva norma de seguridad que se publicará en diciembre 2010: la ISO 29147 - Responsible Vulnerability Disclosure. El debate sobre cómo publicar la información de una vulnerabilidad descubierta siempre ha sido calentito, y como el que os escribe no tenía ni idea acerca de la existencia de esta norma, he estado leyendo un poco sobre ello, aquí va lo que he sacado.
En primer lugar: de qué va. En la web de ISO no dice absolutamente nada, ni otras personas, reconocidas en el mundo de la seguridad informática, parecen tener tampoco información de primera mano. Al parecer la mera existencia de esta norma ha causado algún revuelo en la comunidad de la seguridad informática, al menos entre los grandes del mundillo (leer, por ejemplo, el propio post de OSVDB, o este de Halvar Flake), porque podría querer "regular" cómo ha de comportarse quien descubre una vulnerabilidad. Sin embargo, parece lógico suponer que no tendrá nada que ver con aquellos vulnerability researchers que publiquen, de forma independiente, sus hallazgos en la materia, sino con cómo una organización va a lidiar con la publicación de los defectos encontrados en sus productos (esta línea de pensamiento la sugiere, por ejemplo, technicalinfodotnet, que escribe Gunter Ollmann). Más que nada, porque el individuo se pasará la ISO por el arco del triunfo, estando las normas de este estilo orientadas a su adopción a nivel corporativo.
Segundo punto: si está orientada a una organización, ¿qué podría tener cabida en esta norma?. Algunas cosas podrían ser: cuándo hacer público el problema. Qué detalles publicar. Orientación para valorar el problema. El tiempo que se considera aceptable desde que se descubre el problema hasta que aparece una solución al mismo. Si sólo se publican los detalles de problemas descubiertos por expertos ajenos a la empresa que produce el producto con problemas, o también los descubiertos de forma interna sencillamente durante el desarrollo de actualizaciones del producto o nuevas versiones, informando al usuario para que este actualice (este nivel de transparencia sería casi idílico). Cómo trabajar con otras organizaciones, en caso de que haya que publicar problemas de forma coordinada. ¿Otros?.
Tercer punto: ¿Existe algún trabajo ya hecho en esta línea?. Pues resulta que sí. Gunter Ollmann nos indica la existencia del proyecto "Common Frameworks for Vulnerability Disclosure and Response (CVRF)" de ICASI. ¿Alguien sabe de algún otro? Si es así, deja un comentario por favor.
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 29 de octubre de 2009
la ola de google
Todos llevamos algún tiempo oyendo hablar de Google Wave, la última innovación de Google para darnos a todos más capacidad de comunicación y de subir contenido a la red. De momento, está en fase beta y sólo accesible con invitación, pero ya ha dado mucho de qué hablar (aquí dos enlaces: alt1040 y El País).
Como es de ley, ya se le ha empezado a sacar problemas de seguridad. En TheHarmonyGuy nos cuentan que su autor ha probado Beef en Google Wave, con éxito, lo que podría convertirlo en una buena herramienta para hax0rs.
Slds
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
lunes, 19 de octubre de 2009
Estadísticas de WASC
Hace unos días WASC publicaba los resultados de la nueva edición de su proyecto Web Application Security Statistics. Este proyecto tiene como objetivos identificar las vulnerabilidades web más comunes en aplicaciones realizadas a medida, así como comparar cuál es el mejor método para detectarlas (pruebas automáticas, pruebas de caja negra, o pruebas de caja blanca).
Se basa en la información recopilada en auditorías de seguridad y tests de intrusión realizados por un conjunto de empresas, listadas en los resultados del informe, y que comprenden un total de 12186 aplicaciones revisadas con un total de 97554 vulnerabilidades descubiertas en ellas. Sus resultados son los siguientes:
- El 13% de los sitios web analizados puede ser comprometido de forma automática
- El 49% de los sitios web analizados contienen vulnerabilidades de carácter grave o crítico que pueden ser detectadas mediante pruebas automáticas, aumentando esta cifra al 80% cuando se realizan pruebas exhaustivas (pruebas automáticas y manuales con conocimiento previo del aplicativo, revisión de código, etc).
- Los problemas más extendidos son XSS, revelado de información, inyección SQL y HTTP Response Splitting.
- Es un 20% más probable que un agujero de seguridad sea debido a un problema de administración del sitio web, que a un fallo introducido por un diseño o codificación inadecuados
- El 99% de las aplicaciones no cumplen con los requisitos de PCI-DSS para aplicaciones de web
- Las pruebas de caja blanca permiten detectar hasta 91 vulnerabilidades por aplicación de web, y sólo podrían detectarse 3 mediante pruebas automáticas sin ningún tipo de conocimiento previo acerca del aplicativo.
Tener estas estadísticas a mano siempre es muy útil, hay que felicitar a quien hace estas estadísticas por su esfuerzo. Permiten saber, por ejemplo, como de buenas son las herramientas utilizadas para hacer los análisis automáticos (son todas comerciales, por supuesto), ya sea con conocimiento previo del aplicativo o sin él. Sin embargo, a mí me gustaría que se detallara un poco el tipo de aplicativo analizado, porque creo que es también relevante saber qué se encuentra dónde. O con qué tecnología están desarrollados (PHP, Java, .Net, Colfusion…).
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 8 de octubre de 2009
El desarrollador educa también al usuario
Seguramente es una de las noticias más comentadas de los últimos días: el leak masivo de contraseñas de usuarios de correo electrónico. Primero fue Hotmail, advirtiendo Microsoft que la causa no tiene que ver con infiltraciones en sus sistemas, sino con un phishing de tomo y lomo. Después, se ha confirmado que Gmail, Yahoo o AOL han tenido el mismo problema (dos enlaces).
Este ataque de phishing, además de exponer el poco sentido común que tiene la mayoría de los mortales en Internet, también saca (como ya sabíamos) el poco cuidado que tiene la gente con sus contraseñas en todos los sitios de Internet, como puede verse en el análisis de las passwords encontradas realizado por Bogdan Calin en el blog de Acunetix, que deja claro que las contraseñas más utilizadas son bien sencillas: 123456, por poner un ejemplo.
Por ello, expertos de renombre mundial, nos vuelven a recordar que las contraseñas utilizadas por los usuarios no pueden ser demasiado complejas, porque si hay que poner una diferente en cada sitio (como medida de seguridad), pues van a acabar olvidando, así que podría ser mejor tener passwords complejas para los sitios más importantes, llevando las más necesarias escritas en un papel en la cartera.
A mí, que soy un pelo desconfiado para estas cosas, no me parece muy buena idea, la verdad, y prefiero aplicaciones como Keepass para guardar mis passwords y además cambiarlas periódicamente. Llevarlas en papel en la cartera me parece igual que llevar el número PIN de tu tarjeta de crédito en el mismo sitio.
Por otra parte, no creo que la solución pase únicamente por protestar continuamente de la poca educación en seguridad informática que tiene el usuario, e intentar educarlo, sino también en obligarle a que se eduque a sí mismo cuando utilice las aplicaciones web que desarrollamos. Así, si ve en todas las aplicaciones que utiliza que se le indica la fortaleza de su contraseña, quizás se pregunte por qué. Y si se le obliga a que tenga un nivel mínimo, pues más todavía. Cada desarrollador puede aportar su granito de arena, aportando a su aplicación todas las medidas de seguridad que pueda en tema de passwords, ya no sólo en beneficio de la seguridad de su desarrollo, sino en beneficio del usuario. En definitiva: enseñar con el ejemplo.
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 24 de septiembre de 2009
Mejorando frameworks de desarrollo
Me gustó hace unos meses este paper: A gap analysis of application security in struts2, desarrollado por el Owasp Intrinic Security Working Group . En él nos contaban cómo el framework Struts2 puede ser utilizado para implementar determinados aspectos de seguridad, como puede ser la validación de entrada, y cómo este framework puede ser mejorado agregándole algunos aspectos que sí están en Owasp ESAPI. (Posteé sobre esto en seguridad en struts).
Como uno no deja de descubrir cosas nuevas, acabo de descubrir gracias a la entrevista a Andrés Riancho en elladodelmal sobre HDIV (HTTP Data Integrity Validator, un proyecto cuyo objetivo es ampliar frameworks de desarrollo como Struts2 o Spring MVC y dotarles de características de seguridad de las que no dispongan. En particular, tiene como misión dar mecanismos para proporcionar:
- Integridad de todos los datos generados por el servidor y que no deben ser modificados en el lado cliente (enlaces, campos ocultos, etc)
- Validación de los datos de entrada: para aquellos datos que sean editables por el usuario (campos de texto), se establecen controles de validación genéricos
- Confidencialidad: garantizar la confidencialidad de datos no editables, pues pueden representar información a proteger: nombres de tablas de BBDD, directorios web, nombres de máquinas de la red interna de la empresa, y un largo etcétera
- Token anti-csrf: en cada formulario y enlace se puede poner un token generado aleatoriamente, como medida de protección adicional contra problemas de CSRF.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
martes, 8 de septiembre de 2009
Para saber si el navegador del usuario está virtualizado
Aquí va una entrada, a modo de apunte rápido, sobre cómo emplear los recursos del navegador para detectar si un usuario está navegando o no desde un entorno virtualizado. Jeremiah Grossman escribía sobre esto hace unas semanas.
J.G nos sugiere dos trucos para detectar entornos virtualizados: ver el tamaño de la ventana del navegador mediante Javascript, y ver la dirección MAC del equipo. El tamaño de la ventana puede obtenerse mediante Javascript, y al parecer, en el caso de entornos virtualizados suelen obtenerse tamaños un tanto extraños. La dirección MAC del equipo no puede obtenerse mediante Javascript, pero sí mediante un applet Java, y ocurre que los primeros octetos de la dirección MAC son fijos, e identifican al fabricante (por ejemplo VMWare).
Además de saberse si un navegador se encuentra virtualizado, también es posible saber por ejemplo si está usando el modo “privado” del navegador (“InPrivate” de IE8, “Private Browsing” de Firefox, o “Incognito” en Chrome). Un usuario empleará este modo en el caso de que se encuentre usando un equipo público, por ejemplo un PC de un cibercafé. Le permite controlar la información que se guarda en el histórico del navegador, cookies, etc. Una última utilidad interesante podría ser conocer si el usuario está usando plugins de seguridad como Noscript.
La conocida herramienta “beef”, que permite explotar vulnerabilidades en los navegadores, incorpora un módulo para detectar si el navegador Internet Explorer está o no virtualizado, mirando la dirección MAC mediante Javascript.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
martes, 11 de agosto de 2009
Seguridad en la nube según NIST
Una de las tendencias tecnológicas más valoradas, como ya nos dijeron los oráculos, es sin duda el Cloud Computing. Estoy seguro que casi todo el mundo sabe ya lo que es y cómo funciona, y además hay mejores definiciones por ahí que la que yo pueda dar, así que no entraré a detallar qué significa SaaS, PaaS, IaaS, o las tecnologías implicadas en la construcción de estos, aquí por ejemplo podemos encontrar una introducción rápida que viene bien.
Hace unos días NIST presentaba algo de material acerca de este tema, en particular una ppt que sirve no como palabra de NIST (o sea, que no es una guía oficial), sino como recurso educativo, una recopilación de material sobre Cloud Computing, de dónde sale el término, qué es y cómo utilizarlo de forma segura, discutiendo sus ventajas y los desafíos que presenta a nivel de seguridad de la información. Para repetirlo una vez más y que también salgan en este blog, aquí va el listado de ventajas del cloud computing:
- Fragmentación de los datos, que estarán alojados (dispersos, si traducimos literalmente) en distintos lugares. (Como se dice en España, es el principio de no poner todos los huevos en la misma cesta).
- Equipo de seguridad dedicado
- Mayores inversiones en infraestructuras de seguridad
- Controles de seguridad implantados bajo demanda
- Protección frente a ataques a nivel de red, gracias a las medidas de los hipervisores
- Posible reducción de las actividades orientadas a la certificación y la acreditación, al acceder a entornos ya certificados. Simplificación de los análisis de cumplimiento (normativo, se entiende)
- Datos custodiados por un tercero objetivo (según indican los propios proveedores de cloud hosting)
- Mayor fiabilidad y tolerancia frente a fallos
- Soluciones de almacenamiento de datos y recuperación frente a desastres, de bajo coste. Reconstitución del servicio rápida.
- Detección de ataques e intentos de manipulación de los sistemas, en tiempo real. Posibilidad de utilizar redes honeynet avanzadas
Otras, en cambio, chocan con las propias desventajas listadas en esta ppt, con lo cual serán ventajas o desventajas según cada cual. Por ejemplo, el hecho de que los datos que uno almacena en la nube estén alojados a la vez en lugares diferentes planteará un problema de cumplimiento con las leyes de protección de datos, puesto que será posible que los datos estén no sólo en tu país, sino en otros donde el proveedor de cloud hosting tenga infraestructuras. O el hecho de que los datos estén custodiados por un tercero que se define como objetivo, hace que te cuestiones de quién te fías más: si de ese tercero, o de tus propias infraestructuras y tus propios administradores de sistemas, como nos hacen ver los que saben de verdad.
Habrá que estar atento a ver cómo sigue esta nueva línea de documentación de NIST. De momento, está bien como recopilatorio, aunque tampoco nos han contado nada realmente nuevo: más o menos las mismas ventajas y riesgos salen hasta en wikipedia.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
miércoles, 29 de julio de 2009
Dos utilidades básicas
Siempre tenemos muchas noticias sobre herramientas de seguridad de mil clases y tipos, y es imposible (además de poco innovador) hacer un post cada vez que sale una, salvo que sea novedosa o particularmente relevante. Hoy toca un pequeño post por darse el segundo caso, pues ha habido novedades en dos imprescindibles: Nmap y SQLMap. Ambas forman parte de la caja de herramientas imprescindibles de todo aquél que se dedique a tests de intrusión.
Nmap, por excelencia una de las herramientas imprescindibles para el análisis de red y servicios, ha incluido numerosas mejoras (aunque como nos dicen en SecurityByDefault, de muchas cosas ya disfrutábamos desde versiones anteriores), entre las que se incluyen: motor mejorado, libro sobre la herramienta (parte de él está gratis en Internet, si lo quieres entero hay que comprarlo), la herramienta Ncat para hacer las funciones de la ya antigua netcat, y NDiff para poder comparar dos escaneos y ver las diferencias (útil para administradores de sistemas y departamentos de seguridad, que han de hacer una vigilancia continuada). Además, y aunque no sean exclusivas de esta versión, hay dos mejoras que me gustan mucho: el interfaz gráfico mejorado Zenmap, y los scripts NSE, que incluyen muchísimas utilidades.
SQLMap es imprescindible en la realización de test de intrusión sobre aplicaciones web, para explotar vulnerabilidades de inyección SQL, razón por la que la suite w3af la utiliza. Hace unos días se publicó la versión 0.7 (publicitada vía mensajes a diversas listas de correo, entre otros medios), y por lo que veo en el Changelog, los últimos cambios son para dar estabilidad a la herramienta, e incluir numerosas mejoras que permiten aprovechar mejor la integración con metasploit, entre otras cosas. Su autor, B.Damele, es un crack en esto del hacking web y en particular de la inyección SQL, como muestra, se puede ver su material sobre el tema.
¡Que aprovechen!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
miércoles, 15 de julio de 2009
pwnie awards 2009
Me han gustado en las dos ediciones que han hecho ya, y en unos días tendremos la tercera de las Pwnie Awards (o los Oscar de los Haxor) Es una ceremonia, concurso, o ranking, como queramos llamarlo (aunque no signifique lo mismo) sobre lo que ha acontecido en el mundo del hacking durante un año. Buscando lo bueno y lo malo de lo que haya salido, estas son sus categorías:
- Pwnie for Best Server-Side Bug
- Pwnie for Best Client-Side Bug
- Pwnie for Mass 0wnage
- Pwnie for Most Innovative Research
- Pwnie for Lamest Vendor Response
- Pwnie for Most Overhyped Bug
- Pwnie for Best Song
- Pwnie for Most Epic FAIL (new for 2008)
- Pwnie for Lifetime Achievement (new for 2008)
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
lunes, 13 de julio de 2009
Owasp Testing en español
Un post rápido para decir que acaba de ser publicada la traducción al castellano de la guía de pruebas web Owasp, versión 3 (Owasp Testing Project). Con el tiempo, esta guía se ha conformado como el estándar de facto a seguir para la realización de test de intrusión sobre aplicaciones de web, por lo que su disponibilidad en español es sin duda una buena noticia.
Kudos para el grupo de Owasp Spanish, que se encarga de la traducción al español de las guías de Owasp.
Kudos para el grupo de Owasp Spanish, que se encarga de la traducción al español de las guías de Owasp.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 25 de junio de 2009
Plan de Ciberseguridad
Me ha gustado leer esta noticia: España defenderá un plan de ciberseguridad a lo Obama en Europa. El titular es quizás un tanto sensacionalista, pero que se den este tipo de iniciativas es en cualquier caso importante. En el blog de F.Lavilla, senador que planteó esta propuesta en el Senado, hay más información. Resumiendo, parece que son tres propuestas:
- impulso de un plan europeo de ciberseguridad, aprovechando la presidencia de España en la Unión Europea
- creación de un plan nacional en ciberseguridad, que sirva de referente
- creación en Inteco de un laboratorio de certificación de sistemas de gestión de infraestructuras críticas que permita elaborar un catálogo de empresas y productos certificados, tanto de España como de la Unión Europea
Algunos enlaces:
Europapress
Economist
IDG
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
lunes, 8 de junio de 2009
Seguridad en Struts
¡Buenas a todos!. Como prometí hace ya bastantes días voy a tomar de nuevo algo más de actividad en "Informático y Segurata", que he tenido algo abandonado en los últimos tiempos. El trabajo y algunas otras cosillas no me dejan mucho tiempo para trastear y escribir en el blog, aunque espero que la cosa cambie.
Últimamente ha salido bastante material interesante sobre desarrollo seguro en el sitio web de OWASP. Hace ya un par de semanas se celebraron las conferencias Appsec Europe Conference y hay muchísimas cosas fresquitas para ir leyendo y mirando sobre desarrollo seguro. Pero no es esto lo que quería destacar, sino un trabajo de un grupo menos conocido, el Intrinsic Security Working Group, que ha realizado un estudio sobre los mecanismos de seguridad disponibles en Struts 2, y cómo ampliarlos.
Es una práctica habitual recomendar, como opción predeterminada, el uso de los mecanismos de seguridad que ofrezca el framework sobre el que se desarrolla una aplicación. Es una cuestión de sentido común: mejor no reinventar la rueda. Sin embargo, conviene estudiar cuáles son estos mecanismos, pues es posible que no sean completos. Este estudio compara Struts 2 con OWASP ESAPI, en cuestiones como autenticación centralizada, validación de entrada o defensa contra XSS (por poner tres ejemplos). Altamente recomendable :)
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
martes, 12 de mayo de 2009
Blogs de seguridad informática
¡Buenas a todos!. Hace unos días los amigos de SecurityByDefault nos proponían una lista de blogs para leer sobre seguridad informática, en el que se incluía el de un humilde servidor, animándome a escribir más. Muchas gracias por el detalle ;) . Yo también quiero colocar mi lista con algunos de los que yo leo de habla hispana, sólo 10 para no hacer una lista muy larga. Aquí van:
- SecurityByDefault (cómo no)
- Apuntes de seguridad de la información
- Seguinfo
- Kriptópolis
- SergioHernando
- El lado del mal
- Port666
- Lobosoft.es
- "Todo es seguro" de GigA
- Gurú de la informática
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
jueves, 5 de marzo de 2009
Más de SSLStrip
Hace unos días hacían una pequeña entrevista al Sr. del SSLStrip. Está en Youtube, aquí la dejo también:
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
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:
- 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
- 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
- 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
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
- 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)
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 .
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...
Suscribirse a:
Entradas (Atom)