miércoles, 30 de marzo de 2016

Curso: Python para pentesters

Compartir este artículo:
El próximo 4 de Abril da comienzo el curso online de Python para Pentesters, de la empresa Security Sentinel, cuyo profesor es Daniel Echeverría, @jdaanial. El curso tiene una duración de 10 semanas y es completamente online y grabado, por lo que puedes visualizarlo las veces que quieras. Daniel es autor de varios libros de la editorial 0xWord, entre ellos Python para Pentesters y Hacking con Python. 

El precio del curso es de 270 € y tiene como obsequio el libro de Python para Pentesters del propio Daniel Echeverría. Para reservar tu plaza o pedir más información puedes escribir a info@thesecuritysentinel.es. A continuación, os dejamos el contenido del curso, no lo dudes y aprovecha esta formación sobre Python y desarrolla tus propias herramientas en el ámbito de la seguridad.

Semana 1. Módulo 1
1. Introducción a la programación con Python.
                - Introducción a Python.
                - Conceptos básicos de programación estructurada.
                - Conceptos básicos de programación orientada a objetos.
Semana 2. Módulo 2
2. Elementos básicos para el desarrollo de herramientas con Python.
                - Módulos y librerías en Python.
                - Manejo de excepciones.
                - Manejo de ficheros.
                - Librerías estándar en Python.
                - Instalación y uso de librerías de terceros.
Semana 3. Módulo 3
3. Recolección de información.
                - Procesos de recolección de información básicos con Python.
                - Utilizando Python para el acceso programático a los servicios de Google.
                - Utilizando Python para el acceso programático a los servicios de Twitter.
                - Utilizando Python para el acceso programático a Shodan.
Semana 4. Módulo 3
                - Consultas a servicios DNS y WHOIS.
                - Geolocalización con Python y GoogleMaps.
                - Geolocalización con PyGEOIP.
                - Análisis de metadatos en imágenes.
                - Análisis de metadatos en documentos PDF.
Semana 5. Módulo 4
4. Escaneo, enumeración y actividades de pentesting.
                - Tipos de escaneos en redes.
                - Análisis de paquetes y escaneos con Scapy.
                - Uso avanzado de Scapy para manipulación y reinyección de paquetes.
Semana 6. Módulo 4
4. Escaneo, enumeración y actividades de pentesting.
                - Uso de Scapy para realizar ataques de ARP Spoofing.
                - Uso de Scapy para realizar ataques de DNS Spoofing
                - Enumeración con Python-nmap.
Semana 7. Módulo 4
4. Escaneo, enumeración y actividades de pentesting.
                - Librerías comunes en Python para la creación de clientes HTTP.
                - Parseo y extracción de contenidos de aplicaciones web con BeautifulSoup.
                - Scraping de aplicaciones web con Scrapy.
                - Detección de vulnerabilidades en aplicaciones web con Python.
Semana 8. Módulo 4
                - Pentesting sobre servicios FTP utilizando FTPLib
                - Pentesting sobre servicios SSH/SFTP utilizando Paramiko
                - Creación de túneles cifrados y redirección de puertos con Paramiko.
                - Pentesting de servicios SMTP.
                - Pentesting de servicios SMB con PySMB.
Semana 9. Módulo 5
5. Integración de Python con herramientas de pentesting habituales.
                - Integración de Python con Nessus.
                - Integración de Python con Metasploit Framework.
                - Integración de Python con NeXpose
Semana 10. Módulo 6
6. Pautas y buenas practicas a la hora de desarrollar herramientas.
                - Buenas practicas y “tips” para el desarrollo de herramientas
                - Patrones de diseño y arquitectura de software.
                - Depuración de programas y detección de fallos

martes, 29 de marzo de 2016

Securmatica 2016

Compartir este artículo:


Buenas a todos, en el post de hoy queríamos compartir con vosotros el evento Securmatica 2016, en el que tendré el placer de participar este año para dar una conferencia sobre la Deep Web titulada "Los ciberterrosecretos de la Deep Web".

La conferencia tendrá lugar el día 28 de Abril a las 11:10:

11:10
PonenciaLos ciberterrosecretos de la Deep Web
PonentesMaría Carmen Aguilar Carneros, Responsable de Concienciación, Auditoría y Cumplimiento. Departamento de Seguridad de la Información. Dirección de Seguridad y Compras. Ferrovial.

Juan Antonio Calles. Cyber Security Senior Manager. KPMG España

Tenéis toda la información sobre nuestra ponencia y el evento en el sitio web de Securmatica:


Y en el siguiente PDF:

 
Si vais a Securmatica nos veremos por allí ;)
 
Saludos!

domingo, 27 de marzo de 2016

Informe Flu - 246

Compartir este artículo:

Buenas a todos, hoy se acaban las vacaciones para muchos de vosotros, aunque para otros aún continuarán a lo largo de la semana (¡disfrutadlas!), pero nosotros puntuales a nuestra cita y como cada domingo os dejamos con nuestros enlaces de la semana:
 
Lunes 14 de Febrero


Miércoles 16 de Marzo

Saludos!

    miércoles, 23 de marzo de 2016

    MySQL LAN Injection (Network Packet Manipulation)

    Compartir este artículo:
    Hace unos días leí un artículo en el que Rick Osgood hablaba de un detalle el cual, en muchas ocasiones, pasamos por alto. Rick se encontraba haciendo un pentest cuando se dio cuenta que en SQL Server, por defecto, la autenticación va cifrada, pero no las consultas. Esto, a priori, puede dar mucho juego, ya que cómo ocurría tiempo atrás con redes sociales que cifraban la autenticación y dejaban la sesión por HTTP, aquí nos encontraríamos con un escenario similar. 

    Se me ocurrió llevar esta prueba de concepto al mundo MySQL con el objetivo de comprobar si podemos modificar on the fly una query enviada por un cliente legítimo. El objetivo es sencillo, modificar tráfico de la consulta MySQL y conseguir ganar acceso sobre el sistema. En primer lugar, comprobé que el tráfico, por defecto, va sin cifrar. En el caso de MySQL, tanto el login como las querys van sin cifrado. La contraseña del login va hasheada. 


    Estando en la misma red LAN o colocándonos en medio de la comunicación, por ejemplo entre 2 redes, podríamos obtener el usuario y la contraseña hasheada. La configuración por defecto no es la más segura, eso queda reflejado y claro. Ahora, estando en el medio de la comunicación vamos a ver algunas consultas que la víctima realiza. De primeras se puede ver una consulta del tipo “Select * from cookie;”.


    La víctima puede esperar resultados sobre cookies, fechas de expiración y otros datos que pueda contener dicha tabla. ¿Cómo podemos modificar la consulta y conseguir devolverle otros datos? Este paso podría ser denominado el paso Troll, en el que cambieramos on the fly la consulta “select * from cookie;” por “select * from stolen;”. Para ello creamos un filtro con EtterFilter. Crear filtros con esta herramienta es sencillo e intuitivo y proporciona un gran potencial en la edición de paquetes on the fly.

    La sintaxis del filtro será sencilla y puede ser representada mediante este pseudocódigo:

    Si tcp port es 3306 Y paquete contiene “Selec” Entonces
    Reemplazar “Selec” por “Select * from stolen;#”
    Fin Si

    ¿Por qué ponemos la almohadilla? Vamos a reemplazar sólo la palabra “Selec”, aunque podríamos reemplazar todo, por la consulta “Select * from stolen”, por lo que la almohadilla nos ayuda a comentar todo lo que venga después. El filtro podría realizarse a través de datos en hexadecimal o decodificar y sacar las strings. Para esta prueba de concepto lo haremos a través del DECODED que estos filtros aportan.


    Para compilar el filtro hay que ejecutar el comando etterfilter –o [mysql.ef] [mysql.filter]. Esto generará un fichero con extensión ef, el cual es el filtro compilado. Ahora tenemos la opción de utilizar ettercap para lanzar un ARP Spoofing en la red y cargar nuestro filtro creado para la ocasión. 
    Para realizar el envenenamiento se ejecuta la siguiente instrucción ettercap –T –q –i [interfaz red] –F [mysql.ef] –M ARP. El parámetro –T indica que ejecutaremos Ettercap a través de la línea de comandos. Por último, indicar que el módulo ARP permite indicar un target o toda la red, por lo que si queremos envenenar a un target concreto sería –M ARP /t1// /t2//. En la siguiente imagen se puede ver cómo queda el lanzamiento de Ettercap.


    En este instante la víctima se encuentra con caché ARP envenenada y sus querys pasarán por nosotros. Desde Wireshark podemos visualizar las peticiones y observamos que llega la query original con el típico aspecto. Esta consulta será modificada on the fly por nuestro filtro, por lo que en Wireshark veremos la nueva petición que sale de nuestra tarjeta dirección al servidor MySQL. A continuación se muestra la petición legítima que llega y la modificada que sale de nuestra máquina. Hay que tener en cuenta que la legítima nunca llegará al servidor MySQL.


    También podemos ver la respuesta que obtenemos a través de Wireshark y veremos cómo, lógicamente, no se obtiene el contenido de la tabla cookie y sí el contenido de la tabla stolen. En la siguiente imagen se puede ver una comparativa de una query con resultado legítimo, a la derecha, y una con la inyección/modificación en la query, a la izquierda.


    ¿Qué nos ofrece este mecanismo? La no fortificación de la base de datos nos proporciona la posibilidad de añadir a la consulta una instrucción del tipo “Create User” con el que podamos crearnos un usuario en la base de datos. También queda abierto la creación de un filtro para el tráfico de vuelta por si hay algo que no queremos que se muestre a la víctima e intentar ser lo más transparentes posible.

    lunes, 21 de marzo de 2016

    Auditoría interna con SPARTA. Parte 3

    Compartir este artículo:
    Buenas a todos, en el post de hoy continuaremos con la cadena "Auditoría interna con SPARTA", para hablaros sobre la potencia de su integración con Nikto.

    Normalmente, en procesos de auditoría interna, Nmap y escáneres como Nessus u OpenVas, suelen constituir un 40-50% del trabajo. La capacidad de Nmap para reconocer sistemas y servicios, y la versatilidad de los escáneres, las convierten en el core de un proceso de revisión interna de seguridad lógica. Uno de estos escáneres imprescindibles es Sparta, de la que ya os hemos hablado en anteriores ocasiones. Aunque no llega a ser un escaner de vulnerabilidades del tipo Nessus, cuenta con varias utilidades que la convierten en una navaja suiza muy útil en procesos de descubrimiento e intrusión.

    Sparta, además de integrarse con Nmap para el reconocimiento de activos y servicios, también integra el software Nikto y la herramienta Hydra (entre otros de los que os hablaremos más adelante), para automatizar ciertas pruebas que permiten probar la existencia de vulnerabilidades básicas en la red y credenciales de usuarios fácilmente predecibles.

     

    Por ejemplo, con Sparta y gracias a Nikto y a Hydra sremos capaces de probar usuarios por defecto en numerosos servicios, como servidores FTP con usuario anónimo y credenciales básicas, activos como routers con autenticación básica o servicios de distinta índole como servidores web, de bbdd, de aplicaciones, etc:

    Contraseña de servidor FTP

     
    Contraseña de servidor Tomcat
    Contraseña de root de servidor de bbdd MySQL
    Contraseña de servidor FTP recuperada con Hydra mediante ataque por diccionario
    Puede parecer una trivialidad, pero en entornos empresariales en los que escaneamos redes de 5k. 10k o incluso 100k estaciones de trabajo, es de agradecer contar con utilidades que prueben todo ello de forma automática, rápidamente y generen reportes facilmente exportables.

    Por ejemplo Sparta permite exportar toda la información a una bbdd sqlite, que facilmente podréis abrir con alguna herramienta del tipo SQLite Browser, y llevaros todos los datos a un archivo excel.

    Cómodo, ¿verdad? Próximamente seguiremos hablando de este interesante software.

    Saludos!

    Fuentes de imagenes: frsecure.com, secforce.com y rwbnetsec.com

    domingo, 20 de marzo de 2016

    Informe Flu - 245

    Compartir este artículo:

    Buenas a todos, como cada domingo os dejamos con nuestros enlaces de la semana:
     
    Lunes 14 de Febrero
    Miércoles 16 de Marzo
    Viernes 17 de Marzo

    Saludos!

      jueves, 17 de marzo de 2016

      0Day: XSS en VMWare por Álvaro Trigo

      Compartir este artículo:
      Normalmente cuando uno prepara la revisión de seguridad de un producto comercial espera encontrarse una revisión complicada, donde la mayoría de los controles son correctamente implementados dificultando la labor del auditor. Sin embargo, en una de las últimas asignaciones que tuve el año pasado, tuve la ocasión de revisar un producto comercial de VMware donde pude detectar y reportar una vulnerabilidad no conocida por el fabricante. Desgraciadamente para mí, la vulnerabilidad no fue encontrada ni en un ESXi, ni en un Player o una Workstation, sino en un producto menos conocido destinado a servir de ayuda en la gestión financiera de los departamentos de TI: VMware vRealize Business (http://www.vmware.com/es/products/vrealize-business).

      La vulnerabilidad en cuestión es un Cross-Site Scripting persistente en uno de los módulos de la aplicación destinado a mostrar cuadros de mando e informes pregenerados. Si bien estoy casi seguro que existen vulnerabilidades similares en otras secciones, por limitaciones en la ventana de pruebas, sólo pude verificar la existencia de la vulnerabilidad en este. La explotación de la vulnerabilidad no tiene mayor misterio: cuando detecté tras las primeras pruebas que al modificar el título de alguno de los informes no se realizaba un filtrado adecuado de los caracteres HTML enviados, lo siguiente fue hacer una batería de pruebas para ver si era capaz de inyectar en la respuesta del servidor código Javascript.


      En los primeros intentos, pude percatarme como algunos tags clásicos como el “<script>” se encontraban correctamente filtrados, tanto si se eran enviados en texto claro como si eran encodeados de alguna manera. De este modo, para poder hacer la inyección, me tuve que valer de otras etiquetas acabando por encontrar la manera con aquella destinada a incluir imágenes en aplicaciones HTML, “<img>”. Si el título del informe es modificado de la siguiente manera, el código Javascript acaba siendo ejecutado por el navegador del usuario cada vez que éste acceda al módulo de informes (obteniendo así el carácter de persistencia):

      Cost vs. Budget Trend</h2><img src="dummy" onerror="javascript:alert(23);"

      Lo que hemos hecho es inyectar una imagen inexistente y forzar la ejecución de código en el evento “onerror”, en este caso la ejecución de un inofensivo cuadro de diálogo:


      Investigando en las diferentes listas y páginas destinadas a recopilar vulnerabilidades conocidas, no encontré nada relativo a este producto, por lo que decidí ponerme en contacto con VMware a través de su Security Response Center y confirmar si se trataba o no de un Zero-Day. 

      Para poder hacer un reporte de una vulnerabilidad a VMware, seguí el procedimiento publicado en la siguiente URL: https://www.vmware.com/support/policies/security_response.html. Básicamente el punto de contacto lo gestionan a través de un correo electrónico, security@vmware.com, recomendando hacer uso de cifrado PGP. Para ello, tienen a su vez disponible su clave pública en el siguiente enlace: kb.vmware.com/kb/1055

      La comunicación del hallazgo se dio en malas fechas, y mi interlocutor cambió en varias ocasiones. Sin embargo, la respuesta por parte de VMware siempre fue diligente confirmándome a las dos semanas la vulnerabilidad. A partir de ese momento, el trabajo se centró en la investigación de las ramas o versiones de la aplicación que podían verse afectadas, ofreciéndome a colaborar en su resolución en todo momento. En total, los trabajos de investigación y corrección se llevaron a cabo en 3 meses aproximadamente, recibiendo cada cierto tiempo información de los avances realizados.

      La experiencia con ellos ha sido muy buena y la satisfacción de que se reconozca tu trabajo muy grande. El único aspecto negativo de esta historia ha sido que aún no he recibido los regalos que me prometieron, seguramente porque se encuentren todavía dando vueltas en alguna de las cintas infinitas de algún aeropuerto…



      Artículo cortesía de: Álvaro Trigo

      miércoles, 16 de marzo de 2016

      X1RedMasSegura "ESPECIAL FAMILIAS" el día 16 de Abril

      Compartir este artículo:
      Desde la organización de X1RedMasSegura siempre pretendemos llegar al usuario final de Internet con la intención de proporcionarle el conocimiento y las herramientas para poder disfrutar de la red de forma segura.

      Las Jornadas X1RedMasSegura, que estamos preparando y que como bien sabéis se celebrarán en el mes de mayo, nacen con esa idea.

      A lo largo del año participamos en talleres tanto para adultos como a menores, incluso llevándolos a los distintos congresos de seguridad con la finalidad de llevar la seguridad a las personas no técnicas, especialmente a adultos y niñ@s.

      Pero hasta ahora no habíamos planificado, dentro de las jornadas X1RedMasSegura, una jornada específica en la que toda la familia pueda pasar el día aprendiendo seguridad en Internet sin tecnicismos y a la vez disfrutando las nuevas tecnologías todos juntos.

      Por ello, este año volvemos intentar subir las "revoluciones" de la maquinaria de X1RedMasSegura organizando una "Jornada X1RedMasSegura Especial Familias".

      La Jornada tendrá lugar el próximo día 16 de Abril en el Centro Cultural Eduardo Urculo (Pl. de Donoso, 5, 28029 Madrid) y tendremos el honor que sea inaugurada por D. Pedro Núñez Morgades, quien fué Defensor del Menor en la Comunidad de Madrid y, aún hoy en día, una persona muy sensibilizada con la protección de nuestros menores también en la red.

      Así mismo contaremos con un plantel de excepcionales ponentes que nos hablarán sobre los distintos aspectos de la seguridad en Internet de nuestros menores, nos harán conocedores de los peligros que los acechan en la red, pero también nos aportarán soluciones para evitar esos peligros así como fórmulas para mitigar sus consecuencias en caso de sufrirlos. En breve publicaremos sus Bios para que os hagáis una idea de lo importante que será escuchar sus charlas.

      La jornada se desarrollará de acuerdo a la siguiente agenda: 


      Pero como jornada familiar que es, también hemos planificado tres talleres que se desarrollarán en paralelo, y por los que podrán pasar todos los niños asistentes de forma rotativa.
      Los talleres serán posible gracias a la inestimable colaboración de Raúl Renales, junto con Feli, Pilar, Jacob, David, Paco, Martita, Miguel, Julian, Miriam, Félix, Ricardo, Silvia, Antonio, Karel y Mayte, de la Asociación HoneySec,  nos ofrecerá un taller llamado "Detectives Criptográficos",  Olga Martín, directora de la Academia Educa en Digital montará un interesantísimo taller de robótica y nuestro rapero David "Insonusvita", y su estudio de grabación "Inflama Estudios", nos pondrá la nota musical con un taller específico. Todos con la intención de concienciar sobre los peligros y educar en el buen uso de las TIC a los más pequeños de la familia.

      -        Taller de “Detectives Criptológicos” - ¿Quieres
      que tus hijos aprendan criptografía jugando? Tenemos un divertido taller para
      niños de 6 a 12 años que quieran resolver misterios y les guste la
      investigación. 

      -      Taller de Robótica - Actividad para iniciarse
      en la robótica, aprendiendo a diferenciar las diferentes partes de un robot,
      observar, manipular, comprobar y verificar mientras construyen su primer robot.

      -       
      Taller Musical -A modo de RAP se
      transmitirán mensajes sobre seguridad, privacidad y uso responsable de 
      Internet, encaminado a la concienciación del uso responsable de Internet,
      conociendo los peligros que cualquier menor puede estar expuesto en la red. Se
      llevará a cabo mediante canciones propias, compuestas y cantadas
      por David Avilés (David "Insonusvita")


      Os dejamos el cartel para que nos ayudéis a llegar a más gente y que puedan disfrutar de forma totalmente gratuita de las actividades que hemos planificado. (pulsa sobre el mismo para descargarlo)



      Os recordamos que podéis asistir de forma totalmente gratuita y que para ello tenéis que registraros en el siguiente enlace.



      lunes, 14 de marzo de 2016

      Los SecureString protegen en RAM

      Compartir este artículo:
      La memoria RAM y los tricks que rodean a este elemento volátil son interesantes y un punto de exposición. Muchos usuarios piensan que de ella no se puede obtener datos de interés, pero cómo hemos visto en los artículos “Cómo sacar la contraseña de Gmail de la memoria del proceso de Firefox usando Metasploit” o el de “Volcar credenciales del proceso KeePass con Meterpreter”, se puede obtener datos jugosos o indicios que nos ayuden en un pentest.

      En esta ocasión voy a tratar el tema de los SecureStrings. Según indica Microsoft en su MSDN los SecureString es un objeto similar a los Strings, el cual tiene un texto almacenado como atributo. Dicho atributo es almacenado en memoria, pero se utiliza un mecanismo que protege el valor del atributo. El mecanismo suele ser el cifrado que el propio sistema operativo proporcione. Esta es la principal diferente con un String. Con el String no es posible predecir cuando la instancia será eliminada del equipo, por lo que existe un riesgo de que esa información sea visualizada por otro usuario o proceso. Al final todo se reduce a: la información sensible, tales como contraseñas, deberían ser almacenadas en SecureString, mientras que el resto de información podría ser almacenada, sin más, en Strings.

      Para esta prueba de concepto se ha utilizado un código .NET escrito en C#, el cual permite ejemplificar dos situaciones:
      1. En la primera situación el usuario utiliza SecureStrings para gestionar su clave. La clave no se imprime por pantalla y si buscamos la información en memoria RAM no debemos encontrar nada. 
      2. En la segunda situación el usuario gestiona su clave en un tipo String. Cómo ya hemos visto en anteriores artículos, la información será mostrada.

      El trozo de código anterior muestra 2 funciones, una que permite convertir un String a SecureString y la otra realiza el proceso inverso. Una correcta gestión de los SecureString puede ayudarnos a solventar problemas de leaks a través de información en la RAM.

      Para realizar el volcado de memoria RAM del proceso .NET utilizado, el cual en este caso solo gestiona información con SecureStrings, se utiliza el script de Meterpreter llamado proc_memdump para obtener el volcado remoto.


      Cómo puede verse en la imagen, si buscamos cadenas como “System.Security” se encuentra Password: System.Security.SecureString. En el caso de que se utilizará un String ya tendríamos el leak y el valor de la contraseña.

      Conociendo la contraseña que hemos almacenado en el SecureString realizamos una búsqueda sobre el dumpeo de memoria. El resultado es el que se puede ver en la imagen, nada. No encontramos información sobre la contraseña en el volcado, se está gestionando de forma correcta y segura.


      Ahora vamos a ejecutar el proceso nuevamente pero haciendo que la contraseña se gestione a través de un String. Tal y como se puede ver en la imagen se ejecuta process_memdump y se obtiene el volcado en crudo del proceso.


      Realizando la búsqueda sobre la captura de la palabra “Pass” podemos encontrar la contraseña en texto plano en la memoria RAM. Esta información ha sido mostrada por pantalla, por lo que obtenemos del proceso está ahí en la memoria del proceso.


      Cómo conclusión decir que una correcta gestión del uso de Strings sensibles y unas buenas pautas a la hora de programar nos ayudan a hacer nuestro desarrollo más seguro. No son ataques sencillos o comunes en un pentesting, pero la información que, generalmente, almacena la memoria RAM es sensible, por lo que se debe cuidar de forma similar a mimamos la información que se encuentra en disco.

      domingo, 13 de marzo de 2016

      viernes, 11 de marzo de 2016

      Localizando Cpanel y Phpmyadmin abiertos con Google Hacking

      Compartir este artículo:
      Buenas a todos, en los últimos meses hemos dedicado en Flu Project varios artículos a Google Hacking, y a identificar distintas búsquedas que nos han permitido localizar información curiosa indexada por Google y a la que cualquier usuario tiene acceso simplemente realizando búsquedas en su buscador. La semana pasada nos contactó Juan Martínez, al cual enviamos un abrazo desde aquí, para compartir con nosotros dos interesantes dorks sobre Cpanel y Phpmyadmin que procedemos a contaros:
      • Dork Cpanel (200k resultados): inurl:login inurl:user inurl:pass -intext:pass -intext:user




      • Dork Phpmyadmin (14k resultados): inurl:phpmyadmin "information_schema" filetype:php

       
      Saludos!

      miércoles, 9 de marzo de 2016

      Publicada nuestra conferencia sobre malware en Android de las Jornadas TASSI 2016

      Compartir este artículo:
      Buenas a todos, en el post de hoy queríamos informaros de que ya se encuentra disponible en el canal YouTube de la Universidad Politécnica de Madrid la primera conferencia del XII Ciclo UPM TASSI2016, Temas Avanzados en Seguridad y Sociedad de la Información, de título El malware en dispositivos móviles, que tuve el placer de presentar el pasado 11 de febrero de 2016 en el Campus Sur de la Universidad Politécnica de Madrid. 
       
      ¡Disfrutadla!
       
       

      lunes, 7 de marzo de 2016

      Retromalware: Jugando con Netbus (Parte II de II)

      Compartir este artículo:
      Como se comentó en el artículo anterior debido al tiempo por el norte seguí trasteando con Ruby y NetBus, lo que llamamos retromalware. Mi idea era hacer un módulo auxiliary, mi prueba de concepto, más didáctico que efectivo en una auditoría, aunque módulos en Metasploit que detectan malware o que detectan paneles de gestión existen. Si visualizamos la ruta modules/auxiliary/scanner/misc podemos encontrar los módulos en Ruby que comentaba.

      Apoyándome en un módulo scanner el cual ya nos proporciona la posibilidad de escanear rangos de direcciones IP quise implementar la funcionalidad que tenía en mi script anterior.


      Es importante observar los mixins que se incluyen con Tcp, scanner y report. Un mixin es una llamada a un método que es proporcionado por otra clase y que simplifica las tareas que realizamos. Por ejemplo, en el caso de Tcp se nos proporciona connect() y disconnect(). Con la primera se crea un socket contra el puerto y dirección IP que toque, recordemos que un módulo scanner coge rangos de direcciones IP y mediante un bucle se van recorriendo estas direcciones IP. El mixin disconnect() nos permite cerrar el socket. Más adelante en el post se muestra una zona de código dónde se pueden visualizar tanto el connect() como el disconnect().

      La función initialize que todo módulo debe incluir permite inicializar el módulo cuando éste es cargado en el framework. Podemos ver que existen ciertos atributos que se configuran a modo informativo sobre el nombre del módulo, autor, tipo de licencia, etcétera. Esta información puede ser visualizada en msfconsole a través del comando info.


      Por último, la función initialize tiene una llamada importante que es register_options. Con este método podemos incluir o sobreescribir nuevos atributos o parámetros del módulo. En este caso se indica que el parámetro RPORT por defecto tiene el valor 6000, que como hemos podido ver es un puerto en el que NetBus trabaja. Si decides implementar tus módulos utilizarás esta llamada en algún momento.

      Al final la otra función que debe tener un módulo de Metasploit de tipo auxiliary es la de run_host. En esta función se le pasa el target_host, que simplemente será la dirección IP que toque ser escaneada. En otras palabras, como es un módulo auxiliary y de tipo scanner, de forma trasparente al programador el framework le proporciona un bucle que va ejecutando esta función, siendo en cada iteración un target_host distinto. También otra opción viable es la utilización de un número mayor de THREADS, ya que por defecto es 1. Esto también es trasparente al programador gracias al framework, por lo que podemos lanzar distintos hilos que el programador no tendrá que realizar la gestión ni de esto, ni de la llamada a run_host con distintos valores.


      Como se puede ver en la definición de la función run_host se abre un socket a través del mixin connect. Una vez abierto el socket se espera que patch.exe, el bicho de NetBus nos envíe su versión. Tras esto se imprime la por pantalla que se ha encontrado en una dirección IP una versión de NetBus. En este punto se podría utilizar una expresión regular para asegurarnos que lo encontrado es lo que buscábamos.

      En el momento que se encuentra una dirección IP infectada se muestra un menú al usuario para que interactúe con él. A modo de prueba de concepto se han implementado algunas funcionalidades para manejar el troyano.


      A continuación podemos ver cómo se puede lanzar un message box sobre la máquina infectada. Realmente se ha implementado un mini cliente de NetBus en esta prueba de concepto. Posteriormente se muestra la captura dónde se recibe lo que ha pulsado el usuario víctima.



      Por último, quiero mostraros una función interesante como es el listado de ficheros que se encuentran en el disco de la víctima. Tras analizar con Wireshark como realiza esta operación paso a comentarla. El cliente legítimo manda un “GetFiles” a través del socket abierto en el puerto 6000, el servidor nos contesta con “DiskDone” y nos indica un tamaño en bytes de lo que ocupa toda la información (textual) que recibiremos. Después de esto, el cliente legítimo abre un segundo socket al puerto 12346 y es dónde tras abrir la conexión se recibe toda la información del disco duro.


      Tenéis disponible el código en mi github para poder trastear con ello un rato y poder evolucionarlo. Si quieres aprender más sobre Metasploit y el desarrollo en el framework consulta Metasploit para pentesters.

      domingo, 6 de marzo de 2016

      Informe Flu - 243

      Compartir este artículo:

      Buenas a todos, ya estamos de vuelta en Flu Project tras la resaca de ayer de RootedCON, por lo que como cada domingo os dejamos con nuestros enlaces de la semana :)
      Lunes 29 de Febrero

      Miércoles 2 de Marzo
      • El pasado miércoles compartimos con vosotros el post Sacándole partido al bash_history, que tendrá segunda parte la semana que viene con interesantes búsquedas que nos estáis enviando via email ;)
      Viernes 4 de Marzo

      Saludos!

        viernes, 4 de marzo de 2016

        Retromalware: Jugando con Netbus (Parte I de II)

        Compartir este artículo:
        En el año 98 el mundo de la informática conoció el troyano NetBus. Esta pequeña aplicación fue lanzada como una herramienta de administración remota de máquinas, aunque existían algunas versiones más oscuras que eran utilizadas por atacantes para troyanizar máquinas. Yo dediqué tiempo a jugar con NetBus cuando iba al instituto, allá por el año 2001, pero eso es otra historia.

        En verano me dio por trastear y sacar del baúl de los recuerdos a software que hoy en día tienen poca aplicación, ya que son desbordados por otras herramientas con mucho más poder, pero apareció de nuevo el NetBus. Decidí echarle un ojo, y ver como los creadores de malware de la época hacían para transmitir la información y las órdenes desde un cliente a un servidor. Hay que recordar que el malware de aquella época seguía una arquitectura cliente-servidor clásica. Cuando mandaban el fichero patch.exe (servidor de NetBus) a una víctima ésta disponía de una dirección IP, la cual era una dirección pública. Esto hacía que cualquier usuario pudiera tener conectividad directa con dicha máquina. Después aparecieron los routers y la idea tuvo que cambiarse y ser el “bicho.exe” el que haga la conexión al atacante.

        Echando un ojo con un Wireshark a la interacción entre el cliente y servidor en una red me llamó la atención la facilidad con la que NetBus se identificaba.


        En la imagen se ve como el cliente (versión 1.60) realiza la conexión con el servidor (three-way handshake) y el servidor “escupe” un segmento con datos. Parece que el servidor muestra el baner, como si de otro servicio normal se tratase. Con Wireshark podemos ver que nos dice la versión a la que nos hemos conectado.


        Al ver esto, y viendo que el verano por el norte no ha sido muy productivo a lo que horas de sol se refiere, me puse a trastear con Ruby. Muchos saben que desde el libro de Metasploit para pentesters un servidor anda con ganas de ir haciendo más y más cosas para el framework, aunque no todo lo que me gustaría debido al poco tiempo libre. Para pasar el rato decidí codificar un script en Ruby para dándole una dirección IP detectar un NetBus y su versión.


        En el código, muy sencillo, se puede ver como se abre un socket contra una dirección IP y un Puerto que, en la version 1.60 de NetBus es el 6000, es por el que se gestiona. Tras abrir el socket esperamos a recibir un “\r” que es el delimitador que utiliza NetBus, y lo cual también se puede obtener del mensaje mostrado con Wireshark anteriormente. Se puede ver que cada commando, o información enviada acaba con un “\r”, en hexadecimal 0d.

        Si lo que recibimos por el socket encaja con la expresión regular definida para localizar un baner de NetBus se imprime por pantalla la versión. Como se puede imaginar esto es algo bastante rápido de montar, y el sol seguía sin salir por el norte así que decidí ir un poco más allá.

        El cliente de NetBus tiene diversos botones que permitían al atacante hacer maldades sobre sus víctimas. Pero, como ya hemos visto antes, la comunicación era trivial, el texto plano es la clave. Al probar el botón de Get Info, el cliente obtiene algo de información de la máquina remota, por ejemplo el Usuario con el que se está logueado, la ruta dónde se encuentra el patch.exe o el número de clientes conectados. Si observamos la trama en Wireshark veremos que el comando no puede ser más sencillo “Get Info”, escrito a través del socket, eso sí que no se nos olvidé el 0d al final, o lo que es lo mismo “\r”.


        Tras ver esto quise interactuar con el bicho a través del script, era como meterle mano al juguete que tenía de pequeño. El código al final era algo así:


        Es sencillo, si el socket está abierto se manda por el socket el texto GetInfo con el delimitador 0d al final y esperamos a que patch.exe nos proporcione la infomación. Una vez recibida, la damos un poco de format sustituyendo los ; y | por saltos de línea y se muestra.

        Seguí investigando y jugando un poco con el troyano e implementé también la posibilidad de enviar texto a la víctima, recopilar información sobre el disco duro, por ejemplo listar todos los archivos y carpetas, y la posibilidad de ejecutar un message box en remoto. Justo en este punto el sol empezó a salir por el norte y decidí que las vacaciones eran para coger algo de color…

        Os dejo un screenshot de la ejecución del script, el cual lo podéis descargar desde mi github.


        ¿Segundo día y también llueve? En efecto, llover y mucho llover por el norte, por lo que decidí llevar mi pequeño script al mundo Metasploit.

        miércoles, 2 de marzo de 2016

        Sacándole partido al bash_history

        Compartir este artículo:
        Buenas a todos, en el post de hoy me gustaría analizar algunas búsquedas interesantes de Google, basadas en el archivo bash_history y orientadas a la localización de carpetas de Linux expuestas en la red.

        Uno de los programas que más utilizamos los informáticos para enviarnos archivos entre máquinas es SCP. A través del cual podremos remitir un archivo de un origen a un destino. Tanto ese origen, como el destino deben figurar en la cadena del comando SCP, por lo que si identificamos archivos bash_history expuestos en Internet, es posible que identifiquemos algunas decenas de carpetas origen y/o destino pululando por la red. 

        Algunos ejemplos:

        • 122 resultados cacheados de rutas "/home": 



        • 78 resultados cacheados de rutas "/root": 


        • Mientras que solo se encuentran 9 resultados cacheados de rutas "/var/www", donde podrían encontrarse los archivos en producción de un servidor web Apache: 


        Otro filtro interesante podría ser "*.sql", para identificar exportaciones de BBDD que hayan quedado cacheadas por el mundo mundial. En este caso con 283 resultados:


        Se le puede sacar mucho partido a bash_history en una auditoría, por lo que echadle imaginación :)

        Saludos!