Bienvenidos al maravilloso mundo del UXSS, el Cross Site Scripting Universal. Siéntense y disfruten, porque si muchas veces se ha dado por sentado que la mayoría de sitios web son vulnerables a ataques XSS, hoy estamos más cerca que nunca de afirmarlo.
Y es que 2007 no ha podido empezar peor en lo que a la Seguridad en Internet respecta. Si en 2006 los webmasters corríamos desesperados a parchear nuestros sitios en cuanto se descubría una nueva falla que pudiera permitir ataques XSS en nuestro particular software, en 2007 ya casi no merece la pena correr porque, de la noche a la mañana, nos hemos enterado de que todos nuestros sitios son vulnerables...
Debido a múltiples vulnerabilidades descubiertas en el plugin de Adobe Acrobat versiones 6.x y 7.x, los ficheros PDF (cualquier fichero pdf) se han revelado como el mejor vector de ataque que pudiera imaginarse. ¿Qué sitio (incluyendo bancos, organismos oficiales, etc, etc.) no alberga algún pdf en sus servidores? Si puede invocarse un PDF (cualquier pdf público, sin necesidad de tener permisos especiales) de forma que ejecute código javascript (cualquier código javascript), apaga y vámonos.
Para colmo de males, el aviso original informa de que los fallos detectados permiten la ejecución de código en Firefox, ataques DoS en Explorer y el robo de sesiones en Firefox, Opera y Explorer. Ahí es nada.
Y es que no existen soluciones milagrosas. Como webmasters podemos retirar los pdf de nuestros servidores; como usuarios algunos pueden actualizar a la versión 8 (pero no todos los usuarios lo harán, y mucho menos aún los de Linux, que ni siquiera lo tenemos disponible), deshabilitar Javascript (poco sentido tiene utilizar NoScript cuando todos los sitios son ya sospechosos), no abrir PDFs en el navegador (e instruirle para ello), utilizar extensiones (como PDF Download) que nos concedan mayor control...
Pero el daño ya está hecho. La vulnerabilidad esencial de una Red creada para compartir "de buen rollito", ha vuelto a quedar en evidencia.
Y esta vez de qué manera.
Actualizaciones:
- 4-Enero, 18:45/ También funciona en local: Ya ni siquiera hacen faltra servidores web para explotar el ataque. Lo cuento aquí.
- 4-Enero, 10:37/ Una explicación para "torpes": En este comentario he procurado explicar las consecuencias del fallo desde el punto de vista del usuario y del webmaster, así como algunas medidas preventivas que ayudarán a unos y otros.
- 21:39/ Una contramedida para webmasters: Vía PHP Security encuentro unas líneas que pueden hacer que Apache obligue a descargar los pdf, en vez de que se abran con el dichoso plugin. Son éstas:
SetEnvIf Request_URI "\.pdf$" requested_pdf=pdf
Header add Content-Disposition "Attachment" env=requested_pdfFuncionan en httpd.conf o en un .htaccess. Gracias a esta medida he podido reponer en el sitio los pdf y Kriptópolis -creo- ya no es vulnerable, pero si alguien piensa lo contrario por favor que me avise para contarlo ;). Si no, ya estáis tardando en aplicarlo los que tengáis sitios web alojando pdf.
- 21:20/ Diferencias entre Explorer 7 y Firefox en Windows: Al tratar de ejecutar javascript en un pdf, Explorer 7 se niega y da un "error de red". Firefox 1.5.0.9 se lo traga, abre el plugin y ejecuta el javascript sin rechistar. Uhm...
Más información:
- Adobe Acrobat Reader Plugin - Multiple Vulnerabilities [Aviso original de los descubridores].
- Subverting AJAX [Trabajo presentado en CCC, paradójicamente disponible en pdf].
- Danger, danger, danger [GNUCitizen]
- Hacking with Browser Plugins [Sven Vetsch dando la voz de alarma. Detalles y algunos ejemplos].
- Acrobat Reader plug-in vulnerable to attacks [ComputerWorld]
- Universal XSS in PDFs [Ha.ckers.org]
- PDF XSS vulnerability announced at CCC [SANS Institute]
- Universal XSS with PDF files: highly dangerous [SecurityFocus]
- When PDFs Attack! [Symantec]
- Adobe Reader Cross-Site Scripting Vulnerability [Secunia]
La solución definitiva
anónimo14 Mayo 2007 - 7:39pm
No usar la mierda del acrobat reader en güindo, y mucho menos en nuestro maravilloso gnuLinux, y asunto resuelto.
Se acabó el problema.
no logro descargar libros digitales de internet
anónimo19 Abril 2007 - 2:32am
todo un tema, fui actualizando adobe hasta llegar a 8.0 y no resulta. me sale un cuadro que dice no es un tipo de archivo admitido o esta dañado (ej. se envio como adjunto de correo electronico y no se codifico correctamente) que hago?
La descarga de la versión 8 de Acrobat
Fernando Acero4 Enero 2007 - 10:07pm
Acabo de intentar una instalación de la versión 8 de Acrobat con dos ordenadores distintos (por si el problema era otro) y en los dos casos me ha dado error.
Primero me dice:
Va a reanudar la descarga, pero el archivo del servidor ha cambiado. ¿Desea reiniciar el proceso de descarga?y luego, cuando le digo que adelante con el reinicio de la descaga, de dice que:
El archivo descargado está dañado. Inténtelo en otro momento.Las desgracias nunca vienen solas...
"Copyleft 2006 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".
Ultimas aclaraciones desde Adobe
logadmin4 Enero 2007 - 3:49pm
Leonard Rosenthol de Adobe systes aclara:
solucion para proteger desde servidor
gordofoo4 Enero 2007 - 1:51pm
Otra posible solución es proteger los archivos pdf frente a enlaces externos a nuestra web.
Dentro del archivo .htacces ponemos el siguiente código:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://([-a-z0-9]+\.)?example\.com[NC]
RewriteRule .*\.(pdf)$ http://www.example.com/images/NoExternalLinkOnPDF.gif [R,NC,L]
Si el visitante intenta abrir un archivo PDF enlazado desde otro sitio web, nuestro servidor lo redirije a una imagen (podemos poner una web, un .txt...) que le avisa que no podrá acceder a ese archivo de forma externa al servidor.
Es un parche que apliqué hace tiempo a mi servidor web para evitar "hotlinking" a las imágenes pero aplicado a los pdf.
Sobre la solución en el lado del servidor
spidi4 Enero 2007 - 12:29pm
Hola.
Llevo toda la mañana trasteando con la solución propuesta y voy a indicar algunas cosas que quizá puedan ayudar a alguien, además de pedir un poco de ayuda.
Para empezar hay que indicar que es necesario tener cargados los módulos del header y del setenvif. Lo digo porque el header no suele venir por defecto.
Segundo, no sé muy bien por qué en la página esa, en el "SetEnfIf" ponen al final "requested_pdf=pdf". Por lo que vi en la doc del apache no tiene mucho sentido el "=pdf".
Aquí viene mi problema. Bajo windows, el apache1.3 casca al intentar usar una variable env en la directiva Header. Ojo, tb lo probé con la directiva deny y funciona perfectamente. Tampoco es problema del ámbito de aplicación, porque me casca igual en la configuración del servidor o dentro de un Directory.
Lo he probado en linux con el apache2 y la directiva acepta perfectamente la variable env.
Me quedaría probar un linux con 1.3 y un windows con 2.0, pero es una puñeta. Alguien sabe de algún problema conocido en la directiva Header con windows y apache1.3?
No acabo de encontrar nada en google, supongo que es porque no encuentro las palabras adecuadas.
Sé que estos comentarios no es el sitio más adecuado para hacer esta pregunta, pero como los principales enlaces están referenciando aquí, a ver si tengo suerte y alquien que sepa lo lee.
Graciassss
¿Y si "zipeas" los pdf?"
Enriquez4 Enero 2007 - 12:04pm
Pues eso, puede ser una ñapa, pero si zipeas los pdf en el server ¿no obligas a la descarga?
admin despejando dudas (espero)
admin4 Enero 2007 - 11:37am
Aunque la vulnerabilidad incluye en realidad varias (ver aviso original), me centraré en la que más nos interesa: la ejecución de javascript en el navegador del usuario a través de un sitio web que actúa de transmisor inocente.
Para desencadenar este ataque hay que invocar un pdf con ciertos parámetros en la URL.
Por ejemplo:
http://www.kriptopolis.org/docs/reto.pdf#hola=javascript:alert('Ojo Documento Infectado');
Si un sitio te propone que pulses este enlace, irás a Kriptópolis y tu plugin vulnerable (si tienes Acrobat 6-7 y éste te abre los pdf "on the fly" ;) te mostrará en tu navegador el documento kriptopolero en cuestión...
Pero... al tiempo te saltará una ventanita que dirá "Ojo Documento Infectado" y tú te acordarás de mis parientes más lejanos, pensando que Kriptópolis aloja documentos infectados, sin que yo haya tenido nada que ver.
Y eso porque sólo estábamos jugando. El atacante podría haber puesto un código javascript cualquiera para robarte tus cookies y hacerse pasar por ti o cualquier otra malignidad.
Cachis! Por haber arreglado el asunto en el servidor de Kriptópolis (creo) no puedo poneros una demo real en este servidor, pero podéis probar con las que están por ahí, en los enlaces... o en cualquier web que no haya tomado medidas (al menos retirar los pdf mientras no se pueda hacer otra cosa).
En resumen:
Solución para usuarios:
El usuario ha de cambiar de visor de pdf (Foxit y otros) o actualizar el de Acrobat a la versión 8 (sólo Windows) o usar PDF Download con Firefox o desactivar Javascript en todos los sitios (porque no se sabe cuál está protegido frente a esto). En última instancia, la culpa de Acrobat radica en permitir la ejecución de javascript. De aquellos polvos, estos lodos.
Solución para inmunizar sitios web:
Retirar tus pdf, mientras no puedas hacer otra cosa. Si puedes, modifica la configuración del servidor para que obligue al usuario a guardar los pdf, en vez de abrirlos desde el navegador. Otra buena solución sería configurar el servidor para que cualquier petición de un pdf con parámetros muestre un mensaje de error.
A ver si ahora que un poco más claro el tema...
Perdón:
mahuro4 Enero 2007 - 11:18am
Ya lo había aclarado bongo mientras yo escribía la pregunta. Gracias bongo
"Aún con los ojos abiertos... ¡No veo absolutamente nada! <Zatoichi>
Aclaración, plis:
mahuro4 Enero 2007 - 11:15am
A ver si me he enterado bien: si tengo un servidor con un PDF infectado con cierto código javascript, supuestamente lo que pongo en peligro es la maquina del usuario que abra ese PDF no el propio servidor en sí ¿No?. Quiero decir que todo javascript se ejecutaría en la máquiina cliente ¿Es así?
"Aún con los ojos abiertos... ¡No veo absolutamente nada! <Zatoichi>
En pocas palabras
Turkistan (no verificado)4 Enero 2007 - 11:14am
Si un usuario de Kriptópolis se baja un pdf de Kriptópolis y su navegador lo abre con el plugin afectado puede sufrir la ejecución de código arbitrario en su navegador, como si el código procediera de Kriptópolis.
No me extraña que Kriptópolis retirara sus pdf. Es lo que debería hacer todo el mundo YA.
No lo entiendo
raster4 Enero 2007 - 11:05am
A ver si me he enterado: un bug en el plugin de Adobe reader hace que se pueda ejecutar, en el cliente, cualquier código JavaScript que haya en un PDF bajado de una página, código que puede ser malicioso. Hasta aquí bien.
¿Pero qué tienen que ver los ficheros PDF de kriptópolis? Si los habeis hecho vosotros mismos entonces se supone que son fiables. ¿Por qué los retirais? ¿Me he perdido algo?
Un saludo.
Protegerse en sitios con IIS(Correcion)
devjoker4 Enero 2007 - 10:51am
Al principio interprete mal la noticia, pense que permitia ejecutar codigo del lado del servidor ... por eso puse el comentario anterior!. Indagando un poco más veo que no ... por lo que el comentario anterior es un poco tonteria.
Protegerse en sitios con IIS
devjoker4 Enero 2007 - 10:34am
Una primera medida para protegerse en sitios que funcionen con IIS es deshabilitar cualquier tipo de permiso de ejecución sobre los directorios que contengan algún pdf.
antes de investigar quiero
chamoscript4 Enero 2007 - 6:24am
antes de investigar quiero hacerle sunas preguntas porke esto no me ha kedado del todo claro....
si la vulnerabilidad es del adobe reader los pdf´s vulnerables son solo los q se han hecho bajo este programa? q pasa si uso por ejemplo ghostreader? o si hago los pdf con openoffice?
o mas claro: ¿la vulnerabilidad es del adobe reader o del formato pdf?
por otra parte: dice q el fallo es de un plugin del reader ¿cual plugin? yo deshabilito todos los plugins del reader menos los esenciales para q abra + rapido, entonces la 2da pregunta es ¿cuál es el plugin vulnerable y q pasa si lo deshabilito o lo borro?
salu2 y gracias de hantebrazo
De la misma manera que hace
mced4 Enero 2007 - 6:06am
De la misma manera que hace mucho tiempo que no abría adjuntos directamente desde el cliente de correo, tampoco dejaba que el navegador se encargara de los PDF. Era ese pequeño avisador interior que te recordaba siempre la disyuntiva 'comodidad vs. seguridad'. Y es que, ¿tanto PDF on-line consultamos para que nos sea incómodo el método guardar-revisar-abrir?
Plug-ins
felipe_alfaro4 Enero 2007 - 1:35am
Nunca me ha gustado el plug-in de Adobe para PDFs y Flash. Ahora, una razón más para que me siga disgustando.
no uso el adobe
suscripcion4 Enero 2007 - 1:14am
supongo que con el uso de FoxIT Reader no tendré el problema.