Archive

Archive for the ‘Networking’ Category

Nueva temporada en THW Academy: Más cursos y lanzamiento de THW Labs

mayo 13, 2016 1 comentario

THW Academy lleva cerca de un año en funcionamiento y los resultados han sido muy satisfactorios, he tenido la oportunidad de conocer gente que tiene un interés legitimo por aprender y que además, participan activamente. Este proyecto ha nacido como una plataforma de aprendizaje dedicada a las personas interesadas en el mundo de la seguridad informática y el hacking con un enfoque completamente práctico, con esto en mente, uno de los principales objetivos de la academia es el de impartir una formación que en la medida de lo posible fomente la investigación. Nunca me ha interesado crear cursos atiborrados de muchos conceptos teóricos con escasa aplicación práctica y creo que a día de hoy, estoy consiguiendo ese objetivo. No obstante, mucho antes de comenzar con THW Academy y desde la perspectiva de cualquier aprendiz (que es lo que soy y siempre seré) considero que no es suficiente con simplemente recibir cursos, por muy buenos que estos sean, ya que la mejor forma de aprender de verdad es pegarse con problemas y tratar de resolverlos. Por este motivo, he decidido dar un paso hacia adelante y ofrecer algo más, algo que todos pedís constantemente y que no es tan fácil de conseguir: Llevar a la práctica lo aprendido en entornos reales que supongan un reto autentico. Los conocimientos en hacking son esencialmente prácticos, pero aplicar esos conocimientos es complicado, ya que “no puedes”, o mejor, “no debes”, atacar cualquier sistema por las consecuencias legales que tus acciones te pueden acarrear. La mejor forma que tenemos actualmente de poner a prueba nuestras habilidades es por medio de máquinas virtuales con vulnerabilidades o participar en retos del tipo CTF, son cosas que están muy bien, pero es probable que se te queden cortas y que quieras ir un poco más allá. En este sentido, tienes a tu disposición el reto de Offensive Security con la certificación OSCP, un reto que siempre recomiendo por su alto nivel técnico y además de que tienes que “ensuciarte las manos”, ser muy autodidacta y esforzarte mucho para conseguir el objetivo de comprometer todos los sistemas del entorno. Hace algún tiempo os hablé de mi experiencia en el laboratorio de la OSCP y comentaba que es bastante completo  para poner a prueba tus conocimientos, sin embargo tiene un “pequeño problema” y es que te puede llegar a constar 1.500 dolares o más, dependiendo del tiempo que contrates. Es un entorno que está muy bien, pero seguramente muchos de vosotros os lo pensaréis dos veces ya que su costo es alto.
Partiendo de esta situación, desde el año pasado me propuse crear un laboratorio de pruebas completo que vaya un poco más allá del típico CTF, un entorno en el que se simule una red corporativa y que suponga un verdadero reto para cualquier hacker o pentester y es así como el día de hoy os presento THW Labs.

                                                                                              (Pincha sobre la imagen)
Optimized-THWAcademy-network-1

Se trata de un laboratorio que actualmente cuenta con más de 30 sistemas que incluyen vulnerabilidades de todo tipo y con niveles de dificultad variables, es posible realizar cualquier tipo de prueba y ejecutar ataques contra segmentos de red internos utilizando técnicas de pivoting y port-forwarding, todo ello por medio de una conexión a la VPN de THW Labs. Se trata de un entorno muy similar al de la OSCP, solamente que ahora mismo cuenta con menos sistemas, pero os aseguro que irá creciendo y en poco tiempo estará a la altura del de la OSCP. El objetivo es que se convierta en un entorno tan extenso como el que existe en la OSCP  pero con tres diferencias importantes:

  1. En primer lugar, las vulnerabilidades no son las mismas para cada sistema y cada objetivo tiene sus propias vías de explotación, algo que no tiene la OSCP, ya que fácilmente nos encontramos de 6 a 8 sistemas que se explotan del mismo modo, aplicando las mismas técnicas, los mismos exploits y siguiendo exactamente los mismos procedimientos. En el caso de THW Labs cada sistema es único.
  2. En THW Labs existen 3 niveles de dificultad (básico, intermedio y avanzado), de esta forma cada participante podrá decidir en qué sistemas centrarse y buscar formas de explotarlos dependiendo de sus habilidades y conocimientos.
  3. Como se ha mencionado antes, THW Labs es un entorno dinámico, lo que quiere decir que a lo largo del tiempo irá creciendo en objetivos y vulnerabilidades, algo que no ha ocurrido en mucho tiempo con el laboratorio de la OSCP, ya que te vas a encontrar con los mismos sistemas que se podían ver en la versión de PWB (Pentesting With Backtrack). Esto significa que muchas de las vulnerabilidades que han salido recientemente no se encuentran incluidas en el laboratorio de la OSCP, sin embargo, en el caso de THW Labs, se estima que en un promedio de cada 2 meses, habrán nuevos sistemas con vulnerabilidades o vías de explotación que han sido recientemente descubiertas o que en las que es necesario aplicar técnicas de explotación interesantes.

Dicho todo lo anterior, os recomiendo visitar la página web oficial de THW Labs.

Por otro lado, tal como dicta el título de ésta entrada, los cursos que actualmente se están ofreciendo en THW Academy llegan a su fin  en el mes de diciembre y a partir de Enero del año que viene, comenzamos con la siguiente temporada de cursos, los cuales se listan a continuación:

Nivel básico:

THWB5 – INTRODUCCIÓN A LA ARQUITECTURA DE ORDENADORES

THWB6 – CONFIGURACIÓN Y USO DE METASPLOIT FRAMEWORK

Nivel Intermedio:

THWI4 – HACKING EN REDES Wi-Fi

THWI5 – PENTESTING CON METASPLOIT FRAMEWORK, NMAP Y SET.

THWI6 – POSTEXPLOTACIÓN SOBRE SISTEMAS GNU/LINUX.

Nivel Avanzado:

THWA4 – NETWORKING CON PYTHON: Scapy, Twisted, Tornado y AsyncIO

THWA5 – EXPLOITING EN SISTEMAS WINDOWS Y GNU/LINUX

 

Próximamente tendréis disponibles los contenidos de cada uno de estos cursos, además, os recuerdo que podéis registraros a THW Academy en cualquier momento y acceder a todos los contenidos que se han publicado anteriormente y los que se publican mes a mes.

De momento esto es todo, sin embargo si tenéis cualquier duda, comentario o cualquier otro asunto, puedes escribir un correo a adastra@thehackerway.com y se te responderá tan rápido como sea posible.

Un saludo y Happy Hack!
Adastra.

Censys: Motor de búsqueda sobre dispositivos y servidores en Internet

