Mar 26 2012

Nuevo informe de incidentes DBIR 2012

chmeee

A menos que hayas vivido en una isla los últimos ocho años te sonará el informe de incidentes (o robo de datos) que Verizon realiza cada año comúnmente conocido como DBIR (Data Breach Investigations Report).

El informe 2012 (con resultados de incidentes de 2011) ya está disponible para vuestro deleite.

Estos señores analizan los incidentes ocurridos durante 2011 y extraen conclusiones (¡y métricas!) para ayudarnos a comprender cómo ocurren y cómo evitarlos.

El informe tiene una cuidada composición y una perfecta elección de gráficas. Incluso me gusta el pie chart que han usado.

El año pasado tuve un post en borrador durante un tiempo a la espera de terminar de leerlo y, al final, ni terminé de leerlo ni terminé el post. Como no quiero que pase lo mismo este año, os animo a que lo leáis y seas iluminados por su sabiduría.

Para ir abriendo boca os adjunto una de las métricas resumen iniciales donde se pueden apreciar algunas conclusiones que no tienen precio.

Fijaos que información más golosa para concienciar a vuestros superiores. La mayoría de los ataques no fueron complicados y podrían haber sido evitados con medidas simples de seguridad. Medidas que ni siquiera están presentes en muchas organizaciones.

¿Y qué hay de la monitorización? La mayor parte de los incidentes no se detectó en semanas y además los detectó un tercero. De ahí que cuando se oye que alguien dice “nosotros no hemos tenido incidentes” uno piensa “que te hayas dado cuenta”.

Lo del cumplimiento, pues eso. Llevándolo a un tema más cercano ¿quién cumple la LOPD o el ENS? Igual eso tampoco te protege, pero hay que reconocer que las medidas de seguridad que requieren son bastante razonables y ni por esas se encuentran implantadas.

En fin, no os quedéis sólo con esto y echad un vistazo al informe que no tiene desperdicio.


Mar 25 2012

Paranoia bancaria

Pirri

Estaba yo trabajando duro a la hora de la siesta, cuando recibo una llamada que me saca de un profundo sueño mi estado de concentración mental. Es un número de esos raros, me quieren vender algo fijo. Normalmente no descuelgo, pero ese día tenia ganas de marcha:

Operadora: Buenos tardes señor, me llamo Ampari y llamo de OpenBank.
Yo: A las buenas.
Operadora: le llamo para ofrecerle un producto chachipiruli. ¿Le interesa?
(....aquí viene mucho palabrerio del tipo "no me lo creo", "que si señor que es verdad", etc etc.)
Yo: bueno, vale, acepto, vamos a contratarlo.
Operadora: muy bien señor, necesito su clave de acceso.
Yo: ¿cualo?
Operador: su clave de acceso a la web, para poder acceder a sus datos.
Yo: ¡y una mieeeeeeeeeeeerda! (aquí entré ya en modo paranoico)
Operadora: Señor, no pasa nada por que me de la clave de acceso, para operar se utiliza la de firma y no la de acceso.
Yo: si si, ya ya, vas tu lista.

En fin, la cosa se alargó un poco más antes de colgar. Por supuesto, la clave no se la di. Y además, les dejé un mensaje-protesta en su twitter, al que respondieron diciendo que “piden la clave de acceso por seguridad”. Obviamente, respuesta estándar del pobrecillo que estaba encargado de la cuenta twitter.

