Archivo

Posts Tagged ‘hacking linux’

Evadiendo no-exec stacks con técnicas ret2libc

septiembre 14, 2017 1 comentario

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

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

El origen del mal.

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

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

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

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

Explotando el programa con No-Exec habilitado

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un saludo y Happy Hack.

Adastra.

Introducción a SecurityOnion

abril 17, 2017 Deja un comentario

SecurityOnion es un distribución basada en GNU/Linux, concretamente en Ubuntu y contiene un conjunto bastante completo de herramientas para la detección/prevención de amenazas. Utilizando una o varias instancias de SecurityOnion se puede tener una red con mecanismos de defensa sólidos y sensores que identificarán rápidamente las principales amenazas y eventos potencialmente peligrosos. Entre las herramientas que se encuentran incluidas en SecurityOnion nos encontramos con IDS/HIDS, herramientas para el procesamiento de paquetes, de logs y análisis de tráfico, entre otras. A continuación se explicará el funcionamiento de SecurityOnion y sus elementos “core”.

Netsniff-ng: Se trata de sniffer muy potente y pensado principalmente para sistemas GNU/Linux, muy similar a TCPDump/Wireshark, pero con la diferencia de que explota de una forma bastante eficiente los beneficios que aporta el “PACKET_MMAP” del Kernel. En el caso de SecurityOnion el uso de “Netsniff-ng” se centra en la captura constante y completa de los paquetes de datos que se mueven en la red y obviamente, dicha información es posteriormente utilizada por otras herramientas para su análisis completo.

Suricata y Snort: Se trata de las soluciones más conocidas y populares en el mundo de los IDS open-source. Ambas alternativas se encargan detectar intrusiones y/o posibles amenazas gracias los motores de reglas personalizables que incluyen ambas soluciones. En efecto, tanto Suricata como Snort son IDS “rule-driven”, es decir, herramientas que tras aplicar una serie de patrones configurables por el administrador, son capaces de detectar tráfico sospechoso o malicioso.

Bro IDS: Si bien el objetivo de Bro IDS es el mismo que el de Suricata y Snort, el modelo aplicado para la resolución de las amenazas en un entorno de red es completamente distinto. Como se mencionaba antes, los IDS basados en reglas utilizan un conjunto de patrones que sirven como “fingerprints” de amenazas o incluso ataques que se están llevando a cabo en la red. Dichos patrones pueden ser muy flexibles y tener unos muy buenos niveles de efectividad contra amenazas comunes, pero dado el dinamismo del tráfico en segmentos de red y la facilidad que tienen los atacantes de ocultar payloads, malware y todo de tipo de paquetes maliciosos, es muy probable que un sistema basado en reglas sea capaz de filtrar todas las posibles amenazas que pueden producirse. En éste sentido, los IDS “analysis-driven” suponen un enfoque distinto a los IDS tradicionales basados en reglas, ya que además de capturar eventos potencialmente peligrosos, provee de un framework bastante potente para analizar todos los eventos y el tráfico generado, de tal forma que el analista de seguridad podrá verificar si efectivamente si se está llevando a cabo un ataque o si hay algún tipo de amenaza en la red.

OSSEC: Además de las soluciones de seguridad basadas en eventos producidos en red como los NIDS mencionados antes, SecurityOnion también cuenta con OSSEC como solución HIDS para el establecimiento de endpoints y agentes que se encarguen de monitorizar los eventos producidos en “puntos fijos” dentro de la red. OSSEC permite ejecutar labores de recolección y análisis de logs, chequeos de integridad en ficheros, gestión de políticas, sistema en tiempo real de alarmas, entre otras cosas. OSSEC, al igual que los NIDS mencionados anteriormente, tienen licencias opensource y por ese, entre otros motivos, se encuentran incluidas directamente en SecurityOnion con una configuración por defecto.

La capacidad de capturar y correlacionar eventos producidos en sistemas aislados y en el contexto de red es algo bastante aconsejable para una detección y prevención mucho más eficiente de amenazas y desde luego es por lo que apuestan soluciones como SecurityOnion. No obstante, la cantidad de paquetes a procesar no es nada despreciable y precisamente por ese motivo, en SecurityOnion también existen herramientas para el análisis de toda esa información.

Instalación