abril 19, 2016 1 comentario

Shodan es probablemente uno de los motores de búsqueda más utilizados por hackers (y curiosos) que quieren encontrar dispositivos y servidores en Internet que ejecutan servicios con características muy concretas, no en vano se le conoce como “el google de los hackers”. Es una herramienta muy valiosa que también permite acceder a sus funcionalidades de forma programática desde lenguajes de programación tales como Python, Perl o Ruby. En varias ocasiones se han mencionado sus virtudes en este blog y seguramente para muchos de vosotros nada de lo dicho anteriormente es algo nuevo, sin embargo cuando se menciona a “Censys”, actualmente son “pocas” las personas que conocen sus bondades. Del mismo modo que ocurre con Shodan, con Censys es posible realizar búsquedas muy concretas sobre dispositivos, servidores y redes que se encuentran en Internet, siendo un servicio muy similar y directa “competencia” de Shodan. El funcionamiento de Censys se basa en el uso de una herramienta que también es relativamente reciente y de la que ya se ha hablado anteriormente en este sitio, se trata de Zmap un escaner que permite ejecutar un escaneo completo contra el rango de direcciones IPv4 y que con los recursos de computo adecuados, permite el escaneo entero de Internet en un tiempo bastante razonable. Se trata sin lugar a dudas de una herramienta que merece la pena estudiar y comprender. Censys se encarga de ejecutar escaneos con Zmap diariamente y recolecta información sobre los servicios que se encuentran disponibles en las direcciones IP analizadas, que como se ha dicho anteriormente, comprenden el rango de direcciones IPv4 entero. El creador de Censys es el mismo de Zmap (Zakir Durumeric) y desde el primer paper público sobre el uso de Censys, en octubre de 2015, tanto él como John Matherly (Shodan) han defendido a capa y espada sus respectivos sistemas como es natural, exponiendo las virtudes del uno sobre el otro. Después de estudiar ambos, personalmente no me decanto por uno solo, todo lo contrario, prefiero utilizar ambos para obtener más información y poder comparar/complementar resultados. Del mismo modo que ocurre con Shodan, es posible utilizar una API basada en servicios Rest que pueden ser consultados fácilmente si se tiene una “Developer Key”, la cual se puede conseguir simplemente creando una cuenta gratuita en el servicio. Todos los días es posible acceder a un snapshot de los datos recolectados por el servicio, indicando la información disponible sobre direcciones, puertos, sitios web, certificados, etc. Por otro lado, la API está compuesta por los siguientes endpoints.

search Permite ejecutar búsquedas contra los índices más recientes que ha recolectado el sistema.
view Permite recuperar información sobre un host concreto, sitio web o certificado.
report Permite generar un reporte agrupado sobre un campo concreto en el conjunto de resultados.
query Permite la ejecución de una consulta SQL contra la información actual e histórica que se ha ido registrando en el sistema y únicamente está disponible a investigadores verificados.
export Permite la exportación de un conjunto de registros en formato JSON
data Expone metadatos sobre la información en formato “crudo” que es recolectada diariamente por el sistema.

Como se puede apreciar, son muy pocos endpoints y no es una API tan completa como la que implementa Shodan, pero sigue siendo muy interesante por la información que aporta. En este punto es posible interactuar con Censys por medio de dichos endpoints de forma programática, para ello es necesario crear una cuenta en Censys y obtener los campos API ID y Secret, tal como se puede apreciar en la siguiente imagen.

censys1

A la fecha de redactar este documento no hay ningún tipo de cliente oficial para Censys, pero dado que se trata de un servicio que se expone por medio de una API Rest, es posible utilizar cualquiera de las librerías disponibles en lenguajes de programación como Python, Ruby, C o Java, para consumir dichos servicios Rest sin mayores dificultades. En este caso concreto y tal como se ha visto en varias ocasiones en este blog, se utilizará Python para crear un cliente básico que consuma algunos de los servicios disponibles en Censys.

			
import sys 		
import json 
import requests 
API_URL = "https://www.censys.io/api/v1" 
UID = "xxxxx" 
SECRET = "zzzzz" 
res = requests.get(API_URL + "/data", auth=(UID,
			SECRET)) 
if res.status_code != 200: 
    print "error occurred: %s" % res.json()["error"]
    sys.exit(1) 
for name, series in res.json()["raw_series"].iteritems():
    print series["name"], "was last updated at",
			series["latest_result"]["timestamp"] 
params = json={"query": "Apache", 
			 "page":1} 
res = requests.post(API_URL + "/search/certificates",
			auth=(UID, SECRET), json=json) 
print res.json()["results"][0].keys() 
print res.json()["results"][0].values()

Hay que tener en cuenta que de acuerdo a la documentación la API Rest de Censys, es necesario invocar a cada uno de los endpoints con un método HTTP concreto, una serie de parámetros obligatorios y que además, muchas de las peticiones reciben datos en formato JSON, con lo cual es necesario realizar las peticiones HTTP siguiendo estás especificaciones. El script anterior es simplemente un ejemplo sobre el uso de los endpoints “/data” y “/search/certificates”. Tal como se puede apreciar, es bastante sencillo crear un cliente y obtener información de Censys utilizando su API Rest.

De todos modos, desde mi punto de vista hay dos características que hacen que Shodan sea una buena opción con respecto a Censys, considerando nuevamente que a mi juicio es recomendable utilizar ambas.

1. La API de Shodan parece estar mejor documentada y ser más completa, además de que hay clientes en diferentes lenguajes, lo que facilita su integración en cualquier herramienta, esto a la fecha de redactar este documento, no se consigue con Censys.

2- Shodan cuenta con varios filtros que permiten afinar las búsquedas y a la fecha de redactar este articulo, son mucho más completos que los que se encuentran disponibles en la interfaz de búsqueda de Censys.

En contrapartida, Censys permite el acceso a la información histórica que se ha ido recolectado y no pone limitaciones sobre los tipos de servicios que se pueden consultar, algo que si hace Shodan.

Se trata simplemente de un servicio que podéis utilizar de forma complementaria a Shodan para la recolección de información, se perfila como una excelente herramienta para ejecutar procesos OSINT y análisis de datos.

Un saludo y Happy Hack!
Adastra.

Entrevista a David Marugán (@RadioHacking)

abril 13, 2016 Deja un comentario