Quizás alguno piense que no tiene nada de malo darle la clave de acceso a la primera operadora que te llame a la hora de la siesta (¿llamarán a esa hora para pillarte con la guardia baja?). Pero yo a esto le veo una serie de problemillas así sin importancia:

  1. Todos los que trabajamos en seguridad no paramos de decir “no le des tus claves a nadie”, “la clave es personal e intrasferible”, “tu banco jamás te va a pedir tus claves”…..¡y ahora resulta que va el banco y te la pide!. Ala, a tomar por culo años de adoctrinamiento (porque todo el mundo sabe que la operadora sabe mucho más de seguridad que el friki de la empresa, asi que…¿a quién van a hacer caso?).
  2. Te han llamado ellos a ti, no tu a ellos. ¿Quién te dice a ti que realmente te están llamando de Openbank? Al fin y al cabo al llamar te dan algunos datos personales (nombre, dirección, dni), que son bastante fáciles de obtener. Con tu clave de acceso y tu DNI, la supuesta operadora ya puede ver todo lo que tienes en el banco. ¡¡Esos datos son una mina!! Se me ocurren muchas formas de aprovecharlos.
  3. ¿Quién te dice a ti que la operadora (suponiendo que en realidad lo sea), que seguro que está explotada y tiene un sueldo de mierda, no está anotando esos datos para usarlos en otro momento? (las personas tendemos a confiar en otras personas, pero por ahí hay gente mala, que nadie piense que estoy criminalizando a todas las operadoras del mundo). Por ejemplo, desde la comodidad de un cibercafé, podría intentar acceder a los bancos online más populares en España (somos humanos, todos tenemos la misma clave para varios sitios web). Seguro que en alguno más entra. O le podría dar por comprar productos usando tus datos bancarios.
  4. Vale, aún necesita la clave de firma para poder hacer operaciones. Pero es que con esa información (situación financiera, datos bancarios, dirección postal,número de teléfono, etc.), podría pedir al banco que reseteasen las claves de firma (seguro que todos los datos de verificación que le van a preguntar están entre los que ha conseguido accediendo a la web). Suelen mandarlas por carta, asi que una semanita de interceptar el correo en el buzón y listos (y si han visto con anterioridad que andas “sobrao de euros”, si tienen que acampar debajo de tu buzón, acamparán).
  5. O más fácil, que me lo estoy imaginando:

Operadora: señor, necesito las posiciones 1 y 5 de su clave de firma para contratar el producto chachipiruli (en realidad, está haciendo una transferencia).
Yo: h y p
Operadora: señor, el sistema ha dado un error, ¿puede decirme de nuevo las posiciones 2 y 6?
Yo: i y u
Operadora: señor, el sistema ha vuelto a dar un error, ¿puede decirme de nuevo las posiciones 3 y 7?
Yo: ofú con el sistema, vaya mierda ¿no?. Venga va, j y t
Operadora: señor, se que le estoy incordiando mucho, pero sigue sin funcionar, ¿le parece que hagamos un último intento?, ¿puede decirme las posiciones 4 y 8?
Yo: joooooerrrrrrrrrrr, la a y la a
Operadora: gracias señor, ya le he desplumado contratado el producto chachipiruli (y cuelga).

 

¿Paranoia? Pues no lo se, pero ataques de ingenería social más raros he visto/leido.

En fin, que no me ha gustado nada, pero nada, la operativa de Openbank. Es más, estoy planteándome muy pero que muy seriamente mover mis millones y millones de euros a otro banco. Asi que a los que esteis leyendo esto, si alguna vez os llama una operadora de (supuestamente) Openbank, NI SE OS OCURRA DARLE VUESTRA CLAVE.  Algunos consejos generales:

  1. Nunca le deis vuestras claves a nadie, nunca, bajo ningún concepto. Ni del banco, ni del correo, ni de vuestro diario de la “señorita pepis”.  Se que no tengo el mismo poder de convicción que una operadora bien adiestrada, pero ahi queda eso.
  2. Si os piden “la posición X e Y de  su clave de firma”, aseguraos de que X e Y sean siempre el mismo.
  3. Si os interesa lo que os ofrecen, contratadlo por vuestra cuenta desde la web del banco, tecleando la dirección web por vosotros mismos, ni se os ocurra entrar en una dirección que os manden por correo u os digan por teléfono.

 


Mar 19 2012

Lunes desmotivador (XIV): consultoría de seguridad

chmeee

Aprovechando que entra la primavera vuelve el afamado lunes desmotivador para hundiros en la más profunda depresión de la que saldréis mucho más concienciados que de cualquier charla motivadora positivista.