No es un procedimiento complejo ni mucho menos, se trata de una distribución basada en Ubuntu, más concretamente en la versión 14.04 (a la fecha de redactar éste artículo) y se puede instalar directamente en el ordenador o como una máquina virtual con VMWare o VirtualBox. Lo primero es descargar la imagen ISO que se encuentra disponible en el repositorio GitHub del proyecto, ubicado en la siguiente dirección: https://github.com/Security-Onion-Solutions/security-onion
Una vez descargada la imagen, se puede proceder con la instalación del mismo modo que se haría con cualquier sistema basado en GNU/Linux. Otra alternativa para instalar todas las características disponibles en SecurityOnion, consiste en instalar un Ubuntu 14.04 y posteriormente añadir los repositorios PPA de SecurityOnion, los cuales nuevamente, a la fecha de redactar éste artículo, únicamente son compatibles con dicha versión de Ubuntu. Por otro lado, también es importante verificar el checksum de la imagen ISO descargada para comprobar su integridad, no cuesta mucho y lleva poco tiempo así que es altamente recomendable hacerlo, las instrucciones se encuentran incluidas en el siguiente enlace: https://github.com/Security-Onion-Solutions/security-onion/wiki/Installation. Ahora bien, para la instalación se puede utilizar una versión de Ubuntu 14.04 recién instalada y posteriormente, configurar todos los paquetes disponibles en SecurityOnion, es algo que viene bien aprender a hacer ya que en despliegues en entornos de producción es mejor instalar un Ubuntu e ir configurando todo de la forma más fina posible. El procedimiento es simple, basta con ejecutar los siguientes comandos para tener todo lo necesario antes de comenzar la instalación de los paquetes de SecurityOnion con “apt-get”.

>sudo apt-get -y install software-properties-common

>sudo add-apt-repository -y ppa:securityonion/stable

>sudo apt-get update

Tras la importación del repositorio es necesario ejecutar un “update” para posteriormente, ejecutar el siguiente comando de instalación:

>sudo apt-get install securityonion-all syslog-ng-core

Se trata de un procedimiento que puede tardar un buen rato mientras se instalan todos los componentes necesarios. Finalmente, se debe ejecutar el siguiente comando para realizar el procedimiento inicial de configuración, el cual consiste en la ejecución de un asistente muy sencillo que nos guiará paso a paso.

>sudo sosetup

En el último paso, se procede a realizar los cambios directamente en el sistema y finalmente se reinicia. Después de reiniciar es posible arrancar todos los servicios de SecurityOnion con el siguiente comando:

>sudo service nsm start

No obstante, es probable que existan errores tras reiniciar el sistema, como por ejemplo que el servidor “securityonion” no exista o no se encuentre el usuario “sguil”. Esto indica que el asistente no ha realizado todas las labores de configuración que debería y para solucionarlo, basta simplemente con volver a ejecutar el script.



Por último, se puede apreciar que SecurityOnion se encuentra activo con todos los servicios levantados y en funcionamiento, ahora queda comenzar a configurar cada uno de los servicios de forma individual para llegar a la mejor configuración posible de acuerdo a las necesidades especificas del cliente o empresa.

En próximas entradas se explicara mas en detalle cada uno de estos servicios y las herramientas disponibles para realizar una configuración enfocada a entornos productivos.

Un saludo y Happy Hack!
Adastra.

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.

Bridges en TOR y una introducción a los “Pluggable transports”

abril 28, 2015 3 comentarios