David Marugán (@RadioHacking) es una persona que resalta por sus amplios conocimientos en radiofrecuencias y trayectoria en dicho campo. Ha sido ponente en eventos de seguridad informática, es uno de los colaboradores del programa de televisión “Mundo Hacker” y ha colaborado en la redacción de los libros “HACKING PRÁCTICO DE REDES WIFI Y RADIOFRECUENCIA” y “HACKING CON INGENIERÍA SOCIAL. TÉCNICAS PARA HACKEAR HUMANOS” ambos publicados por la editorial RA-MA.
Aquellos que le conocéis seguramente habréis podido notar que se trata de una persona sencilla y amable, uno de los mayores expertos en su área que conozco, con una personalidad carismática que explica y comparte sus conocimientos a todo el que quiera aprender. En esta entrada he querido hacer una pequeña entrevista a David para que nos cuente un poco sus motivaciones y su perspectiva sobre el apasionante mundo de las radiofrecuencias.

Adastra:
Tengo entendido que llevas muchos años como radioaficionado, ¿cómo ha surgido tu interés por el mundo de las radiofrecuencias?

David:
Cuando era niño, con unos nueve años, me di cuenta por casualidad que haciendo una pequeña modificación en un radiocasette Sanyo escuchaba “algo” extraño al comienzo del díal de la radio, algo que no tenía nada que ver con la FM comercial, después de un tiempo escuchando me percaté de que era la policía de Madrid. Aquello me fascinó y comencé a observar cómo eran las emisoras y antenas de la policía, taxis, ambulancias, camiones, etc. hasta que averigué que existían unas emisoras de radioaficionado que permitían incluso hablar con otros paises.”Engañé” a mi padre para que me comprara un equipo de segunda mano muy básico con una antena de coche instalada en la barandilla de la terraza. Al poco tiempo hacía contactos internacionales a veces repitiendo frases en inglés que escuchaba a otros “de oído” sin saber muy bien que querían decir. Han pasado 30 años de aquello y me fascina igual que antes, apenas sé nada todavía.

Adastra:
¿Cómo consigues mantener la motivación y el interés por lo que haces? ¿consideras que hay algún “truco” especial, tienes algún consejo para las personas interesadas en convertise en radioaficionados?

David:
Mi consejo es que comiencen desde lo más básico. Conozco personas capaces de decodificar radio digital TETRA y no sabrían sintonizar una simple emisora de Onda Corta con un receptor analógico. Aunque obviamente hay ciertas emisiones digitales muy interesantes (y cada vez más), es importante comenzar comprendiendo lo más básico, saber cómo funcionan las cosas para poder sacar a la radio todo el provecho posible y no estar luego perdido y quizás perder la motivación. Animo a las personas interesadas a que pregunten a radioaficionados con cierta experiencia que estarán encantados de ayudarles con los primeros pasos y por supuesto a buscar información en Internet, algo que muchos no tuvimos y que supone una gran ventaja en esta época. Luego el límite lo pones tú.

Adastra:
En tu experiencia, ¿qué dispositivos y herramientas recomendarías a una persona que quiere adentrarse en el complejo mundo del radiohacking?

David:
Siempre recomendaría comenzar con algún equipo analógico, por ejemplo un receptor no muy avanzado, buscar en internet frecuencias que puedan interesarnos y sobre todo “escuchar” mucho para ir aprendiendo. Una buena forma es usar un receptor como el SDR on-line de la Universidad de Twente que cubre toda la Onda Corta sin gastarnos nada de momento y así ver qué nos interesa en realidad. Por supuesto es imprescindible un SDR low-cost para poder monitorizar frecuencias más altas y comenzar a ver señales en nuestro ordenador de forma muy asequible. Después, si la experiencia nos ha gustado, cosa muy probable, vendrán otro tipo de dispositivos SDR más avanzados, software de análisis de señales, analizadores de espectro, antenas específicas, etc. Hay magníficos tutoriales, libros y foros para comenzar en esto de forma muy sencilla.

Adastra:
Actualmente cuando se habla de “delitos informáticos”, casi siempre se hace alusión a ciberdelincuentes que actúan en Internet. ¿Crees que las radiofrecuencias en los tiempos que corren pueden ser aprovechadas por los delincuentes para realizar actividades ilegales? ¿De qué forma lo harían?

David:
En ocasiones digo que solemos mirar siempre hacia Internet y que quizás se está dejando de lado un terreno enorme y complejo como la radio, que además está presente en todo tipo de comunicaciones críticas de nuestra vida diaria. Por poner un ejemplo que se comprenda, imaginemos una empresa de seguridad que custodia una infraestructura crítica. Es posible que cuide su seguridad informática y siga todas las recomendaciones al respecto, haga auditorias y use medidas de seguridad típicas en sus redes, y que por otro lado los agentes que vigilan estas instalaciones estén usando una red de radio digital sin cifrado, dando información muy importante de sus procedimientos de trabajo y movimientos en el terreno. Esto es más común de lo que parece e incluso ocurre en ciertos cuerpos policiales que además transmiten información muy sensible sobre personas, vehículos, etc. ¿Por qué este desequilibrio cuando hablamos de seguridad? En los tiempos que corren, con las amenazas a las que nos enfrentamos cada día, esto debería corregirse por las autoridades competentes sin más dilación.
Otro caso sería la posible utilización de comunicaciones radio en el ámbito de la delincuencia o el terrorismo. Por ejemplo el DAESH utiliza equipos de alta gama de la marca Hytera y transmiten en DMR cifrado para evitar las técnicas COMINT por parte de sus enemigos, ellos sí se cuidan mucho de la seguridad en sus comunicaciones. Todavía hoy servicios de inteligencia de todo el mundo usan las denominadas Estaciones de Números para mandar comunicados cifrados con el método OTP a sus agentes a miles de kilómetros. Existen métodos de comunicación radio de muy difícil control, que no pasan por ninguna pasarela de terceros, como sí ocurre en Internet o GSM y que con medios asequibles podrían mantener comunicaciones a larga distancia de forma cifrada ¿Si el sistema de las estaciones de números se aplicara para comunicaciones entre células terroristas? ¿cuánto tiempo tardaríamos en detectarlas? ¿seríamos realmente capaces de hacerlo? En el próximo Mundo Hacker Day hablaré, entre otras cosas, sobre la relación de las comunicaciones radio y el mundo del crimen organizado. Aprovecho para llamar la atención sobre el hecho de que no solo hemos de mirar a Internet o a las comunicaciones móviles cuando buscamos canales de comunicación ocultos. A lo mejor debemos mirar un poco más hacia “arriba”.

Adastra:
Me has contado que sueles hacer “excursiones” sobre el espectro radioeléctrico y que en ocasiones te has encontrado con cosas extrañas las cuales suelen ser comentadas entre radioaficionados. En tu experiencia, ¿cuáles han sido las cosas más extrañas/curiosas que te has encontrado?

