security - que - exploits web
¿Sorprendentes vulnerabilidades de software o exploits? (30)
:-)
texto alternativo http://www.codingthewheel.com/image.axd?picture=transparent_intercept.png
¿Cuáles son las vulnerabilidades o vulnerabilidades de software más extrañas / sofisticadas / sorprendentes / profundamente ocultas que haya visto? Lugares en el código donde pensaste que no hay peligro oculto, pero estaban equivocados?
[Para aclarar: todo el mundo sabe inyecciones de SQL, XSS o desbordamientos de búfer - errores que a menudo resultan de una codificación descuidada. Pero cosas como el troyano oculto de Ken Thompson (Reflexiones sobre Trusting Trust: http://cm.bell-labs.com/who/ken/trust.html ), la reciente vulnerabilidad de desreferencia NULL en el núcleo de Linux ( http://isc.sans.org/diary.html?storyid=6820 ), o un ataque complejo en RNG que usa la denegación de servicio ( http://news.ycombinator.com/item?id=639976 ) me ha molestado mucho.]
Actualización: Gracias a todos por las respuestas, fueron geniales. Tuve difícil elección. En última instancia, decidí otorgar la recompensa al canal lateral / ataque de monitoreo de energía. Sin embargo, todas sus respuestas combinadas muestran que tengo que aprender más sobre seguridad, ya que es un tema muy profundo :).
Aquí hay un comando de shell de una línea que hace una escalada de privilegios para OS X:
osascript -e ''tell app "ARDAgent" to do shell script "whoami"''
No es tan fácil como parece, ya que necesita un vector de ataque separado para acceder al shell de un usuario, pero es una carga útil realmente genial.
Ya no estoy seguro de que esto funcione, pero recuerdo haberlo hecho en mi Mac en ese momento (con una copia simple, pegar) y felizmente reporté ''root''.
Aquí está el artículo slashdot:
Creo que una vulnerabilidad de Linux relativamente reciente califica para su descripción de código de explotación que parece seguro (aunque un poco mal estructurado).
Esta fue específicamente la pieza de código en el kernel de Linux:
struct sock *sk = tun->sk; // initialize sk with tun->sk
…
if (!tun)
return POLLERR; // if tun is NULL return error
Debido a una optimización de GCC, se eliminan la instrucción if y el cuerpo (lo que es razonable para el código de usuario, no tanto para el código del kernel). A través de un poco de inteligencia, una persona fue capaz de construir un exploit a partir de esto.
Un resumen:
http://isc.sans.org/diary.html?storyid=6820
Un exploit publicado:
http://lists.grok.org.uk/pipermail/full-disclosure/2009-July/069714.html
EDITAR : Aquí hay un resumen mucho más detallado de cómo este código fue explotado. Es una lectura corta, pero una muy buena explicación de los mecanismos utilizados para la explotación.
En la escala "sofisticada", el ataque de Dowd en la máquina virtual ActionScript es insuperable. Vea este artículo para un entretenido resumen del artículo.
Hace años eché un vistazo a un programa (en Acorn Archimedes) que estaba protegido con un complejo sistema de encriptación (solo para ver cómo se hizo y aprender de él). Se hizo de manera muy inteligente, con el código de descifrado que se utiliza como parte de la clave de descifrado, de modo que cualquier intento de alterarlo rompería el descifrado y, por lo tanto, le dejaría basura en la memoria.
Después de 2 días tratando de averiguar cómo se hizo y cómo podría evitarlo, un amigo lo visitó. Utilizando una herramienta del sistema operativo (un clic y un arrastre para maximizar la asignación de memoria de RMA), limitó la RAM disponible para que el proceso se ejecute solo un poco más grande que el tamaño del archivo .exe. Luego lo corrió. Inmediatamente después de descifrarse, intentó asignar memoria, falló y se bloqueó. Luego guardó el programa descifrado de la memoria. Tiempo total de crack: aproximadamente 2 minutos, utilizando solo un arrastre del ratón y un comando de guardado de la línea de comandos.
Aprendí de esto que no vale la pena dedicar demasiado tiempo y esfuerzo a proteger su software. Si alguien quiere descifrarlo, lo hará, y probablemente lo hará por un medio simple que nunca se le ocurrió.
(Descargo de responsabilidad: los dos habíamos comprado copias legales de este programa y nunca usamos el código descifrado de ninguna manera. Realmente fue solo un ejercicio de programación intelectual)
Hace un mes estuve en una conferencia francesa de seguridad de TI (SSTIC, por sus siglas en inglés) donde un chico explicó por qué y en qué no se debe confiar en la arquitectura de computación confiable actual. Cómo ? Nos mostró una "puerta trasera acpi" que le dio uid 0 (root privs) después de desconectar / volver a enchufar un par de veces el cable eléctrico de su computadora portátil. Es posible leer el documento y las diapositivas (en francés, pero creo que una búsqueda de google en "loic duflot + acpi" debería dar algunos resultados en inglés): http://actes.sstic.org/SSTIC09/ACPI_et_routine_de_traitement_de_la_SMI/
Hace un par de años, un estudiante de doctorado en la VU en Amsterdam ideó virus para las etiquetas RFID: http://www.rfidvirus.org/
LWN.net publicó un post sobre el exploit de Cheddar Bay a través de punteros nulos, que por sí solo no es peligroso, pero a través de la optimización del código gcc puede ejecutar código no deseado incluso si ha configurado SElinux.
El uso de la función javascript en las páginas web a través de los ataques mitm para crear un registrador de teclas (onkey (presionar / subir / bajar) y publicar en una url es bastante simple, supongo.
La "ingenuidad" de los humanos nunca deja de sorprenderme.
La segunda edición del Manual de Shellcoder: Descubrir y explotar los agujeros de seguridad es bastante entretenida:
Examina de dónde provienen los agujeros de seguridad, cómo descubrirlos, cómo los piratas informáticos los explotan y toman el control de los sistemas a diario, y lo más importante, cómo cerrar estos agujeros de seguridad para que nunca vuelvan a ocurrir.
Leí sobre una forma inteligente de robar el historial de su navegador ayer mismo: al agregar JavaScript que mira el color de sus enlaces (cambian de color para los sitios que visitó).
Esto se puede usar para atacar sitios que agregan un token de seguridad a la URL (si ese token no es demasiado largo) simplemente probando todas las combinaciones posibles.
Lee esto, te dejará sin aliento (¡ciertamente me voló la cabeza!).
http://news.ycombinator.com/item?id=639976
Un hacker rompió el sitio de ''Noticias de hackers'' al explotar que la generación de cookies aleatorias no era realmente aleatoria. Un comentario en el mismo hilo da una descripción perfecta para el hack,
Gracias Dfranke. Todos estos años, siempre que pensé en el verdadero pirata informático, esto es lo que imaginé en el fondo de mi mente: material lo suficientemente complejo como para que saque mis libros de Álgebra de Estadísticas y Liner. Todos los demás intentos de hackeo web durante la última década han sido XSS, contraseñas incorrectas y problemas de envío de formularios estúpidos. Francamente, había renunciado a la existencia de verdaderos hackers de whitehat hasta este post. Mis felicitaciones a usted señor.
Algunos elogios para el hacker:
Compañeros hackers, tomen nota. ¡Así es como resuelves un problema! Dfranke es Pandora, una rata en un laberinto, Sherlock Holmes, el General Sherman, William Randolph Hearst y tu padre, todo envuelto en uno.
Como Pandora, él es tan curioso, que tiene que ver esto.
Como una rata en un laberinto, sigue buscando el camino claro.
Al igual que Sherlock Holmes, aplica la lógica para determinar el siguiente paso.
Al igual que el general Sherman, él sigue marchando, construyendo herramientas en el camino a medida que las necesita.
Al igual que William Randolph Hearst, define el paisaje. ("Tú proporcionas las imágenes, yo proporcionaré la guerra".) "Así que decidí un enfoque más proactivo: ¡arréglalo!" (divertidísimo)
Y como cualquier padre, no renunció hasta que su bebé caminó.
Gracias daniel Espero que hayas encontrado una manera de canalizar ese talento en tu trabajo diario.
Lo mejor que he visto hasta ahora, fue el comentario de la línea mrand.c sobre los paquetes Debian SSL, porque Purify se quejó del uso de datos no inicializados. Esto no fue un error de código por sí mismo, sino más bien un error de refactorización, fue introducido por un agente de mantenimiento al comentar una línea de código. La línea que se comentó fue una llamada a una función que estaba allí para proporcionar entropía a las generaciones clave, pero debido a que usó datos no inicializados para hacer esto, Valgrind se quejó.
El mantenedor envió un correo electrónico a la lista de correo SSL preguntando si estaba bien comentar esta línea, ya que todo lo que estaba haciendo era agregar algunos datos aleatorios, alguien dijo que era seguro y la línea estaba comentada, dejando toda la clave SSL generada por la librería debian ssl no es segura.
Esto se prolongó durante varios años, y solo fue descubierto por error cuando Luciano Bello estaba creando cientos de claves para un proyecto universitario y notó varias colisiones clave.
Estos errores son la verdadera amenaza, continúan durante años y, ¿cómo prueba que un PRNG es realmente aleatorio? texto alternativo http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/2000/300/2318/2318.strip.gif
La línea exacta era:
md_rand.c
MD_Update(&m,buf,j); /* purify complains */
Puedes leer todo sobre este error increíble aquí: texto del enlace
Los ataques de arranque en frío son quizás más un ataque de hardware, pero sin embargo son muy interesantes y sorprendentes.
Mostraron que se puede leer el contenido de la RAM normal después de un reinicio. Al enfriar los chips a -50 ° C con un pulverizador de aire comprimido (no nitrógeno líquido ni nada de eso), encontraron que menos del 1% de los bits se voltearon después de 10 minutos sin energía (!)
Este es un ataque serio en todos los programas de cifrado de disco. Deben mantener la clave de descifrado en la memoria RAM y, si puede reiniciar la máquina, probablemente pueda acceder a la clave. Podría decir que no permitirá que la gente reinicie su máquina de esa manera, pero piense en computadoras portátiles robadas en modo de espera. Se activarán y presentarán un protector de pantalla pidiendo una contraseña. En ese momento, la clave de cifrado del disco está en RAM => un reinicio más tarde, la clave podría estar en posesión del malo ...
Tienen videos y el documento de conferencia muy legible en su página de inicio .
Método extremadamente simple para entrometerse con su aplicación web: si la aplicación permite a los usuarios agregar imágenes a perfiles, tableros de mensajes o publicaciones de blog, el usuario malintencionado puede configurar una URL de imagen como ''/ Account / LogOut'' (o cualquier otra URL local válida que cause acciones no queremos). Si logra publicar su perfil / publicación / mensaje "hasta la página principal", se cerrará la sesión de cada usuario inmediatamente después de iniciar sesión (el navegador ejecutará la solicitud en / Account / LogOut en el contexto del usuario actual para descargar la imagen), por lo que la funcionalidad de la página será gravemente dañada.
Mi favorito y el más impresionante que he visto hasta ahora es una clase de técnicas de criptografía conocidas como Side Channel Attacks .
Un tipo de ataque de canal lateral utiliza la supervisión de potencia. Las claves de cifrado se han recuperado de los dispositivos de tarjeta inteligente al analizar cuidadosamente la cantidad de energía extraída de la fuente de alimentación. Los procesadores integrados en ellos utilizan diferentes cantidades de energía para procesar diferentes conjuntos de instrucciones. Utilizando este pequeño bit de información, es posible recuperar datos protegidos, de forma completamente pasiva.
Mis favoritos son una clase de ataques bastante particulares conocidos como Format String Attack . Explotan las etiquetas de formato tipo printf para sobrescribir los datos en la pila. Algunos de ellos usan tokens oscuros como% n, que aunque son bastante raros de encontrar, podrían inyectarse en el código si el programador es lo suficientemente descuidado como para permitir que una entrada sin filtrar llegue a la cadena de formato.
Aunque aparentemente no son diferentes de los desbordamientos de búfer, en cambio llevan una complejidad adicional: en un desbordamiento de búfer, simplemente sobrescribe la dirección de retorno en la pila. Con Format String Attack, debe adaptar cuidadosamente su ataque para poder redirigir el flujo de ejecución sin causar un bloqueo, por lo que son mucho más complejos de diseñar.
Otro ataque interesante es el error off-by-one . Una vez más, no es fácil de explotar, pero definitivamente es factible.
Ok, esto no es una vulnerabilidad o vulnerabilidad de software, pero aun así:
" Van Eck Phreaking es el proceso de espionaje de los contenidos de una pantalla CRT y LCD mediante la detección de sus emisiones electromagnéticas". (De Wikipedia)
Simplemente guau...
Otro aspecto sorprendente y reciente es el Clickjacking , que una vez más muestra la insuficiencia de nuestro modelo actual de lo que es y debería ser un navegador web. Evita fácilmente la mayoría de las defensas contra XSS, CSRF, etc., y permite que un sitio web malintencionado "robe" el control de sus clics y los desvíe hacia un lugar específico en otro sitio web, por ejemplo, el botón "OK" en la página "Transferir fondos" en el sitio de su banco, o el cuadro de diálogo de opciones de Flash que le permite al atacante ¡VER SU WEBCAM SIN SU CONOCIMIENTO!
Sorprendente, y brillante ...
Pensé que el reciente ataque a las cuentas de correo electrónico de un empleado de Twitter fue bastante aterrador.
Básicamente se aprovechó de una cuenta de correo electrónico vencida y del sistema de recuperación de "contraseña olvidada" de otra cuenta.
Quién no recuerda el Killer Poke (explicación no técnica): el viejo Commodore 64 tiene una memoria de video lenta. Al usar un POKE, puede escribir un valor especial para una dirección en la memoria de video; esto causa todo tipo de vudú, entre los cuales se encuentra el cambio del voltaje de algunos de los circuitos, lo cual tiene la consecuencia afortunada de hacer que la pantalla se actualice más. con rapidez.
Cuando Commodore actualizó su hardware de video, el mismo comando de empuje hace que la tensión se dispare a todos los tipos de tornillos y fríe el hardware. Un exploit de software puede causar daño al hardware. Increíble.
Realmente no es software, pero estoy seguro de que juega un papel en algún lugar.
Recientemente se ha descubierto que puede interceptar y decodificar la radiación electromagnética emitida por todos los teclados, no solo las variaciones inalámbricas. Esto se puede utilizar para crear un keylogger remoto.
Sí, sí, todos sabemos acerca de la inyección SQL, y todos sabemos cómo protegernos, ¿verdad?
Su aplicación debe estar haciendo validación de entrada, llamando a procedimientos almacenados, etc., etc.
Pero, ¿sabía que, en ciertas situaciones, el contrabando de SQL puede fácilmente pasar por alto todo eso?
Lo más impactante de esto, es que esto se debe a una "característica" poco conocida, en su mayoría no documentada, en algunas bases de datos, marcos, objetos de bases de datos, etc. En resumen, la base de datos (o la plomería en el camino) podría ayudarlo. ¡El favor de traducir feliz y silenciosamente algún personaje desconocido en otro! Por ejemplo, el carácter U + CABC de Unicode podría convertirse en una cita (U + 0027), que intentó bloquear en su aplicación, pero desafortunadamente el DB decidió crear y permitir que el atacante vuelva a montar su ataque SQLi directamente a través de sus defensas.
Sí, publiqué el artículo vinculado, pero cuando descubrí originalmente este comportamiento, me sorprendí.
Todo el mundo sabe acerca de las inyecciones de SQL, pero una de las hazañas más sorprendentes que escuché recientemente fue poner inyecciones de SQL en códigos de barras. Los evaluadores deben verificar TODAS las entradas en busca de SQL malicioso. Un atacante podría aparecer en un evento y colapsar su sistema de registro, cambiar los precios en las tiendas, etc. Creo que solo la piratería de códigos de barras en general me sorprendió. No hay factor sorpresa aquí, solo hay algo más de lo que hay que estar enterado.
EDITAR: acaba de tener una discusión en la que se planteó la idea de colocar la inyección SQL en una tira de tarjeta magnética. Supongo que puede colocar uno en cualquier lugar, así que pruebe cualquier entrada, especialmente de los usuarios y este tipo de dispositivos de almacenamiento de datos.
Una hazaña clásica fue el truco de Ken Thompson para darle acceso de raíz a todos los sistemas Unix en la Tierra.
Cuando Bell Labs era el único proveedor de Unix, distribuían el código fuente para que cada instalación pudiera construir y personalizar su propio sistema operativo. Esta fuente incluye el comando de inicio de sesión de Unix. Ken modificó el compilador de C para reconocer si estaba compilando el comando de inicio de sesión y, si es así, agregar una comprobación de contraseña inicial. Esta contraseña era su propia magia y se le concedió acceso a la raíz.
Por supuesto, cualquiera que lea la fuente del compilador de C verá esto y lo eliminará. Así que Ken volvió a modificar el compilador de C, de modo que si compilara un compilador de C, volvería a poner el inicio de sesión en el hack
Ahora viene la parte de la mente mental; Ken compiló el compilador de C con su compilador pirateado, luego eliminó todo rastro de su piratería, eliminándolo de la fuente, las copias de seguridad, el control de la fuente, todo. Solo existía en el binario compilado que era parte de la distribución de Unix.
Cualquiera que haya obtenido este Unix de Bell Labs obtuvo un inicio de sesión pirateado y un compilador de C. Si miraban la fuente, era seguro. Si reconstruían el sistema operativo, el compilador pirateado hackearía el compilador reconstruido, lo que reinsertaría el hack en el comando de inicio de sesión.
La lección que extraigo de esto es que no puede garantizar la seguridad de cualquier cantidad de análisis estático (inspección del código fuente, sistema operativo, aplicaciones).
Ken reveló esto en un artículo de ACM titulado http://cm.bell-labs.com/who/ken/trust.html .
Uno de los ataques menos sofisticados que he visto fue uno de los más efectivos. Un probador que sabía que estaba trabajando en probar una aplicación VB6 bajo Win98. La aplicación fue construida para abrirse en una ventana de tamaño fijo. El probador, al ser inteligente, creó un acceso directo a la aplicación y configuró el acceso directo para abrir la aplicación maximizada. Cuando la aplicación se abrió en un tamaño mucho más grande de lo que el desarrollador había previsto, expuso un control de datos que normalmente no sería visible. Al hacer clic manualmente en el control de datos, el probador logró moverse a un registro que no debería haber podido ver, y modificarlo ...
Uno se pregunta todo el tiempo, ¿no es así? Este año "No puede ser real ... pero wow" ha sido la contaminación de parámetros y el rastreo de su historia sin usar JavaScript .
Iré por el último, porque es asombroso al mismo tiempo (creo que todo el mundo tendrá este momento en el que se da cuenta de que él mismo pudo haber tenido esta idea ... no debería haberlo hecho) y utiliza el mismo ancho de banda de los navegadores. Optimización que asegura que una imagen de fondo solo se carga cuando es necesario.
Me gusta.
Y no se mitiga fácilmente sin romper algunas cosas. En realidad, estoy equivocado aquí, puede que evites iframes "invisibles" en el navegador. No sé si alguien realmente quiere eso.
Lo he considerado como uno de los más simples, pero devastadores. Hasta que CSRF llegó a la escena, los desarrolladores web asumieron, o más bien los navegadores de confianza para enviar solicitudes generadas por el usuario, pero ya no. Un ejemplo clásico de un diputado confundido .
Vulnerabilidad de Hyper-Threading :
Esta falla permite la divulgación de información local, incluida la posibilidad de que un usuario sin privilegios robe una clave privada RSA que se utiliza en la misma máquina.