Hoy toca desmotivar sobre la consultoría de seguridad, ese arcano arte de interpretar una situación compleja desde el punto de vista de seguridad y convertirla en algo que entienda el cliente y que le motive a tomar acción.

Cuando digo cliente me refiero al destinatario de la consultoría de seguridad que debe tomar decisiones, independientemente de si es tu jefe, el responsable de otra unidad o tu cliente en una relación profesional.

La complejidad está en escapar del “¿y qué?” sin llegar a caer en el sensacionalismo y el meter miedo excesivo ni tampoco acabar dando la impresión de que todo es una puta mierda pero no decir que están bien porque entonces igual no hace nada… En fin, los que hayáis hecho esto alguna vez sabréis de qué hablo.

Recordad siempre sustituir palabras negativas por positivas (programación neurolinguista, como diría alguno que yo me sé). Por ejemplo: problema -> desafío, carencia -> aspecto de mejora y cosas así.

En definitiva, disfrutad del lunes desmotivador de esta semana.

Una puntualización sobre la cita anterior. Siempre trato de ser absolutamente fiel a las palabras empleadas en la versión española de la película. Incluso he llegado a descargarme la película para capturar la pantalla y ver exactamente qué dice en español.

En este caso, sin embargo, he hecho una excepción porque la traducción de la película en español es francamente chorra “Este trabajo lo fastidian los malditos clientes“. Cuando en inglés es “This job would be great if it weren’t for the fucking customers“. Así que he puesto una traducción propia que creo que ejemplifica mejor la intención original.


Mar 14 2012

Calculando el CAPTCHA de la AEPD

chmeee

La nueva herramienta de la AGPD para disposiciones de ficheros de Titularidad Pública DISPONE, Como veis, abajo parece que para usarlo hay que resolver una compleja suma (¡¡¡de dos dígitos!!!).

Ya he visto otras veces este tipo de acertijos como CAPTCHAs que se agradecen frente al típico borrón que tienes que intuir y que cada vez me cuesta más.

Sin embargo, parece como que sería muy sencillo de insertar automáticamente, ¿no?

Veamos cómo. La operación es siempre una suma con números. O por lo menos todas las peticiones que he hecho daban como resultado una suma.

La suma es una imagen con la siguiente URL  http://www.servicios.agpd.es/Dispone/seam/resource/captcha por lo que habrá que pasarla primero por un OCR y luego efectuar el cálculo.

Para descargar la imagen usaremos curl, para extraer la suma a texto usaremos gocr y para efectuar el cálculo usaremos bc. Para calcular la suma eliminamos el igual de la operación y hay que tener cuidado porque el OCR no identifica bien el signo negativo. identifica un ‘_’ y habrá que convertiro a ‘-’.

Armados con esto, la línea para realizar el cálculo es la siguiente.

curl -sLk http://www.servicios.agpd.es/Dispone/seam/resource/captcha | convert jpg:-  pnm:- | gocr -i - | tr -d = | tr _ - | tee suma | bc -l

El tee nos guarda la suma en un fichero para que podamos verla después y comprobar la operación.

En fin, que quién iba a querer spammear esta aplicación, no lo sé, pero ha sido divertido automatizar el cálculo.


Mar 13 2012

Imprimiendo inseguridad

chmeee

Recientemente he tenido ocasión de analizar redes de clientes donde había expuestas multitud de impresoras de diversas marcas y he estado investigando un poco sobre el tema. Os comento brevemente lo que he averiguado sobre la configuración habitual de estos equipos y sus implicaciones para la seguridad de la organización.

Aunque digo impresoras, realmente, en algunos casos se trata de equipos multifunción que hacen no sólo de impresora sino también de fax, escáner, fotocopiadora, máquina de café, sandwichera y picadora.

Servicios

Antes de nada, veamos qué ofrece una impresora cualquiera.