TOR se caracteriza por ser una red centralizada, en la que cada hora, una serie de servidores de confianza llamados “autoridades de directorio” se encargan de generar información sobre los repetidores que conforman la red y algunos datos adicionales sobre el estado general de la misma. Dicha información es pública y se puede consultar fácilmente ejecutando peticiones HTTP contra cualquiera de las autoridades de directorio o sus espejos. Dado que la información sobre los repetidores la puede consultar cualquiera, una de las principales medidas que toman las entidades represoras a la hora instaurar controles y censurar contenidos, consiste simplemente en incluir dichas direcciones IP en una lista negra para impedir que se puedan realizar conexiones contra cualquier repetidor de TOR. Es una medida que se utiliza muchísimo y que según algunos artículos publicados en el blog de TOR (https://blog.torproject.org/) es una de las medidas más utilizadas en países como Cuba, China, Etiopía, Corea del Norte, etc. Con el fin de hacer que la red sea resistente a este tipo de censura, el equipo de TOR ha desarrollado un sistema para que los ciudadanos de países como los anteriores puedan seguir utilizando TOR sin problemas, aunque las direcciones IP de los repetidores incluidos en los consensos o incluso las direcciones IP de las autoridades de directorio se encuentren bloqueadas. Dicho sistema es conocido como “Automatic Bridging” y es un mecanismo en el que se busca eludir la censura por parte de adversarios fuertes, como es el caso del gobierno de un país. Para conseguir esto, las autoridades de directorio utilizan unos repetidores especiales llamados “Bridges” o puentes, los cuales funcionan exactamente igual que cualquier repetidor que hace parte de un circuito en TOR, pero con la diferencia de que no se exponen públicamente en los descriptores emitidos cada hora por las autoridades de TOR. Los bridges pueden ser creados por cualquier usuario de TOR y si estás a favor de la libertad de expresión y te asquea ver como en ciertos países la gente no puede expresar libremente sus ideas sin temor a que sus vidas o las de sus familiares corran peligro, te recomiendo que configures tus instancias de TOR para que también funcionen como puentes y sean utilizadas por aquellas personas que desean reportar los abusos que se comenten en ciertos lugares del mundo.
Para aquellos que desean obtener un listado de bridges de TOR, dado que no se pueden conectar directamente con las autoridades de directorio o con los repetidores que conforman la red, existen dos formas:

1. Consultar los puentes en “BridgeDB”, el proyecto oficial de TOR para acceder a un conjunto reducido de puentes que servirán para eludir la censura. Dicho proyecto se encuentra ubicado en el siguiente enlace: https://bridges.torproject.org. Para obtener los bridges basta con pinchar sobre el botón en el que pone “Get Bridges” u “Obtener puentes” y después de ingresar un captcha, se enseñarán dos puentes que deben ser configurados en la instancia de TOR que no consigue llegar a las autoridades de directorio o a los repetidores de la red.

2. En el caso (bastante frecuente) de que el proyecto “BridgeDB” también se encuentre censurado, la otra alternativa para recibir un par de puentes validos es escribir un correo a la dirección “bridges@torproject.org”. El mensaje no tiene que tener un contenido, es simplemente una dirección de correo que responde de forma automática al remitente con lo que ha solicitado. En el asunto del mensaje se debe especificar un “comando” para obtener información sobre BridgeDB. Si se envía un mensaje a dicha dirección, sin asunto, la respuesta automática contendrá los posibles comandos que puede enviar el comando a la plataforma de BridgeDB.
El contenido del mensaje devuelto, en el caso de no incluir un asunto es el siguiente:


Hey, debiadastra! Welcome to BridgeDB!

COMMANDs: (combine COMMANDs to specify multiple options simultaneously)
get bridges Request vanilla bridges.
get transport [TYPE] Request a Pluggable Transport by TYPE.
get help Displays this message.
get key Get a copy of BridgeDB’s public GnuPG key.
get ipv6 Request IPv6 bridges.

Currently supported transport TYPEs:
obfs2
obfs3
obfs4
scramblesuit
fte

BridgeDB can provide bridges with several types of Pluggable Transports[0],
which can help obfuscate your connections to the Tor Network, making it more
difficult for anyone watching your internet traffic to determine that you are
using Tor.

Some bridges with IPv6 addresses are also available, though some Pluggable
Transports aren’t IPv6 compatible.

Additionally, BridgeDB has plenty of plain-ol’-vanilla bridges – without any
Pluggable Transports – which maybe doesn’t sound as cool, but they can still
help to circumvent internet censorship in many cases.

[0]: https://www.torproject.org/

❤ BridgeDB

En el caso de indicar el asunto “get bridges”, lo que se puede ver es lo siguiente:

“Hey, debiadastra!
[This is an automated message; please do not reply.]
Here are your bridges:

83.212.111.114:443 0A6EF34EDF047BFD51319268CD423E
194.132.208.140:1418 E6F48300BB17180451522069F16BD5
192.36.31.74:22656 FEB63CA5EBD805C42DC0E5FBDDE82F

To enter bridges into Tor Browser, first go to the  Tor Browser download
page [0] and then follow the instructions there for downloading and starting
Tor Browser.

When the ‘Tor Network Settings’ dialogue pops up, click ‘Configure’ and follow
the wizard until it asks:

> Does your Internet Service Provider (ISP) block or otherwise censor connections
> to the Tor network?

Select ‘Yes’ and then click ‘Next’. To configure your new bridges, copy and
paste the bridge lines into the text input box. Finally, click ‘Connect’, and
you should be good to go! If you experience trouble, try clicking the ‘Help’
button in the ‘Tor Network Settings’ wizard for further assistance.

[0]: https://www.torproject.org/

Como se puede ver, ha devuelto tres repetidores con la dirección IP, puerto y fingerprint del puente. Ahora, para que una instancia de TOR pueda utilizar dichos puentes, basta con especificar las siguientes líneas de configuración en el fichero “torrc”.

Bridge 83.212.111.114:443
Bridge 194.132.208.140:1418
Bridge 192.36.31.74:22656
UseBridges 1

Si estas interesado en crear tu instancia de TOR para que funcione como puente, el procedimiento es bastante sencillo, sin embargo, no se puede configurar una instancia de TOR que funcione como repetidor y puente al mismo tiempo, lo cual es lógico, ya que los repetidores son públicos y los puentes privados y establecer una instancia que actúe como repetidor y puente es equivalente a crear un puente de acceso público y fácil de censurar, lo cual evidentemente no tiene ningún sentido.

Es necesario incluir las siguientes líneas de configuración en el fichero “torrc”:

SocksPort 0

ORPort 8080

Exitpolicy reject *:*

DataDirectory /home/adastra/workspace/bridge/

BridgeRelay 1

Como se puede ver, tanto configurar como utilizar un puente es una tarea bastante simple y es una solución que se ajusta bastante bien al problema de la censura. Sin embargo, algunos “rivales fuertes”, tales como los gobiernos de China o Corea del Norte, ahora ya no solamente bloquean las direcciones IP que se encuentren relacionadas con la red de TOR, ahora aplican técnicas de análisis de paquetes que detectan si los paquetes intercambiados utilizan el protocolo de TOR. Ante una medida así, los puentes por si solos pierden efectividad y se hace muy difícil ocultar el trafico. Aquí entra en juego lo que se conoce como “Pluggable Transports”.

Introducción a los Pluggable Transports

Las técnicas DIP (Deep Packet Inspection) se han vuelto cada vez más comunes en aquellos países en los que el nivel de censura es alto. Las rutinas DIP se encargan de analizar un conjunto de paquetes y reensamblarlos para clasificarlos partiendo de patrones conocidos. De esta forma, con DIP es posible determinar que un conjunto de paquetes se encuentran transmitiendo datos en la red de TOR aunque la dirección IP no se encuentre bloqueada.

Ahora bien, la especificación de “Pluggable Transports” define a esta tecnología como la capacidad de convertir flujos de trafico de TOR entre el cliente y un puente, en flujos admitidos y no reconocidos por técnicas de DIP, como por ejemplo, una conversación inocente con cualquier servidor web en Internet. Notar que aunque el rival (censor), pueda monitorizar el trafico y analizar los paquetes en profundidad, no verá ningún patrón conocido que le permita determinar con exactitud que se trata de un paquete que viaja por TOR.

El objetivo de los PT (Pluggable Transports) consiste básicamente en ofuscar el trafico entre el cliente y sus puentes. Para ello, se utiliza un componente de software adicional tanto en el cliente como en la instancia de TOR que funciona como puente. Dichos componentes deben conocer una serie de reglas para poder ofuscar el trafico (cliente) y posteriormente, poder desofuscarlo (servidor). Actualmente existen varias herramientas y frameworks desarrollados siguiendo la especificación de PT ubicada en el siguiente enlace https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt y seguramente la más conocida y popular es OBFSPROXY, un framework implementado en Python del que os hablaré en un próximo articulo.

Un saludo y Happy Hack!
Adastra.

Procesamiento del lenguaje natural con NLTK para Ingeniería social automatizada

febrero 17, 2015 7 comentarios

En una entrada anterior os hablaba de un proyecto que llevo estudiando desde hace algún tiempo para el análisis de emociones, dicho proyecto es “wefeelfine” y tal como os comentaba, cuenta con una API Rest que permite realizar varios tipos de consultas para obtener un listado de sentimientos recolectados en Internet. La recolección de datos que realiza dicha plataforma se basa en la ejecución de varios procesos de crawling para extraer y almacenar información de múltiples sitios en Internet, sin embargo, una de las cosas que más me ha llamado la atención es el procesamiento de los textos y las funciones utilizadas para determinar la polaridad de dichas palabras. La complejidad de un proceso de “stemming” (derivación y combinaciones de palabras) sobre el lenguaje natural no es una tarea sencilla, especialmente cuando hablamos de las características propias de cada lenguaje, al final ocurre que solamente nos podemos centrar en un conjunto limitado de lenguajes, tal como ocurre en “wefeelfine” que solo procesa los textos escritos en ingles y en castellano, aunque este último con bastantes deficiencias. Si estás pensando en desarrollar un proceso de minería de datos sobre alguna red social como Twitter, Facebook o cualquier otro sitio web en Internet, lo más probable es que te interese también extraer información útil a la que posteriormente le puedas aplicar algún tipo de análisis estadístico sobre marcas, tendencias o de carácter histórico/evolutivo. En cualquier caso, es necesario aplicar técnicas de “Procesamiento del lenguaje Natural” o NLP (Natural Lenguage Processing) por sus siglas en ingles, las cuales permiten aplicar patrones a un texto concreto y extraer información de interés (no confundir con NLP: Neuro-Linguistic Programming). Antes de continuar, viene bien explicar en qué consiste NLP y cómo se puede utilizar la librería NLTK en Python.

¿Qué es NLP?

Se trata de un conjunto de técnicas que permiten el análisis y manipulación del lenguaje natural. Dada la complejidad intrínseca que acompaña cualquier proceso de NLP, muchas de las técnicas automatizadas están relacionadas con el uso de la IA (Inteligencia Artificial) y las ciencias cognitivas. Para aplicar las técnicas más comunes en NLP, la librería NLTK (Natural Language Tool Kit) permite que cualquier programa escrito en lenguaje Python pueda invocar a un amplio conjunto de algoritmos que sustentan las principales técnicas de NLP para la generación de métricas, frecuencia de términos, polaridad negativa/positiva de frases y textos, entre otras muchas técnicas.
Existen algunos
términos comunes en NLP que se deben comprender antes de poder aplicar cualquier técnica y entender los resultados que arrojan, dichos términos resultarán de lo más lógicos, pero si no se tienen en cuenta a la hora de programar, pueden resultar confusas las funciones y resultados arrojados por NLTK.

Token: Se trata de la unidad más simple de procesamiento y representa una palabra en el texto.
Sentencia: Secuencia ordenada de tokens.
Tokenización: Se trata del proceso de segmentar una sentencia en cada uno de los tokens que la componen. Aunque puede ser un proceso simple para textos escritos en algunas lenguas, especialmente en el caso de las románicas cuyo token separador es un espacio, en otras lenguas como las altaicas, extraer los tokens de una sentencia es un proceso mucho más complejo debido a la sintaxis y semántica de los escritos en dichas lenguas.
Corpus: Cuerpo del mensaje que se encuentra compuesto por un conjunto de sentencias.
Part-of-speech (POS): Dependiendo de la semántica del lenguaje, cada token que compone una sentencia puede ser un verbo, un adjetivo, un pronombre, un articulo, etc. Un POS es simplemente una clasificación para cada token dentro de una sentencia, de esta forma es posible identificar el significado de cada token y las partes clave de cada sentencia.
Árbol: Todos los textos están compuestos por varias sentencias y cada sentencia tiene varios tokens con sus respectivos POS. Un árbol parseado incluye cada una de las dependencias de las sentencias y cada parte del texto. Es una forma de ordenar cada uno de los elementos del “corpus” de una forma que sea fácil de consultar.

Ahora que se ha expuesto la terminología básica, lo siguiente es conocer las principales técnicas definidas en un proceso NLP.

Etiquetado de POS: Una de las principales labores en un proceso de NLP, es identificar cada una una de las sentencias de un texto y clasificar cada uno de los tokens con sus correspondientes POS. Un “POS Tagger” es una rutina que se encarga de crear un diccionario con cada uno de dichos tokens y sus correspondientes POS. Por ejemplo, si la sentencia “El coche es rojo” es procesada por un POS Tagger el resultado es el siguiente: {“El” : AT , “coche” : NN , “es” : VB, “rojo” : JJ}
Donde cada POS asume los siguientes valores:
AT : Artículo
NN : Sustantivo
VB: Verbo
JJ: Adjetivo.

Parsers:
Un parser se encarga de producir un árbol de tokens con sus correspondientes POS partiendo de una sentencia determinada. Muchos de estos parsers depende un POS Tagger antes de poder generar un árbol.

Morfología:
Consiste en el proceso de catalogar cada token de una sentencia y extraer sus “morfemas” y “
raíces” para posterior análisis. Para comprender lo anterior, es necesario saber que cada token tiene una morfología que determina la estructura interna de la palabra. La morfología de una palabra puede dar lugar a nuevas palabras a partir de su morfema base y en todo caso, es importante diferenciar la morfología de la sintaxis de una palabra, ya que la morfología intenta determinar la estructura interna de las palabras, mientras que la sintaxis explica las normas para crear oraciones y textos.

Traductor:
Se trata de unas las principales aplicaciones de NLP, en la que partiendo de un texto escrito en un lenguaje determinado, es posible conseguir su traducción en otro lenguaje. Es una tarea compleja y requiere que el texto origen se encuentre correctamente
construido y cada bloque semántico del “corpus” se encuentre perfectamente redactado para conseguir una traducción legible en otro lenguaje. Google Traductor es uno de los servicios más completos y mejor implementados (que conozco) que utiliza parsers y POS Taggers avanzados para conseguir la traducción más exacta posible.

Instalación y uso básico de NLTK

La instalación del proyecto NLTK puede realizarse fácilmente utilizando PIP o easy_install.

sudo pip install -U nltk

Una dependencia opcional que también puede instalarse con PIP es numpy. Para verificar que ha quedado correctamente instalada, basta con importar el módulo ntlk y si no se aprecia ningún error, se puede asumir que el proceso de instalación ha ido bien.

Por otro lado, además de la librería también es necesario instalar una serie de ficheros y diccionarios con patrones para varios tipos de estructuras gramaticales llamados “corporas”, dichos ficheros se instalan de forma independiente por medio de un gestor de descargas que puede iniciarse utilizando el modulo nltk

>python
>>>import nltk
>>>nltk.download()


Invocando a “download” se abre una ventana en la que se pueden gestionar todos los ficheros “corpora” en diferentes
categorías. Si es la primera vez que se utiliza nltk, se realizará la descarga de dichos ficheros.
Los corpus principal
es que se suelen utilizar en el procesamiento de texto son conocidos como “gutenberg”, el cual incluye una selección de 18 textos del proyecto Gutenberg (http://www.gutenberg.org/) y contiene más de 1.5 millones de palabras. Para consultar los textos de gutenberg incluidos en el corpus de NLTK, se pueden ejecutar las siguientes instrucciones.

>>>from nltk.corpus import gutenberg

>>>print gutenberg.fileids()

['austen-emma.txt',

'austen-persuasion.txt',

'austen-sense.txt',

'bible-kjv.txt',

'blake-poems.txt',

'bryant-stories.txt',

'burgess-busterbrown.txt',

'carroll-alice.txt',

'chesterton-ball.txt',

'chesterton-brown.txt',

'chesterton-thursday.txt',

'edgeworth-parents.txt',

'melville-moby_dick.txt',

'milton-paradise.txt',

'shakespeare-caesar.txt',

'shakespeare-hamlet.txt',

'shakespeare-macbeth.txt',

'whitman-leaves.txt']

Ahora es el momento de comenzar a utilizar la librería y para ello, se puede utilizar el siguiente script, el cual se encarga de pintar por pantalla cada uno de los textos del proyecto gutenberg, el número de caracteres, el número de tokens, el número de sentencias y el número de veces que un item del vocabulario aparece en una sentencia.

from nltk.corpus import gutenberg
for fileid in gutenberg.fileids():
    num_chars = len(gutenberg.raw(fileid))
    num_tokens = len(gutenberg.words(fileid))
    num_sents = len(gutenberg.sents(fileid))
    num_vocab = len(set(w.lower() for w in gutenberg.words(fileid)))
    print str(num_chars) + " - " + str(num_tokens) + " - " + str(num_sents) + " - " + str(num_vocab)

Aunque se ha utilizado un corpus que se encuentra implementado en NLTK, también es posible utilizar uno propio y de hecho, es lo más común para realizar diferentes tipos de análisis sobre los datos de un texto. Para ello se pueden utilizar las clases PlaintextCorpusReader o BracketParseCorpusReader.

from nltk.corpus import PlaintextCorpusReader
import nltk
wordlists = PlaintextCorpusReader("/home/adastra/Escritorio/textos", '.*')
wordlists.words('prueba.txt')
print "Sentences: "+str(len(wordlists.sents()))
for sentence in wordlists.sents():
    tokens = nltk.word_tokenize(str(sentence))
    tagged_tokens = nltk.pos_tag(tokens)
    verbs = 0
    for tagged in tagged_tokens:
        token, tag = tagged
        if tag == 'VBP' or tag == 'VB':
            verbs += 1
    print "Tokens: "+str(len(tokens)) + " - Verbs: "+str(verbs)</td>

El script anterior lee el fichero “prueba.txt” que se encuentra en el directorio “/home/adastra/Escritorio/textos” y se encarga de contar el número de sentencias, el número de tokens por sentencia y los verbos de cada sentencia, los cuales están marcados con el tag “VBP” o “VB”.

Estas son solamente algunas de las características incluidas en NLTK y me dejo muchas, muchísimas cosas que se pueden hacer con esta librería y que entran en el campo de la lingüística y el análisis de datos.
Antes de terminar con este articulo, os indico brevemente un proyecto que utilizan NLTK y que cuenta con algunos servicios que pueden utilizarse por medio de peticiones HTTP planas. Dicho proyecto es “text-processing”. Desde la URL http://text-processing.com/demo/ pueden apreciarse 4 ejemplos del procesamiento de texto en lenguaje natural, siendo el más interesante, desde mi punto de vista, el que corresponde con el análisis de sentimientos. Como comentaba antes, dicho servicio se puede invocar directamente por medio de una petición HTTP utilizando el método POST, algo que se puede hacer con cualquier lenguaje de programación e infinidad de herramientas, entre las que se incluyen wget y curl.

>curl -d “text=spain is different” http://text-processing.com/api/sentiment/

{“probability”: {“neg”: 0.38781650900239895, “neutral”: 0.59783687451926548, “pos”: 0.61218349099760105}, “label”: “neutral”}

Como se puede apreciar, el parámetro “text” es el que incluye el texto que la plataforma debe procesar y el resultado es una estructura JSON con el porcentaje que indica qué tan “negativa”, “positiva” o “neutral” es la frase. En este caso, se ha enviado el texto “spain is different” y como se puede apreciar en el resultado, la plataforma determina que el texto es neutral, aunque el porcentaje de “positivismo” es del 61% frente a un 38% de “negatividad”. Al parecer, ni la plataforma, ni NLTK son capaces de distinguir la ironía.

Todo esto puede ser muy interesante para procesos automatizados de ingeniería social que permitan recolectar información de sitios en internet como Twitter o Facebook y determinen la polaridad de los mensajes de ciertas cuentas y además, determinar si las condiciones climáticas en la hora y lugar desde donde se publico el tweet han podido tener algún tipo de influencia.
Esta y otras ideas, se desarrollarán en mayor detalle en próximos artículos.

Un saludo y Happy Hack!
Adastra.

Explotación de Software Parte 34 – Desarrollo de Shellcodes en Linux – Egghunters

octubre 2, 2014 1 comentario

Explicación sobre el funcionamiento y uso de los EggHunters bajo plataformas Linux.
Utilizamos las técnicas descritas por Skape en su paper titulado “Safely Searching Process Virtual Address Space” el cual puede ser encontrado en el siguiente enlace: http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf

skapeEggHunter.nasm:    https://github.com/Adastra-thw/ExploitSerie/blob/master/skapeEggHunter.nasm
shellcodeEggHunter.c:     https://github.com/Adastra-thw/ExploitSerie/blob/master/shellcodeEggHunter.c

Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git


Make a Donation Button

Explotación de Software Parte 33 – Desarrollo de Shellcodes en Linux – Reverse Shell

septiembre 18, 2014 1 comentario

Desarrollo de una ReverseShell en un sistema Linux. Se enseña el uso de la systemcall “socketcall” con las funciones “socket” y “connect”.

reverse.nasm:      https://github.com/Adastra-thw/ExploitSerie/blob/master/reverse.nasm
reverseTest.c:     https://github.com/Adastra-thw/ExploitSerie/blob/master/reverseTest.c


Repositorio GIT de la serie:

https://github.com/Adastra-thw/ExploitSerie.git


Make a Donation Button

A %d blogueros les gusta esto: