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…

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???

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 1, 2, 3, 4
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

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“

En definitiva, siendo la valoración un ejercicio completamente arbitrario conviene conocer las implicaciones de valorar cada dimensión. Así que he perdido un rato ordenando los controles de forma que tenga claro qué significa cada incremento en la valoración para cada dimensión.

Os recuerdo que la valoración de activos del ENS se efectúa en base a cinco dimensiones: [I] Integridad, [C] Confidencialidad, [A] Autenticidad, [T] Trazabilidad, [D] Disponibilidad. La categoría final del sistema será el máximo valor de estas dimensiones.

Posteriormente, los controles aplican en función de la categoría del sistema o de su valoración para alguna de las dimensiones. Así que, cuando valoras alguna dimensión de nivel medio, tienes que cumplir todos los controles que tienen definidas medidas para categoría media y aquellos que, específicamente, tienen definidas medidas para valoración media de dicha dimensión.

Tened en cuenta que cuando se asigna un valor distinto de bajo (o sea medio o alto) pueden ocurrir dos cosas:

• Que una medida existente tenga que cumplirse de forma ampliada o más estricta
• Que haya que aplicar una nueva medida

En estos casos, la única necesidad es la navegación por Internet de los que se conectan. Pero nos encontramos con dos condiciones de contorno interesantes y opuestas

• Los ‘visitantes’ tienen que poder acceder fácilmente, sin demasiadas trabas
• Debe reducirse el riesgo de intrusión en las redes de la organización a través del acceso inalámbrico

En estos casos, ‘la mejor solución‘ es contratar un ADSL adicional y mantenerlo separado del resto de redes de la organización. Entonces, la red inalámbrica se deja abierta (sin autenticación ni trazabilidad) porque, al no estar conectada a la red de la organizacion, ya no hay peligro, ¿verdad?

Bueno, obviamente, sigue existiendo riesgo. Tal y como funciona TCP/IP, si consigues estar en la misma subred que ‘una víctima’, es posible tener éxito en ataques sencillos y con gran impacto (desde simplemente análisis de tráfico a suplantación de equipos, del DNS e, incluso, intrusión aprovechando vulnerabilidades del equipo).

Además, es mucho más fácil suplantar al propio AP si no se utiliza ningún tipo de cifrado.

Si consideramos que las ‘víctimas’ pueden ser miembros de la organización que están en salas de reunión, salones de actos, bibliotecas, etc. pues el riesgo tiene peor pinta.

Por no hablar de la posibilidad de que se realicen ‘malas acciones’ desde el ADSL que está a tu nombre.

En fin, no quiero tampoco extenderme mucho con este tema, es sólo para hacer notar que el hecho de que una red no se encuentre conectada a la organización no implica mágicamente que ya no haga falta mantener unos niveles mínimos de seguridad.

Y aunque sea engorroso, es siempre mejor que, quién se quiera conectar, tenga que pedirlo. Dejar una red (inalámbrica o no) abierta suele ser una mala idea.

Desde lo del IKEA le tengo ganas a cualquier quiosco que pillo y siempre intento meterles mano. He pillado alguno más que no puedo contar porque son de clientes (algunos pagados y otros de buen rollo).

En particular, este que os cuento hoy ha sucedido esta mañana en unas oficinas de un organismo nacional del que prefiero mantener el anonimato.

El quiosco en cuestión está en la puerta para expedir los tiques de turno para ser atendido. Nada más verlo te das cuenta de que es un Explorer con una web.

Pues la cosa es que dándole varias veces en la esquina con el dedo así rápido conseguimos sacar el menú de imágenes del Explorer. A partir de ahí, es posible acceder al navegador de ficheros pulsando el último icono (que te lleva a ‘mis imágenes’), que te muestra también la barra de Windows.

Aquí os dejo una foto del hecho. Observad que se trata de Windows XP con servicios Novell y, al menos, tiene instalado el MySQL -Front. Este software es gracioso porque, según su descripción es:

MySQL-Front es una sencilla pero útil aplicación diseñada especialmente para desarrolladores que trabajan con MySQL.

Desde el primer momento en el que empiezas a usar este administrador descubres su facilidad para obtener información sobre las bases de datos, tanto de sus tablas como de su estructura y contenido.

Todo ello desde un interfaz muy intuitivo que recuerda bastante a la estructura del Explorador de Windows.

Con MySQL-Front se pueden realizar acciones básicas como añadir, borrar o modificar tablas, campos, registros, y además:

No parece muy necesario en un quiosco… Lo que me sorprende también es que tiene un software de quiosco… pero vamos, no parece ser muy efectivo contra acceso al sistema operativo.

Por cierto que, os estaréis preguntando… ¿pero tenia conexión a Internet? ¿Se podía acceder a otros equipos del organismo? ¿Qué privilegios tenía vuestro usuario? ¿Era parte del dominio? ¿Presume un pájaro cuando vuela? ¿Ha visto usted algún marciano?

Pues la verdad es que… ni puta idea. Lo primero es que el cacharro no tiene teclado físico. Así que por aquél entonces no sabía como lanzar uno virtual (parece que Windows XP trae un ‘on screen keyboard’ que puede lanzarse mediante el comando OSK).

Y lo segundo es que no paraba de entrar gente a por su turno y así no había manera de probar nada.

Por lo tanto, si vuelvo a ir ya os contaré, siempre y cuando no esté la cosa saturada de peña, que si no…

Para terminar, un poco de moralina. Y es que no se pueden tener quioscos así desprotegidos porque afectan a la seguridad de toda la organización y, en muchos casos, es trivial saltarse la protección del ‘modo quiosco’.

Y en este caso en concreto, ¿de verdad es necesaria una página web y un windows XP para cuatro botones que escupen un turno secuencial?

Como podréis imaginar, los resultados no han sido muy buenos. Os resumo lo que he encontrado. No voy a dar nombres aquí, aunque si alguno tiene interés que me haga un DM en twitter y ya veremos.

La buena noticia es que, todavía, no hay mucha información sensible en los colegios que tenían vulnerabilidades. Pero eso no es ningún consuelo si imaginamos que la inclusión de nuevos servicios e información probablemente sea más rápida que la adopción de nuevas medidas de seguridad.

Colegio 1

Colegio privado bilingüe de renombre y bastante caro para gente exclusiva. Su web da un poco de pena porque parece traída directamente de los 90.

Se nota que está hecha a mano y que no utilizan ningún framework o software a medida. Está hecha en PHP. Nada más ver algunos de los enlaces nos podemos hacer una idea del problema: http://colegio1.com/index.php?main=datos/pollos.php

El contenido de la URL indicada en el parámetro main es empleado para poblar un iframe en la página resultante. Como podéis imaginar, modificandolo podemos hacer que muestre cualquier otro sitio. Y además, no sólo permite http://, podemos hacer que sea javascript: o data:

Una vez podemos ejecutar javascript en el navegador de alguien desde un sitio que no es nuestro, lo que podemos hacer depende de nuestra imaginación. Por ejemplo, phishing, desacreditación, SPAM, etc.

O mejor aún, ejecutar BeEF sobre el cliente y convertirlo en zombie. Desde BeEF es posible controlar el navegador del usuario e, incluso, explotar vulnerabilidades en el navegador, Flash o Java.

Echad un ojo al BeEF y decidme si os parece que el XSS no es importante.

Colegio 2

Otro colegio privado bilingüe muy afamado y de difícil acceso. De apariencia su web es mucho más moderna y cuidada con un diseño más profesional. Está desarrollada en PHP.

La web es informativa excepto por una sección de acceso privada (con usuario y contraseña) y un formulario de envío de datos. El formulario de envío de datos te deja enviar un mensaje a distintos departamentos.

Echando un ojo al código HTML nos encontramos la direcciones de correo a las que se envía el mensaje (para cada departamento) y el mensaje que se envía. Si cambiamos esos datos… ¡sorpresa! el formulario envía el correo a quién queramos con el mensaje que queramos desde la cuenta info@colegio2.com.

Por lo tanto, podemos suplantar al colegio con comunicaciones falsas personalizadas (si conocemos a alguien con niños en el colegio) o podemos emplearlo para enviar SPAM, ataques de phishing o cualquier otra idea maligna que se nos ocurra.

Se ve que los que han hecho la web no han pensado en la posibilidad de que se puedan usar comillas simples. Asi que si incluyes una, cierras el ‘string’ y puedes insertar comandos en el software que envía los mensajes.

Respecto a la autenticación de usuarios, pasa lo mismo. Con poner una comilla ya ves que hay SQLi. El clásico ' OR 1=1; -- te permite entrar como el primer usuario a la zona privada.

Colegio 3

El tercer colegio es un centro privado concertado normalito. Su web es simple, está desarrollada en PHP y tiene un menú en Flash para diferentes secciones.

No parece tener nada dinámico ni de acceso a simple vista. De hecho, varias secciones aparecen vacias o con ‘noticias de prueba’.

Sin embargo, probando la URL http://colegio3.com/admin nos encontramos un formulario de acceso para administración. Probando el clásico admin/admin podemos entrar como el único administrador de la plataforma. Nos permite crear usuarios, publicar noticias, poner texto en secciones, etc.

Colegio 4

Colegio privado de fama local sólo para infantil y primaria. Su página está desarrollada toda en Flash con un diseño rayante y, en mi opinión, poco efectivo.

