[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.