20 sept 2018

8dot8 en #Chile Talleres de Ethical Hacking y #Metasploit ¡Para no perderse!

Los próximos 22 y 23 de octubre tengo el placer de estar impartiendo, dentro de la 8dot8, dos talleres muy especiales para mí. El lunes 22 de octubre tendrá lugar el taller Metasploit para pentesters. He tenido la suerte de tener dos charlas en la 8dot8, en 2014 y en 2015, y esta vez toca impartir talleres.

Para cualquier tipo de duda y más información se puede consultar la siguiente dirección de correo electrónico: talleres@8dot8.org. El temario puede encontrarse en este enlace



El segundo taller tendrá lugar el martes 23 de octubre. El taller es sobre Hacking Ético y técnicas modernas del día a día en el ámbito del Pentesting. A continuación, se puede ver el temario y contenido del curso, eminentemente práctico:


El precio de los talleres es de 8 UF, como se puede ver en la propia página del evento, salvo el de Salvador Mendoza que es de 16 UF. Si estás por Chile para el evento de la 8dot8 no dudes en pasarte por los talleres. Un precio ajustado para unos talleres especiales en este año en la 8dot8. Además, Salvador Mendoza imparte otro taller sobre hacking con NFC que también tiene pintaza! Nos vemos en Santiago de Chile los días 22 y 23 de octubre.

11 sept 2018

Explotación de sistemas Android con ADB y Shodan.io

Hola gente, ¿cómo están?. En primer lugar como siempre darle las gracias especialmente a los administradores de este gran blog, los señores “Juan Antonio Calles” y “Pablo Gonzalez” por darme un espacio en Flu-Project. Lo que les voy comentar es un bug/feature que permite tener una Shell local en más de 35.000 Androids, algunos de ellos root, que se conectan con ADB (Android Debug Bridge).


A continuación os copiamos algunos detalles sobre ADB extraídos de la fuente oficial, por si no estáis familiarizados con esta herramienta:

Android Debug Bridge (ADB) es una herramienta de línea de comandos versátil que permite comunicarse con una instancia de un emulador o un dispositivo Android conectado. Esta herramienta proporciona diferentes acciones en los dispositivos, como la instalación y la depuración de aplicaciones, y proporciona acceso raíz de Unix que se puede utilizar para ejecutar varios comandos en un emulador o un dispositivo conectado. Es un programa cliente-servidor que incluye tres componentes:

  1. Un cliente: que envía comandos. El cliente se ejecuta en el equipo de desarrollo. Puede invocar un cliente desde un terminal de línea de comandos mediante la emisión de un comando ADB.
  2. Un daemon: que ejecuta comandos en un dispositivo. El daemon se ejecuta como un proceso de fondo en cada instancia del emulador o dispositivo.
  3. Un servidor: que gestiona la comunicación entre el cliente y el daemon. El servidor se ejecuta como un proceso en segundo plano en el equipo de desarrollo.
Se puede encontrar la herramienta adb en el siguiente link: https://adb.clockworkmod.com/

¿Cómo funciona ADB?

Cuando se inicia un cliente de ADB, el primer cliente comprueba si hay un ADB corriendo un proceso del servidor. Si no es así, inicia el proceso de servidor. Cuando se inicia el servidor, se une al puerto local TCP 5037 y busca los comandos enviados por los clientes ADB; todos los clientes ADB utilizan el puerto 5037 para comunicarse con el servidor de ADB.


A continuación, el servidor establece conexiones con todas las instancias de emuladores o dispositivos en funcionamiento. Localiza las instancias de emuladores o dispositivos mediante el escaneo de los puertos con números impares en el rango del 5555 al 5585. Cuando el servidor encuentra un demonio ADB, se establece una conexión con ese puerto. 

Cada instancia del emulador o dispositivo adquiere un par de puertos secuenciales; un puerto con número par para las conexiones de la consola y otro con número impar para las conexiones ADB. Por ejemplo:
  • Emulador 1, consola: 5554
  • Emulador 1, adb: 5555
  • Emulador 2, la consola: 5556
  • Emulador 2, ADB: 5557
y así...