Como podéis ver, hay un conjunto considerable de servicios ofrecidos para diferentes métodos de impresión y de acceso. Como yo no soy un experto en impresoras me centraré en los protocolos que sí conozco y son los que me interesan:

  • ftp: acceso para la subida directa de ficheros que serán imprimidos por la impresora.
  • telnet: interfaz de configuración en modo texto. Se trata de una pequeña shell con los parámetros de configuración y consulta de estado.
  • http/https: interfaz web de configuración. Son los mismos parámetros que en la interfaz telnet pero para quien prefiera el navegador.
Sobre el acceso FTP es interesante conocer que algunas impresoras permiten realizar escaneos de puertos mediante el uso de la directiva PORT de las impresoras. Con el script ftp-bounce de nmap podemos identificar si un servidor FTP lo permite.

En el caso de que el servidor lo soporte, es posible, mediante nmap, realizar un escaneo empleando el servidor FTP: nmap -b servidor_ftp servidor_destino

Acceso

Normalmente, las impresoras te dejan ver su configuración sin necesidad de disponer de credenciales de acceso. Sin embargo, para configurarlas es posible establecer una contraseña de administración, aunque la experiencia me dice que no es común cambiar la que traiga por defecto, si es que traen.

Cuando encontréis una impresora con contraseña, buscad en vuestra lista de contraseñas por defecto favorita y probad a ver si es que no han cambiado la contraseña por defecto.

Por ejemplo, algunas de las que me he encontrado recientemente:

  • Impresoras HP: no suelen tener contraseña
  • Impresoras Kónica/Minolta: la contraseña de administración por defecto es 12345678
  • Impresoras Canon: normalmente sin contraseña
  • Impresoras Ricoh: la contraseña del usuario admin está en blanco por defecto
  • Impresoras Brother: las credenciales de administración son ‘admin/access’
  • Impresoras Kyocera: normalmente sin contraseña
  • Impresoras EPSON: normalmente sin contraseña
  • Impresoras OKI: la contraseña del usuario admin son los 6 últimos dígitos de la MAC (que puedes obtener sin necesidad de autenticación)
  • Impresoras Lexmark: normalmente sin contraseña
  • Impresoras Printronix: la contraseña del usuario admin está en blanco

Esto es mi experiencia reciente en los modelos que he encontrado, para más información véase el manual del modelo correspondiente o las susodichas listas de contraseñas por defecto.

Registro

A través de la interfaz de configuración es posible acceder al registro de impresión donde, si tenemos suerte, veremos nombres de usuario, otros equipos de red y los nombres de los documentos imprimidos.

En el caso particular de las impresoras Ricoh, que disponen de un Document Server, podemos ver algunos documentos almacenados (como imágenes) en la propia impresora.

Posibilidades

Bueno, pues ahora que puedo acceder a administrar una impresora… ¿qué puedo hacer que sea relevante desde el punto de vista de seguridad? O, dicho de otro modo, ¿cómo puedo putear? Os adjunto un listado de posibles acciones sencillas con las que dar por culete al que se ha dejado la impresora sin proteger:

La primera cosa que se puede hacer es, por supuesto, imprimir. Esto puede ser una chorrada evidente. Pero considerad que hay veces que la impresora está gestionada por un servidor de impresión con software dedicado a controlar (restringir, registrar) la impresión. Si la impresora permite imprimir por jetdirect, ftp o desde la propia interfaz web… probablemente nos saltemos estas restricciones y registros.

Ahora bien, consideremos que, realmente, podemos imprimir cualquier cosa, no sólo documentos. Haciendo un volcado de nuestro disco duro a la impresora nos aseguramos una denegación de servicio y un gasto de papel considerable.

Por otro lado, dado que la mayor parte de las impresoras no tienen asignada la contraseña de administrador, podemos asignar una contraseña y forzar a que tengan que volver a ‘factory default’ para reconfigurarla. Si esto lo hacemos en un número interesante de impresoras podemos incurrir en un coste interesante en mantenimiento y pérdida de funcionalidad.

Modificando la configuración de los parámetros de impresión podemos volver loco a más de uno, que pensará que se trata de una mala configuración del Word.

