9 jul. 2020

Covenant: Un Command and Control un tanto vacilón (Parte III)

Por el 9 jul. 2020 con 0 comentarios
¡Muy buenas a todos!

Tras un pequeño lapso de tiempo, aquí os traigo la tercera y última parte de esta serie sobre Covenant. ¡Espero que os guste y os sea de utilidad!

Nota: Cabe destacar que cuando empecé esta serie, la última versión de Covenant era la 0.4, pero actualmente, se encuentra en la 0.5. Por lo que he podido investigar, muchos de los errores se siguen reproduciendo en esta nueva versión.

Problema 8: Los HTTP Grunt se mueren tras ejecutar el comando Shellcode con una meterpreter.

Solución: El comando Shellcode, como bien dice su nombre, permite ejecutar shellcodes en memoria. Es más que probable que si la shellcode no ha sido generada correctamente (por ejemplo, si la IP o el puerto de destino son incorrectos), ocasione la pérdida del Grunt desde el que lancemos el comando. ¡Recordad revisar antes de ejecutar!

Fig 1: Imaginaos que os pasa esto a punto de entrar en el DC...

Problema 9: En algunas situaciones, los ficheros subidos a un Listener (Hosted Files) no se pueden descargar.

Fig 2: Sí, aunque está ahí, es imposible acceder desde otro PC por HTTP(s).

Solución: Por motivos que todavía desconozco, cuando esto ocurre, la única manera que he tenido de solucionar el problema es partir desde cero borrando la base de datos y volviendo a levantar el Listener. Molesto, pero efectivo.

Problema 10: Todos los SMB Grunts pasan a estado Lost nada más recibirlos.

Solución: Que no, que no están muertos, que están de parranda. Lanzad varios comandos como cmd o whoami seguidos para verificar si siguen activos. Si tras varios intentos siguen sin responder, entonces sí, certificad su defunción.

Fig 3: Qué travieso, lost, pero activo.

Otra solución (más eficaz) es realizar los cambios indicados por Chopicalqui en este issue para mejorar la estabilidad de estas sesiones. Aunque el Pull Request se hizo sobre la versión 0.4, la 0.5 tampoco lo tiene.

Fig 4: Gracias Chopicalqui.
Por último, no quiero terminar este serie de artículos sin "dar" un gran KUDOS a Ryan y a todos los que están detrás de este proyecto apoyándolo y mejorándolo cada día... Un halo de esperanza para su mantenimiento y continuidad como proyecto de software libre 👏👏.

Happy Juancking!
Leer más
      editar

8 jul. 2020

Introducción al Cloud Computing con Azure. Parte 3: Levantando un entorno de cracking con Hashcat

Por Juan Antonio Calles el 8 jul. 2020 con 0 comentarios
Buenas a todos, en el artículo de hoy sobre nuestra cadena de Azure, vamos a continuar por donde lo dejamos en el anterior post, el cual dedicamos a la creación de máquinas virtuales. Hoy, aprenderemos a montar una máquina concreta con unas características muy especiales, y que nos facilitará enormemente nuestras tareas de pentest. ¡Vamos a ello!

Cuando realizamos un Red Team, un pentest o cualquier otra labor de intrusión dentro de un proceso de hacking ético con un cliente, solemos capturar hashes de diferentes tipos y de diferentes lugares. Responder, la SAM del sistema, lsass, etc. etc. Puede que nos interese conocer las contraseñas protegidas tras estos hashes de Windows capturados, ya que, aunque pudiésemos hacer un Pass the Hash, es posible que esas contraseñas puedan haber sido usadas en otros servicios y aplicaciones (ajenas a Windows). Ya sabéis que el ser humano es poco original... :) Y en estos procesos, el tiempo es oro. Los clientes obviamente no manejan presupuestos infinitos, y los alcances son limitados. Para crackear estos hashes disponemos de diversas utilidades de las que ya os hemos hablado largo y tendido, aunque sea hay alguna que es la preferida de (casi) todo el mundo, es Hashcat.

De Hashcat ya os hemos hablado en muchas ocasiones, así como de Hashtopolis y sus bondades. Por lo que me ahorraré todo esa introducción. Simplemente os explicaré qué máquinas debemos utilizar, y cómo las debemos configurar, para tener Hashcat en la nube ;)

Para el uso de GPU tenemos que optar por la Serie N de Azure. Sobre ello podréis leer en el siguiente enlace:


Citando a Microsoft, <<La serie N es una familia de Azure Virtual Machines con funcionalidad de GPU. Las GPU son perfectas para cargas de trabajo que utilizan una gran cantidad de proceso y gráficos, y ayudan a los clientes a impulsar la innovación con características como visualización remota de alto nivel, aprendizaje exhaustivo y análisis predictivo>>.



Así que iremos a nuestra cuenta de Azure, y seleccionaremos la opción para crear una nueva máquina virtual. Os recomiendo buscar una imagen de "NVIDIA - Ubuntu 18.04". Así mismo, no todas las regiones tienen máquinas con GPU. Una dónde sí he encontrado esta opción es en el centro del Sur de Reino Unido:


A continuación, seleccionaremos en "Tamaño", la máquina deseada. Recordad que tenemos que seleccionar una de la serie N. De lo contrario, no tendremos GPU Nvidia. La mejor oferta calidad/precio que he visto es la "NC6_Promo":


Ahora seleccionaremos el disco. En mi caso, que le he metido un diccionario de cerca de 100GB, he seleccionado un SSD de 128, con el que tengo más que de sobra. 


Y en unos minutos, tendremos nuestro nuevo entorno levantado:




Ahora nos podremos conectar por SSH, con el medio de autenticación seleccionado:


Si hemos seleccionado la máquina correcta, mediante el comando "lspci" podremos comprobar que tenemos la controladora de Nvidia.


Estas es la susodicha joya :)


Ahora tendremos que instalar cuda para Ubuntu. Los drivers los encontraréis en el siguiente portal. Solamente hay que seguir los pasos:


Y si todo ha ido bien, con el comando "nvidia-smi" veremos un pequeño panel de control con detalle sobre nuestra nueva GPU:


Ahora solo nos queda instalar Hashcat, y bajar un diccionario potente. En anteriores posts de Flu Project os hemos hablado de muchos diccionarios, por lo que tampoco me entretendré en este punto:


Con todo montado, solamente quedará subir a la máquina los hashes a crackear, y disparar:


Y en función del nº de hashes y el diccionario seleccionado, tendremos el resultado en cuestión de minutos, horas o días... :P


Saludos!


Autor: Juan Antonio Calles (@jantonioCalles), CEO de Grupo @ZerolynxOficial. CSO de @OsaneConsulting. Doctor en Informática. Cofundador de @fluproject y @X1RedMasSegura. Impulsor del proyecto Open Mobility Security Project (OMSP). Microsoft MVP.

Para consultas a Juan Antonio puedes utilizar su Buzón Público



Leer más
      editar

7 jul. 2020

Tesla Model 3 Dashcam Bypass: Si eres una aseguradora, esto te interesa

Por Juan Antonio Calles el 7 jul. 2020 con 0 comentarios
Buenas a todos, en el artículo de hoy quería hablaros de un problema funcional a nivel de seguridad, que hemos encontrado en el sistema Dashcam del Tesla Model 3, en concreto, el referente a su nueva funcionalidad, integrada en la versión 2020.12.5 del sistema, con la que es posible visualizar desde la propia pantalla los videos grabados por el sistema de seguridad:


El problema lo identificamos hace dos meses (en pleno confinamiento), como podréis ver en las capturas. De hecho, el mismo tiempo precisamente que llevamos intentando mover el tema con Tesla para proponerles recomendaciones de mejora en el sistema.

