Mostrando entradas con la etiqueta Ruby. Mostrar todas las entradas
Mostrando entradas con la etiqueta Ruby. Mostrar todas las entradas

miércoles, julio 14, 2021

Pentester e Intrusión en un sistema Versus Analista Forense y Detección de Intrusión (Parte I de III)

A lo largo y ancho de Internet no son difíciles de encontrar casos prácticos que explican el uso de diferentes técnicas y herramientas para aprovechar vulnerabilidades en sistemas, aplicaciones, dispositivos móviles, redes de datos, etcétera. De la misma forma, aunque en menor medida, es posible encontrar sin mucha dificultad supuestos prácticos en los que se realizan acciones de detección y análisis de distintos tipos e incidentes de seguridad.

Figura 1: Pentester e Intrusión en un sistema Versus
Analista Forense y Detección de Intrusión (Parte I de III)

En el primer caso estaríamos dentro del ámbito de la seguridad ofensiva, los red team, el pentesting y el hacking ético; y en el segundo, nos estaríamos moviendo dentro del ámbito de la seguridad defensiva, los blue team y el DFIR (Digital Forensic and Incident Response). Sin embargo, lo que no es tan fácil de encontrar son supuestos prácticos que aúnen las dos aproximaciones, es decir, supuestos prácticos en los que se realicen una serie de acciones para lograr vulnerar un sistema e inmediatamente después se analice el rastro dejado por dichas acciones en los distintos elementos o artefactos del sistema.

Ethical Hacking Didáctico

Aplicando un enfoque didáctico, son indudables las ventajas que aporta el trabajo con este tipo de casos prácticos. Desde el punto de vista ofensivo, ayuda a tomar consciencia de la mayor o menor incidencia que las acciones realizadas durante una auditoría de seguridad o test de intrusión dejan en los sistemas, lo cual redundará en una mejora a la hora de tomar decisiones durante un trabajo de este tipo.

Figura 2: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Por otro lado, desde el punto de vista defensivo, ayuda a comprender mejor el proceso por el cual han sido generadas las evidencias encontradas durante un proceso de análisis o el motivo por el cual se produce una alerta en nuestros sistemas de monitorización, esto redundará en una mayor eficiencia a la hora de analizar los artefactos de un sistema o a la hora de diseñar alertas personalizadas o indicadores de compromiso (IoCs) para nuestros sistemas de monitorización.

Durante el curso que ahora acaba, he impartido, en el CIFP Rodolfo Ucha Piñeiro de Ferrol, los módulos de Análisis forense informático y Bastionado de redes y sistemas que forman parte del nuevo Curso de especialización en ciberseguridad en entornos de las tecnologías de la información de la familia profesional de Informática y comunicaciones. Durante el transcurso del mismo, y principalmente para el primero de los módulos mencionados, he tenido que diseñar e implementar diferentes supuestos prácticos de este estilo para poder trabajar posteriormente con distintos artefactos y herramientas forenses que nos permitiesen analizar lo sucedido.

A modo de ejemplo, describo a continuación como implementar y analizar un escenario práctico sencillo sobre una máquina metasploitable 3 basada en Ubuntu Server 14.04. La utilización de máquinas de este estilo, con diferentes vulnerabilidades en los servicios que implementan, facilita mucho la tarea de preparación de un escenario ya que, sobre el mismo sistema, es posible realizar una gran variedad de acciones que tendrán distintos tipos de impacto sobre los diferentes artefactos del sistema. 

Además, es fácil encontrar abundante documentación sobre cómo explotar las vulnerabilidades que presentan. Obviamente, para ilustrar la explotación y análisis de vulnerabilidades más recientes será necesario partir de máquinas con sistemas más actuales.

Explotación de vulnerabilidades

Para realizar la intrusión utilizaremos una máquina Kali Linux situada en la misma red que la máquina objetivo. Comenzaremos realizando un escaneo con nmap sobre todos los puertos de la máquina (-p) tratando de obtener la versión del servicio que se está ejecu- tando (-sV) y estableciendo un número mínimo de paquetes enviados por segundo (--minrate 7500).

Figura 3: Servidor HTTP descubierto en puerto 3500

En este caso, vamos a aprovechar las vulnerabilidades existentes sobre el servidor de Ruby on Rails que se está ejecutando en el puerto 3500. Y haremos sobre este entorno un poco de Pentesting con Metasploit

Figura 4: Metasploit para Pentesters Gold Edition
de Pablo González en 0xWord

Utilizaremos para ello el exploit rails_actionpack_inline_exec de Metasploit que sacapa partido de la explotación de la vulnerabilidad con CVE 2016-2098. Primeramente, estableceremos los parámetros necesarios para ejecutar el exploit.

Figura 5: Configuración del exploit en Metasploit

Acto seguido lo ejecutamos e inmediatamente conseguimos una shell remota, pero con el usuario chewbacca que no tiene permisos de administrador.

Figura 6: Conseguido permisos de usuario

Trataremos de hacer ahora una Escalada de Privilegios que nos dé permisos de root dentro de la máquina. Para ello, primero miramos la versión de sistema operativo y el kernel de la máquina víctima.

Figura 7: Versión del kernel de la máquina víctima

Luego, haciendo una búsqueda por los exploits disponibles para dicha versión, seleccionaremos uno que nos permita una Escalada de Privilegios.

Figura 8: Búsqueda de exploits para escalada de privilegios

Una vez elegido, lo que haremos a continuación será descargar el fichero con el exploit dentro de la máquina víctima, en este caso el 37292.c, compilarlo y ejecutarlo. Lo descargaremos de https://www.exploit-db.com/download/37292:

Figura 9: Descarga del exploit de EoP que vamos a usar

Lo renombramos, compilamos y ejecutamos. Tras la ejecución vemos que hemos conseguido hacernos con privilegios de root dentro de la máquina víctima.

Figura 10: Compilación, ejecución y Elevación de Privilegios a root hecha.

Vamos a habilitar ahora un mecanismo para facilitar accesos posteriores. Ya hemos conseguido entrar pero ahora hay que conseguir la permanencia, que es otra de las fases de todo buen Ethical Hacking. Cómo conseguir tener control perdurable a lo largo del tiempo, incluso después de los reinicios y de la aplicación del parche a las vulneratilidades explotadas para conseguir el acceso inicial.

Figura 11: Pentesting con Kali Silver Edition

Para ello, vamos a mirar los usuarios que hay en el sistema y vamos a elegir uno de los que crean por defecto los servicios instalados y con los que, en teoría, no es posible iniciar una sesión interactiva. En este caso, nos fijamos en el usuario www-data. La daremos una contraseña, le indicaremos una shell de inicio y lo añadiremos al grupo sudo:

Figura 12: Usuarios disponibles en el sistema

Vamos a comprobar ahora si es posible conectarnos por SSH con dicho usuario. Lo haremos desde otra terminal de nuestra máquina Kali Linux.

Figura 13: Preparando el usuario www-data

Comprobamos cómo, efectivamente, hemos podido acceder al sistema y obtener permisos de root haciendo uso del usuario www-data que previamente hemos dejado bien preparado para poder volver a esta máquina siempre que queramos.

Figura 14: Accediendo como www-data

Y hasta aquí nuestra toma de control total de una máquina, tal y cómo lo haría un atacante de verdad. Pero toda intrusión deja rastros, y aquí no los hemos borrado pertinentemente. Esto es algo que, curiosamente, no se enseña en los cursos de test de penetración. La razón es bastante simple, cuando alguien es contratado para realizar un proyecto un Ethical Hacking no tiene porque preocuparse de que los analistas forenses lo localicen, pero los malos de verdad si que están preocupados por eso... o deberían.

En las siguientes partes vamos a ver cómo un trabajo de Análisis Forense puede descubrir todo lo que ha pasado a la hora de hacer un post-mortem de una intrusión, pero eso lo vermos en la siguiente parte de este artículo.

Saludos,

lunes, julio 12, 2021

GitHub Copilot y el debate de la Propiedad Intelectual

Ya llevo un tiempo hablándoos de Inteligencia Artificial y de algunas de sus innovadoras respuestas a problemas de la vida cotidiana y de cómo pueden afectar al futuro de nuestra sociedad. Hoy toca hablar de uno de los últimos casos polémicos en los que ha estado involucrada la Inteligencia Artificial, en este caso, de cómo GitHub Copilot ha abierto un debate acerca de si la inteligencia artificial en casos de uso como estos infringe los derechos de autor de los programadores al utilizar el código escrito por ellos para entrenarse.

Figura 1: GitHub Copilot y el debate de la Propiedad Intelectual

Si no conoces GitHub Copilot te lo presentamos brevemente. Copilot es un asistente de código diseñado para ayudar a los programadores y que funciona con Codex, un innovador sistema creado por Open AI que utiliza la inteligencia artificial para comprender el contexto del código que los programadores están haciendo para sintetizar código que coincida con el resto del programa. De hecho, Copilot es capaz de proponer a sus usuarios desde líneas de código hasta funciones completas.

Figura 2: Copilot, asistente de programación.

GitHub Copilot cuenta es de una gran velocidad, y es capaz de proponerte otras alternativas a tu código mientras escribes, además funciona como una extensión de Visual Studio Code, lo que quiere decir que podremos utilizarlo tanto en nuestro equipo como en la nube o en el entorno de desarrollo instantáneo de GitHub. Copilot también trabaja con una gran cantidad de idiomas y lenguajes de programación entre los que se encuentran Python, JavaScript, Ruby y Go, aprendidos con sus algoritmos de "Machine Learning", lo que hace que sea una herramienta capaz de orientar a la mayoría de los programadores. 