Una cosa que no he probado nunca es a pedir suministros a través de la propia impresora. En algunos modelos, existe la opción de enviar un informe de estado de la impresora y solicitar suministros… De hacerlo, no sé qué pasaría.

Si queremos que no se pueda imprimir, siempre podemos cambiar la configuración de red de la impresora o suprimir  servicios de impresión.

Pero lo que me parece más divertido es la posibilidad de modificar la configuración de red de la impresora para interferir con otros sistemas. Por ejemplo, podemos ponerle a la impresora la dirección IP del router por defecto, provocando un conflicto de direcciones IP que afectará a los que se encuentren cerca. O ponerle la dirección IP de cualquier otro servicio al que queramos afectar. Me imagino cuándo y cómo se darán cuenta de que se trata de la impresora.

Conclusiones

La verdad es que todo esto viene porque un cliente en particular tiene un conjunto considerable de impresoras expuestas a Internet, por lo que el riesgo es mucho mayor que en otros casos. Por lo tanto, la primera conclusión, visto lo visto, es no exponer las impresoras a Internet (no puedo pensar en ninguna razón para hacerlo).

La segunda conclusión es que es bastante recomendable ponerle una contraseña a la impresora para administración o sustituir las que vengan por defecto. Las contraseñas asignadas pueden ser almacenadas en algún repositorio cifrado para que la comparta el personal de microinformática, por ejemplo.

Por aquello de reducir la superficie de exposición y evitar que exploten vulnerabilidades en servicios que no usas, merece la pena perder el tiempo en analizar la funcionalidad de la impresora y reducir los servicios expuestos que no sean necesarios.

Respecto a la situación de las impresoras, es práctica habitual que se encuentren en el mismo segmento de red de los usuarios, aunque no hay nada que impida ubicarlas en su propio segmento de red con reglas del cortafuegos para evitar que usuarios no autorizados accedan a servicios expuestos que no sean necesarios (en el caso de que no se puedan desactivar o para curarse en salud).

Por otro lado, no está de más monitorizar la impresora. La mayor parte tienen la posibilidad de monitorización mediante SNMP, así que no cuesta nada añadirlas a nuestro Nagios o software similar y monitorizar su estado. Algunas incluso soportan syslog.

También conviene hacer una copia de la configuración por si se desconfigura de forma misteriosa, reducimos el tiempo de volver a ponerla operativa.

En fin, quizá estoy siendo un poco paranoico en este sentido. Aunque desde luego exponer tus impresoras a Internet está totalmente fuera de lugar, normalmente nadie en la red interna suele andar puteando… pero… yo me quedo más tranquilo si tengo todos los cacharros controlados, ¿y tú?

Referencias

Además de lo citado anteriormente, hay otros problemas que podrían provocar denegación de servicio e incluso ejecución de código. Para más información podéis leer este artículo de IronGeek o esta presentación de Andrei Costin.

Por último, si todo esto no te convence, siempre puedes hacer lo que hicieron los protagonistas de ‘Trabajo basura’ y desahogarte de todas las veces que la puta impresora te hizo la vida imposible.


Mar 8 2012

Proyectando inseguridad

chmeee

El otro día por azar encontré una Wi-Fi abierta cuyo ESSID era ‘AirProjector’ o algo similar. Tuve curiosidad y me conecté para ver de qué se trataba.

Resulta que era un sistema de proyección a través de wireless de la empresa Optoma. Mediante un software que te puedes descargar del propio proyector todos los participantes en una reunión pueden proyectar en la pantalla.

Una vez tienes IP, si intentas navegar hacia cualquier sitio te redirige a la dirección IP 192.168.100.10 donde te presenta una página con diversas opciones:

  • Descarga del software para usar el proyector
  • Control de la conferencia, donde se indican los parámetros de cada sesión
  • Administración

Pinchando en administración me encontré con una pantalla de login:

  • Usuario: admin (ya relleno)
  • Contraseña… contraseña… una palabra de 5 letras que rima por admin… ¡ya lo tengo! admin.

Pues sí. Me pregunto cuando dejará de funcionar esto del admin/admin.

En definitiva, en la interfaz de administración puedes cambiar los típicos parámetros de red, las contraseñas, actualizar el firmware y alguna cosa más.

Aunque la contraseña no fuese esa el peligro que tiene un sistema de este tipo abierto es patente. Simplemente suplantando al equipo para la descarga de software o atacando al resto de clientes conectados o un largo etc.

Respecto a la Wi-Fi, sólo soporta WEP por lo que parece fácilmente explotable.

En fin, tened mucho cuidadito con estas moderneces que luego pasa lo que pasa.


Feb 22 2012

Security investigations (Dire Straits)

chmeee

Siempre que empiezo alguna auditoría de seguridad resuena en mi mente el Private Investigations de Dire Straits. Esta canción retrata la investigación de un detective privado y cómo lo que descubre le va afectando emocionalmente.

Como supongo que muchos de los que trabajamos en seguridad nos sentimos identificados con esto, he hecho algunas leves modificaciones en la letra de la canción para incluir elementos de seguridad. Os la dejo aquí:

It’s a mystery to me – the game commences
For the usual fee – plus expenses
Confidential information – it’s in a database
This is my investigation – It will last a few days
I go checking out the reports – digging DNS
You get to know all tools in this line of work
Unhardened services – there’s always an excuse for it
And when I find the reason I still can’t get used to it
And what have you got at the end of the day?
What have you got to take away?
A couple of XSS and a new set of lies
Blind SQL injection and a pain behind the eyes
Scarred for life – no compensation
Security investigations

Os dejo un vídeo de la canción para que podáis escucharla…


Feb 22 2012

Indefensión aprendida y psicoSeguridad de la Información

olyoly

 

 

Hace tiempo que no escribo nada. Disculpadme, motivos personales y profesionales me tienen disperso. Algunos de estos motivos son positivos y otros no tanto. Entre los positivos (como algunos sabéis) está que me matriculé en la UNED para estudiar el grado de Psicología y he estado las últimas semanas centrado en aprobar los primeros exámenes…

Por cierto, en el último examen me encontré con otro de los miembros de nuestro selecto club de la seguridad y las cervezas… así que en la próxima quedada creo que vamos a poder discutir sobre algunos temas interesantes.

Después de este primer semestre se van confirmando mis sospechas: “el enfoque de otras disciplinas puede enriquecer mucho la gestión de la seguridad”.

Como comprenderéis, aun no tengo ni idea de psicología y solo he empezado a sumergirme en algunas de las teorías que componen este marco de estudio científico. Poco a poco voy conociendo conceptos que no puedo evitar relacionar con el día a día de la gestión de la seguridad. Si consigo disponer del tiempo suficiente trataré de compartirlos con vosotros y si algún psicólogo nos lee y ve que digo burradas que arroje luz por favor!!

El de hoy es el concepto de Indefensión aprendida:

Es un proceso que tiene lugar cuando un organismo aprende que sus respuestas y los reforzamientos son independientes, llevando al organismo a un estado de incapacidad percibida de resolver las situaciones de amenaza. La indefensión tendría lugar cuando se pierde el control de las consecuencias del propio comportamiento.

Cuando una persona o un animal se enfrentan a una amenaza o una pérdida, aparece la respuesta de estrés asociada al miedo. Si aprenden que la respuesta no es controlable y tiene lugar la indefensión aprendida, la depresión sustituye al miedo, es decir que las situaciones no controlables generan estrés.

Seguramente el vídeo del principio del post os deje más claro el concepto.

Yo me pregunto si esta teoría explica la conducta de muchos gestores TI que no hacen nada por mejorar la seguridad de sus servicios e información. Sabemos que la seguridad al 100% nunca se consigue y que aunque una organización gestione adecuadamente su seguridad se producirán incidentes. Además en muchas ocasiones los responsables TI no están formados y capacitados para una gestión integral y metodológica de la seguridad, lo que se traduce en acciones puntuales, no planificadas, artificiales y contratadas a proveedores que muestran poco interés en algo que no sea trincar el dinero y salir corriendo al próximo cliente.

En definitiva tenemos personas que dan respuestas (más o menos adecuadas) a amenazas y que perciben que los resultados siguen siendo incontrolables: continúan produciéndose incidentes. Aparece la indefensión aprendida y el miedo/acción se transforma en depresión/inacción/resignación…

Si esto es así… ¿qué sentido tiene que en cada una de las presentaciones comerciales y charlas de concienciación se siga usando el miedo para provocar la acción?

¿¿Le veis sentido o es una paja mental???

 

 


Feb 17 2012

Vota por las principales técnicas de hacking web de 2011

chmeee

Jeremiah Grossman, conocido experto en seguridad web (co-inventor, entre otras cosas, del término clickjacking) abre el plazo de votación de las principales técnicas de hacking web de 2011.

A diferencia del TopTen del OWASP que indica las principales vulnerabilidades en servicios web independientemente del tiempo, este listado muestra técnicas muy recientes y nos ayuda a conocer mejor el engañosamente sencillo entorno de las aplicaciones web.

Sablo aquí el listado de las 51 técnicas de las que se elegirán 15 para tenerlo disponible.

  1. Abusing Flash-Proxies for client-side cross-domain HTTP requests [slides]
  2. Abusing HTTP Status Codes to Expose Private Information
  3. Autocomplete..again?!
  4. BEAST
  5. Bypassing Chrome’s Anti-XSS filter
  6. Bypassing Flash’s local-with-filesystem Sandbox
  7. CAPTCHA Hax With TesserCap
  8. CSRF with JSON – leveraging XHR and CORS
  9. CSRF: Flash + 307 redirect = Game Over
  10. Close encounters of the third kind (client-side JavaScript vulnerabilities)
  11. Cookiejacking
  12. Cross domain content extraction with fake captcha
  13. Crowd-sourcing mischief on Google Maps leads customers astray
  14. DNS poisoning via Port Exhaustion
  15. DOMinator – Finding DOMXSS with dynamic taint propagation
  16. Double eval() for DOM based XSS
  17. Drag and Drop XSS in Firefox by HTML5 (Cross Domain in frames)
  18. Excel formula injection in Google Docs
  19. Exploitation of “Self-Only” Cross-Site Scripting in Google Code
  20. Exploiting the unexploitable XSS with clickjacking
  21. Expression Language Injection
  22. Facebook: Memorializing a User
  23. Filejacking: How to make a file server from your browser (with HTML5 of course)
  24. Google Chrome/ChromeOS sandbox side step via owning extensions
  25. HOW TO: Spy on the Webcams of Your Website Visitors
  26. Hidden XSS Attacking the Desktop & Mobile Platforms
  27. How To Own Every User On A Social Networking Site
  28. How to get SQL query contents from SQL injection flaw
  29. How to upload arbitrary file contents cross-domain (2)
  30. JSON-based XSS exploitation
  31. Java Applet Same-Origin Policy Bypass via HTTP Redirect
  32. Kindle Touch (5.0) Jailbreak/Root and SSH
  33. Launch any file path from web page
  34. Lotus Notes Formula Injection
  35. Multiple vulnerabilities in Apache Struts2 and property oriented programming with Java
  36. NULLs in entities in Firefox
  37. Rapid history extraction through non-destructive cache timing (v8)
  38. Session Puzzling (aka Session Variable Overloading) Video 1234
  39. SpyTunes: Find out what iTunes music someone else has
  40. Stealth Cookie Stealing (new XSS technique)
  41. Stripping Referrer for fun and profit
  42. SurveyMonkey: IP Spoofing
  43. Temporal Session Race Conditions Video 2
  44. Text-based CAPTCHA Strengths and Weaknesses
  45. The Failure of Noise-Based Non-Continuous Audio Captchas
  46. Timing Attacks on CSS Shaders
  47. Tracking users that block cookies with a HTTP redirect
  48. Using Cross-domain images in WebGL and Chrome 13
  49. XSS in Skype for iOS
  50. XSS-Track as a HTML5 WebSockets traffic sniffer
  51. HashDOS: Effective Denial of Service attacks against web application platforms
 Si sólo tuviéramos tiempo para leerlas y entenderlas todas….