El programa de actualizaciones de Tesla evoluciona mucho, y desde entonces, el propio Dashcam ha cambiado. De hecho, ahora permite formatear pendrives desde el propio coche. Pero de esto os hablaremos en posteriores artículos.

Si analizamos el pendrive o disco duro usado en el Dashcam, según lo que utilicemos, donde se almacenan estas grabaciones, veremos un árbol de carpetas como el siguiente:


Y dentro de la carpeta de cada grabación, veremos el siguiente contenido:


De arriba hacia abajo, nos encontraremos con los videos en formato mp4 de la grabación desde los 4 ángulos del coche, un archivo json con los datos principales de la grabación, y una miniatura, que se corresponde con la previsualización del menú que tenemos en la pantalla del coche. Ni más, ni menos. Cómo os podréis imaginar, si os cuento todo esto es porque vemos un problema funcional importante, y es que estos contenidos no se encuentran firmados, por lo que son totalmente manipulables.

Comenzando por los thumbnails, que podremos alterar a nuestro gusto, como en el siguiente en el que hemos incluído el término "HACKED":



Continuando por el lugar de la grabación o la fecha de la captura:





O incluso, alterando los propios videos mp4:



¿Qué problema tiene todo esto? Pues además de las features que seguro que se os están ocurriendo para gastar bromas o ver películas en la pantalla del coche (aunque sin sonido), el objetivo del Dashcam es el de mostrarnos que hemos tenido un percance como un accidente, un robo o un acto de vandalismo entre otros, en formato de video, el cual podríamos utilizar para poner una denuncia y que los seguros respondan, de acuerdo a las condiciones de nuestro contrato. Ahora bien, si estos datos son manipulables, ¿qué garantía tenemos? ¿Podríamos utilizar un pendrive de un coche que haya tenido un golpe, por ejemplo, en el parachoques trasero, y "llevarnoslo" a otro coche, que haya tenido un golpe similar, pero que tenga el seguro a terceros y que, por tanto, no tendría derecho a una reparación gratuita? Pues la respuesta es SÍ. Dashcam actualmente no ofrece garantía de que las grabaciones y sus datos sean verídicos, porque no se encuentran firmados. Es más, como podéis ver arriba, he simulado una grabación en mitad del Océano Ártico, en una ubicación denominada como Mordor, en el año 2000, 20 años antes de que existiese el coche.



Dado el problema funcional, lo incluiremos como prueba en Open Mobility Security Project (OMSP), para que pueda estandarizarse en los itinerarios de pentest que se realicen siguiendo este modelo de evaluación.

Saludos!

Autor: Juan Antonio Calles (@jantonioCalles), CEO de Grupo @ZerolynxOficial. CSO de @OsaneConsulting. Doctor en Informática. Cofundador de @fluproject y @X1RedMasSegura. Impulsor del proyecto Open Mobility Security Project (OMSP). Microsoft MVP.

Para consultas a Juan Antonio puedes utilizar su Buzón Público



Leer más
      editar

6 jul. 2020

Tus contraseñas (aún más) seguras

Por el 6 jul. 2020 con 0 comentarios


¡Muy buenas! En este post comentaremos acerca de una característica interesante que poseen algunos gestores de contraseñas, muchos de ellos mencionados en varias oportunidades en nuestro blog. Para utilizar como ejemplo, nos centraremos en KeePassXC y en particular nos referimos a la posibilidad de doble factor que nos brinda la herramienta para acceder y descifrar la base de datos de secretos no sólo a través de una contraseña maestra, sino también agregando un archivo de descifrado llamado Key File. Es decir, que para poder acceder a nuestros datos protegidos será necesario presentar ambos recursos. Incluso se podría realizar dicho proceso únicamente con Key File, aunque esta es una práctica no recomendada.

En cuanto al procedimiento para activar el desbloqueo utilizando contraseña + Key File, es posible llevarlo a cabo tanto para una base de datos ya creada, como para una nueva.