Como se muestra, la instancia del emulador conectado a ADB en el puerto 5555 es la misma que la instancia cuya consola es responsable de recibir en el puerto 5554.

Una vez que el servidor establece conexiones con todas las instancias del emulador, puede utilizar los comandos ADB para acceder a esos casos. Dado que el servidor gestiona las conexiones a las instancias del emulador o dispositivo y maneja los comandos de diferentes clientes ADB, puede controlar cualquier instancia del emulador o dispositivo desde cualquier cliente (o desde un script).

Los sistemas android tienen el puerto 5555 abierto y se puede conectar a ellos con un PC mediante el comando:
  • adb connect ip: 5555
O con esta aplicación de ejemplo:
Adb shell es una aplicación de terminal que permite conectarse al servicio de ADB mediante otros dispositivos Android a través de la red y ejecutar comandos de terminal. Esto puede ser útil para depurar de forma remota los dispositivos Android.

Esta aplicación es un wrapper de ADB. Mantiene un historial de 15 comandos a los que se puede acceder mediante una presión prolongada del botón principal. Una presión larga en la pantalla del terminal en sí dará la opción de enviar un Ctrl + C, alternar el desplazamiento automático, o salir de la sesión de terminal.



Esto funciona de la misma manera que el comando "adb shell" trabaja en un ordenador, debido a que esta aplicación utiliza una implementación nativa del protocolo de ADB en Java, que no requiere root. Los dispositivos simplemente hablan el mismo protocolo entre sí, al igual que lo harían con un equipo que ejecuta el cliente ADB desde el SDK de Android.

Para conectarse a un dispositivo Android remoto, tan solo es necesario introducir la dirección IP del dispositivo y el número de puerto (5555).

Si ahora buscamos en shodan.io dispositivos Android con dicho puerto expuesto, nos encontraremos con un gran número de terminales expuestos:


Presentado el problema, un potencial atacante podría seleccionar facilmente una víctima y utilizando la herramienta que cité anteriormente podría acceder remotamente via shell a uno de dichos terminales:

Con escribir la dirección ip y el valor por defecto del puerto 5555, tendremos una Shell en el Android remoto }:)





Como se puede ver en estas imágenes, se trata de pruebas controladas xD:

Espero que les haya interesado y sed buenos…

Saludos a.k.a Rootkit pentester.

8 sept 2018

Primer malware que explota el exploit de ALPC LPE

Como ya hemos comentado en entradas anteriores, hace unos días una investigadora de seguridad descubrió un 0-day que permite la escalada de privilegios local hasta SYSTEM en Windows 10 a cualquier usuario del sistema.




Como podemos leer en el blog de ESET, han pasado sólo dos días hasta que han encontrado la primera muestra que hace uso de este jugoso exploit. La muestra, asociada a una campaña del grupo bautizado como PowerPool, se ha detectado en Chile, Alemania, India, Filipinas, Polonia, Rusia, el Reino Unido, Estados Unidos y Ucrania.

Los actores maliciosos han modificado el exploit original para cambiar los privilegios del fichero de actualizaciones de Google, situado en el siguiente directorio:


Una vez cambiados los privilegios, lo pueden sustituir con el second-stage de su malware, consiguiendo así obtener permisos de SYSTEM cada vez que se ejecute el sistema de actualizaciones de Google.

Aunque no se tienen demasiados datos, parece que el compromiso inicial lo están realizando al menos mediante dos mecanismos. El primero de ellos es el envío directo de un first-stage como adjunto de correo a buzones concretos. El segundo es mediante spam con ficheros .slk, que permite el compromiso a través de un mecanismo ya reportado a finales de mayo en los foros del Internet Storm Center del SANS.

Este segundo mecanismo permite ejecutar código desde Excel. Podemos ver el ejemplo mostrado en los foros del SANS, en el que se puede ver que si actualizas el código dinámico de una celda acabaríamos ejecutando un típico ataque basado en Powershell.


Durante la investigación han encontrado, precisamente, un ejemplo de estos correos de SPAM con un fichero slk malicioso.


