Casi todas las organizaciones tienen alguna forma de hacerles llegar comentarios en la web. En algunos se trata de un simple ‘mailto:‘ pero en otros casos nos encontramos frente a un ‘formulario de contacto‘.

Por otro lado, quizá como un vestigio de la era pre-redes sociales, todavía siguen existiendo formularios de ‘envía a un amigo‘ en muchas páginas.

Quiero compartir aquí algunas experiencias con estos formularios que, si no se hacen bien, pueden presentar ciertos riesgos.

mailbox

El principal riesgo es la posibilidad de envío de correos desde las redes y servidores del afectado de forma automatizada hacia direcciones de correo arbitrarias. Otro riesgo consiste en saturar los destinatarios internos con múltiples consultas a través de estos formularios.

En el primer caso, se puede utilizar para realizar ataques de phishing, con la ventaja de que realmente los mensajes salen de un servidor ‘confiable’.

Veamos algunos errores a la hora de diseñar estos aparentemente inofensivos formularios.

No hay CAPTCHA

Si no hay CAPTCHA o algún mecanismo que limite el uso automatizado, podemos encontrarnos con las situaciones arriba descritas de saturación de buzones internos o, en el caso de que el formulario lo permitiese, envío automatizado de mensajes.

Muchos formularios no lo incluyen porque es un coñazo para el usuario descifrar el CAPTCHA, que cada vez lo ponen más difícil.

El CAPTCHA es repetible

Hay veces, que ya me he encontrado más de una, en las que el CAPTCHA es ‘repetible’. O sea, que el sistema te permite re-utilizar los mismos datos. Normalmente suele ir asociado a que almacenan un hash de la solución en el HTML. Esto es claramente inefectivo y se puede automatizar muy fácilmente.

Nunca se debe confiar en lo que envías al navegador. Siempre tiene que haber algún chequeo en la parte del servidor.

El destinatario puede elegirse

En en caso de ‘enviar a un amigo’, el destinatario puede elegirse y, el problema recae en hasta qué punto es posible manipular el contenido.

En el caso de un formulario de contacto, ya he visto varios en los que puedes elegir al destinatario porque se codifica en campos hidden del HTML.

Se pueden elegir múltiples destinatarios

En algunos casos es posible separar por puntos y coma varios destinatarios, lo que hace que aumentemos nuestros poderes de Spammers. Imaginaos que se puede enviar hasta 50 direcciones… pues os hacéis una idea del peligro, ¿no?

El servidor envía un mensaje automático al remitente

Hay veces que el servidor envía un mensaje automático al supuesto remitente. Como ahí puedes poner cualquier dirección ‘origen’, el resultado es que realmente le estás enviando un mensaje a quién tú quieras.

El contenido puede manipularse

Este es interesante en los formularios de ‘enviar a un amigo’ es importante asegurar que el remitente no puede controlar el texto a enviar. Por ejemplo, me he encontrado formularios que deja poner la dirección de correo origen y el nombre del remitente y lo mismo para el destinatario. En este caso, si no se limita el tamaño del nombre ni se filtra (véase el siguiente epígrafe) resulta que es posible insertar un texto considerable e incluso HTML.

Igualmente, he visto casos en los que el texto estaba en un campo hidden del formulario.

En los casos de formulario de contacto está claro que el contenido debe poder ser manipulado por el usuario, pero hay que tener cuidado en evitar que pueda modificarse el título del mensaje, por ejemplo. En muchos casos, se mete como un campo hidden en el código, por lo que mejoraría nuestra capacidad para crear mensajes falsos.

Se puede modificar el enlace a la página

A veces para el formulario es importante la página origen. Por supuesto en ‘enviar a un amigo’ lo es. En el contacto, puede serlo si se trata de alguna notificación respecto a la página.

En este caso, suele ocurrir que la página se envía en un campo adicional o se toma del Referer y en ambos casos, se puede manipular.

Si se trata de una URL completa, tenemos suerte y podemos sustituirla por otra.

Si se trata de una URL relativa, dependerá de si somos capaces de insertar o no HTML para añadir nuestro propio enlace (véase el siguiente epígrafe).

El contenido no se filtra

Si no se filtra el contenido (aunque sea el nombre del usuario, el enlace, el propio mensaje, etc.) nos encontramos con la posibilidad de introducir código HTML o incluso javascript.

El éxito dependerá de cómo lea el correo el destinatario. Si lo hace en el navegador con un sitio web no muy cuidadoso (o sea, no con Gmail) podemos tener suerte. No he probado demasiados sitios pero los que utilizan un servicio web propio suelen ser más laxos en este sentido.

Si controlamos el HTML podemos meter imágenes, iframes, enlaces, código para lanzar acciones cuando el usuario pase por encima, etc.

Se pueden enviar mensajes a usuarios internos

Una gracia de seleccionar la dirección de correo es que el que la resuelve es el servidor de aplicación. Por lo tanto, se puede intentar enviar correo a usuarios locales o a listas internas.

Por ejemplo root@localhost.localdomain me ha colado alguna vez. Y si conseguimos llenar el disco a base de mensajes…

No se monitorizan los mensajes

Los mensajes que envía el servidor de la aplicación no se monitorizan de forma habitual. Suele ocurrir que si alguien aprovecha estos inofensivos formularios para enviar Spam no se da cuenta nadie. A menos que los Spammers sean tan poco cuidadosos de no dejar de mandar mensajes a saco, en cuyo caso ya saltará alguna alerta de uso de la red o alguien avisará de que está recibiendo Spam o los meterán en algunas listas negras.

Pero en definitiva, no hay monitorización que permita detectar esto pronto.

Almacenamiento online del mensaje

Lo peor que he visto ha sido un formulario de contacto que no enviaba un correo, sino que guardaba el mensaje “sin filtrar” en una base de datos Notes (sí, no es broma) a la que podías acceder siempre que quieras con el identificador correspondiente y además, enviaba un mensaje al emisor.

Así que tenemos XSS almacenado más mensaje de la fuente fidedigna al usuario para que se lo crea del todo.

Sin palabras.

Concluyendo

Pensándolo bien, lo mejor es no tener ninguno de esos formularios. Para compartir, añadid los típicos botoncicos de las redes sociales y listo.

Y para contactar con la organización pues casi mejor el mailto: o también a través de las redes sociales. Todo lo demás es meterse en problemas y, por otro lado, molestar al usuario con CAPTCHAs.

Ah, por último, yo para hacer pruebas de estas cosas siempre uso Mailinator, un servicio que te permite usar cualquier cuenta de correo que se te ocurra (siempre con sus dominios) sin necesidad de registro ni de nada. Muy útil para registrarse en sitios y que no te manden publicidad y también para hacer pruebas de envíos de mensajes.

Bueno, tras un extenso parón espero poder retomar poco a poco el ritmo del blog. Animo al resto de “editores” a que publiquen algo y así no se note tanto cuando alguno entramos en un agujero negro. Y si alguno de los que estáis por Sevilla en esto de la seguridad queréis publicar algo, pues hacedmelo llegar, ¿ok?

Hoy quiero hablaros de un detalle de inseguridad de los visores de SIG (Sistemas de Información Geográfica). El visor es una aplicación web que extrae las imágenes de un mapa de alguna base de datos con localización geográfica (el SIG propiamente dicho). Sobre estas imágenes es posible añadir ‘capas’ que no es otra cosa que más información relacionada con la posición.

Muchos de estos visores te dejan, como usuario, añadir nuevas capas de otras fuentes para crear tu propio mapa. Otros ya traen sus capas fijas y puedes añadirlas o quitarlas pero sólo esas.

Ahora bien, la implementación de la funcionalidad de añadir capas suele incluir un cuadro de diálogo donde le pones un nombre, le indicas una URL para descargarla y le pones qué tipo de capa es (hay varias opciones).

Internamente, es el servidor el que se conecta al recurso, se lo descarga y lo devuelve al navegador. Lo bueno (o lo malo, según se mire) es que de este modo es posible solicitar cualquier URL que queramos y el servidor la pillará para nosotros.

el_mapa

Analicemos un poco esta situación: básicamente esta funcionalidad es un proxy que se ejecuta en un servidor en una red interna del organismo correspondiente al que le puedes solicitar cualquier URL, incluso de equipos internos. De hecho, en algunos SIG que he visto la URL se llama proxy o MapProxy o similar.

¿Cómo identificar esta funcionalidad? Si se trata de un visor que acepta capas, nada más fácil que añadir una URL cualquier y observar con un proxy de interceptación (Burp, por ejemplo) a ver qué URL utiliza. Si tenéis algún servidor web por ahí, ponedlo y echad un ojo a los logs.

Si no acepta capas, esta funcionalidad de proxy puede estar presente aunque no se use en la aplicación web y conviene echar un ojo al código fuente de los ficheros javascript para identificar la URL en cuestión.

Por lo tanto, si hacemos un análisis de seguridad a un organismo que tiene un SIG con esta ‘vulnerabilidad’ ya tenemos una forma de acceder a sus webs internas.

Pero ojo, ese no es el único problema, que te usen como ‘proxy’ abierto para hacer fechorías te puede traer muchos problemas (consumo de ancho de banda, inclusión en listas negras, ser origen de ‘delitos’, etc.).

Algunas limitaciones de este tipo de proxies:

  • El método HTTP está fijado, en algunos es GET y en otros, POST.
  • Normalmente no es posible generar solicitudes complejas, ya que la URL que pongamos es un parámetro de otra URL, incluir variables puede no acabar de funcionar.
  • Los enlaces de la página interna no funcionan, claro, porque no tienen en cuenta que hemos accedido de una forma subrepticia.
  • A veces el Content-Type es xml y el navegador no lo acaba llevando bien.

¿Cómo solucionar esto? Pues si no se trata de un visor SIG con capacidad para añadir capas, desactivando la funcionalidad ‘proxy’.

Por el contrario, si se trata de un visor SIG para añadir capas externas, se podrían filtrar las URLs con algún criterio o comprobar que la vuelta efectivamente corresponde al formato esperado. También se puede hacer que sea el navegador el que descargue el recurso y no el servidor, evitando este problema.

Y, como siempre, registrad logs y echad un ojo de vez en cuando no vaya ser que…

ACTUALIZACIÓN:

Ups “que sea el navegador el que descargue el recurso y no el servidor“. Acabo de comerme la Same-Origin Policy (aka SOP). Luego pensando me he dado cuenta de que igual no es tan fácil esta opción así de primeras.

Probablemente lo mejor sería comprobar que el fichero se ajusta al DTD específico del tipo de mapa que se quiere cargar, evitando servirlo si no es un fichero esperado y no enviando ciegamente lo que se descargue de la URL.

El otro día estaba haciendo una auditoria de una aplicación web que no tenía medidas anti-CSRF me encontré que era vulnerable a XSS almacenado si se subía un fichero que incluía HTML en un campo que luego se le mostraba al usuario.

Era gracioso porque, al no permitir paréntesis, no podías ejecutar nada en javascript fácilmente. Por lo que me decidí por insertar un EMBED a un Flash que ejecutaba el javascript :).

Pero no es de eso de lo que quería hablaros. Resulta que el problema es ¿cómo haces que el usuario suba el fichero? Pues, al no tener protección contra CSRF, uno puede pensar que sería posible si se consigue que el usuario se conecte a una página que controlamos nosotros en la que le hacemos solicitar la URL de subida de ficheros y le enganchamos nuestro perverso fichero.

Por obra y gracia del CSRF, la sesión del usuario se utilizará para la operación y él ni se dará cuenta. El problema viene cuando resulta que los navegadores han restringido precisamente la posibilidad de incluir un fichero en un FORM. Debido a cuestiones de seguridad.

Si intentas asignar el VALUE a un campo INPUT TYPE=”file” lo que obtienes depende del navegador. En Chrome se envía vacío y en Firefox da un error de seguridad, por ejemplo.

Pero vamos, que es necesaria la intervención manual del usuario para que use el diálogo de seleccionar fichero.

Pero como podrás imaginar, no está todo perdido. Buscando y buscando, me encontré con este artículo donde explica como hacerlo de una forma distinta. Pero antes de entrar en detalle, un poquito de SOP.

Ya sabéis lo que es SOP, ¿verdad? Si no, a leerse el libro de la bruja ahora mismo. Bueno, en esencia y muy simplificado viene a decir que los scripts que proviene de un origen, únicamente pueden interaccionar con ese origen. Entendiendo origen como el dominio desde el que se han cargado, más o menos.

Ya que, de lo contrario, un script malicioso en una página podría hacer barbaridades en tu nombre en cualquier otra página y esto sería el fin de todo.

En particular, las peticiones AJAX (XMLHttpRequest o XHR) que se realizan desde un script únicamente pueden salir hacia el origen del que proviene el script.

Ahora bien, resulta que hay gente que ‘necesita’ hacer peticiones entre dominios. Por lo que se han inventado varias técnicas para permitirlo de forma relativamente controlada.