En el caso de que ya contemos con una base de datos creada, basta con acceder a las opciones de la misma y, bajo la opción Key File, podremos generar un nuevo archivo con datos aleatorios o elegir uno existente. Podemos elegir, por ejemplo, una imagen o un archivo de texto.


Generamos un Key File o elegimos uno existente

Este método de doble factor, basado en algo que sabemos (la contraseña maestra) y algo que tenemos (el Key File), nos aporta una capa de seguridad extra y es muy útil en el caso de que guardemos copias de respaldo de nuestra base de datos de contraseñas (archivo con extensión .kdbx) en la nube, y el Key File en otro servicio cloud o en algún dispositivo externo, por ejemplo.


Accediendo con Key File

Finalmente, cabe aclarar que el archivo elegido como Key File debe mantenerse intacto sin modificaciones para no comprometer el acceso a nuestros datos. También es posible cambiar de archivo si así lo deseamos, para ello tenemos que repetir el proceso anteriormente explicado. Además, es muy recomendable crear copias de seguridad del Key File elegido, ya que en caso de perderlo, no podremos acceder a nuestras contraseñas guardadas, al igual que pasaría si perdemos nuestra contraseña maestra.

¿Qué les parece esta característica que nos ofrecen los gestores de contraseñas? 

Saludos!
Leer más
      editar

3 jul. 2020

Introducción al Cloud Computing con Azure. Parte 2: Levantando máquinas virtuales

Por Juan Antonio Calles el 3 jul. 2020 con 0 comentarios
Buenas a todos, en el post de hoy vamos a continuar con la cadena de Azure, aprendiendo a levantar nuestra primera máquina virtual en la nube.

Lo primero que haremos será acceder al menú de máquinas virtuales, el cual encontraremos en el menú inicial de la plataforma:


Una vez dentro, pulsaremos sobre el botón agregar, o sobre "crear maquina virtual":


A continuación comenzaremos la configuración de la máquina. Lo primero que haremos será seleccionar la región donde queremos levantar nuestra VM y el sistema operativo:



A continuación seleccionaremos las CPUs y memoria del entorno:


Posteriormente indicaremos el medio de autenticación:


Y seleccionaremos el tipo de disco. Dispondremos de HDD estándar y de SSD estándar y premium (con mejor rendimiento y recomendado para entornos con muchas operaciones de entrada/salida de datos):



El siguiente paso será seleccionar los puertos que abriremos en el firewall. Por defecto SSH para administración:


Y si todo ha ido bien, comenzará la generación de la máquina y nos indicará los costes correspondientes:




Tras crearse la máquina, podremos acceder desde el panel principal:


La máquina podremos arrancarla y pararla a nuestro criterio, e incluso podremos "salvar" la dirección IP asignada, aún teniéndola parada:



Así mismo, podremos gestionar la seguridad de la red, y agregar o eliminar reglas a nuestro criterio. En el caso de entornos críticos, sería recomendable limitar el acceso a la máquina únicamente desde vuestra dirección IP, y a los puertos mínimos necesarios:


En el menú "Conectar" podremos encontrar las diferentes posibilidades con las que acceder a la máquina. 



En nuestro caso, nos conectaremos por SSH a través de PuTTY:


Y si todo ha ido bien, nos conectaremos a nuestra nueva máquina virtual:


Como veis, en menos de 5 minutos tendremos una máquina levantada en Internet y lista para publicar los servicios que precisemos :)

¡Nos vemos en el próximo post sobre Azure!


Autor: Juan Antonio Calles (@jantonioCalles), CEO de Grupo @ZerolynxOficial. CSO de @OsaneConsulting. Doctor en Informática. Cofundador de @fluproject y @X1RedMasSegura. Impulsor del proyecto Open Mobility Security Project (OMSP). Microsoft MVP.

Para consultas a Juan Antonio puedes utilizar su Buzón Público



Leer más
      editar
< >