Introduccion Escribir y entender como funciona una shellcode es un tema que tengo pendiente desde hace mucho tiempo y que mejor manera de intentarlo que con una serie de posts sobre el tema. Creo que el conocimiento sobre esta temática esta pendiente en varias personas, muchos de los que nos dedicamos a infosec en algun momento aprendimos como realizar el análisis de una vulnerabilidad del tipo buffer overflow, descubrimos donde falla la aplicación, como redirigir el flujo del programa, buscamos los “bad chars”, pero al momento de escribir la shellcode usamos nuestro querido msfvenom o copiamos una del sitio “shell-storm” a modo de POC, esto no es casualidad desarrollar y entender como se escribe una shellcode requiere una serie de conocimientos previos algunos de los cuales ya los adquirimos mientras aprendíamos sobre BOF como por ejemplo, manejar un debugger, lenguaje ensamblador, como funciona el stack, etc.

WiFi Cooperativo en la aldea de montaña Esta prueba se realizó en un entorno controlado con los permisos de los clientes adjudicatarios de los dispositivos involucrados, con el fin único de reconocer el nivel de seguridad de acceso a los dispositivos wifi desde una perspectiva ética de investigación en InfoSec. Pasé tres semanas en San Martín de los Andes y noté que las claves WiFi por defecto del único proveedor de Internet tienen un patrón sumamente sencillo.

En la primera parte vimos como encontrar el offset a parchear con frida, a partir de ahi solo deberíamos ejecutar el script de frida para que parchee la aplicacion que deseemos en memoria. Debido a que no deseaba rootear mi celular esto trajo aparejado otro desafiado. Para resumir lo que haremos es lo siguiente. Desempaquetar nuestro APK objetivo Descargar el gadget de frida según la arquitectura de la aplicación objetivo arm64 o arm32.

Aun recuerdo cuando la vida era mas fácil para los chismosos y el SSL era utilizado con suerte solo en el envió del login, el resto de la información viajaba sin cifrar, mas o menos en 2010 eso empezó a cambiar luego de que saliera la extension de Firefox Firesheep cualquier persona con solo instalarse la extension podía realizar un ataque del tipo “man in the middle” robarse las cookies de sesión de sitios como Facebook, Twitter, Google y realizar un “session hijacking” o secuestro de sesión y sin saber la contraseña entrar en la cuenta del usuario afectado, junto con la expansión de las redes WIFI publicas esto era un gran problema,muchos se habian convertido en un potencial “hackerman”.

El año pasado fue mi primer eko, después de bastante tiempo, retomé mi pasión por la seguridad informática. Esa curiosidad, sobre todo por entender cómo funcionan las cosas y cómo podría utilizarse ese funcionamiento para otros fines. A diferencia del año pasado, esta eko me encontró participando de un team (BHF) y además con algunas nociones para poder encarar los CTF’s, cosa que el año anterior no hubiese imaginado. Shebi nos anotó como equipo en dos CTF’s: Pucará y Onapsis.

WOW!! La EKO ya terminó y pasó todo muy rápido! Aún queda el cansancio y cuesta conciliar el sueño pensando en todo el contenido que hubo, en las otras posibles soluciones a las que encontramos y las de los retos que no pudimos solucionar. Fueron 3 días intensos de charlas, CTF’s, café y cerveza! “Drink all the booze hack all the things!” Desde que nos enteramos que habría un CTF en el espacio RedTeam nos propusimos intentarlo, el mismo se definía según sus autores de la siguiente manera: CTF RedTeam Space El principal objetivo del Red Team es validar las capacidades de una organización contra ciberamenazas.