Uno de esos mecanismos es Cross-Origin Resource Sharing (CORS). En este mecanismo, el servidor web le dice al navegador para qué dominios permite que se viole el SOP mediante cabeceras HTTP.

Y el navegador web envía solicitudes XHR incluyendo la cabecera Origin: en la que indica el origen para que el servidor de aplicación discrimine si acepto o no la solicitud. Pero… ¿qué pasa si la aplicación no entiende de CORS?

Pues por extraño que parezca algunos navegadores te dejan hacer cualquier petición XHR a cualquier dominio, añadiendo felizmente la cabecera Origin:. Eso sí, la vuelta no la puedes leer desde tu script a menos que el servidor envíe las cabeceras CORS adecuadas (que no lo va a hacer, claro).

Esto es precisamente lo que necesitamos para subir nuestro fichero fraudulento a una web que no entienda CORS (¿y tú conoces alguna que lo haga en tu entorno cercano?).

Por lo tanto, para subir un fichero mediante CSRF, en la página maliciosa creas la solicitud XHR que simula una solicitud HTTP que incluye las cabeceras y contenido de una subida de fichero (añades .withCredentials=”true” para que envíe las cookies del sitio)  y la envías a la URL de subida de ficheros.

Echad un ojo a los ejemplos (víctima, atacante) del artículo que citaba si queréis ver cómo se hace.

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.

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.

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

Recientemente he tenido la ocasión de visitar webs de múltiples colegios de Sevilla por razones personales. Por deformación profesional no he podido evitar valorar por encima la seguridad de algunas de las webs visitadas.

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.

La EFF ha comenzado una serie de artículos sobre la seguridad de HTTPS y SSL/TLS en su blog.

En la primera entrega analizan las causas de revocación de certificados HTTPS de un conjunto de CA’s para comprender hasta qué punto la revocación ha sido provocada por un ‘ataque’.

Es muy interesante el conjunto de posibles medios para comprometer la seguridad de tu conexión HTTPS y que completa lo que ya contamos en su día en el artículo HTTPS Tampoco Te Protege Siempre. Un resumen breve:

  • Comprometer la CA o sus aplicaciones web
  • Comprometer routers cercanos a la CA o cercanos a la víctima
  • Comprometer DNS recursivo usado por la CA o generar entradas DNS falsas para la víctima
  • Atacar protocolos que permitan tener acceso a los correos enviados a la víctima
  • Por último, el gobierno del país donde está la CA puede ordenarle que genere certificados o pueden efectuar cualquiera de los ataques anteriores

Los datos del artículo hacen ver que hay un número considerable de certificados que han sido revocados por ‘CA compromise’, que parecen haber aumentado recientemente.

Hemos sido testigos hace poco de otra CA comprometida en Malasia. Y mucho me temo que no va a ser la última.

Y los certificados de la FNMT sin ser reconocidos por los navegadores, para acostumbrar a la gente a ignorar los warnings.

Dicho todo esto, sin embargo, siempre será mejor usar HTTPS que el fatídico plaintext. Por lo que la EFF ha lanzado su plugin de Firefox HTTPS Everywhere para preferir el uso de HTTPS cuando estéis ahí fuera.

HTTPS Tampoco Te Protege Siempre, más conocido por sus siglas: HTTPS (por fín he creado un acrónimo recursivo y, además, ambiguo, jajaja). Bueno, espero que así lo recordéis la próxima vez que os sintáis seguros al ver el candadito o el https:// resaltado o cualquiera de esas formas en las que el navegador te indica que estás usando HTTPS.

El motivo de este post viene debido a que la EFF (Electronic Frontier Foundation) ha iniciado una campaña contra el status quo de la autenticación y cifrado en el mundo de las aplicaciones y sitios web: el uso de HTTPS. Bajo el lema ‘It’s time to fix HTTPS’ han presentado en varios sitios su opinión sobre la situación actual y cómo proponen que se resuelva.

A continuación os dejo la presentación para que la veáis y, además, añado algunas consideraciones que he estado pensando desde que la vi.

El problema

La verdad es que la situación del uso de HTTPS tiene múltiples problemas a la hora de determinar si la página a la que nos conectamos es o no auténtica. Quizá uno de los mayores sea de concepto y se trata de la confianza. HTTPS es, en el fondo, una PKI y como sabréis, estos sistemas se basan en la confianza.