David:
El espectro radioeléctrico es enorme: emisiones militares, radares OTH, señales no identificadas o de tipo “propietario”, emisiones clandestinas, estaciones de números, jammers que sabotean otras emisiones por motivos de censura, etc, etc. Suelo decir como analogía que el espectro radioeléctrico es un ecosistema con una fauna y flora realmente diversa, y a veces muy extraña. Lo más curioso que me he encontrado es el caso que ahora estoy siguiendo sobre el uso ilegal de un satélite militar norteamericano para mandar fotos “familiares” a medio mundo.
La que quizás más me ha impactado a nivel personal, hace ya más de veinte años, tiene que ver con un conflicto armado brutal y todavía hoy me emociona recordar el contenido de las emisiones. No puedo dar muchos más detalles por respeto a las personas implicadas, pero es muy posible que después de éstas emisiones fallecieran, y además sé que lo hicieron para proteger a otras personas indefensas; incluso pude escuchar de forma lejana el tableteo las ametralladoras y después de los comunicados un largo silencio. Fue realmente estremecedor.

Adastra:
En uno de tus articulos para SecurityArtWork titulado “Creepy images“, has mencionado que las imágenes transmitidas por radio pueden contener mensajes ocultos utilizando técnicas de esteganografía. ¿Has encontrado algo al respecto en esas imágenes?

David:
Yo no he sido capaz de encontrar nada, pero el concepto de estego en radio es muy diferente al informático debido a la forma de transmitir información y aunque podría ocurrir, no creo que estemos en ese caso. En este tema lo que más curiosidad me despierta es saber el motivo que lleva a alguien a mandar estas imágenes ilegalmente por un satélite militar, los detalles técnicos del procedimiento usado para transmitir en realidad están muy claros, localizar la emisión es bastante más complicado, aquí no existen IPs o “huellas digitales” de ningún tipo.

Adastra:
Para ser un radioaficionado, tengo entendido que es necesario obtener una autorización, la cual se consigue presentando un examen y una vez aprobado, te entregan tu carnet. ¿Cómo es dicho examen? ¿es completamente teórico o incluye también una parte practica? ¿Hay puntuaciones?

David:
Hace años eran más complicados, teniendo incluso en algunos casos pruebas prácticas de código Morse y diferentes tipos de licencia según la banda de frecuencias a usar. Hoy se han simplificado en una autorización única que nos abre todo un mundo para experimentar en radio. Se trata de un examen teórico que se compone de dos pruebas: la primera, conocimientos de electricidad y radio, la segunda trata sobre conocimientos normativos. El número de preguntas de cada prueba es de 30, se realizan en el mismo día y para superar cada una de ellas basta con tener 15 correctas. La duración máxima del examen es de 90 minutos. Se trata de una prueba sencilla si se estudia y realizan los test de práctica. Yo recomiendo informarse en la web de la U.R.E, la Unión de Radioaficionados Españoles, donde se puede encontrar todo el material necesario e información sobre los trámites para solicitar el examen y después la autorización.

Adastra:
¿Es obligatorio tener un carnet de radioaficionado para realizar pruebas en tu casa, por ejemplo?

David:
Es obligatorio tener autorización y un indicativo legal único para poder transmitir en bandas que requieren de esta autorización. Para recibir no es necesario tener una licencia, tampoco es necesario para bandas libres o no licenciadas, cumpliendo ciertos requisitos a la hora de transmitir. Pero yo recomiendo, por las posibilidades que nos brinda, realizar el esfuerzo y sacar la autorización a través del examen, merece mucho la pena. No tener esta autorización nos reduce muchísimo nuestro campo de investigación.

Adastra:
Desde el desconocimiento y vaya por delante mi ignorancia sobre estás cuestiones, ¿existe alguna forma de “mezclar” el mundo de redes como Internet con la información que puede existir en el espectro radioeléctrico? ¿es posible implementar una especie de “puente” que permita el intercambio de información?

David:
Claro que sí, de hecho hoy los radioaficionados usamos terminales analógicos y software específico para usar sistemas de voz sobre IP como el denominado Echolink, que permite que a través de un pequeño terminal portátil o walkie de muy bajo coste podamos conversar con personas incluso en el otro lado del mundo, o por ejemplo el sistema digital de radio denominado DMR, un sistema de mayor complejidad y prestaciones superiores, que haciendo una analogía muy facilona, tiene ciertas similitudes con el GSM pero sin pasar por un operador y sin usar cifrado (no porque no se pueda, sino porque está prohibido usar cifrado por parte de radioaficionados, ya que se supone que uno de sus fines es el de la experimentación y divulgación). Fíjate Daniel, tú que eres todo un referente cuando se habla de la Deepweb, que hasta existe un Internet exclusivo para radioaficionados con autorización a nivel mundial. El bloque de direcciones IP 44.0.0.0/8 está reservado desde los 80 para radioaficionados. Invito a los lectores a que busquen información sobre AMPRNET (Amateur Packet Radio Network) y sus posibilidades actuales, seguro que les sorprenderá si no la conocen. Hoy radio e Internet están totalmente relacionados.

Adastra:
En tu opinión ¿Qué relación existe entre el mundo del hacking y la radio?

David:
El hacking y la radio han estado siempre unidos de forma muy estrecha, de hecho se dice que la primeras comunidades de base tecnológica para compartir conocimientos y mejorar los sistemas fue la de los radioaficionados. Recordemos que ya Marconi en 1901 fue víctima de un troleo o ataque en una demo de Morse para demostrarle que su sistema no era tan seguro como presumía. Quizás ahí comenzó la historia del hacking. Después, muchas personas relacionadas con el hacking han sido radioaficionados, por poner un ejemplo citaremos a Clifford Stoll, el autor del famoso libro “El huevo del cuco”, que es radioaficionado y usa el indicativo K7TA. A día de hoy famosos hackers que todos conocemos investigan sobre seguridad en radio, SDR, etc. y cada vez se ve más en las conferencias de seguridad, parece que ahora la radio se ha vuelto a poner de moda gracias a los SDR low-cost… ¡Yo encantado!
Otra importante función de la radio y los radioaficionados es la evasión de sistemas de censura, como por ejemplo en el contexto de la denominada Primavera Árabe, donde muchos radioaficionados se pusieron al servicio de la libertad de expresión y ayudaron a sacar las noticias de ciertos países donde Internet había sido “cortado” en su totalidad por parte del gobierno y sus operadores de telecomunicaciones. Algunos medios de prensa occidentales fueron informados a través de estos radioaficionados de lo que ocurría en las revueltas. Aunque no soy nada conspiranoico, por desgracia muchos gobiernos están cerrando sus emisoras de Onda Corta, y se tiende a que toda comunicación considerada “moderna” pase por un “canuto” muy controlado: Internet, GSM, redes sociales, etc. ¿Existen gobiernos a los que la radio les resulta incómoda? Desde luego que sí, e invierten mucho en sabotear algunas emisiones. Para mi la radio siempre ha sido sinónimo de libertad, experimentación y conocimiento compartido.

