Marcus Murray, un experto en seguridad de la empresa TrueSec, ha desvelado cómo se puede llegar a poner en jaque a un servidor Windows de una red corporativa, simplemente subiendo un archivo JPEG con sus metadatos modificados.
Portada
mis comunidades
otras secciones
Comentarios
Las fotos no son peligrosas... (2004: https://technet.microsoft.com/en-us/library/security/ms04-028.aspx por citar un ejemplo)
#4 Me encanta la literatura ligera.
Da una explicación bastante detallada con un vídeo paso a paso, pero que me es muy dificil entender.
¿Algún experto que aclare si esto es viable, y tan peligroso como parece?.
#1 Es como subir una foto de Falete en tanga. Peligroso, pero nada que no pueda evitar un buen antivirus actualizado.
#2 jajajaja,...
Esta supuesta foto mi antivirus la detectaría sin analizar los metadatos.
#1 Esto es lo más parecido que se me ocurre: https://xkcd.com/327/
En el comic dan a entender que el nombre del niño es "Robert); Drop TABLE Students;". Lo que ocurre es que cuando la base de datos mete el nombre de un alumno, hace esto: "INSERT INTO Students VALUES (Robert);" que es lo bueno. La madre le cambia el nombre para que haga esto "INSERT INTO Students VALUES ( ' Robert); Drop TABLE Students; ' ); lo que hace que primero meta el nombre del alumno "Robert" (bueno) y luego inmediatamente borre toda la tabla de alumnos (malo).
Pues en ese sentido funciona esto. Como la madre del comic dice, solo hay que tener cuidado con las entradas y no meter todo a saco como si no hubiese mañana.
#5 Eso es el clásico ataque por inyección SQL. Y si un servidor no está protegido contra ello, el personal merecería que les dieran unos buenos azotes en el trasero. Y además, que se los diera Falete en tanga.
#5 Eso es SQL injection, no creo que sea el caso porque no suele ser común meter imagenes dentro de la base de datos y en todo caso se meterian como binarios, no como texto. Puede ser que sea lo que comenta #6, aun asi me parece muy raro y en todo caso tendrias los permisos de shell del servidor web, que suelen ser distintos a los del administrador.
#12 estuve viendo un rato la prueba de concepto y así parecía....(tampoco lo vi con mucho detenimiento) , pero vamos que es el típico ejemplo por lo que hay que tener "cuidadin" con lo que permites subir a tu servidor
#1 básicamente que si subes una imagen que tenga cierta cabecera del fichero JPEG con código incrustado (parece que es asp ) , si consigues cambiarla su nombre .aspx o subirla con esa extensión , puedes tener una shell remota al servidor donde está alojada, al visualizar la foto, por un incorrecto procesamiento de las cabeceras JPEG. De todas formas supongo que como ya tiene unos meses estará parcheada.
#1 Este tipo de fallos de seguridad son conocidos desde hace mucho. No es nada nuevo y NO es un fallo que afecte de forma general a toda la web. Más bien afectará a webs que estén mal programadas, en este caso, que no validen y muestren de forma segura las imágenes que se suban.
De verdad. No entiendo como ha podido llegar esto a portada.
Te explico un poco cómo funciona: Los ficheros de imagen (fotos) tienen unos metadatos que contienen cosas como la fecha de la foto, el lugar, la cámara con la que se ha hecho, una descripción etc. Lo que hace es meter el código malicioso en uno de esos campos y subir la imagen pero con el nombre cambiado a "foto1.aspx". En este caso el servidor solo comprueba que el contenido siga siendo una imagen, pero no comprueba el nombre de fichero.
Luego, a la hora de mostrar el fichero, ejecutará el código en lugar de mostrar la imagen porque el nombre de fichero tiene una extensión ejecutable (foto1.aspx), en lugar de nombre de imagen (foto1.jpg).
#17 Polimorfismos de toda la vida.
#17: No entiendo como ha podido llegar esto a portada.
No debes ver mucho la portada.
#17 Pero esto ocurre por un bug del desarrollador, a veces se piensa que es la tecnología la que tiene estos fallos de seguridad. Las inyecciones SQL también son bugs del desarrollador.
#17 "Luego, a la hora de mostrar el fichero, ejecutará el código en lugar de mostrar la imagen porque el nombre de fichero tiene una extensión ejecutable (foto1.aspx), en lugar de nombre de imagen (foto1.jpg)."
Creo que lo que ocurre es que el servidor envía la foto, pero al no tener la extensión jpg, no la envía con el mime image/jpg, y entonces el navegador la muestra como texto, y ahí es donde aparecen todos los caracteres extraños, y también el código html que ha insertado en el comentario exif. Luego con el "runat=server", consigue que lo que teclea en el navegador se ejecute en el servidor.
#c-30" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2435072/order/30">#30 El servidor no simplemente envía el fichero ASPX, sino que lo procesa. Es decir, ejecuta el código VBScript / C# que contiene en el lado servidor y envía el resultado al cliente. Que en parte contiene la imagen, que se ve como texto basura, y en parte contiene HTML, generado por el código ejecutado en el lado servidor.
Piensa que si se enviase al cliente tal cual, no se podría ejecutar código en el servidor salvo aprovechando otros bugs.
Por supuesto, este tipo de errores no podrán ser aprovechados si los ficheros estáticos (de imagen) están configurados correctamente para que no puedan procesarse como código.
#31 Es verdad, no lo pensé bien. Al poco de comentar me he dado cuenta. Es que nunca he trabajado con aspx, y no conocía lo del runat. Supongo que es parecido al php, el servidor envía el fichero tal cual, pero ejecutando antes los elementos "" incrustados.
Gracias por la aclaración.
#32 Sí, eso parece. Yo no soy programador, ni mucho menos sé ASPX.
https://msdn.microsoft.com/es-es/library/f0111sbh%28v=vs.100%29.aspx
De nada
Por lo que parece no es la foto la que tiene el problema, son los metadatos, vamos lo de siempre Windows se traga los metadatos como sino hubiera mañana, si ademas aunque comprobamos que es una imagen pero permitimos cualquier extensión eso es un golpe de remo, al menos en 2014 que es cuando se posteo el video en vimeo
It’s amazing how easily modern network systems can be breached, making exhaustive vulnerability management programs more critical than ever. Please join us for a demonstration of how easy it is for attackers to compromise your network during a webinar with Marcus Murray, Cyber Security Manager at TrueSec.
In this awareness session, Marcus Murray will demonstrate a live hack where he uses a specially crafted JPEG picture to circumvent the security mechanisms of a modern Microsoft Windows server 2012R2 Webserver. He will also use this foothold to expand influence over the entire network and compromise a Windows Server 2012 R2 Domain Controller.
During the presentation, Marcus will also discuss countermeasures you can take to increase security in your environment. This is a must-see session for anyone responsible for vulnerability management.
http://go.beyondtrust.com/thejpeghack
20/08/2014 me da por pensar que ya esta mas que parcheado en las versiones recientes de .NET
¿Pero qué tipo de vulnerabilidad utiliza?
Podrían documentar estos asuntos con enlaces a los codigos estandarizados de las vulnerabilidades, tipo cve xxxxxx
#7 La vulnerabilidad de ser idiotas y permitir la ejecución de imágenes proporcionadas por el usuario. Puede que no sea ni un bug, si no simplemente mala configuración.
El titular me parece amarillista. Una red corporativa no tendría esa mierda de servidor, que deje subir archivos con cualquier extensión y encima permita pre-visualizar binarios.
La presentación está bien, muestra cómo de fácil es explotar vulnerabilidades en servicios mal programados. Pero no, no esperes juackear meneame subiendo algo parecido como imagen de avatar en tu perfil...
Alguien a visto el video? Demuestra que un JPG con codigo ASPX dentro se puede ejecutar en el servidor, pero si tiene la extension ASPX.
Es decir, la pagina web tiene que permitirte que subas un fichero con esa entension y que lo guarde dentro del directorio donde esta la pagina web para que puedas ejecutarlo... o eso o subir el fichero JPG y cambiarle en nombre al fichero despues...
Quien permita eso permite tambien subir directamente tu codido malicioso, sin necesidad de hacer nada con un JPG.
"Simplemente subiendo un archivo JPEG con sus metadatos modificados" ... NO
Que alguien busque al autor del genuino "HOYGAN KOMO SE JAKEA EL INTERNET GRASIAS DE ANTEBRASO", que ya tiene respuesta.
Siempre se ha pensado desde lso inicios de Internet que en las fotos no podria haber virus, es decir que esta teoria rompe con todo lo sabido anteriormente
#9 es que esto no es un virus.
#9 El problema fué el listo que decidió meter los metadatos de la foto en una base de datos vomitando su contenido en una sequéncia SQL sin filtrar.
Siempre hay que filtrar y acotar TODAS las entradas.
Hace años ya había algo parecido pero en un formato muy concreto
https://en.m.wikipedia.org/wiki/Windows_Metafile_vulnerability
Vaya nivelazo de menéame, sql injection...
Básicamente se aprovecha de una aplicación mal programada, que permite subir una imagen con extensión aspx que es la extensión que utilizan las páginas de .net, cuando se intenta ejecutar ese aspx se muestra la imagen, como tiene extensión aspx intenta ejecutar tal cual y como los datos exif van en texto claro así que lo que ha hecho es hacer que la imagen tenga un código aspx bastante simple que hace un shellexecute de un input y pinta el resultado, una vez que tienes esto es fácil porque estas corriendo con los permisos del usuario genérico que utiliza IIS para las aplicaciones, que tiene bastantes permisos, desde ahí ejecuta un powershell que descarga un payload que permite conectarse al servidor en remoto y ejecutar comandos, el resto es historia.
En mi opinión es un hack muy imaginativo y aunque no valga ni de lejos para todas las webs sirve para hacer pensar que ante un hacker inteligente básicamente estás jodido porque siempre habrá algo en lo que no has caído.
¿Eso no se podría solucionar verificando la extensión del archivo "a mano" (o en el backcode de la página aspx) en lugar de dejar que sea el control Fileupload el que realice esa verificación?
Usando una expresión regular o algo antes de permitir que el Fileupload realice su función...¿pregunto?
#24 Claro que se podría, es correcto lo que dices.
A modo de anécdota, cuando empecé a programar, yo comprobaba mal las extensiones, no podía pensar en que alguien subiera una doble extensión: .png.php
Así que mi script comprobaba solo la primera extensión, y en realidad dejaba pasar cualquier extension.
A raíz de descubrir eso, me di cuenta de que es un fallo que de vez en cuando ocurre en aplicaciones a medida.
Más de una vez me encontraba con ese precioso LFI que me tocaba corregir.
Por las malas también se aprende...
A mi si no me hablan de interfaces en Visual Basic no me entero de nada
Es una mierda de artículo, por favor, quien tiene un servidor así?
Se basa en una vulnerabilidad previa muy muy burda.