Lo primero que notas es que el fichero Flash es colegio4_web2.swf por lo que si pruebas colegio4_web.swf puedes ver la version anterior.

En este caso, no hay nada demasiado grave en la versión anterior, aunque sí gracioso. Aparece una sección sobre webcams que no está en la nueva web. Lamentablemente esta sección indica que las webcams no son accesibles debido a que no hay consenso entre los padres.

En la nueva web, nos encontramos con una sección privada que pide ‘una contraseña’. Analicemos el código, a ver qué hace.

Empleando la herramienta flare, como vimos recientemnte, podemos ver el código del fichero colegio4_web2.swf. Resulta que hace dos peticiones de ‘carga de variables’, una a acceso.php y otra a datos.php.

Al parecer esto es bastante común en Flash. La aplicación carga un conjunto de variables de una web mediante una petición HTTP. Por supuesto, haciendo lo mismo podemos obtener y analizar tranquilamente esa información que suele ser del tipo clave1=valor1&clave2=valor2, etc.

Esto puede exponer información adicional y desvelar URLs internas. En el caso de este colegio (solicitado datos.php), podemos obtener las URLs de todas las fotos publicadas en la web. Por otro lado, acceso.php espera recibir una contraseña como valor y devuelve un conjunto de variables donde indica si la contraseña es váilda y el tipo de acceso que tiene. Así que, para pervertir al Flash, sólo hace falta capturar esa petición y modificarla como si tuviéramos acceso a todo.

Lamentablemente, en este caso no parece que haya mucha información, no estoy seguro de si es porque está sin terminar o porque hay que hacer algo más que se me ha escapado. Pero no deja de ser curioso este sistema que ‘no parece muy seguro’. Además, da la impresión de que cada ciclo formativo tiene una contraseña distinta, no por usuario.

En fin, esperemos que no activen las webcams con este nivel de seguridad.

Discusión

Estuve viendo webs de otros colegios a los que no pude sacar nada con el tiempo y conocimientos limitados que tengo. Es curioso porque estos centros usan Drupal, WordPress o la plataforma educativa Helvia (presente en los centros TIC aunque no siempre expuesta al exterior). Parece que utilizar un software ya hecho da más garantías que que te lo hagan de cero.

Eso sí, en ningún caso he visto HTTPS y en casi ninguno páginas de error personalizadas

Estoy seguro de que alguna vulnerabilidad tendrán, pero habrá que dedicar mucho más tiempo y esfuerzo. He de decir que estas pruebas las hice en un ratillo empleando únicamente curl y, en algunos casos, sqlmap. No he lanzado ningún analizador web automatico, que igual podría dar con otros problemas.

En cualquier caso, quiero resaltar la importancia de pensar un poco en la seguridad en el diseño antes de cometer estos errores tan tontos y de la importancia de revisar lo que se ha hecho.

Si además consideramos la situación actual de la tecnología web con sus múltiples posibilidades y sutilezas (pronto hablaré algo más de esto cuando termine The tangled web) la tarea se convierte en algo improbable.

Y si encima consideramos la situación de la mayor parte de los equipos de desarrollo (personal externo, rotación, becarios e inexpertos, variabilidad de requisitos, etc.) pues os podéis imaginar dónde acaba la seguridad.

Por eso, os dejo el primer lunes desmotivador de este año, para empezar con buen pié esta nueva vuelta alrededor del astro rey.

Tened en cuenta que desarrollar una aplicación que tiene que ejecutarse en un entorno de producción e interaccionar con un conjunto de servicios no tiene nada que ver con simplemente ‘programar’ en un lenguaje de programación.

Asombroso es también la diferencia entre lo que se gasta en hacer un sistema de información (podéis tirar de los números públicos) y lo que se gasta en analizar y corregir defectos de seguridad.

Sin embargo, debido a la importancia de esta legislación, no está entre sus objetivos el derogarla ni modificarla (después de lo que ha costado). Por lo que han propuesto una curiosa medida para solucionar la situación.

Cada organismo podrá decidir qué tres medidas de las 75 presentes en el ENS no va a cumplir y deberá reflejarlo en la declaración de aplicabilidad. “De este modo se promueve la libertad particular de cada organismo a la vez que se cumplen la mayor parte de los controles del ENS“.

De hecho, esta medida no es nueva, ya se aplica de facto en el cumplimiento de la LOPD donde la mayor parte de las entidades decide no cifrar los datos de nivel alto, no registrar su acceso o, por ejemplo, abandona para siempre la ilusión de gestionar los soportes de información.

Ahora queda la tarea de pensar bien qué tres medidas son las que no se cumplen, porque lo que se decida ya es para siempre. Ya que bien se indica que “lo que no vale es ir cambiando cada dos por tres“.

¿Cuáles quitarías tú?