Tras el análisis del malware parece confirmarse que el first-stage ofrece un mecanismo de triaje a los operadores. El malware puede ejecutar algunos comandos básicos dirigidos al reconocimiento del sistema afectado, es capaz de tomar capturas de pantalla de la víctima, y posteriormente puede exfiltrar la información al C&C junto a datos de configuración del proxy del sistema. Como dato curioso, los operadores han cometido el error de tener la dirección del servidor de comando y control hardcodeada en el código.

Presumiblemente, una vez que los operadores deciden que un sistema es interesante, utilizan el first-stage para descargar la carga secundaria. De nuevo, en este segundo stage el malware tiene hardcodeados los datos del C&C, y se ha confirmado que los operadores no tienen capacidad de actualizar esta importante configuración del malware. Esta carga secundaria permite a los operadores ejecutar comandos, matar procesos, subir y bajar ficheros, y listar los contenidos de carpetas del sistema.

Las herramientas que utilizan los actores maliciosos para ayudarse en la etapa de movimiento lateral son viejas conocidas para la mayoría, como son PowerDump, PowerSploit, Invoke-SMBEnum, Quarks PwDump y FireMaster.

Era de esperar que con la publicación abierta de semejante 0-day, que sigue sin ser parcheado por Microsoft, algún grupo malicioso lo incorporase en su arsenal. Mientras tanto, podéis estar al tanto de los IOC disponibles, o intentar desplegar la mitigación no aprobada por Microsoft que se menciona en el CERT/CC.


¡Un gran trabajo de ESET!

Fuente: https://blog.zerolynx.com/2018/09/primer-malware-que-explota-el-exploit.html

4 sept 2018

Escalando privilegios en Windows 10: Segunda Parte



En la primera entrada sobre la reciente vulnerabilidad de escalada de privilegios local en Windows 10 comentábamos como a través de un enlace duro (hard link), y gracias a la falta de control sobre los permisos, era posible modificar los permisos de forma arbitraria en cualquier objeto del sistema.

Entrando un poco más en detalle, podemos observar que el primer problema reside en que el método SchRpcSetSecurity del Task Scheduler, accesible de forma externa a través de ALPC, no realiza una correcta impersonalización antes de establecer el descriptor de seguridad que define los permisos sobre el objeto que se quiere modificar. Lo lógico sería que, antes de realizar esta acción, el método impersonalizase al proceso que ha llamado a la función, usándose así por tanto los privilegios de dicho proceso para decidir sobre la capacidad de definir descriptores de seguridad sobre cualquier objeto. Sin embargo, esta acción no es realizada correctamente y por tanto se utilizan los propios permisos del Task Scheduler, con la suerte de que este proceso corre con permisos de SYSTEM. Por tanto, tenemos capacidad de asignar cualquier tipo de permiso sobre cualquier tipo de objeto.

Como ya hemos comentado, el segundo problema reside en que además esta acción se puede ejecutar no sólo sobre un objeto final, sino sobre una suerte de enlace simbólico. Gracias a esta incorrecta elección de diseño, es posible utilizar enlaces para redirigir esta modificación de permisos a cualquier objeto del sistema.

Con estos elementos encima de la mesa se repite la historia de siempre. Somos capaces de modificar cualquier ejecutable del sistema, que normalmente estaría protegido frente a modificaciones, y sólo tenemos que esperar a que un proceso privilegiado lo ejecute por error.

SandboxEscaper simplemente encontró una posible vía de ataque, aunque ella misma reconoce en su WriteUp que pueden existir más. Durante su investigación comprobó que al ejecutar la impresora XPS a través del servicio SpoolSv, se ejecutaba una dll del sistema llamada PrintConfig.dll. Además, teníamos la suerte de que habitualmente esa dll no estaba cargada directamente en el sistema, ya que de lo contrario intentaríamos modificar una dll ya cargada y nos encontraríamos con problemas de violaciones de acceso.

Por tanto, su demostración sigue los siguientes pasos:


  1. Crea un fichero UpdateTask.job en %SystemRoot%\Tasks, donde cualquier usuario (guest incluido) puede escribir para poder crear tareas programadas. Este fichero, sin embargo, es un enlace apuntando a PrintConfig.dll, nuestra dll objetivo
  2. Utiliza el método SchRpcSetSecurity del Programador de Tareas para cambiar los permisos de UpdateTask.job, que en realidad se trata de un enlace a PrintConfig.dll, para que cualquiera en el sistema pueda modificarlo. Esto es posible gracias a que esta modificación, recordemos, no se ejecuta con los permisos del usuario, sino con los permisos de SYSTEM asociados al Programador de Tareas.
  3. Acto seguido, se modifica nuestra dll objetivo (PrintConfig.dll) ya que a estas alturas puede ser modificada por cualquiera, y se sustituye con una dll maliciosa de nuestro interés. 
  4. Provocamos que el servicio Cola de Impresión cargue y ejecute la dll maliciosa. Finalmente, la carga maliciosa de nuestra dll se está ejecutando con permisos de SYSTEM, los permisos asociados al servicio de Cola de Impresión.
Es importante darse cuenta de que, como comentamos en la primera entrada, es trivial modificar el exploit para que en vez de ejecutar notepad utilicemos una dll maliciosa con meterpreter o cualquier otra carga dañina.

Mientras Microsoft sigue analizando el problema, una empresa ya ha sacado una solución que parchea al vuelo los binarios del sistema afectados. En esencia han analizado el código y se han dado cuenta de varios problemas.

  • Primero, pensaban que no se encontrarían con código de impersonalización, uno de los principales errores detectados en esta vulnerabilidad. Sin embargo, se han encontrado con que sí existe este código. El problema reside en que esta llamada de impersonalización se realiza incorrectamente justo después de hacer la llamada que asigna los permisos. ¿La solución? Han subido la llamada a RpcImpersonateClient para que se ejecute antes de que se inicie el proceso de asignación de permisos.
  • Segundo, una vez añadido este primer parche el exploit seguía funcionando. ¿El motivo? También existe una llamada a RpcRevertToSelf, que sirve para revertir la impersonalización, pero que de nuevo está incorrectamente situada y se ejecuta antes de la llamada que asigna los permisos. Por tanto, se elimina la impersonalización demasiado pronto. ¿La solución? Han eliminado esa llamada del código y la colocan más tarde, después de que los permisos se hayan asignado correctamente.

En el siguiente vídeo podéis ver en el process monitor, como las llamadas que anteriormente eran permitidas por una incorrecta gestión de los permisos pasan a estar completamente bloqueadas.


3 sept 2018

RootedLab 2018 en RootedCON #Valencia - #Metasploit y Hacking Ético

El próximo 14 y 15 de Septiembre se celebrará la quinta edición de Rooted CON Valencia. Quinto año consecutivo dónde los chicos de Rooted se situarán en Valencia para llevar a todos los asistentes el mundo de la seguridad informática. Si necesitas más información sobre el taller puedes ponerte en contacto con la gente de rooted en info@rootedcon.com.

En esta ocasión la Rooted tendrá el viernes 14 de Septiembre un taller, en el cual participaré de nuevo. En este training, orientado a la práctica del hacking, se mostrará el uso de Metasploit y sus diferentes vertientes. Además, se hará entrega de un libro de Metasploit de la editorial 0xword.

podrás introducirte y sentar bases en los tipos de auditoias, en la forma de trabajo, en cómo llevar a cabo auditorías y como se debe presentar los resultados de éstas. El alumno obtendrá una visión global del hacking ético, profundizando en ciertas partes prácticas de auditorias. ¿A quién va dirigido?
  • Profesionales del sector de la seguridad informática. 
  • Estudiantes.
  • Administradores de sistemas y redes.
  • Desarrolladores que quieren mejorar su perfil.
  • Cuerpos y fuerzas de seguridad del estado.
  • Docentes.
¿Qué veremos?

Introducción al Framework
– Fases del test
– Arquitectura
– Módulos
– Adición de componentes al framework 
– Comandos básicos

Los preliminares
– Las auxiliary
– Escáneres de puertos 
– Fingerprinting
• SSH • SMB • HTTP • Otros
– Servidores 
• DNS • DHCP
– Protocolo ARP
– DoS