Ha sido un placer poder entrevistar a David y conocer un poco más en profundidad el interesante mundo del radio y sus aplicaciones practicas. Os invito a seguirle en su cuenta de twitter @RadioHacking y comprar sus libros, los cuales se encuentran disponibles en la web de RA-MA.
Finalmente, desde aquí expreso mi respeto y agradecimiento a David no solamente por los conocimientos que dispone, sino también por su actitud a la hora de compartir lo que sabe y estar dispuesto a colaborar con las personas que tienen menos conocimientos y experiencia que él.
Espero que os haya gustado la entrevista y que os “pique” un poco la curiosidad por aprender sobre estos temas.

Un saludo y happy hack!
Adastra.

Honeypots: Agrupación y gestión de honeypots con HoneyDrive – Parte 4

marzo 1, 2016 1 comentario

Hace algunos meses comencé a hablar sobre algunos de los honeypots más interesantes que se encuentran actualmente a nuestra disposición, entre los cuales no pueden faltar Kippo y Dionaea, sin embargo hay muchos más que simulan el comportamiento de muchos de los servicios más habituales. Una buena forma de explorar algunos de los más conocidos es por medio de HoneyDrive, una distribución basada en Linux, concretamente con Xubuntu Desktop 12.04 LTS. Cuenta con más de 10 honeypots preconfigurados y listos para ser utilizados en la plataforma, entre los cuales destacan Dionaea, Kippo, Amun, Honeyd, Honeyd2MySQL, Glastopf, Conpot, entre muchos otros que se irán explicando detalladamente en esta y próximas entradas. Evidentemente, es muy ventajoso tener todo correctamente preparado y configurado para que únicamente sea cuestión de arrancar los servicios necesarios y a correr, pero siempre es aconsejado contar con un buen nivel de conocimientos sobre las tecnologías utilizadas ya que en ocasiones resulta conveniente instalar las herramientas “a mano” para entender cuáles son las posibles configuraciones que se pueden aplicar. El proyecto se encuentra ubicado en la siguiente ruta https://bruteforce.gr/honeydrive y se puede descargar la última versión disponible desde el repositorio SVN, el cual se encuentra ubicado en la siguiente ruta: http://sourceforge.net/projects/honeydrive/

Allí se encuentra disponible el servicio virtualizado (.OVA) el cual puede ser desplegado directamente en VirtualBox. Una vez descargada, instalada la imagen OVA e iniciado el sistema, en el escritorio se encuentra un fichero llamado “README” el cual incluye todos los detalles necesarios para poder utilizar todos los honeypots y herramientas que se encuentran instaladas en el sistema. Por ejemplo, es posible utilizar el honeypot Kippo tal como se ha visto en el primer artículo que se encuentra aquí: https://thehackerway.com/2015/03/24/honeypots-parte-1-kippo/

hd1

Imagen 1: Iniciando Kippo en HoneyDrive.

En este caso, Kippo se vinculará al puerto “22” y aceptará peticiones por parte de clientes/atacantes que intenten acceder al sistema. Tal como se ha visto en el artículo sobre Kippo, su configuración es muy simple y únicamente es necesario establecer las opciones adecuadas en el fichero “kippo.cfg”. En el caso de HoneyDrive, dicho fichero de configuración se encuentra ubicado en “/honeydrive/kippo” y su contenido por defecto es el siguiente:

[honeypot]

ssh_port = 22

hostname = svr03

log_path = log

download_path = dl

contents_path = honeyfs

filesystem_file = fs.pickle

data_path = data

txtcmds_path = txtcmds

public_key = public.key

private_key = private.key

ssh_version_string = SSH-2.0-OpenSSH_5.1p1 Debian-5

interact_enabled = false

interact_port = 5123

[database_mysql]

host = localhost

database = kippo

username = root

password = honeydrive

port = 3306

Como se puede apreciar, algunas opciones de configuración vienen con los valores por defecto que trae Kippo, y otras, como el caso de la conexión a una base de datos para el registro de los eventos producidos, si que han sido personalizadas específicamente para funcionar sobre el sistema. Esta configuración puede modificarse sin ningún problema para adaptarse a las necesidades particulares de cualquiera, solamente es necesario conocer cuál es el comportamiento de de cada una de las opciones disponibles, tal como se ha visto en el primer artículo sobre honeypots y Kippo.

En HoneyDrive viene instalado PhpMyAdmin, lo que permitirá conectarse a una de las base de datos MySQL que se encuentran en el sistema y ver los eventos que se han podido registrar. En este caso concreto, interesa la base de datos “kippo”, que es en donde se almacenarán los intentos de acceso al puerto donde se encuentra en ejecución Kippo. El nombre de usuario para acceder a PhpMyAdmin es “root” y la contraseña es “honeydrive”. Una vez el usuario se autentica, tal como se puede ver en el panel de la izquierda, están todas las bases de datos que se encuentran disponibles.

hd2

Imagen 2: PhpMyAdmin en HoneyDrive.

Cuando un usuario intenta acceder al servicio de Kippo, automáticamente su intento de autenticación queda registrado en la base de datos, concretamente en la tabla “auth”, la cual almacena todos los intentos con su correspondiente nombre de usuario y contraseña, así como si el intento ha tenido éxito o no. Por otro lado, dicha tabla se encuentra relacionada con la tabla “sessions”, en donde se registran los datos básicos del usuario que ha intentado autenticarse, incluyendo su dirección IP.

hd3

Imagen 3: PhpMyAdmin en HoneyDrive.

En otras dos entradas se ha hablado de Dionaea, un honeypot enfocado a la detección y análisis de malware y en el caso de HoneyDrive también se encuentra preconfigurado y listo para ser utilizado. Los detalles se encuentran incluidos en el fichero README y son los que se listan a continuación.

[Dionaea]

Location: /opt/dionaea/

Start script: /honeydrive/dionaea-vagrant/runDionaea.sh

Binary: /opt/dionaea/bin/dionaea

Configuration: /opt/dionaea/etc/dionaea/dionaea.conf

Logs: /opt/dionaea/var/log/

SQLite database: /opt/dionaea/var/dionaea/logsql.sqlite

Malware samples: /opt/dionaea/var/dionaea/binaries/

Log rotation: enabled

phpLiteAdmin: /var/www/phpliteadmin/

+ password: honeydrive

+ allow only localhost: enabled

+ URL: http://localhost/phpliteadmin/phpliteadmin.php

Con la configuración por defecto se puede arrancar Dionaea sin ninguna dificultad, simplemente ejecutando el script “/honeydrive/dionaea-vagrant/runDionaea.sh”. Este script se puede modificar con el fin de personalizar el comando de ejecución y remover o incluir otros parámetros que admite el programa “dionaea”.

hd4

Imagen 4: Dionaea en HoneyDrive.

A continuación se puede utilizar Metasploit Framework para comprobar su funcionamiento. Esto mismo se ha visto en una entrada anterior de esta misma serie de artículos: https://thehackerway.com/2015/04/14/honeypots-parte-3-configuracion-y-analisis-de-malware-con-dionaea/

msf > use exploit/windows/smb/ms06_040_netapi

msf exploit(ms06_040_netapi) > set PAYLOAD windows/shell/bind_tcp

PAYLOAD => windows/shell/bind_tcp

msf exploit(ms06_040_netapi) > set RHOST 192.168.1.42

RHOST => 192.168.1.42

msf exploit(ms06_040_netapi) > exploit

[*] Started bind handler

[*] Detected a Windows XP SP0/SP1 target

En el fichero de logs de Dionaea se puede apreciar lo siguiente:

hd5

Imagen 5: Logs de Dionaea.

Tal como se ha visto en una entrada anterior, Dionaea también es capaz de detectar y almacenar muestras de malware que envíe un atacante, algo especialmente útil si se desea analizarlas después con Cuckoo Framework o cualquier otra herramienta.

Aquí se ha visto un ejemplo muy simple del uso de Kippo y Dionaea en Honey Drive, sin embargo existen muchos más honeypots y herramientas que se encuentran incluidos en esta interesante distribución y que se irán viendo con mucho más detalle en próximos artículos.

Un saludo y Happy Hack!
Adastra.

THW Academy: Plataforma de aprendizaje para hackers en castellano.

octubre 19, 2015 4 comentarios