Como dice Marcus Ranum en sus ‘leyes físicas de la seguridad de la información‘ (slide 12): “la cantidad de confianza que ponemos en un sistema puede no tener nada que ver con si se lo merece o no”.

En el caso de la PKI que es el HTTPS, ¿dónde confiamos? Pues principalmente en tres elementos fundamentales:

  • En la CA: La autoridad de certificación es la que firma los certificados (más o menos).
  • En la RA: La autoridad de registro es la que comprueba la identidad de los firmantes (más o menos).
  • En el navegador: Los certificados de las autoridades de certificación en las que ‘confiamos’ por defecto se encuentran en el navegador.

Vamos a ver cada caso por separado.

Autoridad de certificación

La CA es dónde están ‘las joyas de la corona’ de este asunto. Todos nos imaginamos el típico búnquer con guardas donde hacen falta dos llaves que llevan al cuello dos personas distintas y que deben ser giradas al unísono para que se encienda.

Y lo mismo es cierto y todo. El problema es que esa es la CA última (raíz) en la ‘cadena de confianza’. Es probable que con ella se hayan firmado otras CAs delegadas que están en sistemas más ‘accesibles’. Para que cada vez que compras un certificado on-line, no tengan que bajar dos tíos a un búnquer con guardas y girar las llaves que llevan al cuello al unísono, proceder a la firma y tal.

Eso ayuda a que, si una CA delegada es comprometida, se revoca y punto. Pero no hay que generar una nueva CA raíz. Si te das cuenta, claro. Recientes incidentes en RSA o Comodo hacen pensar en la tragedia que supondría una intrusión de alguien creativo en algunas de las empresas que firman certificados.

Porque, una vez generado, nos fiamos plenamente del certificado de un sitio siempre que haya sido firmado por una cadena de CAs que lleve a alguna de las CAs de las que tenemos certificados en nuestro navegador.

O, de lo contrario (y según el navegador que usemos) habrá que aceptar el certificado del sitio como válido… o no podremos verlo y disfrutar de su contenido. Por ejemplo, todas las webs gubernamentales que no tienen la CA raíz de la FNMT… pues hala, a aceptar el certificado. Eso o seguir el cansino proceso de instalar tú mismo la CA raíz de la FNMT en todos tus ordenadores y/o navegadores.

Autoridad de registro

La RA es dónde se valida la identidad de la entidad a la que se emite el certificado. En teoría se comprueba que los datos que se firman realmente pertenecen al que envía la petición. En la práctica esta validación no es tampoco muy exhaustiva (puede serlo más si compras un EV).

Lo cual significa que se podrían conseguir que se tramitaran certificados con datos de otro si se consiguen cumplir los requisitos de la RA. Esto ya ha ocurrido en alguna ocasión. La CA confía en la validación de la RA, por lo que una intrusión en la RA (que está disponible on-line para poder hacer negocio rápido por web) podría dar como resultado solicitudes de certificación falsas.

Navegador

En el navegador (o en el almacén de certificados del sistema operativo) es dónde se mantiene la larga lista de certificados de CA en las que confiamos ciegamente. Porque… ¿cuándo fue la última vez que miraste esa lista? Y, en caso de querer comprobar si los certificados son válidos… ¿cómo lo harías?

En la presentación presentan la posibilidad de insertar certificados de CA en el navegador de forma fraudulenta empleando CSRF. En tal caso, debe ser difícil que nos diéramos cuenta.

La solución propuesta

La presentación analiza diversos factores (incentivos perversos) que hacen que actualmente la situación sea tan negativa.

La solución que proponen la llaman jocosamente TOFU/POP (Trust On First Use; Persistence of Pseudonym). La idea es similar a la confianza que depositamos en el acceso ssh a servidores. Cada servidor tendrá su ‘pseudónimo’ o certificado, confiamos en él la primera vez que nos conectamos y luego, si cambia, seremos informados. Además comenta la posibilidad de diversos métodos para aportar confianza en la primera conexión o cuando haya algún cambio (DNSSEC, redes de confianza, etc.).

¿Qué os parece la idea? ¿ Creéis que nos desharemos del HTTPS tipo PKI para ir hacia un modelo distinto? ¿Os convence esta idea? ¿Cómo crees que afectará al usuario normal? ¿Y cómo se adaptarán los ‘cybercriminales’?

Actualización: No os perdáis este post en Security by default sobre mitos en HTTPS.