¡Tu mensaje de bienvenida, twitter o publicidad aquí!

| Suscríbete vía RSS

20 abr. 2010

Sobre cómo no hacer las cosas

| 0 comentarios |

Cuando se descube un fallo en algún sitio, y normalmente ha sido por un error en la programación, si tiras de ese fino hilo poco a poco acabarás por descubrir más fallos.

Algo similar es lo que ha ocurrido con la página que comentaba líneas más abajo, donde el servicio que ofrecían para recomendar la página a nuestros contactos, podía ser utilizado para realizar un poco de spam.

Mientras navegaba por ella observe que la dirección url se presentaba de la siguiente forma:


http://xxxx/yyyy/zzzz.php?$sesion_idioma=1&$menu=1&identifica=participa&nombrexml=104

Ahí había algo que no me cuadraba... eso de $sesion_idioma, $menu, me hace pensar que de alguna forma las variables del código no están siendo filtradas y que las muestra directamente en la barra de direcciones, y probablemente el valor que estas tomen se verá reflejado de alguna forma en el código fuente de la página y con ello el valor que le demos.

Una prueba nos sacará de dudas:


http://xxxx/yyyy/zzzz.php?$sesion_idioma='&$menu=1&identifica=participa&nombrexml=104

Mirando el contenido de la página notamos que ha cambiado, eso me indica que en cierta manera, lo que pase a los parámetros de la url se verá reflejado en el contenido de esta. Pero vamos hacer otra prueba más, y comprobemos si en el código hay alguna parte donde se haga referencia a esto.



Vamos que estábamos en lo cierto y cualquier cosa que coloquemos en las variables se reflejará en el código fuente. Intentemos ejecutar directamente código PHP en cualquiera de las variables, si todo funciona y teníamos razón conseguiremos que en aquellos lugares del código fuente donde se reflejen los valores pasados a las variables se sustituya por el resultado devuelto de la ejecución de nuestra instrucción.

Vamos a probar con lo siguiente:



Simplemente vamos a tratar de realizar una inyección de código, que una vez interpretada por el servidor nos devolverá lo siguiente:


Parece que alguien no ha hecho la tarea bien en más de una ocasión.

El problema de los formularios con cURL

| 1 comentarios |

A veces pensamos que las restricciones que se imponen en algunos portales para poder comentar una noticia o simplemente rellenar los campos de un formulario son una tontería, pero si están ahí es por algo. Ya sea un captcha, autentificación, token o cualquier método que se os pueda ocurrir.

El caso es que si no haces tus deberes como es debido y planteas un mecanismo patatero, te puede costar caro. Y eso es con lo que me he encontrado hace un rato mientras visitaba cierta página web.

Tenemos como escenario un servicio para recomendar la citada web a nuestros contactos mediante un simple formulario con el que enviamos un correo.



Lo primero que se me ha ocurrido ha sido rellenar los datos con valores falsos y poner una cuenta de correo válida para el remitente. El resultado ha sido el esperado y he recibido en mi bandeja de entrada un correo.

Lo siguiente que he pensado ha sido realizar un pequeño script en php que mediante cURL recibiera los parámetros del formulario, los rellenara con los valores que quisiera y con un bucle indicara el número de mensajes que quería hacer llegar a la víctima. El resultado, ha sido el esperado:



Sí, son 360 mensajes en un intervalo de 20 segundos a la cuenta de correo del remitente, ¿alguien necesita viagra?

El script, bastante sencillo no ha ocupado más de 15 líneas [script]. El resto ha sido ejecutar el código en el servidor de pruebas y esperar al resultado:


Denada, todo un placer.


He borrado algunas partes del mismo por razones obvias, no obstante si alguno está interesado en ver cómo funciona cURL puede visitar las páginas de PHP.

19 abr. 2010

Adress space layout randomization

| 0 comentarios |

Introducción


Más conocida como ASLR, es una técnica de seguridad que se viene encargando de la aleatorización de direcciones de memoria. De forma que no podamos predecir cuál será la dirección de retorno de un determinado buffer o de cualquier otra dirección que se encuentre en la pila.

Esto complica la tarea de cualquier atacante que intente ejecutar un ataque de return-to-libc que tendrá que buscar el código a ejecutar, o aquellos que traten de ejecutar una shellcode, deberán primero averiguar dónde se encuentra la pila.

¿Cómo funciona?


Para demostrar el funcionamiento vamos a utilizar el siguiente código.Que compilaremos utilizando la opción -ggdb:

$ gcc -ggdb -o Prueba Prueba.c

/tmp/ccCPLK8V.o: In function `main':
/home/sebas/Lab/Ensamblador/Prueba.c:19: warning: the `gets' function is dangerous and should not be used.


El mensaje de aviso, es para indicarnos que la función gets es peligrosa y no debería ser utilizada, esto es debido a que no estamos controlando en ningún momento la longitud que vamos a introducirle y podríamos provocar un buffer overflow.

Si ejecutamos la aplicación y hacemos un grep por el nombre de esta para que nos muestre información del proceso, obtenemos la siguiente información:

$ ps -aux | grep Prueba
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
sebas 11777 0.0 0.0 1656 328 pts/0 S+ 00:32 0:00 ./Prueba 10 40
sebas 11783 0.0 0.0 3352 812 pts/1 S+ 00:32 0:00 grep Prueba


El PID es el 11777, ahora podemos buscarlo en la carpeta /proc y mostrar por pantalla cómo está organizada la memoria para permitir la ejecución de la aplicación:

$ cat /proc/11777/maps
08048000-08049000 r-xp 00000000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
08049000-0804a000 r-xp 00000000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
0804a000-0804b000 rwxp 00001000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
b75ac000-b75ad000 rwxp b75ac000 00:00 0
b75ad000-b7709000 r-xp 00000000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b7709000-b770a000 ---p 0015c000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b770a000-b770c000 r-xp 0015c000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b770c000-b770d000 rwxp 0015e000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b770d000-b7710000 rwxp b770d000 00:00 0
b7722000-b7725000 rwxp b7722000 00:00 0
b7725000-b7726000 r-xp b7725000 00:00 0 [vdso]
b7726000-b7742000 r-xp 00000000 08:09 65422 /lib/ld-2.9.so
b7742000-b7743000 r-xp 0001b000 08:09 65422 /lib/ld-2.9.so
b7743000-b7744000 rwxp 0001c000 08:09 65422 /lib/ld-2.9.so
bfaad000-bfac2000 rw-p bffeb000 00:00 0 [stack]


El segmento de direcciones donde se encuentra nuestra pila es bfaad000-bfac2000 y el offset es bffeb000. Si probamos ahora a repetir el mismo proceso (ejecutando la aplicación y averiguando su respectivo PID) obtenemos el siguiente resultado.

$ cat /proc/13372/maps
08048000-08049000 r-xp 00000000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
08049000-0804a000 r--p 00000000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
0804a000-0804b000 rw-p 00001000 08:09 850507 /home/sebas/Lab/Ensamblador/Prueba
b7668000-b7669000 rw-p b7668000 00:00 0
b7669000-b77c5000 r-xp 00000000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b77c5000-b77c6000 ---p 0015c000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b77c6000-b77c8000 r--p 0015c000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b77c8000-b77c9000 rw-p 0015e000 08:09 82774 /lib/tls/i686/cmov/libc-2.9.so
b77c9000-b77cc000 rw-p b77c9000 00:00 0
b77de000-b77e1000 rw-p b77de000 00:00 0
b77e1000-b77e2000 r-xp b77e1000 00:00 0 [vdso]
b77e2000-b77fe000 r-xp 00000000 08:09 65422 /lib/ld-2.9.so
b77fe000-b77ff000 r--p 0001b000 08:09 65422 /lib/ld-2.9.so
b77ff000-b7800000 rw-p 0001c000 08:09 65422 /lib/ld-2.9.so
bfeed000-bff02000 rw-p bffeb000 00:00 0 [stack]


El segmento donde se encuentra nuestra pila ha cambiado, teniendo ahora el valor de bfeed000-bff02000, lo que se mantiene igual es el valor del offset a bffeb000.

Este hecho viene provocado por la variable del sistema randomize-va-space, que nos permite especificar al sistema el tipo de aleatorización a utilizar, donde:

  • value 0 - Desactiva la aleatorización del espacio de direcciones ocupado por el proceso. Se establece por defecto en aquellos sistemas que no soportan esta característica o son iniciados con el parámetro norandmaps

  • value 1 - Asigna direcciones de memorias aleatorias a mmap base, stack y VDSO page. Entre otras cosas las librerías compartidas son cargadas en direcciones al azar, incluyendo también los binarios de PIE-enlazados y el inicio de ejecución de la aplicación. Se establece por defecto si la opción CONFIG_COMPAT_BRK está activada.

  • value 2 - Adicionalmente habilita la aleatorización del montículo (heap). Se establece por defecto si la opción CONFIG_COMPAT_BRK está desactivada.



Para ver el valor que tenemos asignado basta con: cat /proc/sys/kernel/randomize_va_space y si quieres cambiarla: echo valor_numerico > /proc/sys/kernel/randomize_va_space

Quizás sea oportuno comentar que existen varias formas de saltarse este tipo de protección a día de hoy, y que confiar plenamente en ello puede generarnos una falsa sensación de seguridad que podría ocasionarnos algún que otro disgusto. También se pondrá en duda esa aleatoriedad a la hora de generar los segmentos de memoria, donde comprobaremos que realmente sólo 3 bytes de los 4 que componen nuestra dirección sufrirán variación alguna, provocando que de los 32 bits que esta ocupa, tan sólo sean 24 los que sufren el cambio. Pero de eso hablaremos en otra entrada, hoy sólo vamos a mostrar en qué consiste.