sábado, 8 de octubre de 2016

Docker: a pentester tool

Muchas veces, cuando realizas un pentest o solo por investigación, es necesario levantar un servidor similar al que estas "atacando" para realizar pruebas.

Esto generalmente se puede hacer con maquinas virtuales, en las cuales instalamos el sistema operativo, el software base y finalmente el software a probar.
Esto podría no ser complicado para alguien que tiene experiencia con servidores (si eres pentester deberías poder hacerlo).

Otra alternativa puede ser usar servicios como DigitalOcean, Amazon, Bluemix, etc. para, con un click, levantar los servicios. Ejemplo: https://www.digitalocean.com/products/one-click-apps/
Esto es muy fácil, generalmente es gratis los primeros 30 días, y luego si consumes pocos recursos podría llegar a seguir siendo gratis (previo ingreso de tu tarjeta de crédito).

Finalmente, algo que no cuesta y sigue siendo muy fácil, DOCKER.

Como lo instalas?:
https://docs.docker.com/engine/installation/linux/ubuntulinux/


A modo de ejemplo instalaremos un TOMCAT.
==================================
Primero necesitamos crear una "imagen" del aplicativo que queremos crear, en este caso TOMCAT.

Archivos necesarios:
Dockerfile
tomcat-users.xml

"tomcat-users.xml" con el siguiente contenido (para tener un usuario válido para la consola de administración):
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="manager-gui" />
  <user username="tu_usuario" password="tu_password" roles="manager-gui"/>
</tomcat-users>

"Dockerfile" con este contenido:
FROM tomcat
ADD tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
EXPOSE 8080

Una vez que tenemos los dos archivos, construimos la imagen de docker (que finalmente será como un archivo ISO).
Esto puede llegar a tomar un tiempo.
docker build -t tomcat .

Luego levantamos el aplicativo:
docker run --name tomcat666 -p 8080:8080 tomcat

Finalmente accedemos a la consola de administración web:
http://localhost:8080

Con esto ya tenemos un TOMCAT listo para probarlo. Ideas?:
Prueba reGeorg: https://github.com/sensepost/reGeorg

Ahora tu instala un wordpress para que pruebes el weevely: https://github.com/epinna/weevely3

<FIN>

sábado, 7 de marzo de 2015

Kali + Ruby + Oracle

Hoy me levanté como casi todos los días a las 7 a.m. y comencé a preparar todo para pasar un sábado genial. NO chibolo pulpín. NO me estaba preparando para ir a la playa!

Comencé a levantar y a actualizar las maquinas virtuales.
Tomé desayuno y luego me dispuse a comenzar con el ataque a los oracle.
Ya tenía los SIDs, asi que cargue el modulo "auxiliary/admin/oracle/oracle_login" del metasploit y me sale:
  msf auxiliary(oracle_login) > run
  [-] Failed to load the OCI library: cannot load such file -- oci8
  [-] Try 'gem install ruby-oci8'

"Santa cachucha Batman!" si esto funcionaba bien!, ya estaba configurado siguiendo los pasos de "http://blog.infosecsee.com/2013/08/how-to-get-oracle-support-in-metasploit.html" hace varios meses atrás.

Luego de varias horas, y de entender un poco de ruby, las gemas, y etc. "Creo" que he entendido de que se trata.

Más o menos la historia es la siguiente:
-----------------------------------------------

En un Kali-linux-1.1.0-amd64.iso recién instalada sin actualizar:
   #ruby -v
   ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

   #msfconsole
   msf> ruby -v
   ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

En un Kali-linux-1.1.0-amd64.iso actualizado:
   #ruby -v
   ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

   #msfconsole
   msf> ruby -v
   ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux-gnu]

Claro que me di cuenta de eso después de varias horas, y ese fue el hilo de la madeja para "tratar" de solucionar el problema.

En ese mismo Kali-linux-1.1.0-amd64.iso actualizado:
   #cd /opt/metasploit/ruby/bin/
   #./ruby -v
   ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux-gnu]

"Santos frijoles saltarines Batman!" Metasploit ahora maneja su propia instancia de ruby?

Más o menos se corrige así (espero que no haya roto ninguna dependencia):
-------------------------------------------------------------------------------------------
Como "gem install ruby-oci8" no funciona y sólo funciona descargar la fuente ruby-oci8-2.1.7.zip y hacer make & make install.

La siguiente pregunta era como hacer correr eso en la "instancia" del ruby 2.1.5 de metasploit.
Bueno, nos quedaremos sin la respuesta. Si alguien la sabe me la copia como comentario.

Lo que hice al final fue:
Instalar rvm para poder instalar ruby 2.1.5
   #gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
   #\curl -L https://get.rvm.io | bash -s -stable --ignore-dotfiles --autolibs=0 --ruby=2.1.5
   #echo source /usr/local/rvm/scripts/rvm >> /root/.bashrc

Cierran su terminal y vuelven a abrir una nueva (para que cargue el nuevo cambio en el bashrc)
   #ruby -v
   ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux-gnu]
   #cd /opt/oracle/ruby-oci8-2.1.7. (obviamente ya hicieron 'unzip ruby-oci8-2.1.7.zip')
   #make
   #make install
   #mv /opt/metasploit/ruby/ /opt/metasploit/ruby.old

   #msfconsole
   msf> ruby -v
   ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux-gnu]

  msf auxiliary(oracle_login) > run

!PUM! !ZOCK! !BANG!
Espero les sirva.
P.D. Al final SI es un sábado GENIAL.
   




martes, 8 de abril de 2014

¿Cómo se llama la película?

Historia en tres actos:

1. Un Ministro(a) lanza a los cuatro vientos un nuevo aplicativo informático:
En este caso (según Peru21), la ministra de Comercio Exterior, Magali Silva

2. Efectivamente el aplicativo, se encuentra en línea, y al "parecer" funciona "adecuadamente"

3. WTF! El aplicativo viene con "regalo"
3.1 Continuar en el paso 1 sin elegir nada (da la "impresión" que no se debe elegir nada)
3.2 Elegir "Seleccionar todos los bancos" en el paso 2

¿Cómo se llama la película?
1. Me llega al chopin tus NTPs?
2. No tengo presupuesto para contratar personal capacitado?
3. El Ministro indico que el aplicativo salga como sea porque hay que salir en los medios?
4. No tengo ambiente de pruebas, así que hago las pruebas en el ambiente de producción?
5. Lo dejo pendiente para después del OWASP Latam Tour?
6. Quiero ser voluntario de Lulzsec?
7. Como Ministro no me debo preocupar en la seguridad?

jueves, 20 de marzo de 2014

XXE online

Hace unos días Cesar nos regaló un Post bastante interesante sobre XXE.
Al respecto y para que practiquen un poco HACIENDO las cosas (y no sólo leyendo una bonita vulnerabilidad y nunca hacerla) tenemos  a la mano la "comunidad" de HACK.ME (Hack.me tiene varias pruebas y retos que te harán practicar en ambientes autorizados lo que tanto has leído, así que no tienes excusas).

Para XXE tienen un "reto" Hack with XXE elaborado por Denis Kolegov, que nos permitirá practicar muchas cosas que están en el Post de Cesar.

Como verás, el "reto" nos muestra una pantalla común de login:

El objetivo según la descripción del "reto" es tener acceso a las sesiones de los usuarios explotando XXE.
Si bien no lo dicen directamente en la descripción, el reto consta de dos partes (los tags del reto son bruteforce y xml):
1. Enumerar usuarios válidos (bruteforce)
2. Explotar XXE para obtener  las "sesiones de los usuarios" (xml)

Aquí la ADVERTENCIA, ya que a continuación resolveré el "reto". Así que por favor has un esfuerzo, no sigas leyendo, RESUELVE tú el reto, y si tienes problemas para resolverlo, regresa por acá para que busques pistas que te permitan seguir avanzando.

Parte 1 - enumerar usuarios:
Entonces la idea es poner valores aleatorios y verificar como reacciona la aplicación, tanto en el browser como en un proxy tipo burp o zap (burp lover así  que usaré burp).

Si ingreso la combinación usuario:password
En el browser muestra por un breve tiempo "Incorrect username or password", el mismo mensaje nos sale en la respuesta de burp.

Teóricamente debería realizar bruteforce para enumerar usuarios válidos, pero probemos con los evidentes no?
Si ingreso la combinación admin:password
En el browser muestra por un breve tiempo "Incorrect username or password", el mismo mensaje nos sale en la respuesta de burp.

He aquí la importancia en los detalles (de paso comprobamos que no toda vulnerabilidad la encontrará un herramienta automatizada).
Vemos ambas respuestas en el burp (izquierda user:usuario / derecha user:admin):
Observas la diferencia?
Tenemos un header "X-Auth-Policy" con el valor:
e3N0b3JhZ2U6InNlY3JldC50eHQiLHBhdGg6Ii8iLHByaW5jaXBhbDoidG9rZW4ifQ==
Se puede apreciar a simple vista que está codificando en base64, entonces decodificando tenemos:
{storage:"secret.txt",path:"/",principal:"token"}

Entonces podríamos presumir por las respuestas diferentes que hemos acertado con por lo menos un usuario válido: admin.
Y es este usuario el que usaremos en el resto de request.

Parte 2 - explotar XXE:
Observamos el request cuando se realiza el login, y en el body del request tenemos:
<user><login>admin</login><password>password</password></user>

Entonces aplicando el Vector 1:File disclosure del Post de Cesar, modificamos el body del request :
<!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<user><login>admin</login><password>password</password><data>&xxe;</data></user>

Esto nos da como respuesta:
<br />
<b>Warning</b>:  simplexml_load_string() [<a href='function.simplexml-load-string'>function.simplexml-load-string</a>]: I/O warning : failed to load external entity &quot;file:///etc/passwd&quot; in <b>C:\inetpub\wwwroot\coliseum\client\sandbox\20901-101587\BODY\inner\login.php</b> on line <b>19</b><br />
Unknown parameter data with "" value
Incorrect username or password

Que paso? algo está mal? no sirve la teoría? Keep calm and toma tu aguita de coco.
Hemos requerido el archivo /etc/passwd y la aplicación nos responde con un error y nos da una ruta:
C:\inetpub\wwwroot\coliseum\client\sandbox\20901-101587\BODY\inner\login.php
Con esa información modificamos una vez más nuestro request:
<!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///C:/inetpub/wwwroot/coliseum/client/sandbox/20901-101587/BODY/inner/secret.txt">]>
<user><login>admin</login><password>password</password><data>&xxe;</data></user>


Como se que el archivo era secret.txt? Leer al final de la "Parte  1"
Con esto obtenemos las "sesiones de los usuarios" y finalizamos el reto:
comment:"Congratulations! You Hack Me!!!"

Porque no puedo leer otros archivos? Por permisos de usuario

Al infinito y más alla- explotar XXE:
Si bien ya hemos "cumplido" con el reto, vamos tenemos un ambiente virtual, porque no seguir probando cosas no?
Porque no tratar de leer el código fuente para así comprender mejor la aplicación y encontrar más "vulnerabilidades"?
Bueno no pondré la teoría (tal vez Cesar continúe su Post para una parte 2?), ni explicaré porque tengo que usar cosas como "php","filter","read", "convert", etc.
El objetivo: leer el código fuente del archivo login.php
Aquí el "ataque":
<!DOCTYPE root[<!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=login.php">]>
<user><login>admin</login><password>password</password><data>&xxe;</data></user>

Y como respuesta tenemos el código fuente codificado en base64, ya Uds. hagan su tarea.


En el código fuente vemos que los usuarios son:
 $Users = array('admin','administrator','test','guest','root');

Nota final:
Las herramientas automatizadas sirven, pero nunca reemplazarán la labor manual de un atacante experimentado.





martes, 4 de marzo de 2014

Dame tu POI

En todo pentest hay una etapa de "Information Gathering" (https://www.owasp.org/index.php/Testing:_Information_Gathering), que consiste en recolectar la mayor información posible de nuestro "objetivo".

Bien, en el Perú (no se si en otros lados) gracias a la ley de transparencia y el OSCE, tenemos información a caudales de las entidades públicas para este fin.

Adicionalmente tenemos el Plan Operativo Informátivo (a.k.a. POI), que según la RM 019-2011-PCM, debe estar registrado en los portales web (todos los años) antes del último día hábil del mes de febrero.

Entonces estas fechas son propicias para ir guardando información tan valiosa para un "ataque", por ejemplo con un simple google dork: "plan operativo informático" site:.gob.pe.
Si no está indexado por google, entonces bastará con entrar a las páginas webs de las entidades y buscar las últimas resoluciones. Y por último, podemos apelar a la ley de transparencia y pedir esa información formalmente.

Por ejemplo algunos POI:
  • http://www.migraciones.gob.pe/informacion/rd/Plan_Operativo_Informatico.pdf
  • http://www.mef.gob.pe/index.php?option=com_docman&task=doc_download&Itemid=0&gid=11060&lang=es

En el POI de la Superintendencia Nacional de Migraciones vemos:
  1. Tiene 3 Servidores con Windows 2000 (estarán visibles desde internet?)
  2. Tienen 533 computadoras y 7 laptops (540 estaciones finales), tienen 217 Windows XP y 249 Windows 7 (osea 466 SO para estaciones finales, cuadra con las 540 físicas?) y tienen 255 licencias de Eset NOD32 Antivirus (cuadran con los 466 SO?)
  3. Ausencia de herramientas de seguridad informática, alineadas al ISO 27000 y normas técnicas peruanas.
  4. Quieren implementar una aplicación Web que permita generar en línea los certificados de movimientos migratorios firmados digitalmente, con las validaciones y medidas de seguridad correspondientes (tendrá medidas contra slqi y xss?).

En fin, información más que interesante para un atacante ético (para un atacante real y para ataques de otros gobiernos).
Será necesario que ventilen dicha información de esa forma? (según la RM 019-2011-PCM, están OBLIGADOS a hacerlo).

martes, 25 de febrero de 2014

GitHub nuestro de cada día

Creo que todos sabemos que el control de versiones y sacar "backups" continuos son buenas prácticas.
Creo que todos también conocemos un poco acerca de GitHub (http://es.wikipedia.org/wiki/GitHub).

Lo que no parece claro es que no todos saben (o quieren saber) es que la cuenta GRATUITA de GitHub expone todo lo que publicamos:
"El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago." 

Partiendo de eso:
Google: site:github.com peru notaria




Y por lo menos al parecer, la versión de producción es similar a la que se encuentra en forma PÚBLICA en GitHub:




Entonces, tú que has pagado tus miles de dolares a una persona o empresa para desarrollar tu página web o aplicación web, revisa por ejemplo si el código de tu aplicación web esta expuesto (Con el código es más fácil atacar no?).

Ahora revisa con paciencia y encontrarás como parte del código expuesto, archivos de configuración en general con contraseñas, usuarios, etc. (Y si reutilizo contraseñas?)

miércoles, 18 de diciembre de 2013

Exponer Targets de Samurai en la LAN

Advertencia: Hacer esta modificación expone servicios vulnerables en la LAN!

Muchas veces, se necesitan ambientes de prueba vulnerables para practicar o para un lab.

La distribución de SAMURAIWTF2.1 viene con unos cuantos: DVWA, Webgoat, etc. Pero sólo están configurados para ser accedidos desde localhost.

Para exponer en la LAN Webgoat:
modificar en el archivo /etc/tomcat7/server.xml
<Connector address="192.168.0.100" port="8080" protocol="HTTP/1.1"
donde debemos reemplazar 192.168.0.100 por la dirección de nuestra interface de red

Para exponer en la LAN Mutillidae:
reemplazar en el archivo /etc/apache2/sites-available/mutillidae
<VirtualHost 127.42.84.6:80>
por
<VirtualHost *:8090>