Exploiting&Payloads
–Tipos de payloads
• Inline • Stagers • Stage
–Tipos de explotación y módulos 
• Explotación directa • Client-Side • Explotación local
– Escalada privilegio (módulos configuración débil & vulns)
– Bypass UAC 
• Fileformat
–Explotación en distintos sistemas:
• Windows (XP, 7, 8, 8.1)
• Linux • Servicios multiplataforma
• Credenciales (Volcado de hashes, Hashes DC, Mimikatz...)

Post-Explotación
– Funcionalidades
• Recolección de información y ámbito 
– Módulos de Meterpreter
• ¿Qué me permite?
• Extensiones / Plugins – Pass the hash
– Persistencia de payloads – Pivoting
• Túneles
• Portfwd
• PortProxy
• Proxychains
• Herramientas del framework
– Msfvenom
– Msfd
– Pattern_create – Pattern_offset


Precio estándar: 100€ (Libro incluido en el precio)
Fecha de inicio: 14 de Septiembre de 2017
Fecha de finalización: 14 de Septiembre de 2017
Duración: 8 horas
Idioma del curso: Español
Plazas limitadas

¡No lo dudes y guarda tu plaza!


1 sept 2018

Escalando privilegios en Windows 10

El pasado 27 de agosto, la experta en ciberseguridad "SandboxEscaper" liberó en Github un exploit de escalada de privilegios local en Windows 10. El exploit, el cual enlazó desde un tweet publicado en la red social Twitter, se hizo viral rápidamente, saltando la noticia hasta varios medios generalistas:






El exploit aún se encuentra accesible, y puede ser descargado desde el siguiente enlace:

https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-LPE.rar



Dentro del mismo se encuentra un completo Write-up explicando la vulnerabilidad. En concreto, el gestor de tareas de Windows tiene una vulnerabilidad en la interfaz de la Llamada a Procedimiento Local Avanzada, o Advanced Local Procedure Call (ALPC), que permite a cualquier usuario elevar privilegios hasta SYSTEM.



En esta interfaz hay una llamada a la API (SchRpcSetSecurity) que no verifica correctamente los permisos. De este modo, es posible asignar permisos de forma arbitraria a través de un hard link a cualquier objeto del sistema de forma local.



El funcionamiento de la PoC es muy sencillo. En primer lugar decidiremos que proceso deseamos escalar y seleccionaremos su PID. Para ello nosotros utilizaremos el software Process Explorer:



A continuación, lanzaremos el exploit usando por ejemplo el proceso del bloc de notas (PID 4324)




Si volvemos a Process Explorer veremos como el bloc de notas es ejecutado a través del servicio de cola de impresión, esta vez, con privilegios de SYSTEM:


Ahora si intentamos realizar alguna acción que requiera privilegios, como por ejemplo abrir el archivo "hosts" situado en la ruta "C:\Windows\System32\drivers\etc", no tendremos ningún problema:



Obviamente, modificando un poco el exploit podemos olvidarnos del notepad, y ejecutar algo mucho más interesante como podría ser un Meterpreter. Después de generar nuestra propia DLL maliciosa con msfvenom, adaptamos el proyecto de Visual Studio, lo compilamos y volvemos a ejecutar...


Sin embargo, esta vez tenemos nuestro listener preparado y podemos observar como inmediatamente nos llega la sesión de Meterpreter sin problemas, y por supuesto corriendo como SYSTEM.



Os confirmamos que esta PoC ha sido realizada en un sistema Windows 10 Pro x64, actualizado con los últimos parches de seguridad, y se sabe que también afecta a Windows Server 2016. Sin embargo, con modificaciones menores es posible ejecutarlo en la versión 32 bits de Windows 10, y probablemente sea posible hacerlo funcionar en otros sistemas de Microsoft que dispongan de esta funcionalidad.

Microsoft ha reconocido la vulnerabilidad y ha anunciado que se encuentran trabajando para resolver el problema lo antes posible. Hasta entonces, cuidado con lo que ejecutáis... :)

¡Saludos!

Fuente: https://blog.zerolynx.com/2018/08/escalando-privilegios-en-windows-10.html