Figura 3: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández.

Como os hemos dicho antes y como su propio nombre indica, la función de esta herramienta es asistir durante la programación, aunque la herramienta pueda ofrecer interesantes alternativas para optimizar el código el programador será siempre el que tenga la última palabra. Con esto se logra ajustarse a las necesidades de cada usuario, ayudándole cuando lo necesite y dejando que escriba código de forma “tradicional” cuando quiera.

Figura 4: Funcionamiento de GitHub Copilot.

Otra de las grandes ventajas de Copilot es que ofrece la posibilidad de convertir un comentario en código. Solo hay que escribir un comentario en el que se describa la lógica deseada y esperar a que la inteligencia artificial haga su trabajo y ensamble el código por nosotros. Del mismo modo Copilot también es capaz de autocompletar patrones de código repetitivo. Esto quiere decir que si generamos un ejemplo la herramienta es capaz de generar el resto del código haciendo que solo tengamos que decidir con que partes queremos quedarnos. 

Durante la programación es común utilizar pruebas para comprobar que el software que se esta construyendo funciona correctamente y cuenta con unas bases sólidas, con GitHub Copilot es posible importar un paquete de prueba unitaria y dejar que la IA sugiera pruebas que coincidan con el código introducido para comprobar su efectividad.

Figura 5: Ejemplo de prueba para el código propuesta por Copilot.

Pero si GitHub Copilot es tan bueno, ¿por qué ha habido una creciente polémica acerca de la herramienta durante estas últimas semanas? La respuesta es sencilla, Copilot es capaz de programar gracias al código Open Source de la plataforma, código que han compartido otros programadores. Hasta aquí no hay ningún problema, el problema surgió cuando Microsoft anunció que el sistema sería de pago, lo que ha sentado mal a muchos desarrolladores. El código que ha utilizado y sigue utilizando GitHub Copilot se encuentra bajo licencias GPL, esto quiere decir que el código de la plataforma puede utilizarse para generar código derivado pero este nuevo código debe de ofrecerse bajo las mismas condiciones.

El debate de la Propiedad Intelectual

Varios programadores ya han expresado su malestar tanto en las redes sociales como en la propia plataforma ante el hecho de que se haya utilizado una Inteligencia Artificial para generar una rentabilidad comercial al código que ellos, y muchos otros, han compartido desinteresadamente. Esto ha abierto un gran debate acerca de como deberían aplicarse las leyes del Copyright en un caso como este. Según la OMPI (Organización Mundial de Propiedad Intelectual) las obras creativas gozan de la protección del derecho de autor si son originales, sin embargo, en la mayoría de las definiciones relativas a la originalidad se hace referencia a un autor humano, por lo tanto, a pesar de que la Inteligencia Artificial generase código no podría considerarse como un autor.

Figura 6: Organización Mundial de la Propiedad Intelectual (OMPI/WIPO).

Ante esta situación varios expertos han compartido sus distintas perspectivas acerca de las leyes de derechos de autor sobre este caso de uso de la IA. Algunos expertos se han mostrado a favor de que corporaciones como Microsoft utilicen el código abierto para su propio interés, argumentando que evitar su uso con estos fines supondría ir en contra de las bases del código Copyleft, y esto podría derivar en futuras leyes de Copyright cada vez mas restrictivas. También se ha planteado que a pesar de que la Inteligencia Artificial Copilot utilice este código abierto para generar nuevos fragmentos de código, no quiere decir que esto sea un trabajo derivado, y por lo tanto no debería de estar cubierto por las leyes de propiedad intelectual.

Por otro lado, muchos programadores no quieren que se utilice su código para entrenar a la Inteligencia Artificial Copilot. Si este es el caso, GitHub ofrece un detector de duplicación que alertaría a los usuarios de Copilot de que el código propuesto en cuestión se trataría de un duplicado de otro autor y ofrecería la posibilidad de atribuirle esa parte del código, o buscar otra opción. Esta solución planteada por la plataforma no acaba de convencer a aquellos programadores que no quieren que Microsoft utilice la IA para monetizar un trabajo que ellos han compartido de forma gratuita. 

Figura 7: Porcentaje de regurgitación de código tras un análisis de la herramienta
(aproximadamente un caso por cada 10 semanas de uso).

De hecho, en los términos de Licencia de GitHub se explica claramente que al compartir tu código a través de la plataforma se le da permiso para incluirlo en sus bases de datos e índices de búsqueda para que otros usuarios puedan acceder a él y así ayudarles en sus proyectos, pero no venderlo a terceros.

Por el momento no podemos saber cómo concluirá este debate debido a estos pequeños vacíos legales en la ley de Copyright en lo que a Inteligencia Artificial se refiere. Y tampoco sabemos que sucedería en el caso de que un programador demandase a Copilot o Microsoft por el uso de su código ya que, según GitHub, aunque el código que se comparte en la plataforma pueda ser utilizado por otros usuarios sigue perteneciendo a la persona que lo hizo. 

Sin duda alguna, este tema dará mucho que hablar durante los próximos meses e incluso podría llevar a una nueva reforma en la ley de propiedad intelectual.
 
Saludos,
 
Autor: Sergio Sancho, Security Researcher en Ideas Locas.


lunes, febrero 11, 2019

SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

SecDevOps, DevOpsSec, DevSecOps o como lo quieras llamar, supone un gran avance en el diseño y la programación de código seguro. Nuestro libro Docker: SecDevOps estaba centrado en la importancia de este paradigma dentro del diseño de una aplicación hoy en día. Vamos a intentar explicarlo en este post de la forma más simplificada posible siguiendo los principales pasos de este nuevo paradigma que más vale que domines si quieres estar en equipos de creación de tecnología de alto rendimiento, pues se aplica en todos ellos.

Figura 1: SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

DevOps es un cambio en la forma y la cultura de trabajo entre programadores o desarrolladores (“Dev”, developers) y el personal encargado de las operaciones (“Ops”, operations) o mejor dicho de los encargados de la infraestructura (como por ejemplo los administradores de sistemas). Al principio no existía una estrecha relación entre ellos, y una gran mayoría de ocasiones, acarreaba problemas como por ejemplo que la aplicación no funcionara o la típica frase “pues en mi máquina funciona” que tanto hemos oído.

Figura 2: Libro de Docker:SecDevOps en 0xWord de

Uno de los pilares de DevOps no es más que acercar a ambos grupos para que al fin y al cabo trabajen juntos y así rellenar ese hueco que antes existía entre ambos departamentos, en definitiva: "Colaboración".

De esta forma el desarrollador, tendrá mayor conocimiento sobre la infraestructura donde correrá su aplicación, y los de operaciones, los recursos que la aplicación necesitará. Y las ventajas son enormes. Por ejemplo, el técnico de operaciones sabrá en todo momento qué librerías/entorno de ejecución, necesitaría para satisfacer las necesidades de la aplicación, y así detectar aquellas que faltan o que son necesarias.

Otro de los pilares de DevOps, es la automatización. En general, la automatización debería aplicarse a todo el proceso. Todo esto incluso implica a la provisión de entornos y recursos. De esta forma llegamos a otros de los pilares que es el feedback o retroalimentación continua. Así podremos observar no solo errores, sino hasta la evolución misma de la aplicación. En definitiva, el desarrollo ya no será sólo cosa de uno, ahora entrarán más actores en el proceso.

Ciclo de vida DevOps

En la siguiente imagen podemos ver el ciclo de vida “típico” de una aplicación en un entorno DevOps.

Figura 3: Modelo clásico DevOps

En “Plan” se recogen los requerimientos de la aplicación, “Code” es donde se comienza a escribir código, “Test” es la fase de ejecución pruebas, “Package” es donde empaquetamos la aplicación para su despliegue (por ejemplo, un contenedor Docker) y luego “Release” es cuando subimos el artefacto (como el contenedor Docker del ejemplo anterior). En la siguiente fase “Deploy” es cuando se comienzan a aplicar los controles de seguridad.

Demasiado tarde. El equipo encargado de la seguridad (“Sec”, Security) encontrará problemas en esta fase reportándolos al equipo de desarrollo y esto provocará un tapón o retraso en los tiempos de entrega. Pero no sólo eso, una vez aplicados los parches o soluciones, estos deberán de ser probados de nuevo o simplemente se darán por resueltos sin estarlo al 100%, lo cual afectará a la calidad y seguridad del producto final. Hay que aplicar una mitigación a este problema, y se llama SecDevOps.

Ciclo de vida: SecDevOps

Simplemente, consiste mover la aplicación de los controles de seguridad desde la primera fase, en lo que se denomina “Shift Left” o desplazamiento hacia la izquierda. Este sería el esquema visto anteriormente adaptado a SecDevOps:

Figura 4: Nuevo modelo SecDevOps

Y visto esto, la pregunta es ¿Qué funciones hay que realizar de Sec en cada una de las fases de este nuevo modelo de ciclo de vida? Pues vamos a verlo.

“Plan” o planificación.
En esta fase es donde se analiza el modelo de amenazas o Threat Modeling. Por ejemplo autenticación de usuarios, servidores externos, cifrado, etcétera. Aquí se generarán “tickets” también conocidos como “stories” destinados específicamente a la seguridad.
Figura 4: Evil User Stories
Algunas herramientas o recursos son OWASP Application Threat Modeling o Don´t forget EVIL user stories, que básicamente es lo que hacen muchos hackers en sus procesos de research.
 “Code” o programación.
El técnico del equipo de seguridad se convierte en formador y proveedor explicando e informando al equipo de desarrollo cómo utilizar ciertas herramientas de seguridad (análisis de código estático), pero sobre todo a familiarizar al programador términos relacionado con la seguridad como por ejemplo qué son los ataques SQLi, XSS, DDoS, etcétera. Vamos, en el mundo de aplicaciones web debes conocerte los temas de Hacking de Aplicaciones Web: SQL Injection, de Hacking Web Technologies y de Hacking de Aplicaciones Web: Client-Side Attacks al dedillo.
Figura 5: Hacking Web Technologies
Aquí también entrarían herramientas como como Git-Secrets o Git-Hound pueden ser algunas de las que se podrían utilizar, las cuales permiten analizar el envío de un git commit no contiene datos críticos como contraseñas, tokens, etcétera.
“Test” o pruebas.
Aquí se ejecutan los tests unitarios y de integración, pero en el caso que nos ocupa, aquí nos enfocaríamos a tests que verifiquen aspectos de seguridad. Estas pruebas deberían de ser totalmente automáticas para de esa forma no dejar pasar ningún problema de los detectados en la fase principal (detección temprana). Las herramientas para esta fase son varias y dependen del entorno donde se realiza el desarrollo. Tal vez en otros artículos podamos ir viendo algunos ejemplos.

“Package” o empaquetado.
Aquí es donde se unifica todo el código en un sólo paquete o artefacto como por ejemplo un programa compilado, etc. Un escaneo de seguridad para las librerías externas donde se detecten posibles vulnerabilidades, sería la operativa de seguridad a aplicar. En el caso de Docker es el momento de comprobar la seguridad de las imágenes. 

Figura 6: Dagda Docker Security Suite 
Para Ruby, por poner algún ejemplo, existen herramientas como bundler-audit, para Docker tenemos Dagda (creada por nuestro colega y co-autor del mismo libro, Elías Grande) o Docker Bench, para Node tenemos nsp, etcétera.
“Release” o entrega.
Aquí es donde ponemos nuestro artefacto en algún repositorio central desde el cual será consumido durante la fase de despliegue. En el caso de Docker, muchos registros ofrecen escáneres de seguridad ya integrados que escasearán nuestra image, en este caso se podría evitar el escaneo de la imagen en la fase anterior.
“Deploy” o despliegue.
La aplicación se despliega o se instala en un entorno preparado para probarla. Podrán existir varios entornos de pruebas específicos para que cada equipo pueda trabajar en una parte concreta del programa. Esta fase se podría llamar también fase de pre-producción. 
Figura 7: Ethical Hacking
Aquí es donde aparece el equipo de QA para realizar los test de calidad y es donde se realiza un análisis dinámico de la aplicación (XSS, SQLi, SSL habilitado, etcétera). Las herramientas del equipo de seguridad son las típicas de cualquier fase de Ethical Hacking, como por ejemplo nmap, sqlmap, Nikto, o la FOCA.
“Operate”, fase de operación.
La aplicación ya está desplegada y funcionando. Entonces es ahora cuando hay que probar la seguridad realizando pruebas RedTeam de seguridad, resiliencia (Chaos Engineering, Circuit Breaker, etc.), etcetera.

“Monitor” o monitorización. 
Partiendo de la premisa que los logs están centralizados (práctica más que recomendable de seguridad), es cuando estos se analizan de forma automática para detectar posibles ataques como XSS, SQLi, DoS, DDoS, etcétera o incluso situaciones de stress en los equipos como falta de memoria o uso de CPU excesiva. Splunk o Devo de licencias comerciales o ELK sean posiblemente las herramienta más conocidas de las utilizadas en esta fase.
Pues esto es todo, esperamos que este breve artículo sirva de introducción al SecDevOps y entre todos consigamos realizar aplicaciones más seguras.

Fran Ramírez,  es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Rafael Troncoso es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

martes, abril 03, 2018

TwLocation en Python y un viejo script en Ruby: La API de Twitter sigue dando juego con la info GPS

Éste es un tema que no es nada nuevo. La geolocalización de los tuits es algo antiguo, es más, nosotros en ElevenPaths hace unos años hicimos una herramienta que analizaba los tuits de un usuario y los posicionaba en un mapa, siempre y cuando el usuario tuviera activa la geolocalización de los tuits en su cuenta.

Figura 1: TwLocation en Python y un viejo script en Ruby:
La API de Twitter sigue dando juego con la info GPS

Aún recuerdo las pruebas con nuestras cuentas, creando alguna cuenta y configurando la geolocalización de los tuits. Todo comenzó con un script escrito en Ruby y acabo siendo un servicio interno. Quizá fueran los comienzos del departamento de ideas locas y de pruebas de concepto, pero de ello hablaré más tarde.

Figura 2: Geolocalización de Twitts de SteveWozniak con nuestra tool

Echando un ojo por Internet, he topado con una herramienta escrita en Python muy similar a lo que os comentaba. En este caso la herramienta se llama TwLocation y permite fijar unas coordenadas, un rango alrededor y el número de tuits que queremos encontrar en ese radio en tiempo real. La herramienta la vi en KitPloit y tiene una pinta interesante, pero no solo por lo que proporciona, si no por el cómo está hecha. Permite saber quién pone mensajes en Twitter con ubicación GPS activada, en un determinado rango de localización, al estilo del mapa de WatchDogs.

Figura 3: Mapa de Londres We Are Data del juego de WatchDogs

La herramienta se puede descargar desde Github y tiene unos pocos días, al menos en esta versión, subida al repositorio. El funcionamiento es sencillo, la herramienta utiliza OAuth para poder realizar peticiones a la API de Twitter.

Figura 4: TwLocation en Twitter

Cuando descargamos la aplicación de TwLocation, ésta tiene unos requisitos que se pueden encontrar en el fichero de requirements.txt. Para instalar los requisitos ejecutamos el pip install –r requirements.txt. En el fichero config.txt, encontramos la configuración de la App OAuth. En el caso de Twitter requerimos: Consumer_Key, Consumer_Secret, Access_Key y Access_Secret. Esta información se puede obtener con una cuenta de Twitter y accediendo al dominio dev.twitter.com o developer.twitter.com.

Figura 5: Instalación de TwLocation

Cuando se configura el fichero config.txt con lo necesario para poder utilizar la API de Twitter, se ejecuta con Python el script. Al arrancar el script nos solicita datos sobre latitud, longitud, el rango alrededor de ello y el número de resultados máximos que se van a obtener y almacenar en un fichero CSV.

Figura 6: Usuarios que twittean en una determinada ubicación GPS con el tiempo
En la imagen superior, se puede ver los datos introducidos y con el paso del tiempo se van recibiendo en tiempo real diferentes tuits que cumplen las condiciones de geolocalización indicadas. Por ejemplo, si fijamos un punto concreto, estaremos viendo lo que se tuitea alrededor de dicho punto. Es más, veremos quién tuitea, ya que el username también se obtiene.

Figura 7: Fichero CSV de salida

Además, la herramienta facilita la posición en un mapa a través del enlace a Google Maps. Esto es interesante para pintarlo. Esta parte tiene relación con el ‘viejoscript de Ruby llamado Poc_Twitter.rb que en su día realicé. Al finalizar la ejecución, se obtiene un fichero CSV, el cual, como se puede ver en la imagen, proporciona los siguientes campos:
• Username
• Profile URL
• Latitude
• Longitude
• Google Maps
• Tweet
El fichero es automatizable, es decir, podríamos procesarlo con otro script para procesar la información obtenida. Como se puede entender es interesante, cuando manejamos un gran volumen de información. En el siguiente vídeo se puede ver cómo funciona TwLocation.
El viejo script ‘Poc_Twitter.rb’

Este script que data de finales de 2014 tiene bastante historia. Jugando con OAuth por aquel entonces, jugando con Twitter y con el libro Got Root en la cabeza, ya que algo aparece allí, decidí hacer una pequeña prueba de concepto. Primero, identificar si un usuario tenía la geolocalización activa. Esto es algo que la API de Twitter te indicaba a través de un campo. Rápidamente, puedes saber si un usuario tiene la geolocalización activa, y como vimos, famosos y terroristas tenían activada esta geolocalización en Twitter.

Figura 9: Tuits de un terrorista con ubicación GPS

Esto no acaba aquí, si el tuit tiene coordenadas es que ese tuit iba con información GPS. Generalmente, puede que el usuario sepa que su tuit está geolocalizado y sea consciente de ello, es más, quiere que la gente vea desde dónde lo tuiteó. El problema venía cuando el usuario no es consciente de ello. Esto supone un riesgo. Por supuesto, yo hice mi script para ver si mi cuenta tenía habilitada la geolocalización y mis tuits estaban enviando demasiada información ;-)

Figura 10: Mensajes de una cuenta Twitter de un famoso con ubicación GPS

A continuación, se puede ver el comienzo del ‘viejo’ script. Como se puede ver, necesita los mismos parámetros que TwLocation.

Figura 11: Token OAuth para consultar la API de Twitter

Cuando se obtienen los tuits de la cuenta @pablogonzalezpe, en este ejemplo, se verificaba el campo geo y geo_enabled. En el caso de que estos campos fueran positivos, tendrían la localización desde dónde yo tuiteé. Al final, la suma de los tuits puede provocar un timeline de posicionamiento por dónde cualquiera sepa por dónde vas. Hay que tener cuidado con ello y comprobar si nuestros tuits están enviando nuestra ubicación.

Figura 12: Captura de tuits con ubicación GPS activada

Para finalizar, os muestro una ejecución desde una cuenta que tenía antigua y que tenía tuits geolocalizados para la prueba de concepto. Como se puede ver, es un ejemplo muy similar a lo que hemos visto con TwLocation.

Figura 13: Nuestra PoC con info similar a TwLocation

Sin duda, eran sin saberlo, los comienzos del departamento de ideas locas de CDO. Cosas que hacíamos en ElevenPaths a finales del año 2014, aunque por aquel entonces mi responsabilidad era Faast, siempre teníamos tiempo para esas pequeñas ideas locas. En el año 2016 impartí un taller sobre el uso de la API de Twitter con Python con mi amigo Alberto Sánchez, en la HoneyCON, dónde ampliamos casos con la Streaming API de Twitter. Realmente interesante. Al final un pequeño script y una pequeña idea puede dar para varias cosas, cuando poco a poco se va desarrollando y aprendiendo.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

miércoles, marzo 21, 2018

Metasploit: Cómo extender las funcionalidades de meterpreter

En el artículo de hoy, vengo a hablar del popular meterpreter de Metasploit, y mostrar cómo podemos agregarle funcionalidad. Para ello, como me encanta Python, nos vamos a centrar en el uso de este lenguaje. Me he decidido a escribir este post debido al Trabajo Fin de Máster que estoy realizando junto a mi compañero Antonio Marcos, y que se centra en la creación de una herramienta de explotación de vulnerabilidades locales, donde parte de la funcionalidad correrá en meterpreter.

Figura 1: Metasploit: Cómo extender las funcionalidades de meterpreter

Antes de entrar en materia, vamos a ver cómo se llega a ejecutar meterpreter. Imaginemos que la víctima recibe, por ejemplo, un ataque de phishing, pica el anzuelo, se ejecuta nuestro código y de repente se conecta a la máquina del atacante. Se puede ver el flujo a alto nivel en la siguiente imagen.

Figura 2: Flujo de ejecución de una sesión meterpeter vía Phishing

Cuando el objetivo ejecuta el archivo, se conectará a nuestra máquina, que está a la escucha, se le mandará la longitud del código que le vamos a hacer llegar, y acto seguido se le envía el código, que se ejecutará en la víctima y ya estará meterpreter corriendo. Para ejecutar el código que se envía a través del socket, se utiliza la función exec.

Veamos el código que se ejecutará en el objetivo para hacer las pruebas, lo generaremos con msfvenom, y escogemos el payload python/meterpreter/reverse_tcp:

Figura 3: Payload generado con msfvenom

En la imagen de arriba sacamos el código, pero podemos guardarlo directamente en un archivo añadiendo después de raw > file.py. LHOST es la dirección IP de la máquina a la que se conectará el equipo víctima y LPORT el puerto.

Vemos que tenemos código en Base64. Si obtenemos el lenguaje legible veremos cómo lo primero que hace es esperar la conexión. Cuando esa conexión se establece, se recibe la longitud de los datos que van a llegar, y acto seguido en un bucle recibe el meterpreter, para ser ejecutado con exec, vemos que se le pasa el socket como argumento (que podremos utilizar en nuestro código Python con la variable s).

Figura 4: Código en Python

En este punto, ya podremos cargar nuestro código, haciendo uso del comando load, y aquí es donde se va a centrar el post, ¿cómo hacemos ese código? Tendremos que crear algunos archivos, que veremos después:
• Un “Despachador” de entradas del usuario: escrito en Ruby 
• La extensión: escrita en Ruby 
• Type-Length-Value (TLV): archivo Ruby 
• El código que se va a ejecutar en la máquina objetivo: en este caso Python
Estos archivos se tendrán que incluir en las siguientes rutas, teniendo en cuenta que partimos de la carpeta de Metasploit:
• El “despachador” lo agregaremos en la siguiente carpeta: 
metasploit-framework/lib/rex/post/meterpreter/ui/console/command_dispatcher 
• TLV y extensión dentro de una carpeta con el nombre de la extensión, en este caso boomernix, y que se tiene que crear en la siguiente ruta: 
metasploit-framework/lib/rex/post/meterpreter/extensions 
• El código para el meterpreter va dentro de la ruta:
metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-payloads-1.3.23/data/meterpreter
A continuación tenemos un pequeño esquema del flujo que sigue la ejecución de código desde meterpreter:

Figura 5: Esquema de flujo

En el esquema no se muestra la respuesta, que serán dos valores. El primero de ellos para indicar si se ha realizado correctamente y el segundo la respuesta.

El despachador

Y ahora vamos a ver algo de código, no es el objetivo explicarlo en detalle, ya que es fácil. Empezaremos por el primer punto, el que recibe nuestra entrada para el meterpreter (command_dispatcher).

Figura 6: Command_dispatcher (parte 1)

Aquí se definen los comandos que va a permitir nuestra extensión, hay que tener en cuenta que los comandos que proporcionemos no existan en el meterpreter u otra extensión, porque si no habrá conflictos (por ejemplo, el comando run).

Figura 7: Command_dispatcher (parte 2)

También desde aquí se llama a la extensión, a través de la variable client que nos proporciona Metasploit, y se hace tratamiento de la respuesta que obtenemos, como es un ejemplo, simplemente se pinta por pantalla, sin ningún tratamiento.

La extensión y el TLV (Type-Length-Value)

Vamos a ver la parte de extensión y el archivo de tipo de datos para el intercambio de información con meterpreter.

Figura 8: TLV

La estructura TLV es muy sencilla y permite a meterpreter implementar un protocolo robusto para la comunicación.

Figura 9: La extensión

En la línea 29 se ve cómo se crea un paquete, el parámetro, es el nombre de la función que está en Python. Acto seguido en la línea 30 se agrega un parámetro, y en la siguiente línea se hace la petición. Si miramos en la línea 32, se ve como se extrae el resultado, hay que tener en cuenta los TLV que utilizamos. Todas estas funciones nos las aporta Metasploit.

El código en Python

Hasta aquí hemos visto todo este código que nos vale para cualquier meterpreter, y para cualquier lenguaje como PHP, Python, etcétera. Y ahora por último viene el código de Python, que se encargará de extender meterpreter cuando usemos load.

Figura 10: Código en Python para extender meterpreter

Se puede apreciar que se pueden importar librerías, tener en cuenta que hay librerías que solo existen para un cierto sistema operativo, como puede ser ctypes para Windows, así que toca hacer uso de try. En la línea 24 se obtiene el parámetro que se pasa desde el cliente, se ejecuta el comando en la 25 y se empaqueta en la 26. Se puede ver que se tratan las excepciones, para no alertar de estos errores en la máquina víctima, y tener el máximo control de lo que sucede. Meterpreter puede ejecutarse en cualquier sistema, por ello hay que tener en cuenta dónde corre, para no generar errores visibles por la “víctima”, etcétera.

¡Llega el momento de probar el código, y ver cómo funciona!

1. Ejecutamos Metasploit, cargamos exploit/multi/handler, configuramos el payload y a correr.

Figura 11: Abrimos Metasploit y configuramos el payload

2. Ahora en nuestra víctima se ejecuta el código que se conecta a nuestra máquina.

3. Una vez tenemos meterpreter, hacemos uso de load, y nos informa que se cargó correctamente.

Figura 12: Carga de la extensión con la función load

4. Si usamos el comando help, veremos nuestra funcionalidad.

Figura 13: Ayuda de la funcionalidad

5. Podemos usar la ayuda de la nueva funcionalidad

Figura 14: Pidiendo ayuda de la nueva funcionalidad

6. La usamos, y vemos cómo funciona.
a. Linux
Figura 15: Uso de la nueva funcionalidad en Linux

b. Windows
Figura 16: Uso de la nueva funcionalidad en Windows

Conclusiones

Ahora os toca a vosotros crear vuestra propia funcionalidad. La parte Ruby es igual, aunque es recomendable dividir las funcionalidades en varios archivos, para que su mantenimiento sea más sencillo. En este caso era una simple función. La parte de Python la puedes sustituir, crear una DLL, código PHP, o lo que se te ocurra, cada una funcionara con el tipo de meterpreter correspondiente.

Figura 17: Lanzamiento de exploit desde BoomER

Por último, quiero mostrar cómo se lanza un exploit desde la versión de BoomER que se ha adaptado a meterpreter, el Trabajo Fin de Máster que comente al inicio de este artículo.

¡Hasta la próxima!

Autor: Josué Encinar (@JosueEncinar). Analista de seguridad, autor del blog BoomerNiX.

PD: Quiero dar las gracias a mi tutor y amigo Pablo González, por proponer este tipo de trabajos tan interesantes, desde aquí mandarle un saludo. Y dar las gracias también a Chema Alonso por permitirme aportar este post en su blog.

Entrada destacada

+300 referencias a papers, posts y talks de Hacking & Security con Inteligencia Artificial

Hace un mes comencé a recuperar en un post mi interés en los últimos años, donde he publicado muchos artículos en este blog , y he dejado mu...

Entradas populares