Logo HackerWay1 Las cosas han cambiado muchísimo con respecto a hace poco más de 15 años, por aquel entonces encontrar información sobre seguridad informática y hacking no estaba al alcance de todo el mundo, en las bibliotecas ya te podías olvidar de encontrar manuales sobre reversing en sistemas Linux, explotación de software o hacking en general. Por aquella época todo ello era como la magia o la alquimia, cosas maravillosas que pocos habían llegado a escuchar y muchos menos habían llegado a ver.
Ahora tenemos Internet, comunidades, blogs, foros, etc. Mucha información que se encuentra a nuestro alcance y llegamos a ella al instante, muchas nuevas tecnologías y una curva de aprendizaje que cada vez está más cuesta arriba. No obstante nos seguimos encontrando con que prácticamente toda la documentación de calidad y con buenos niveles de profundidad se encuentra en inglés.
Hay muchos sitios en castellano que no son buenos, son lo siguiente, pero a veces se suelen centrar una temática muy concreta o abarcan muchos temas sin llegar a un nivel de profundidad aceptable en ninguno.
Luego, hay muchos cursos/certificaciones en donde te piden que pagues miles de euros para aprender sobre web hacking, reversing, networking, programación o cualquier otra temática concreta, con unos precios que a mi juicio tienen una calidad/precio muy desproporcionada.
Los que me conocéis o seguís este blog, sabéis que me gusta investigar y compartir lo que aprendo, llevo muchos años con una “sed” de conocimiento que nunca he llegado a saciar y aunque han habido épocas en las que me he sentido muy cansado y desmotivado por situaciones concretas, nunca he claudicado y llevo media vida, casi 15 años, intentando aprender y mejorar mis habilidades a nivel personal y académico, lo hago porque como he dicho en otras ocasiones, para mi esto no es solamente un oficio, representa una filosofía de vida a la que me mantengo fiel y también por eso escribo en este espacio cada vez que puedo.
Todo esto me ha llevado a crear THW Academy (http://academy.thehackerway.com/), una plataforma de aprendizaje totalmente online en la que vas a poder aprender sobre seguridad informática y hacking desde una perspectiva completamente “hands on” o practica. No esperes las típicas clases tradicionales llenas de conceptos teóricos sin ningún tipo de demostración practica, o clases demasiado extensas y aburridas en las que desconectas a los 10 minutos. Todas las sesiones de cada uno de los cursos tienen una parte teórica que suele ser muy concisa y una parte practica en la que se puede ver “al vuelo” cómo se aplican los conceptos teóricos.
Este espacio lo he diseñado con tres niveles de cursos: “Básico”, “Intermedio” y “Avanzado”, cada uno adaptado a su correspondiente nivel. Las personas inscritas en la plataforma podrán acceder a todos los cursos de cada nivel sin ningún tipo de restricción. Se suben varias sesiones todas las semanas que se pueden consultar en el calendario oficial, además tendrás acceso a vídeos en HD, documentación y espacios privados especialmente diseñados para probar técnicas de hacking.
Puedes seguir todos los cursos a la vez o solamente aquellos que sean de tu interés. Es aconsejable ir siguiendo las sesiones de todos los cursos para sacar el máximo provecho de la plataforma, pero el estudiante es libre de seguir únicamente aquellos cursos que decida. En la medida en que los cursos van avanzando, los contenidos van siendo más prácticos y didácticos, el desarrollo de las sesiones semanales es constante y muy dinámico, cada mes vas a tener acceso a varios vídeos que podrás repasar las veces que quieras.
La plataforma se encuentra ubicada en: http://academy.thehackerway.com y como podrás ver en el catalogo de cursos, los que se encuentran disponibles actualmente son los siguientes:

“Básico”
THWB1: Introducción a la programación en Python.
THWB2: Introducción a la privacidad y el anonimato.
THWB3: Introducción a la programación en Ruby.
THWB4: Introducción al pentesting y al hacking.

“Intermedio”
THWI1: Pentesting en aplicaciones web.
THWI2: Administración y hardening de servidores web Apache.
THWI3: Desarrollo web seguro con Java.

“Avanzado”
THWA1: Hacking con Python.
THWA2: Uso y configuración avanzada de I2P y Freenet.
THWA3: Uso y configuración avanzada de TOR.

Son 10 cursos a los que vas a tener acceso por el mismo precio y además hay promociones que te podrían interesar.  El calendario oficial incluye la planificación de las sesiones que se van a publicar durante los próximos meses con sus correspondientes contenidos, el cual puedes consultar en el siguiente enlace: http://academy.thehackerway.com/calendario-oficial además, puedes ver más detalles sobre THW Academy aquí: http://academy.thehackerway.com/cuentame-que-es-esto
En los próximos meses también tengo planificados cursos sobre Arquitectura de ordenadores, introducción a ensamblador, Fuzzing y explotación de software avanzado en sistemas Windows y Linux.
Esto es lo que tengo para toda la comunidad, quiero compartir lo que constantemente he ido aprendiendo en los años que llevo dedicado a esto y todo lo que me queda por aprender. Creo que está es una buena forma.

Como siempre, si quieres comentarme cualquier cosa o necesitas más información, me puedes escribir a adastra@thehackerway.com

Saludos y Happy Hack!
Adastra.

Pentesting automatizado con Beef. Consumiendo la API Rest de BeEF con Python – Parte 3

agosto 4, 2015 6 comentarios

La API Rest de BeEF cuenta con todo lo necesario para controlar y automatizar las actividades que se pueden llevar a cabo desde el C&C de BeEF. El hecho de poder invocar a los endpoints definidos en dicha API permite crear rutinas de código que ayuden a ejecutar los procesos de recolección de información y explotación de una forma mucho más rápida y eficiente. Tal como se ha enseñado en las dos entradas anteriores sobre BeEF, utilizar esta API no es nada complicado y solamente es necesario ejecutar las peticiones HTTP con los parámetros correctos. Para hacerlo, se puede utilizar herramientas como wget, curl o incluso netcat/socat y si se quiere automatizar el uso de estas herramientas, una buena forma de hacerlo consiste en crear un script en bash que que las ejecute. Evidentemente también es posible utilizar cualquier lenguaje de programación y ejecutar las peticiones HTTP de forma automatizada utilizando las diferentes librerías que proporcionan todos los lenguajes de programación modernos. Dicho esto, a continuación se explicará cómo invocar a algunos de los endpoints de BeEF utilizando Python y en el próximo artículo, lo mismo pero utilizando Ruby.

Consumiendo la API de BeEF con Python

Python cuenta con un considerable número de librerías para realizar peticiones HTTP, lo que facilita muchísimo las cosas a la hora de crear clientes o incluso servicios utilizando Python y este protocolo. Una de las más conocidas y utilizadas es “requests” ya que con muy pocas líneas de código se puede crear un cliente HTTP completamente funcional y soportando todas las características del protocolo HTTP 1.1, algo que en otras librerías como urllib, urllib2 o httplib requiere más líneas de código y un poco más de esfuerzo. Con esto en mente se podría crear un script utilizando requests para consumir la API Rest de BeEF, pero para facilitar aun más las cosas, existe una librería pequeña y simple llamada BeEF-API que ya se encarga de interactuar con los endpoints de BeEF y solamente es necesario invocar a los métodos adecuados de dicha librería. Se encuentra disponible en el siguiente repositorio de GitHub: https://github.com/byt3bl33d3r/BeEF-API y como ocurre con prácticamente todas las librerías en Python, para instalarla solamente hace falta ejecutar el script “setup.py” con el parámetro “install”.
Esta librería se encarga de gestionar la autenticación con BeEF y almacenar internamente el token generado, el cual como se ha visto en el primer artículo, es requerido para invocar algunos de los endpoints de la API Rest.

 

>python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from beefapi import BeefAPI
>>> beef = BeefAPI({})
>>> beef.login('beef', 'beef')
True

Como se puede apreciar, todo parte de la creación un objeto del tipo “BeefAPI”, cuyo constructor recibe como argumento un diccionario, el cual puede tener las claves “host” y “port” en el caso de que se quiera indicar una interfaz de red y puertos distintos a los valores por defecto (127.0.0.1:3000). Posteriormente se invoca al método “login” enviando como parámetros el usuario y la contraseña para autenticarse en el sistema.
Una vez el usuario se ha conseguido autenticar y se ha generado un token para la sesión actual, la librería dispone de una serie de métodos para invocar distintos endpoints, gestionando el token de autenticación de forma automática en cada una de dichas invocaciones. Algunos de los métodos disponibles en una instancia de la clase BeefAPI, permiten obtener los módulos disponibles en la instancia de Beef, buscar módulos que contengan una cadena determinada, listar todos los navegadores que han ejecutado el “hook” de Beef y que se encuentran “online”, así como aquellos que se encuentran “offline” y por supuesto, ejecutar módulos contra todos o solamente algunos de los navegadores enganchados. Esta librería utiliza internamente “requests” y los valores de retorno de cada petición siempre son diccionarios que representan las repuestas emitidas por cada uno de los endpoints invocados en formato JSON.

beefpython1Listando todos los módulos disponibles en BeEF

Como mencionaba antes, también es posible buscar módulos que cumplan con un patrón de texto determinado, pudiendo filtrar de esta forma aquellos módulos que sean de interés para el usuario.

beefpython2Filtrando módulos en BeEF

Del mismo modo que se pueden realizar búsquedas y listar los módulos disponibles en BeEF, también es posible hacer operaciones similares contra los navegadores que se encuentra online y offline.

beefpython3Listando navegadores hookeados

Y por último, pero no menos importante, es posible ejecutar un módulo determinado contra uno o varios navegadores que se encuentran “hookeados” en BeEF. Para hacerlo, en primer lugar hay que obtener el objeto correspondiente al navegador contra el que se desea ejecutar el módulo y en segundo lugar, se debe especificar el identificador del módulo que se desea utilizar contra el navegador. Cada objeto del tipo “Session” (navegador hookeado) tiene un método llamado “run” el cual recibe como argumento un valor númerico que representará el identificador de un módulo. Dicho método se encargará de buscar el módulo identificado con el valor especificado y posteriormente, se encargará de lanzarlo contra el navegador hookeado, algo que como se puede ver más abajo, se consigue con pocas lineas de código.

>>> for hook in beef.hooked_browsers.online:
...     commandId = hook.run(243)["command_id"]
...     print beef.modules.findbyid(243).results(hook.session, commandId)

En este caso, el módulo con el identificador “243” corresponde al módulo “Detect tor”, el cual como su nombre lo indica, intenta determinar si el navegador en cuestión está utilizando TOR para navegar. El método “run” es el encargado de ejecutar el módulo especificado y de retornar una estructura en formato “JSON” con un identificador del comando, el cual debe ser utilizado posteriormente para obtener los resultados que ha devuelto el módulo.

Como se ha podido ver, utilizar está librería no es complicado y es una buena forma automatizar las tareas que pueden llevarse a cabo desde la consola web de BeEF. En el próximo artículo hablaré sobre cómo hacer esto mismo con Ruby.

Saludos y Happy Hack!
Adastra.

Pluggable transports en TOR para la evasión de Deep Packet Inspection

julio 30, 2015 2 comentarios

Los puentes (bridges) son una de las formas más “tradicionales” de evadir la censura por parte de países y proveedores del servicio que intentan bloquear las autoridades de directorio y nodos de TOR. Se trata de un mecanismo que funciona bastante bien, ya que los puentes son direcciones que no se encuentran directamente relacionadas con TOR y aunque funcionan exactamente igual que cualquier repetidor, su información no se distribuye públicamente en ninguno de los descriptores emitidos por las autoridades de directorio. Aunque esta medida resulta bastante efectiva para evadir mecanismos de bloqueo simples basados en direcciones o dominios, en los últimos años se ha comenzado a ver que organismos censores implementan técnicas del tipo DPI (Deep Packet Inspection) para analizar el contenido de los paquetes en busca de cualquier indicio o patrón que les permita saber si el paquete en cuestión utiliza el protocolo de TOR. Evidentemente este tipo de técnicas suelen ser muy efectivas y permiten detectar y bloquear cualquier paquete de datos que utilice el protocolo de TOR.
Como siempre, nos encontramos en un constante “tira y afloje”, en el que los mecanismos de censura son mucho más complejos y efectivos, lo cual obliga a implementar técnicas de evasión que puedan ir un paso por delante. Dado que utilizar únicamente los bridges tradicionales ahora no es del todo efectivo (en algunos países), el equipo de TOR lleva unos años mejorando las técnicas de evasión y últimamente se ha venido hablando mucho sobre los Pluggable Transports (PT), cuyo principal objetivo es el de ofuscar el tráfico entre un origen y un bridge por medio de PTs. Dichos PTs se encargan de modificar los paquetes de datos para parezcan peticiones normales, ocultando cualquier indicio que permita descubrir de que se trata de un paquete de datos que hace parte de un flujo de TOR. La siguiente imagen simplifica el funcionamiento del sistema de PTs, el cual como se puede apreciar, no es demasiado complejo.

PTFuncionamiento de los Pluggable Transports en TOR

Pluggable Transports en TOR con Obsproxy

La especificación de “Pluggable Transports” está diseñada para que sea independiente de TOR u otras soluciones de anonimato e indica los pasos y directrices que debe seguir cualquier implementación de PTs. En el caso de TOR, existen varias implementaciones de PTs que se pueden utilizar, siendo Meek y ObsProxy las más soportadas y por supuesto, recomendadas.

Obsproxy es un framework escrito en Python que permite implementar PTs. Utiliza Twisted para todas las operaciones de red y la librería pyptlib la cual ha sido creada por el equipo de TOR específicamente para soportar las características de los PTs. Esta librería es especialmente interesante para aquellas aplicaciones que se encargan de transformar y ofuscar tráfico TCP y que requieren enviar dichos flujos de paquetes a un destino utilizando TOR.

Para utilizar Obsproxy en el lado del cliente (ver la imagen de arriba) se puede ejecutar TOR Browser Bundle, el cual contiene las implementaciones de los principales PTs soportados en TOR. En este caso concreto, Obsproxy y las otras implementaciones de PTs se encuentran incluidas en el directorio “<TOR_BROWSER/Browser/TorBrowser/Tor/PluggableTransports>”. Dichas implementaciones pueden utilizarse en modo cliente cuando se arranca Tor Browser y su configuración es prácticamente automática por medio de un asistente muy simple, el cual se inicia al abrir la configuración de Tor Browser.

pt1Configuración del cliente de TOR Browser

Como se puede apreciar, existen dos posibles escenarios, o bien el cliente se encuentra “censurado” y sus peticiones se encuentran filtradas por medio de un proxy o el cliente cuenta con una conexión directa a Internet, con lo cual no tendrá mayores inconvenientes a la hora de conectarse a la red de TOR. En el segundo caso, el asistente de Tor Browser le permite al cliente especificar cuál tipo de PT desea utilizar y a continuación, se encarga de configurar al instancia para que utilice el PT adecuado.

pt2Selección de un PT en Tor Browser

Después de seleccionar el tipo de PT la conexión a la red de TOR se hará por medio de los bridges que vienen por defecto en el Tor Browser y además, todas las peticiones se harán a un servidor OBSProxy por medio del cliente obfs3 local que se ha indicado. En el caso de que no sea posible realizar la conexión a la red de TOR utilizando los Bridges OBFS3 por defecto, Tor Browser indicará que hay un “censor” que se encuentra bloqueando las peticiones a dichas máquinas y en tal caso, se debe solicitar un conjunto de Bridges nuevo tal como se ha explicado en un artículo anterior.

El fichero “torrc” utilizado por Tor Browser habrá sufrido algunos cambios después de aplicar la configuración anterior y como se puede ver a continuación, dichos cambios incluyen el uso de Bridges OBFS3.

Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9Bridge obfs3 83.212.101.3:80 A09D536DD1752D542E1FBB3C9CE4449D51298239

Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9

Bridge obfs3 109.105.109.163:47779 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A

Bridge obfs3 109.105.109.163:38980 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED

DataDirectory /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor

GeoIPFile /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip

GeoIPv6File /home/adastra/tor-browser_es-ES/Browser/TorBrowser/Data/Tor/geoip6

UseBridges 1

Por otro lado, en el combo en el que se puede seleccionar un PT, también se puede ver “meek-amazon”, “meek-azure” y “meek-google”. Probablemente el lector se preguntará qué significa eso, pues bien, el PT Meek se basa en HTTPS y se encarga de modificar el tráfico de TOR para que las peticiones parezcan “inocentes” y en este caso concreto, “meek-amazon” se encarga de transformar las peticiones para que parezca que el usuario se encuentra interactuando con la plataforma de Amazon Web Services, “meek-azure” para que parezca que las peticiones se realizan contra la plataforma de servicios web de Microsoft Azure y finalmente “meek-google” modifica los paquetes de datos para que parezca que las peticiones realizadas por el cliente, son simplemente búsquedas en Google. Si bien es un PT muy interesante, actualmente hay varios detalles que se encuentran en estado de desarrollo y la cantidad de PTs del tipo servidor (puentes) es bastante pequeña, por ese motivo siempre se recomienda utilizar el PT de ObsProxy. Sobre Meek se hablará con mayor detalle en un próximo artículo y aunque aquí solamente se ha mencionado la configuración básica del lado del cliente para utilizar un PT con TOR, aun queda haciendo falta explicar la forma en la que se pueden crear Bridges PT que aporten a los usuarios de la red de TOR que se encuentran censurados, esto también lo explicaré en el próximo artículo.

Saludos y Happy Hack!
Adastra.

A %d blogueros les gusta esto: