Seguridad en ElasticSearch: ES desde la perspectiva de un pentester – Parte V
Cuando ponemos un nodo en modo “cluster” es cuando realmente se empiezan a complicar las cosas desde el punto de vista de la seguridad. Algunas consideraciones que fácilmente se pueden detectar desde el punto de vista de un pentester son las siguientes:
Sin mecanismos de autenticación o autorización en el acceso a la API Rest.
Como se ha visto en los post anteriores de ésta serie (parte1, parte2, parte3, parte4), la API Rest de una instancia de ES es muy potente, de hecho es el corazón del motor. Desafortunadamente, por defecto no se implementa ningún mecanismo de seguridad para la autenticación de usuarios. Recordad que ES es una base de datos, con un modelo de funcionamiento diferente a las bases de datos relacionales pero su objetivo principal es el mismo: el almacenamiento de información. Si en una base de datos tradicional se permite que cualquier usuario sin autenticación previa, ejecute consultas SQL sobre las tablas y que tenga la posibilidad de lanzar procedimientos almacenados, estamos en una situación poco deseable en la que como mínimo, es posible que se produzcan fugas de información sensible y a mayores, en la explotación del sistema. Pues bien, por defecto esto es lo que tenemos con cualquier instancia de ES. Alguien podría decir: “pero no pasa nada, porque la API Rest de ES se vincula únicamente a la interfaz de red local, que no está expuesta a otros sistemas y por lo tanto únicamente un administrador podrá acceder a ella”. Sí y no. Si utilizamos ES en modo de desarrollo, es decir, con un único nodo local y sin activar el modo cluster esto es cierto, pero aún así, si el sistema ya ha sido comprometido y un atacante tiene la posibilidad de ejecutar comandos, se podría crear fácilmente un túnel SSH que exponga el puerto en el que se encuentra en ejecución la API Rest de ES y de esta forma, acceder a la información almacenada en el cluster. Incluso, sin llegar al supuesto de que el sistema haya sido comprometido, es posible que el administrador quiera acceder a la instancia remotamente y lanzar consultas, para ello también podría crear un túnel SSH abriendo la posibilidad de que él y cualquiera pueda entrar ya que por defecto, no hay mecanismos de autenticación y autorización.
| ssh -L 0.0.0.0:9999:127.0.0.1:9200 esuser@localhost |
Por ejemplo, si se ejecuta el comando anterior sobre el sistema en el que se encuentra en ejecución la instancia de ES, se abrirá el puerto “9999” en todas las interfaces de red disponibles y se podrá acceder a la API Rest de ES utilizando dicho puerto. Esta es solo una forma, existen otras más, por ejemplo utilizando redirecciones con socat. Este y muchos otros temas relacionados con la post-explotación de sistemas los enseño en los cursos que imparto en Securízame por si estás interesado.
Operaciones de administración de la instancia de ES sin protecciones de ningún tipo.
Ahora bien, en el caso de que efectivamente, lo anterior no sea posible porque el sistema está correctamente securizado y no hay agujeros de seguridad que le permitan a un atacante crear un túnel como el anterior, aún hay que considerar que si la instancia de ES se ha configurado en modo “cluster”, cualquiera se podrá conectar a ella, ya que como se ha visto en la parte anterior de esta serie, para que el modo cluster funcione correctamente la instancia tiene que permitir la conexión remota por parte de otros nodos. Esto significa que lo más probable es que otras instancias puedan consultar cualquier endpoint de la API Rest, incluyendo aquellos que permiten la administración completa del nodo, nuevamente sin ningún tipo de restricción.
Fugas de información sensible con instancias maliciosas en el cluster
Otra cuestión a tener en cuenta en el modo cluster, es que se puede consultar fácilmente si una instancia actúa como “master” y levantar otra instancia que funcione en modo “esclavo” para obtener las replicas de la información almacenada en el cluster. Esto está muy bien sino fuese porque nuevamente, no hay ningún mecanismo de autenticación y autorización por defecto en ES para este tipo de operaciones, es decir, que por defecto se “confía” en que la instancia que se quiere unir al cluster es legitima y no hay ningún mecanismo para indicar cuáles son aquellas instancias que realmente están autorizadas para unirse al cluster y cuáles no. Es posible que el lector recuerde o haya visto alguna vulnerabilidad de transferencia de zona en servidores DNS mal configurados, pues en este caso estamos ante una situación muy similar. Es posible levantar una instancia de ES y editar la configuración por defecto para que apunte al master y obtener la replica de los documentos almacenados en el cluster, es decir, la información propiamente dicha.
Denegación del servicio sobre nodos del cluster.
Existe otro problema inherente al funcionamiento de ES relacionado con el almacenamiento de la información. Como se ha mencionado anteriormente, la estructura de los documentos almacenados en ES parte de un índice, que funciona como un esquema en una base de datos relacional. Esta información se carga en memoria con el objetivo de que el acceso sea rápido, por lo tanto la máquina sobre la que se ejecutan dichas instancias tienen que ser lo suficientemente potente (tanto en términos de memoria como de procesamiento) para admitir la carga de estos documentos. Se tiene que tener un muy buen control sobre lo que se va a almacenar, es decir, permitir la inserción de documentos únicamente con la información estrictamente necesaria y evitar que sean estructuras JSON muy grandes. Si la API Rest de ES puede ser consultada por cualquiera o simplemente, no se tiene cuidado con las cuestiones indicadas antes, es posible que hayan problemas de almacenamiento en una o varias instancias del cluster, pudiendo incluso provocar condiciones de denegación de servicio. Por otro lado, tal como se ha explicado en uno de los posts anteriores de la serie, gracias a la API Rest de ES es posible abrir y cerrar índices, acción que se encarga de volcar los documentos del índice en cuestión a disco (operación de cierre) o de disco a memoria (operación de apertura). El problema de estas operaciones es que son costosas en términos de recursos como resulta evidente y si se ejecutan constantemente sin ningún control sobre índices con miles de documentos (ejecutando un script malicioso, por ejemplo) es bastante probable que se produzca una condición de denegación de servicio.
Tráfico sin cifrar.
En modo cluster los nodos se comunican e intercambian paquetes de datos sin ningún tipo de protección en la capa de transporte. Esto significa que evidentemente, es inseguro por defecto. Como seguramente ya sabéis, esto puede dar lugar a diferentes tipos de ataques que van desde la captura pasiva de paquetes hasta la manipulación y posterior reinyección de los mismos en ciertos escenarios. En este punto poco más merece la pena explicar, es evidente que se trata de un problema de seguridad que no es aceptable en un cluster encargado de almacenar información sensible.
¿Contramedidas?
Si el lector ha trabajado anteriormente con ES, seguramente una de las primeras cosas en las que pensará será en las características de seguridad disponibles en el módulo “X-Pack” (https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html) y a continuación en la inversión que habría que realizar para adquirir y habilitar dicho módulo en la instancia de ES, ya que no es gratuito. Sin embargo, debido a la presión de la comunidad pidiendo implementar mecanismos de seguridad en la versión gratuita de ES, desde mayo del presente año todas las versiones de ES desde la 6.8 cuentan con características de seguridad incluidas en el producto y que se pueden activar si el administrador así lo desea. Dicho anuncio se ha hecho público hace unas pocas semanas a la fecha de escribir este post y se puede consultar aquí: https://www.elastic.co/es/blog/getting-started-with-elasticsearch-security
No obstante, como resulta evidente las instalaciones de ES existentes tienen que ser “reinstaladas” con las nuevas versiones disponibles en los repositorios de ES, lo cual no es precisamente una tarea fácil cuando la instancia o cluster tiene datos almacenados pero ya es algo.
Algunas de las características relativas a la seguridad en ES, que ahora se encuentran integradas por defecto y para las que no hace falta tirar de X-Pack son las siguientes.
- Control de accesos basado en roles.
- Comunicación segura entre nodos de la instancia.
- Autenticación de usuarios basada en directorio activo, LDAP, Kerberos, SAML o de forma local.
- Tráfico confiable “nodo a nodo”, habilitando filtrados basados en listas blancas.
- Logging en eventos relacionados con la seguridad de forma transparete.
Entre muchas otras cosas más. Se trata de características que evidentemente se deben utilizar en un entorno productivo para proteger la información de accesos no autorizados y “miradas indiscretas”.
Un Saludo y Happy Hack.
Adastra.
Herramientas de pentesting interesantes: Jok3r – Parte 2
En el post anterior se ha comenzado a hablar de Jok3r y sus funcionalidades básicas, una herramienta que es interesante desde el punto de vista de un pentester dado que integra muchas de las herramientas de uso común en auditorías de red y web. En dicho post solamente se han mencionado los comandos básicos, el manejo de bases de datos locales y cómo instalar la herramienta utilizando la imagen oficial de Docker. Ahora, resulta conveniente ver cómo utilizar lo visto anteriormente para realizar verificaciones de seguridad sobre un entorno concreto.
El comando utilizado para realizar las verificaciones de seguridad incluidas en Jok3r es “attack” el cual recibe múltiples opciones que sirven para configurar los detalles del objetivo, añadir los resultados a una base de datos local concreta o incluso para realizar ataques a múltiples objetivos que se encuentran almacenados en alguna “mission” de Jok3r. En la configuración del ataque es posible utilizar un perfil existente en Jok3r, que tal como se ha visto en el post anterior a este, se pueden consultar con el comando “info” de la siguiente forma:
| python3 jok3r.py info –attack-profiles |
Opciones en el comando “attack”
A continuación se verá una lista de las opciones disponibles para el comando “attack”, las cuales hay que conocer para poder lanzar las pruebas correctamente.
| Opción | Descripción |
| -t / –target | Permite especificar el objetivo del ataque. Puede ser una IP:Puerto, un nombre de dominio o una URL. |
| -s / –service | Permite especificar un servicio concreto a auditar. |
| –add2db | Permite añadir o actualizar los resultados obtenidos por el comando en la “mission” (base de datos local) especificada. Si no se utiliza esta opción, los resultados son añadidos/actualizados directamente en la mission “default”. |
| -m / –mission | Permite leer una mission local y lanzar los checks de seguridad contra todos los objetivos registrados en dicha mission. |
| -f / –filter | Filtro sobre los objetivos a los que se deben ejecutar las pruebas de seguridad. Normalmente viene acompañada de la opción “-m”. Los filtros disponibles son ip, host, port, service, url, osfamily y banner. Además, cada filtro debe venir separado por “;” y la sintaxis es “filtro=valor”. Por ejemplo: “ip=10.1.1.0/24,10.0.0.4;port=80,8000-8100;service=http”. También es posible repetir esta opción varias veces en el mismo comando. |
| –new-only | Realiza las pruebas de seguridad únicamente sobre los servicios que no han sido probados previamente. |
| –nmap-banner-grab | Habilita o deshabilita un escaneo con Nmap del tipo “service detection”. Valores validos “on” y “off” |
| –reverse-dns | Habilita o deshabilita las peticiones DNS reversas contra el objetivo. Valores validos “on” y “off” |
| –profile | Permite ejecutar un perfil de ataque concreto. |
| –cat-only | Permite ejecutar las pruebas de seguridad sobre las categorías especificadas únicamente. Cada categoría se indica separada por coma. |
| –cat-exclude | Permite ejecutar las pruebas de seguridad sobre todas las categorías excepto sobre las especificadas en esta opción. Cada categoría se indica separada por coma. |
| –checks | Permite ejecutar los checks especificados en esta opción. Cada check se indica separado por coma. |
| –fast | Modo rápido. Desactiva la interacción con el usuario y todas las verificaciones se ejecutan en modo desatendido. |
| –recheck | Si un check se ha ejecutado previamente, se vuelve a lanzar. Esto es útil especialmente cuando se utiliza una mission sobre la que se ha trabajado previamente e interesa que se vuelvan a realizar todas las comprobaciones. |
| -d | Habilita el modo “debug”. |
| –userlist | En el caso de encontrar un formulario o mecanismo de autenticación, la herramienta ejecuta un atacante por diccionario con listas que vienen incluidas en la herramienta. Con esta opción se utiliza una lista de usuarios indicada por el usuario |
| –passlist | Con esta opción se utiliza una lista de contraseñas indicada por el usuario |
| –cred | En el caso de que se cuente con las credenciales de un servicio concreto, en lugar de permitir que la herramienta ejecute un ataque de fuerza bruta se pueden indicar dichas credenciales en esta opción de la siguiente forma: –cred <service> <user> <pass> |
| –user | Permite especificar un usuario concreto con el que se deberán realizar los ataques de fuerza bruta en el caso de encontrar un formulario o mecanismo de autenticación. |
| –option | Permite especificar una opción personalizada, por ejemplo una cabecera HTTP concreta para realizar las peticiones contra un sitio web. |
Conociendo las opciones, ya se puede utilizar el comando “attack” sin limitaciones. Evidentemente la forma más simple de hacerlo es contra un objetivo concreto y lanzando todas las comprobaciones. Por ejemplo:
| python3 jok3r attack -t http://192.168.1.50/twiki/ |
La herramienta intenta obtener información sobre el servidor web utilizando “Wappalyzer” y también ejecuta un escaneo del tipo “service detection” para identificar el banner del servicio con Nmap. Al no indicar la opción “–add2db” todos los resultados serán guardados en la mission “default”.
Después de recopilar toda la información, la herramienta solicita confirmación para iniciar el ataque. Las comprobaciones pueden tardar un buen rato y en segundo plano, la herramienta se encargará de almacenar los resultados en la mission correspondiente. No obstante, dado que no se ha indicado la opción “–fast”, la herramienta pedirá confirmación antes de lanzar cualquier prueba, lo cual puede ser bastante tedioso tal como se enseña en la siguiente imagen.
El siguiente comando se encargará de lanzar todas las comprobaciones, en modo “fast” y añadiendo los resultados a la mission “adastra”.
| python3 jok3r.py attack –fast -t http://192.168.1.50/twiki/ |
En la medida en la que se van ejecutando las pruebas, se puede apreciar la ejecución de herramientas comunes como “dirsearch”, “wig”, “nikto”, “h2t”, módulos de metasploit y scripts para la detección de vulnerabilidades en CMS, servidores de aplicación y frameworks concretos, aunque evidentemente muchas de estás comprobaciones estarán fuera de contexto dependiendo del objetivo a analizar.
Se pueden combinar todas las opciones indicadas en la tabla anterior, permitiendo ejecutar la herramienta de un modo más concreto contra el objetivo a analizar, por ejemplo.
#python3 jok3r.py attack -t 192.168.1.50:21 -s ftp –cat-only recon –add2db ftpmission
#python3 jok3r.py attack -m adastra -f “port=21;service=ftp” –fast #python3 #python3 jok3r.py attack -m adastra -f “port=2222;service=ssh;ip=192.168.1.1” -f “ip=192.168.1.50;service=ftp” –fast –recheck
Finalmente, cuando finalizan las comprobaciones de seguridad realizadas por la herramienta, todos los resultados se quedan almacenados en la base de datos local y a continuación se puede generar un reporte con la opción “report” del comando “db” tal como se enseña en la siguiente imagen.
Una vez se abre el reporte, se muestra cada una de las herramientas y pruebas realizadas para los hosts que se encuentran almacenados en la “mission” seleccionada. Se trata de un informe en formato HTML que está muy bien estructurado y que da una visión general de las vulnerabilidades descubiertas y la ejecución de las herramientas incluidas en el toolbox.
Bien, esto es todo sobre Jok3r, en el próximo post de esta serie hablaré sobre otra herramienta para pentesting que seguramente te resultará también muy interesante.
Un saludo y Happy Hack
Adastra.
Seguridad en ElasticSearch: modo cluster – Parte IV
En el post anterior ya se ha hablado sobre algunas características avanzadas para la búsqueda de contenidos en ES, ahora es el momento de hablar sobre la configuración necesaria en ES para que funcione en modo cluster. En primer lugar hay que mencionar que cuando se inicia una instancia de ES, lo primero que hace es intentar unirse a un cluster si se han indicado los detalles en dicho cluster en la configuración, en el caso de que no sea así, se entiende que el nodo funcionará en modo “standalone” y en tal caso, creará un cluster en donde es la propia instancia la que funciona como “master”.
Configuración modo “cluster” con múltiples nodos.
La configuración en modo cluster de ES con múltiples nodos es considerada como una configuración para un entorno de producción. Esto significa que en primer lugar, la instancia de ES ya no se ejecutará únicamente en la interfaz de loopback como se ha visto hasta ahora, sino que evidentemente, debe estar disponible y alcanzable por otros nodos/instancias que harán parte del cluster. La configuración de todas las instancias de ES giran en torno al fichero “elasticsearch.yml” para cuestiones concretas de la instancia y otros ficheros como el “jvm.option” y “log4j2.properties” para asignar valores de configuración a la VM de Java, evidentemente se trata de una labor de vital importancia para el tuning de una máquina virtual y el correcto funcionamiento de la instancia, pero se sale un poco del scope de estos post. Todos estos ficheros, así como el keystore y certificado de la instancia se encuentran en el directorio “config”.
ES normalmente requiere muy poca configuración y prácticamente todos los cambios se pueden realizar en caliente gracias a la API disponible en el motor, excepto la configuración en modo cluster, de hecho, si se ha iniciado una instancia con sus valores por defecto se creará un directorio llamado “data” el cual contiene toda la información de los nodos vinculados al cluster. Si se inicia una instancia de ES con la configuración por defecto y luego, se plantea integrar dicha instancia en un cluster existente, es importante tener en cuenta que no solamente será necesario editar el fichero de configuración como se explicará a continuación, sino que además se debe eliminar el directorio “data” para que la instancia comprenda que ahora no es el “master” de un cluster local, sino que se unirá a un cluster existe. Esto último es importante, ya que en el caso de no hacerlo se producirán errores en el arranque aunque la configuración sea correcta.
Ahora bien, los valores de configuración mínimos que se deben indicar en el fichero de “elasticsearch.yml” son los siguientes:
cluster.name: Nombre que tiene el cluster al que la instancia se unirá.
node.name: Nombre del nodo.
cluster.initial_master_nodes: Se trata de las direcciones IP o nombres de dominio de uno o varios nodos “master” del cluster objetivo.
transport.host: Interfaz de red o dirección IP utilizada internamente por los nodos del cluster para la comunicación. Por ejemplo, esta dirección junto con el puerto indicado en “transport.tcp.port” son utilizados por otros nodos en el cluster para las replicas de shards.
transport.tcp.port: Puerto que se abrirá en la interfaz indicada en “transport.host”.
http.host: Interfaz de red sobre la que se servirá la API rest de la instancia (por defecto es localhost).
http.port: Puerto vinculado a la interfaz indicada con la propiedad “http.host” (por defecto es 9200).
network.host: Interfaz de red a la que se vinculará el servicio de conexión de la instancia. Es decir, la interfaz de red sobre la que otros nodos del cluster se conectarán con la instancia local.
node.master: Valor booleano que indica si la instancia es master o no del cluster.
Esto es lo mínimo que debe de existir en un fichero de configuración de ES para que funcione en modo cluster con otros nodos, sin embargo hay muchas más opciones de configuración que se pueden consultar en la documentación oficial. https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html
Una configuración valida podría ser la siguiente:
Nodo master:
| cluster.name: cluster-adastra node.name: adastra-1 transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: true |
Nodo slave1:
| cluster.name: cluster-adastra node.name: slave1-node discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master. cluster.initial_master_nodes: [“adastra-1”] transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: false |
Nodo slave2:
| cluster.name: cluster-adastra node.name: slave2-node discovery.seed_hosts: [“192.168.1.144”] #Dirección IP del master. cluster.initial_master_nodes: [“adastra-1”] transport.host: 0.0.0.0 http.host: 0.0.0.0 network.host: 0.0.0.0 transport.tcp.port: 9300 node.master: false |
Esto se puede ejecutar desde un mismo ordenador con 3 instancias independientes de ES, con máquinas virtuales, contenedores de Docker o máquinas físicas. No obstante aquí no termina la configuración, cuando se utiliza la propiedad “network.host” con un valor distinto de la interfaz de loopback provoca que ES ejecute una serie de comprobaciones sobre el sistema llamadas “bootstrap checks” las cuales se encargan de verificar que el sistema cumple con las especificaciones mínimas para que el nodo funcione correctamente en un entorno productivo y de esta manera reducir los problemas que puedan tener los usuarios al interactuar con nodos configurados “de aquella manera”. La configuración del sistema que se debe de aplicar para cumplir con los requisitos se explica en la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/current/system-config.html
En este apartado la documentación está bien detallada y explica qué se debe hacer a nivel de sistema para que el nodo arranque correctamente y se una a un cluster existente o funcione como master.
Como se puede apreciar en la imagen anterior, cuando existe cualquier tipo de problema en la instancia relacionada con los “bootstrap checks” la instancia simplemente no arranca. Sin embargo es algo fácil de resolver si se siguen las indicaciones que arroja la instancia de ES.
En esta última imagen se puede ver cómo debe de ser una configuración “buena” para el nodo que actuará como master, como se puede ver se han pasado todas las comprobaciones iniciales y posteriormente, se ha elegido al nodo “adastra-1” como master ya que es la forma en la que se ha indicado en la configuración gracias a la propiedad “node.master: true”.
De momento, con lo que se ha visto en éste post en las partes 1 , 2 y 3 es suficiente para comenzar a abordar cuestiones relacionadas con el pestesting y securización sobre instancias de ES.
Un saludo y Happy Hack.
Adastra.
Seguridad en ElasticSearch: búsquedas avanzadas y operaciones sobre índices – Parte III
En el post anterior se ha hablado sobre como crear y gestionar índices así como la forma de realizar búsquedas con el endpoint “_search”, lo cual es el punto de entrada para comprender el funcionamiento de ES. Probablemente las características más complejas de este producto están precisamente relacionadas con las búsquedas, ya que como se verá en este post, existen varias maneras de aplicar filtros sobre índices y documentos.
En primer lugar, el endpoint “_search” no solamente admite peticiones GET, también es posible ejecutar una petición POST y en el cuerpo de la petición enviar filtros un poco más específicos que los que se podrían incluir en una petición GET. Por ejemplo:
| POST /indice/tipo/_search { “query”: { “match”: { “title”: { “query”: “palabra1 palabra2”, “operator”: “and”} } } “size”: 2, |
Se trata de una búsqueda más compleja, en la que se incluye el campo “query” que a su vez admite una estructura muy concreta para realizar la búsqueda. Con “match” se especifican los filtros, que en este caso aplican únicamente al campo “title”, es decir, que todos los documentos que tengan dicho campo serán objeto de búsqueda. Luego, se repite nuevamente el campo “query” pero en esta ocasión será útil para indicar un texto libre. Es posible utilizar operadores como “or” y “and”, de tal manera que dicha operación lógica se aplicará sobre las palabras especificadas en el campo “query”. En el ejemplo anterior, al aplicar el operador “and”, significa que la búsqueda devolverá solamente aquellos documentos que tenga en el campo “title” las palabras “palabra1” y “palabra2”. Luego, se puede apreciar en el cuerpo de la petición otros campos adicionales, tales como “size” y “from”, los cuales permiten devolver resultados en bloques, algo ideal para implementar búsquedas paginadas. Finalmente, los campos “_source” y “highlight” sirven para indicar aquellos campos del documento que devolverá la búsqueda, en este caso “campo1”, “campo2” y “campo3”. Si el documento tiene más campos estos no son incluidos en los resultado de la búsqueda.
El resultado de una búsqueda como la anterior es una estructura en formato JSON que contiene algunos campos interesantes, como por ejemplo “_source” y “score”. En el caso del primero, se trata de la estructura JSON con los resultados de la búsqueda, es decir, todos los documentos que han coincidido con los filtros especificados y el segundo, es el factor de coincidencia y es aquí en donde ES se complica un poco más, ya que ES internamente realiza una serie de calculos para asignar a cada resultado de las búsquedas un valor de coincidencia, esto es un indicativo que permite ubicar cada documento en un orden concreto en el listado de resultados. Pensad por ejemplo en Google, los enlaces a páginas externas que arroja cada búsqueda enseñan en las primeras posiciones aquellos que tienen mejor page rank, aquellos que pueden ser más interesantes para el usuario. ES hace lo mismo partiendo de los filtros que se incluyen en las búsquedas. Por ejemplo, en el caso anterior, cuantas más veces aparezca en un documento las palabras “palabra1” y “palabra2”, el documento tendrá mejor score y por lo tanto aparecerá en mejores posiciones dentro del resultado de la búsqueda. En la documentación oficial de ES podéis ver algunos ejemplos de búsquedas de este tipo para que quede un poco más claro, aunque desafortunadamente en mi opinión, la documentación oficial de ES es una de las más escuetas, poco claras y con más errores que me he encontrado hasta ahora en un producto de software, desafortunadamente es lo que hay y muchas veces toca pegarse con el producto para aprender realmente cómo funciona y ver las cosas que han cambiado, que ya no funcionan o que funcionan de forma diferente entre diferentes versiones. Los siguientes enlaces pueden ser útiles:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html
Por otro lado, algunos de los campos que se han incluido en el cuerpo de la petición (los más simples) también se pueden incluir como parámetros en la URL del endpoint “_search”, por ejemplo:
GET /_search?size=5
Enseña los 5 primeros resultados de la búsqueda.
GET /_search?size=5&from=5
Enseña los resultados del 5 al 10.
GET /_search?size=5&from=10
Enseña los resultados del 5 al 15.
como se ha explicado anteriormente, ES se encarga ordenar los resultados de las consultas antes devolverlos basándose en el campo “_score”, por lo tanto es común y recomendable utilizar los mecanismos de paginación para evitar problemas de rendimiento en las consultas.
Operaciones sobre índices y documentos.
Es importante conocer la forma en la que ElasticSearch interpreta los documentos almacenados en un índice concreto, ya que es posible que algunos de los campos no contengan la estructura esperada, tal como se ha visto en el post anterior a este, es posible crear documentos que no siguen ninguna estructura referente a los campos. Para ver el “mapeo” que tienen los documentos (parecido a la definición de una tabla en una base de datos relacional) es necesario utilizar el endpoint “_mapping” disponible en el índice.
GET /index/_mapping
A la hora de crear un índice es posible incluir el campo “mappings” y especificar cómo será la estructura de los campos que podrán ser heredados por los documentos creados en el índice, por ejemplo:
PUT my_index
{ “mappings”: { “properties”: {
“campo”: { “type”: “keyword”}
}}}
Es recomendable echarle un vistazo a lo que se explica en la documentación oficial sobre los mapeos en índices: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-params.html
Los índices pueden estar abiertos o cerrados, lo que significa que es posible trabajar con ellos para operaciones de lectura/escritura o no. No es posible indexar documentos o realizar búsquedas sobre índices cerrados. Cuando un índice está cerrado, ES no mantiene las estructuras de datos internas para la búsqueda, es decir, los documentos no se indexan y por lo tanto, el consumo de memoria es menor. No obstante, dependiendo del tamaño de los documentos de dicho índice, un índice cerrado puede suponer un consumo considerable de disco duro ya que como resulta evidente, la información de dichos documentos se debe guardar de forma persistentemente en disco en el caso de que el índice se abra nuevamente. Abrir o cerrar un índice es muy sencillo tal como se muestra a continuación. (obviamente, “my_index” corresponde al nombre del índice).
* Abrir un índice: POST /my_index/_open
* Cerrar un índice: POST /my_index/_close
Alias sobre índices.
Una forma rápida y sencilla de obtener todos los índices disponibles en ES es por medio del endpoint “_aliases” el cual devuelve un listado de todos los alias disponibles para cada uno de los índices. Con este endpoint también es posible crear o eliminar alias (etiquetas) sobre los índices creados.
POST /_aliases {
“actions” : [ { “add” : { “index” : “test1”, “alias” : “alias1” } },
{ “remove” : { “index” : “test1”, “alias” : “alias2” } } ] }
En el caso anterior, las acciones utilizadas son “add” y “remove”. Se ha creado un alias el nombre “alias1” sobre el indice “test1” y además, se ha eliminado el alias “alias2” sobre el índice “test1”. Un índice puede tener múltiples “alias” sin que esto afecte a los documentos o estructura del índice.
Probablemente una de las características más potentes de los alias es que permiten crear vistas sobre los índices partiendo de los filtros, por ejemplo:
POST /_aliases {
“actions” : [ {“add” : {“index” : “test1”, “alias” : “alias2”,
“filter” : { “term” : { “campo” : “valor” } } } } ] }
Como se puede apreciar, se ha creado un alias con nombre “alias2” sobre el índice “test1”. Cuando se intente consultar dicho alias, ES aplicará el filtro indicado en el campo “filter” y devolverá los documentos que coincidan con la búsqueda. Esto en el mundo de las bases de datos relacionales es similar a las vistas, lo cual simplifica mucho las consultas que se pueden realizar contra un índice concreto. Para consultar el alias, se accede directamente al endpoint “_search”, por ejemplo:
GET /alias1/_search
GET /alias2/_search
Al realizar una petición como la anterior ES se encargará de buscar dicho alias, ver el índice al que apunta y si hay algún filtro, aplicarlo.
Los alias también se pueden utilizar como vistas de escritura, es decir, una forma de simplificar la creación de documentos con el atributo “is_write_index”.
POST /_aliases
{ “actions” : [
{ “add” : {“index” : “test”, “alias” : “alias1”, “is_write_index” : true } }
]}
Como se puede apreciar, para crear un alias en modo escritura, basta simplemente con incluir el campo “is_write_index” con el valor “true” a la hora de crearlo. Para utilizar el índice en modo de escritura se podrá realizar una petición POST o PUT de la siguiente forma.
PUT /alias1/_doc/1
{
“campo”: “valor”
}
En donde “_doc” es un endpoint que le permite a ES saber que se intenta acceder a la estructura de documentos que se encuentran almacenados en el índice al que apunta el alias “alias1”, luego en el cuerpo de la petición viene el JSON con el documento propiamente dicho.
Consultas interesantes en ES
Antes de finalizar este post, es conveniente conocer algunos de los endpoints disponibles en el producto para realizar consultas directas sobre el estado del nodo o cluster. Para ello existen varios endpoints interesantes que son muy sencillos y aportan información valiosa. Por ejemplo:
GET /_cat/master?v
GET /_cat/nodes?v
GET /_cat/indices?v
GET /_cat/plugins?v
GET /_cat/shards?v
GET /_cat/health?v
GET /_cat/master?help
GET /_nodes/node1,node2
GET /_nodes/process
GET /_nodes/_all/process
GET /_nodes/node1,node2/jvm,process
GET /_nodes/plugins
GET /_nodes/stats/indices
GET /_nodes/stats/os,process
GET /_nodes/192.168.1.101/stats/process
GET /_nodes/usage
GET /_nodes/nodeId1,nodeId2/usage
GET /_nodes/hot_threads
Son peticiones fáciles de entender y que permiten extraer información relevante sobre una instancia de ES en ejecución, de hecho, complementos como “cerebro”, “elasticsearch-HQ” o el propio Kibana hacen uso de estos endpoints de forma directa para enseñar la información en un formato amigable para el usuario.
En el próximo artículo de la serie se hablará sobre configuración de una instancia de ES y algunas consideraciones de seguridad que se entenderán mucho mejor después de haber leído la parte 1 y la parte 2 de la serie.
Un saludo y Happy Hack.
Adastra.
Herramientas de pentesting interesantes: Jok3r – Parte 1
Desde hace bastante tiempo he querido escribir ésta serie de artículos pero por cuestiones de tiempo no había podido. Últimamente han ido apareciendo bastantes herramientas enfocadas al pentesting/hacking para diferentes contextos, algunas de ellas realmente interesantes y que merece la pena mencionar en este blog. Es importante automatizar todo el trabajo posible para soportar el procedimiento de descubrimiento, detección y posterior explotación de vulnerabilidades, incluyendo otras actividades que en ocasiones se deben realizar directa o indirectamente como ataques de Phishing, aplicación de técnicas OSINT, traceo y seguimiento de usuarios, análisis de tráfico, desarrollo de software, etc. No obstante, como siempre he dicho, ninguna herramienta o conjunto de ellas puede sustituir el trabajo y la metodología que aplica un pentester/hacker a la hora de lanzar un plan de ataque contra un objetivo, aunque las herramientas permiten recopilar información y en algunos casos, directamente explotar vulnerabilidades, lo más común es encontrarnos entornos en donde hay unas medidas de seguridad que ya tienen en cuenta las cosas más obvias, como actualizaciones y medidas de seguridad entre otras cosas. Dicho esto, no hay que olvidar nunca que como en prácticamente cualquier trabajo relacionado con tecnología, es necesario ser muy metódico, ordenado y limpio a la hora de realizar pruebas de penetración y esto es algo que no lo aprendes lanzando todo lo que viene en Kali Linux, lo aprendes con la experiencia y conociendo exactamente qué hacen por debajo las herramientas que utilizas en tu día a día para que no te conviertas en un “Nessus con patas” que solo lanza scripts y si no reportan nada es que todo está bien. Dicho esto, comenzaré a explicar algunas herramientas libres que me ido encontrando y que de alguna manera me han venido bien para trabajos que he realizado para algunos de mis clientes.
Jok3r: https://github.com/koutto/jok3r
Se trata de una herramienta particularmente interesante ya que no “reinventa la rueda” sino que en lugar de eso, reutiliza y combina un buen conjunto de herramientas de pentesting comunes para extraer la mayor cantidad de información de manera conjunta, sin tener que estar ejecutando cada una de forma independiente. Cuando se instala Jok3r el proceso puede tardar unos minutos ya que intenta instalar todas las dependencias y librerías necesarias por los proyectos que intenta combinar. También es posible instalar Jok3r desde su imagen oficial de Docker, una forma cómoda y rápida de tener la herramienta preparada para su uso.
Tal como se indica en el “README” del proyecto, cuenta con algunas características que la convierten en una herramienta muy interesante:
* Integración con más de 50 herramientas de pentesting comunes.
* Configuración sencilla, es posible eliminar o añadir herramientas con un simple fichero de configuración.
* Soporte a múltiples servicios de red basados en TCP y UDP, tales como HTTP, SSH, FTP, DNS, VNC, PostgreSQL, MySQL, etc.
* Se encarga de verificar el objetivo y seleccionar de forma automática las herramientas que puedan arrojar mejores resultados de acuerdo al contexto. Por ejemplo, en el caso de una aplicación web habilitará las herramientas relacionadas con pentesting en entornos web.
* Es capaz de detectar versiones y banners de productos específicos, para posteriormente compararlos con bases de datos CVE online, concretamente tirando de CVE Details y Vulners.
* Es capaz de realizar la explotación automática de algunas vulnerabilidades.
* Es capaz de realizar comprobaciones en CMS para detectar complementos o vulnerabilidades conocidas en Joomla, Drupal, WordPress, entre otros.
* Todos los resultados encontrados por la herramienta se van almacenando localmente en una base de datos y cuenta con algunas funcionalidades de reporting y gestión de resultados de forma independiente para cada auditoría realizada.
Bien, una vez visto el potencial de la herramienta lo siguiente es instalarla y usarla. Tal como se indica en las instrucciones de instalación del proyecto, la forma recomendada de hacerlo es utilizando la imagen Docker oficial, de esta forma no será necesario instalar dependencias directamente en el sistema host (son unas cuantas). No obstante, también se puede instalar directamente desde código fuente fácilmente, ya que cuenta con un script de instalación llamado “install_all.sh” que se encarga de dejarlo todo preparado para que sea posible utilizar la herramienta sin mayores dificultades. Basta simplemente con descargar la imagen y crear un nuevo contenedor, de la siguiente manera:
#sudo docker pull koutto/jok3r #sudo docker run -i -t --name jok3r-container -w /home/adastra/jok3r -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --shm-size 2g --net=host koutto/jok3r |
Las opciones “-w”, “-e”, “-v” y “–shm-size” son utilizadas para evitar problemas de memoria en el contenedor, así como para utilizar herramientas con una GUI como por ejemplo un navegador web. Con “–net” en Docker se especifica el modo de red, en este caso es compartido con el fin de que tanto anfitrión como contenedor se puedan ver y sea posible crear conexiones reversas.
Luego, para poder detener y volver a levantar el contenedor, se puede utilizar el comando “sudo docker start -i jok3r-container”
Una vez levantado el contenedor, es necesario dirigirse a la ruta “~/jok3r” que es donde se encuentra el script “jok3r.py”. Para ver las herramientas que se encuentran instaladas se debe ejecutar el comando:
#python3 jok3r.py toolbox --show-all |
En el caso de la imagen Docker, se podrá ver que están todas las herramientas instaladas, luego para la gestión de las mismas, se pueden ejecutar los siguientes comandos:
Instalar todas las herramientas disponibles (algo que ya viene en la imagen de Docker). #python3 jok3r.py toolbox --install-all --fast Actualizar todas las herramientas sin realizar preguntas, todo sí y adelante. #python3 jok3r.py toolbox --update-all --fast Desinstalar todas las herramientas. #python3 jok3r.py toolbox --uninstall-all --fast Desinstalar una herramienta concreta. #python3 jok3r.py toolbox --uninstall-tool nombre_herramienta Desinstalar un servicio concreto y las herramientas asociadas. #python3 jok3r.py toolbox --uninstall nombre_servicio |
Además del comando “toolbox” existen otros que permiten realizar verificaciones, ataques y ver el estado de la base de datos local.
Comando de información para los perfiles, servicios y productos.
El comando “info” permite ver qué perfiles se encuentran habilitados en la herramienta, las pruebas de seguridad que se aplican sobre cada protocolo soportado e información de los productos de software que se encuentran registrados en la herramienta. Tal como se ha visto antes con el comando “toolbox” hay una serie de opciones que permiten interactuar con éste comando.
Como se puede apreciar, el comando “info” soporta algunas opciones simples que permiten ver qué cosas puede hacer jok3r contra un objetivo determinado y otros detalles informativos que pueden ser útiles. Se puede ejecutar la herramienta de la siguiente manera.
| #python3 jok3r.py info –services
Enseña una tabla con los servicios, puertos por defecto de cada servicio, herramientas asociadas y número de checks que realizará Jok3r sobre dicho servicio. #python3 jok3r.py info --checks <servicio> Enseña una tabla con el nombre de cada una de las comprobaciones disponibles para el servicio indicado, así como la categoría del chequeo y la herramienta empleada para ejecutarlo. #python3 jok3r.py info –products Enseña una lista de servicios disponibles y los diferentes tipos de productos que implementa dicho servicio, por ejemplo, para un servidor web, el producto puede ser Apache, Nginx, IIS, etc. #python3 jok3r.py info –attack-profiles Enseña una tabla con los perfiles de ataque disponibles, los cuales simplemente se encargan de agrupar varios checks y herramientas en un contexto concreto, por ejemplo para realizar comprobaciones sobre un CMS. |
Base de datos local en Jok3r.
Antes de realizar cualquier tipo de auditoría de seguridad, en Jok3r se almacena todo en diferentes espacios de trabajo, de tal manera que cada auditoría y sus resultados correspondientes, se encuentran almacenados de forma persistente en contextos separados, esto es similar a lo que hay en Metasploit Framework cuando se utiliza el comando “workspace” desde msfconsole. El comando “db” es el encargado de definir misiones, las cuales son simplemente el contexto de una auditoría y partiendo de dichas misiones ejecutar pruebas de seguridad contra los objetivos indicados, los resultados quedarán almacenados en dicha misión.
Para crear una misión basta con ejecutar el comando “mission” tal como se aprecia en la imagen anterior.
Tal como se puede apreciar, el comando “mission” sirve para gestionar las misiones en Jok3r y además, al crear una nueva misión automáticamente cambia el contexto y ubica al usuario en la misión que se acaba de crear. Para moverse entre las diferentes misiones previamente creadas, se ejecuta el comando “mission <nombre>” y la herramienta se encargará de cambiar el contexto y apuntar a la misión indicada.
De momento esto es suficiente para ver las funcionalidades básicas de la herramienta, en el siguiente post se profundizará en su uso a la hora de ejecutar pruebas para auditorías de seguridad.
Un saludo y Happy Hack
Adastra.
Uso de Empire Framework contra sistemas Windows.
Empire es un framework muy interesante que incluye varios elementos de post-explotación enfocados a sistemas windows utilizando PowerShell, así como sobre sistemas GNU/Linux comprometidos utilizando Python. Cada uno de dichos elementos en Empire cuentan con varios mecanismos interesantes para la transferencia y ejecución de “stagers” en la máquina comprometida, siguiendo un modelo muy similar al que sigue Metasploit Framework a la hora de generar sesiones. Las comunicaciones entre el atacante y víctima son cifradas, algo que también comparte Metasploit Framework a la hora de utilizar payloads del tipo “meterpreter” y además, permite ejecutar instrucciones en PowerShell sobre un sistema windows aunque en dicho sistema no tenga el ejecutable “powershell.exe”. Los módulos de post-explotación incluidos en Empire son fáciles de desplegar y de utilizar, algunos de los cuales permiten la ejecución de keyloggers para el “espiar” las actividades del usuario, nuevamente algo muy parecido a lo que nos encontramos en los payloads del tipo meterpreter de Metasploit Framework . Empire también tiene la capacidad de ejecutar comandos en memoria, lo que significa que al no ser instrucciones que requieren acceso a unidades de almacenamiento persistente, tienen mayores probabilidades de no ser detectadas por AVs u otros mecanismos de seguridad que puedan estar en ejecución en el sistema comprometido.
Empire Framework asiste al pentester en las labores de elevación de privilegios, reconocimiento de red y de sistemas alcanzables, movimientos laterales entre hosts (pivoting) y la recolección de credenciales o cualquier detalle informativo que pueda resultar interesante. Empire consigue éste objetivo partiendo de 3 componentes principales: Listeners, Stagers y Agents.
– Listeners: Proceso en la máquina del atacante y que espera conexiones por parte de las víctimas.
– Stager: Instrucciones que envía el atacante a la víctima.
– Agents: Se trata del componente que mantiene la conexión entre la víctima y el atacante desde el sistema comprometido. Es el encargado de recibir cada stager enviado por el atacante y ejecutarlo.
Instalación de Empire
Hay 2 formas de instalar Empire, la más “clásica” consiste clonar el repositorio del proyecto, el cual se encuentra ubicado en: https://github.com/EmpireProject/Empire
| git clone https://github.com/EmpireProject/Empire.git
sudo ./setup/install.sh sudo ./empire |
Durante el proceso de instalación, se solicitará establecer una contraseña que será utilizada posteriormente entre el agente y listener.
La otra alternativa consiste en utilizar la imagen de Docker que se encuentra preparada para dicho propósito.
| docker pull empireproject/empire |
Una vez instalada la herramienta, basta simplemente con ejecutar el comando “./empire” y comenzará el proceso de carga de listeners, módulos, stagers y todo el entorno del framework.
Empire cuenta con un interprete de comandos para utilizar las funcionalidades principales de la herramienta. Como se puede apreciar en la imagen anterior, al iniciar Empire se enseña el número total de módulos cargados, número de listeners que se encuentran activos y los agentes en ejecución en alguna máquina remota.
Los comandos básicos se pueden apreciar rápidamente ejecutando el comando “help”, no obstante los más importantes inicialmente son aquellos que permiten interactuar con los diferentes elementos del framework, especialmente los listeners y módulos. Para enseñar los Listeners que se encuentran actualmente activos, basta simplemente con ejecutar el comando “listeners” y para utilizar alguno de los disponibles en el framework, ejecutar el comando “uselistener”. El interprete de Empire permite auto-completar con la tecla “tab” lo cual resulta extremadamente útil y práctico a la hora de interactuar con los elementos de la herramienta.
Una vez seleccionado uno de los listeners disponibles, es posible ejecutar el comando “info” para obtener información de las opciones de dicho listener y a continuación, cada una se puede establecer con el comando “set option value”.
Una vez iniciado el listener es el momento de seleccionar un stager existente con el comando “usestager stager”. Por ejemplo “usestager windows/launcher_bat”. Posteriormente se deben definir sus propiedades, del mismo modo que se ha explicado antes para los Listeners, en éste caso concreto, siempre será necesario establecer la propiedad “Listener” con el nombre del listener que se ha iniciado en el paso anterior, el comando a ejecutar es “set Listener nombre-listener”.
Si se ha utilizado el stager “windows/launcher_bat”, una vez el fichero “.bat” sea transmitido y ejecutado sobre el sistema Windows comprometido, se podrá obtener una conexión reversa en Empire y se podrá ver que en la consola aparece un nuevo agente habilitado.
Un agente es como una sesión en Metasploit Framework, lo que significa que el siguiente paso consiste en interactuar con él para llevar a cabo el proceso de post-explotación. Hay que tener en cuenta que Empire no es un framework de explotación como sí lo es Metasploit Framework, con lo cual el proceso de iniciar una conexión reversa tras ejecutar un agente en un sistema remoto tiene que llevarse a cabo después de que el sistema haya sido comprometido y sea posible ejecutar instrucciones sobre él, en el caso de la figura anterior, por ejemplo, ha sido la ejecución de un fichero “.bat”. Una alternativa en el proceso de explotación podría consistir en utilizar técnicas de ingeniería social y “forzar” de alguna manera a un usuario del sistema objetivo a ejecutar el fichero .bat que se ha generado desde Empire u otra podría ser la explotación de alguna vulnerabilidad en el sistema objetivo, subir el .bat y ejecutarlo.
Para interactuar con un agente se debe utilizar el comando “interact”, tal como se puede apreciar en la siguiente imagen.
Existen varios módulos disponibles en Empire que se encuentran en el contexto de cada uno de los agentes disponibles, dichos módulos se centran en la extracción de información y en la elevación de privilegios. Uno de los elementos más interesantes para conseguir el propósito de elevar privilegios sobre un sistema windows es “PowerUp” el cual contiene múltiples módulos para identificar y explotar servicios vulnerables, registros del sistema y cualquier oportunidad de elevar privilegios. Todos los módulos de PowerUp se encuentran incluidos en “privesc/powerup/*” y uno de los más útiles es precisamente “powershell/privesc/powerup/allchecks” ya que realiza todas las pruebas de PowerUp contra el sistema.
ByPass UAC con Empire
Como seguramente el lector ya sabe, el mecanismo UAC (User Account Control) se ha implementado a partir de Windows Vista y se caracteriza por contar con 3 niveles de integridad que separan los permisos que tienen los usuarios del sistema sobre los recursos: Alto, Medio y Bajo. La mayoría de aplicaciones y servicios que ejecuta un usuario se encuentran en el nivel medio, en donde se incluyen los privilegios estándar para el acceso a recursos comunes, pero evidentemente no es posible ejecutar actividades administrativas para las que es requerido estar en el nivel “alto”. En los últimos años han surgido varias técnicas de “ByPass UAC” que permiten escapar del nivel “Medio” y moverse directamente al nivel “Alto” de UAC. Dichas técnicas incluyen, entre otras cosas, la inyección de librerías dinámicas que intenten realizar el proceso de elevación o la ejecución del programa “wscript.exe” / “cscript.exe” con un fichero manifest malicioso ubicado en C:\Windows para lanzar instrucciones con un nivel de integridad UAC alto. Estas técnicas se encuentran disponibles en Metasploit Framework con sus correspondientes módulos de Post-Exploitation como en Empire por medio del comando “bypassuac” disponible en cada uno de los agentes del framework.
Como se puede apreciar en la figura anterior, se ha lanzado el módulo “bypassuac” directamente en el contexto del agente, el cual no tiene privilegios administrativos sobre el sistema. Dicho módulo recibe como argumento el nombre de un listener en ejecución, en éste caso se puede utilizar el mismo listener que se ha iniciado anteriormente a la hora de obtener una conexión reversa con el agente. Hay que tener en cuenta que todos los módulos en Empire se ejecutan en segundo plano, por lo tanto es posible seguir interactuando con la herramienta y en la medida de que los módulos lanzados van recuperando información o generando algún tipo de traza, van apareciendo en la consola, lo que a veces puede confundir un poco. En la imagen anterior se puede ver que tras la ejecución del módulo “bypassuac” se ha generado un nuevo agente, el cual, al listarlo en la herramienta, aparece con un “*” en la columna de “Username” lo que significa que dicho usuario puede ejecutar comandos como administrador.
Mimikatz con Empire
Mimikatz (o Kiwi) es una herramienta muy conocida en el mundo de la post-explotación en sistemas Windows, permite extraer información sensible de la memoria del sistema concretamente detalles relacionados con cuentas de usuarios y credenciales. Se trata de una herramienta que se encuentra disponible en Metasploit Framework en forma de módulo externo, sin embargo en el caso de Empire también se encuentra disponible entre los módulos disponibles para cada uno de los agentes. Para poder usar el módulo “mimikatz” en Empire, es necesario tener privilegios administrativos, por lo tanto es necesario tener un agente con permisos elevados, ya sea un usuario administrador o que el proceso del agente se encuentre en el nivel “Alto” de UAC, esto es importante para que Mimikatz pueda leer registros e información en la memoria del sistema operativo, sino se cumple con este requisito la herramienta no puede extraer prácticamente nada de la memoria.
Como se puede apreciar en la imagen anterior, Mimikatz ha sido capaz de extraer información interesante del sistema, incluyendo nombres de usuarios y contraseñas en texto plano.
Empire es una alternativa interesante que es fácil de utilizar, flexible y a día de hoy funciona bastante bien. Si el lector se encuentra interesado en temas de post-explotación de sistemas y busca participar en algún proyecto basado en Python para mejorar sus habilidades, probablemente Empire será una muy buena opción.
Un saludo y Happy Hack.
Adastra.
Formaciones para el segundo semestre del 2019 en Securízame
Como algunos de vosotros ya sabéis, llevo un tiempo colaborando con Securízame en los cursos presenciales de Hacking y RedTeam, así como en la certificación RTCP. Llevamos un tiempo elaborando y actualizando los contenidos de estas formaciones y estamos muy contentos de ver los progresos que han tenido nuestros estudiantes, a título personal me resulta muy satisfactorio el hecho de haber tenido alumnos sin ningún conocimiento previo en seguridad informática y ver su evolución a lo largo de las formaciones. Evidentemente, como siempre he dicho, es importante que los alumnos tengan una buena predisposición para el estudio y ganas de aprender, afortunadamente en prácticamente todos los casos me he encontrado con personas que realmente están interesadas en su aprendizaje, en afianzar sus habilidades para mejorar profesionalmente. Por otro lado, también estamos muy contentos con la certificación RTCP, la cual está teniendo un impacto y aceptación tremendo entre profesionales y empresas del sector al tratarse de la primera certificación española 100% práctica en un entorno real. RTCP marca diferencias importantes con respecto a otras certificaciones tan conocidas y valoradas como la OSCP, una de ellas es que el examen es completamente práctico, presencial y enfocado al mundo real. Qué quiere decir esto? Que no es como un CTF cualquiera, que no te vas a encontrar preguntas de selección múltiple, ni tampoco te vamos a pedir que crees un exploit para una vulnerabilidad de Buffer Overflow simple en un sistema windows XP, como ocurre en la OSCP. Consideramos que esto puede estar muy bien en el mundo académico, pero no en el mundo empresarial en donde existen firewalls, sistemas de detección de intrusos, aplicaciones actualizadas, AVs, etc. La certificación la enfocamos a ese tipo de situaciones, a las que un pentester profesional se tiene que enfrentar en su día a día, esto significa que no es una certificación fácil de conseguir pero del mismo modo, se traduce a que el poseedor de dicha certificación REALMENTE tiene conocimientos sobre el tema, que es precisamente lo que buscan las empresas y por los perfiles que más se paga.
Como algunos ya sabéis, el pack de formaciones completo está compuesto por un curso básico, avanzado, entrenamiento y finalmente la certificación, sin embargo un alumno puede optar por adquirir uno o ambos cursos, el entrenamiento o presentarse directamente al examen de certificación, en este sentido no hay ninguna restricción.
Para este segundo semestre del 2019 hemos incluido algunos cambios y mejoras, en primer lugar hemos actualizado algunos contenidos del curso avanzado y además, vamos a incluir algunas máquinas del entrenamiento (las más sencillas). Luego, en el entrenamiento que se hará un mes después del curso avanzado, el último día hemos decidido plantearos como reto resolver el examen RTCP anterior (cada nueva convocatoria del RTCP incluye un examen diferente al de la convocatoria anterior), es decir, que desde el entrenamiento ya vais a saber cómo es la filosofía del examen y podréis ir más preparados. La idea es que antes de finalizar el entrenamiento, intentéis resolver el examen de la versión anterior del RTCP y tras un tiempo prudencial, explicaros la solución.
Finalmente recordaros que la primera formación comienza en pocas semanas, concretamente el día 20 de septiembre empezamos con el curso básico de Hacking y aún nos quedan plazas, pocas pero aún hay, así que si estás interesado no dudes en apuntarte.
Un saludo y Happy Hack.
Adastra.
Servicios en TheHackerWay
Descubre los productos y servicios enfocados a la seguridad informática que ofrecemos en TheHackerWay
Deep web: Privacidad y anonimato.
Compra el libro de "Deep Web: TOR, FreeNET & I2P - Privacidad y Anonimato"
Hacking con Python
Compra el libro de "Hacking con Python".
Python para Pentesters
Compra el libro de "Python para Pentesters".
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