Feb 16 2012

El libro de la bruja

chmeee

El libro de la bruja‘ es como llama mi hija al libro ‘The tangled web‘ de Michal Zalewski (también conocido como lcamtuf).

Por fin he terminado este magnifico libro sobre seguridad en aplicaciones web modernas y voy a escribir algunos comentarios al respecto.

Para empezar, os recomiendo encarecidamente este libro si queréis comprender cómo funcionan las aplicaciones web y sus mecanismos de seguridad tanto actuales como los que están por venir.

Dicho esto, debo advertiros de que no se trata de un libro sobre programación segura ni se tratan problemas típicos como la inyección SQL.

Realmente, lo que hace este hombre es explicar la relación existente entre  los componentes de las aplicaciones web (servidor web, protocolo HTTP, navegador) y, sobre todo, se centra en las formas de explotar esa relación.

Así mismo, explica las diferencias de implementación de las medidas de protección en los navegadores. Es fascinante ver lo diferente que se comportan. De hecho, parte del libro surge de su estudio de los distintos navegadores reflejado en el browser security handbook.

Partiendo de la idea de que para poder gestionar la seguridad de un entorno, hay que conocerlo bien (el diablo está en los detalles), el mundo de los navegadores es engañosamente sencillo y, en muchos casos, anti-intuitivo.

Por ejemplo, algo tan sencillo como una URL da para un capítulo completo donde te vas a enterar de cosas que no sabías sobre este aparentemente trillado tema. Desde diferentes modos de codificación de los nombres de dominio a los distintos tipos de ‘scheme‘ (la parte que indica el ‘protocolo’ al principio de la URL) tales como ‘data:‘ Zalewski nos cuenta aquello que nos puede hacer pupita y las diferentes formas en las que gestionan los navegadores la URL cuando se construyen pensando en confundirlos.

Lo más importante del libro quizás sea la explicación de las técnicas de aislamiento que mantienen los navegadores. Principalmente el famoso y mal entendido Same Origin Policy (SOP). Aunque su formulación es muy sencilla, hay un conjunto de detalles a tener en cuenta en función de qué elementos estén implicados.

Zalewski también valora las recientes técnicas empleadas por desarrolladores precisamente para escapar al SOP e intercambiar información entre dominios.

Otro aspecto que me gustó mucho es el tratamiento de frames y contenidos insertados de otros dominios. El libro detalla qué medidas de protección frente a scripts insertados en tu página que provengan de otro dominio y cómo implementarlo de forma segura.

En todo el libro, Zalewski incluye su opinión (en muchos casos cínica y realista) y da una perspectiva de cómo han ido evolucionando los distintos navegadores, qué decisiones han tomado ante determinadas situaciones y cuales se plantean en el futuro.

El epílogo es ciertamente sorprendente y revelador ya que plantea hasta qué punto necesitamos más seguridad en el mundo digital que en el mundo real, mediante analogías de la vida cotidiana donde ‘confiamos’ en muchísimas actividades que realizamos y donde nuestros mecanismos de seguridad son, por así decirlo, imperfectos.

Tampoco quiero extenderme mucho más que no os quiero quitar tiempo de leerlo. Os dejo algunas perlas que me gustaron y que fui registrando en twitter.

All signs point to security being largely a nonalgorithmic problem for now

But despite claims to the contrary, such products are no substitute for street smarts and technical prowess—at least not today

Too often, “by keeping your fingers crossed” is the best response we can give

A whole new class of security vulnerabilities that a taxonomy buff might call a failure to account for undocumented diversity

Inquisitive readers are advised to grab Web Application Obfuscation (…) and then weep about the fate of humanity

If it comes to this, cookies will probably have to be redesigned from scratch” hablando de los TLDs genéricos

Instead, additional, sometimes hopelessly imperfect security boundaries need to be created from scratch