Convirtiendo un Proxy en Transparent Proxy

En algunas ocasiones queremos utilizar de manera transparente un servidor proxy, ya sea para saltar un firewall o, simplemente, para enrutar por él determinadas conexiones o las conexiones de determinados usuarios o grupos. Pero no siempre es posible, porque no todos contemplan la posibilidad de Transparent Proxy.

Si utilizamos Privoxy con la opción accept-intercepted-requests, nos sirve para redirigir el tráfico vía firewall. Sin embargo, no podremos redirigir el tráfico https. Además, una vez que activemos la opción accept-intercepted-requests, no podremos utilizarlo manualmente desde la aplicación deseada.

También se puede utilizar un proxy Socks5 creado con ssh. A él no podremos redirigir el tráfico directamente vía firewall.

Si queremos redirigir el tráfico con nuestro firewall a un proxy como los anteriores, podemos utilizar RedSocks. Esta herramienta nos permite crear un proxy transparente http, http-connect, socks4 o socks5 y actuará de túnel con el proxy real. De esta manera, podremos “convertir” un proxy que no es Trasnparent Proxy, en uno, y dirigir a él el tráfico que necesitemos.

Una ventaja adicional es que puede enrutar también el tráfico DNS. Si disponemos un proxy Socks5, que no sea creado con ssh, también podremos redirigir por él el tráfico UDP.

Vamos a ver un ejemplo de uso. Para ello, vamos a enviar todo el tráfico http y https a Privoxy.

Privoxy, en principio, enrutará todo el tráfico a través de TOR. La ventaja de pasar previamente por Privoxy es poder aprovechar los filtrados que proporciona, como publicidad, etc., además de poder decidir desde él qué hacer con cada URL. El resto del tráfico, lo enrutaremos por TOR. Todo esto se realizará siempre que la aplicación/herramienta se haya lanzado con un grupo de usuarios concreto.

Nos va a permitir utilizar estos proxys sólo cuando la aplicación se lance con un determinado grupo, de manera que no vamos a “Torificar” todas las salidas, solo aquellas que nos interesan.

La instalación la vamos a realizar sobre Kali. En el resto de distribuciones basadas en Debian será similar. En ArchLinux, podemos encontrar Redsocks en el AUR o, si hemos añadido a los repositorios BlackArch, lo tendremos ya disponible, dado que forma parte de esta distribución.

Empezamos instalando:

apt-get update && apt-get install redsocks privoxy tor

Una vez instalados los paquetes, vamos a configurarlos. Primero, editamos el fichero /etc/tor/torrc. Necesitaremos mapear los dominios onion, activar el servicio de DNS de TOR y el TProxy. Para ello, al final del archivo añadimos:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

DNSPort 53
TransPort 9040
SocksPort 9050

Con esto tenemos que, el servidor de DNS estará escuchado en localhost:53, los dominios onion los mapeará con una ip aleatoria del rango 10.192.0.0/10 y tendremos el TProxy en el 9040, además del proxy socks habitual en el 9050.

Ahora vamos a editar la configuración de Privoxy y añadir al final de la misma:

forward-socks5 / 127.0.0.1:9050 .
forward localhost/ .
forward 127.*.*.*/ .
forward 192.168.*.*/ .

Bien, ya tenemos Tor y Privoxy configurados, pasemos a RedSocks. Primero sacamos un backup del fichero /etc/redsocks.conf. En él tenemos todas las opciones disponibles, con sus respectivos comentarios. Hecho esto, lo editamos y le añadimos el siguiente contenido:

base {
 log_debug = off;
 log_info = on;
 log = "syslog:daemon";
 daemon = on;
 user = redsocks;
 group = redsocks;
 redirector = iptables;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8218;

ip = 127.0.0.1;
 port = 8118;


 // known types: socks4, socks5, http-connect, http-relay
 type = http-relay;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8318;

ip = 127.0.0.1;
 port = 8118;

type = http-connect;
}

Básicamente, hemos creado un TProxy en el puerto 8218 que apunta al 8118 (Privoxy), de tipo http-relay y otro en el 8312, de tipo http-connect (https), que también apunta a Privoxy.

Ya tenemos la configuración inicial, vamos a arrancar los servicios:

systemctl start tor privoxy redsocks

Ahora vamos a añadir un grupo. Será el que utilicemos para enrutar de manera transparente sus conexiones:

groupadd socksified

Hecho esto, añadimos los usuarios que necesitemos al grupo:

usermod --append --groups socksified USUARIO

Con esto ya tenemos casi todo lo necesario. Toca configurar el firewall. Editamos/creamos el fichero /etc/network/iptables.rules y añadimos lo siguiente:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:REDSOCKS - [0:0]

# Los DNS se los dejamos a TOR
-A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53
-A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53

# El grupo socksified se redirige a REDSOCKS
-A OUTPUT -p tcp -m owner --gid-owner "socksified" -j REDSOCKS

## Redes internas
-A REDSOCKS -d 0.0.0.0/8 -j RETURN

# Usamos parte de 10.0.0.0/8 para onion, entonces:
-A REDSOCKS -d 10.0.0.0/9 -j RETURN
-A REDSOCKS -d 10.128.0.0/10 -j RETURN

-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN

## Redirecciones
# Privoxy, peticiones http
-A REDSOCKS -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8218

#Privoxy, peticiones "Connect" (https)
-A REDSOCKS -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8318

#Direcciones onion
-A REDSOCKS -d 10.192.0.0/10 -p tcp -j REDIRECT --to-ports 9040

COMMIT

Una vez tenemos las reglas, ejecutamos:

iptables-restore < /etc/network/iptables.rules

Y ya solo nos queda probar si todo es correcto:

# No sale por privoxy
curl https://check.torproject.org | grep -i congra
#ahora, como lanzamos curl con el grupo socksified, sí que lo hace
 sg socksified 'curl https://check.torproject.org |grep -i congratulation'

Como puede observarse, este mecanismo nos puede ser muy útil para dirigir el tráfico a uno u otro proxy, dependiendo, por ejemplo, del grupo con el que se lance la aplicación. También podría hacerse por usuarios. Además, podemos añadir tantas secciones Redsocks como necesitemos, permitiéndonos “jugar” bastante con nuestro sistema, para adecuarlo correctamente a nuestras necesidades.

¡¡Espero que os haya gustado !!

OWASP Mobile Security Project

Introducción

OWASP (Open Web Application Security Project) nos provee de una serie de recursos basados sobre todo en guías y herramientas para que nuestros proyectos web sean lo más seguros posibles, tanto desde el punto de vista de desarrollo seguro como de la evaluación de la seguridad de éstos.

Para los desarrolladores ofrece una gran cantidad de recursos para ayudar a llevar a cabo un ciclo de vida de desarrollo de software seguro (S-SDLC, Secure Software Development Life Cycle).

Para los auditores de seguridad ofrece una gran cantidad de recursos como guías y herramientas para evaluar la seguridad de las aplicaciones móviles.

OWASP Objetivos

OWASP Mobile Security Project

Pues bien, tanto los desarrolladores de aplicaciones móviles como los auditores de éstas, pueden aprovecharse también de recursos de este tipo para poder alcanzar el objetivo de la máxima seguridad posible. Para ello OWASP nos propone su Mobile Security Project.

owasp-msp-logo

La imagen anterior es el logotipo oficial del proyecto OWASP Mobile Security Project.

OWASP ProcesosAl igual que en las aplicaciones web, para conseguir el nivel máximo de seguridad posible es imprescindible que todos los factores se alineen; personas, procesos y tecnología.

Recursos OWASP Mobile Security Project

A continuación nombraremos algunos de los recursos disponibles en este proyecto.

Top 10 Mobile Risks: Tal y como podemos encontrar con el Top 10 de riesgos en aplicaciones web, también tenemos este recurso disponible en el proyecto MSP.

Developer Cheat Sheet: Una “chuleta” con consejos para el desarrollador para evitar errores que puedan dar lugar a vulnerabilidades en su aplicación.

App Security Testing Cheat Sheet: Una “chuleta” para el auditor con información interesante para llevar a cabo la evaluación de la seguridad de la aplicación.

Secure Mobile Development: Recurso para el desarrollador que le ayudará durante el ciclo de desarrollo de software seguro (S-SDLC).

Security Tesing Guide: Similar a la Testing Guide para aplicaciones web, también podemos encontrar una guía de test para ayudar al auditor durante sus tareas de evaluación de los controles de seguridad de la aplicación.

Tools: OWASP nos propone un arsenal de herramientas que nos ayudarán tanto para el desarrollo seguro así como para testear los distintos controles de seguridad. Disponibles para las diferentes plataformas (Android, iOS o Windows Phone).

Top 10 Mobile Controls: Definidos conjuntamente por la ENISA y OWASP, nos indica el top 10 de los controles de seguridad a evaluar.

owasp-msp-resources

En próximos artículos en el blog hablaremos de los distintos recursos que acabamos de comentar. Como siempre, esperamos que sean de vuestros interés y esperamos vuestro feedback.

¡Saludos!

@miguel_arroyo76

 

 

Anonimizando la Kali con anonym8

En determinadas ocasiones, necesitamos utilizar nuestra máquina de auditorías de manera anónima. La mayor parte de herramientas cuentan con una opción para configurar un proxy, ya sea http o sock, con lo que puede configurarse para utilizar TOR.

Sin embargo, no todas tienen esta característica, con lo que nos vemos obligados a utilizar herramientas adicionales como proxychains. Además, en muchas ocasiones queremos también comprobar el tráfico UDP, y esto no es posible hacerlo con TOR.

También es posible que queramos suplantar la MAC de la tarjeta de red, cambiar el nombre del host, no tener fugas de DNSs y, una vez terminada la auditoría, dejar todo como estaba, eliminando, por supuesto, los rastros que hayamos dejado en SWAP, cachés, etc.

privacy

Bien, para hacer todo esto, disponemos de un script que nos va a facilitar todo el trabajo. Lo podéis encontrar en https://github.com/HiroshiManRise/anonym8, y es válido para distribuciones basadas en Debian, por ejemplo, Kali.

Read more

Bypasseando firewalls con Shadowsocks

En shaalgunas ocasiones queremos ocultar nuestro tráfico en la red en la que nos encontramos.

Por ejemplo cuando nos conectamos a redes wifi públicas o no fiables. En otras ocasiones, simplemente, queremos eludir un firewall.

Para esto hay diferentes opciones. Una muy utilizada es usar TOR. Sin embargo, es posible que no queramos utilizarla. Sencillamente queremos usar una conexión a Internet y usar nuestro propia red para navegar. Para ello es para lo que nos sirven los proxys.

En nuestra red segura, levantamos el servidor proxy. En los dispositivos cliente, sencillamente nos conectamos a ella. En el caso de los proxys socks5, podemos, además enrutar tráfico UDP (en el caso de TOR, aunque sea un proxy socks5, y el los túneles ssh, no se puede usar el tráfico UDP ).

Read more

Desactivando ASLR en una app iOS con Radare2 – Parte 2

Introducción

Continuamos con la segunda y última parte de este artículo acerca de cómo desactivar ASLR en una aplicación iOS con Radare2. En la primera parte, que podéis consultar aquí, vimos cómo comprobar si un binario de tipo Mach-O tiene activado o no la protección PIE (Position-Independent Executable). PIE permite el uso de Exec Shield o PAX que utilizan técnicas de direccionamiento aleatorio como ASLR (Address Space Layout Randomization).

También vimos que dependiendo de la arquitectura, ARMv7 o ARM64 tendríamos que buscar una cadena u otra. Además vimos que esa cadena a buscar en nuestro binario estaría cerca de la cadena _PAGEZERO, que nos puede servir de referencia.

Manos a la obra

Vamos a “parchear” nuestro binario para modificar unos bytes que nos permitirán desactivar el PIE. Para ello abriremos el binario en modo escritura con Radare2. Para abrir un binario en modo escritura utilizaremos el parámetro -w (write).

Radare2 - Write modeEn la imagen anterior podemos ver que hemos abierto ya no está cifrado (aplicado Clutch en la primera parte), y que tiene habilitado PIE.

Localizamos la cadena a buscar, tal y como hemos visto en la primera parte de este artículo, y pasaremos a explorar el binario para hacer el “parcheo“.

Con la tecla v (visual mode) de Radare2 podemos entrar en modo visual, lo que nos va a permitir a ver las distintas direcciones relativas y sus contenidos. Con la tecla c (cursor mode) activamos el cursor y podremos desplazarnos por los contenidos mostrados.

Una vez localizados los bytes a modificar, 850020 (recordad que varía según la arquitectura), procedemos a activar el modo insertar, para lo que pulsaremos la tecla i en Radare2.

Radare2 - Insert modeEn este modo de inserción, podremos modificar los bytes, dejándolos como vemos en la siguiente imagen.

Radare2 - Insert mode

Salimos de Radare2, los cambios se guardarán automáticamente porque hemos “escrito” directamente en el binario.

Comprobación

Comprobamos nuevamente con la herramienta otool si PIE sigue activado o no.

otool - iOS PIE

Podemos comprobar como efectivamente en el binario cuyo nombre acaba en _NoPIE hemos conseguido deshabilitar PIE.

Para finalizar, con otra herramienta del framework de Radare2, como es radiff2, podemos buscar diferencias entre dos binarios. Si lo aplicamos a los dos binarios con los que hemos estado trabajando, uno con PIE activado y el otro con el PIE desactivado con Radare2, podemos ver la diferencia en el byte modificado.

A continuación se puede ver un ejemplo de radiff2 con estos archivos.

Radiff2 - PIE

Hasta aquí este artículo que, como siempre, esperemos haya sido de vuestro interés. Todos los comentarios y sugerencias serán bienvenidos. Gracias de antemano.

¡Hasta pronto!

Miguel A. Arroyo – @miguel_arroyo76

Introducción al SDR – Radar pasivo de Aviones

Hace ya un tiempo, en Mayo de este año, publiqué un artículo de iniciación al mundo SDR. Con un simple TDT y un chip adecuado podíamos escanear nuestro espectro radioeléctrico y observar-escuchar infinidad de señales. Recuerdo que en mis primeras pruebas, sin apenas saber que hacía, pude “navegar” en unas frecuencias bastante comunes (30-33mhz creo que era) y escuchar una conversación telefónica. Debido al sitio en el que me encontraba y la “enorme potencia” de mi SDR USB, solo podía ser un familiar mío. El otro lado de la comunicación igualmente era también familiar de un servidor.

Esto podría ser la historia de cualquier persona que esté en el momento preciso en el sitio adecuado con un receptor SDR (recordar que esto no emite, solo recibe por tanto no es intrusivo), y no una Poc que realicé con unos viejos teléfonos inalámbricos analógicos sin DECT(tecnología digital que usan los no tan actuales teléfonos inalámbricos, para que nos entendamos). La idea es sencilla: un receptor TDT con chip RTL, sdr-sharp y zadig y a situarte en frecuencias comunes y ya tienes un mini-kit para husmear el espectro radioeléctrico.

Como ya comenté en el artículo inicial, Introducción al SDR, podemos seguir las instrucciones que refiero en el artículo para jugar con esta herramienta, que si la evolucionamos (construirnos una antena más sensible, por ejemplo) podemos obtener resultados muy interesantes.

logosdr

Read more

Desactivando ASLR en una app iOS con Radare2 – Parte 1

Introducción

En este artículo explicaremos cómo podemos desactivar ASLR (Address Space Layout Randomization) en una app iOS. Ya vimos en un artículo anterior cómo podemos comprobar con la herramienta otool si una aplicación iOS tiene activada esta protección o no. Podéis leer el artículo en este enlace.

ASLR, PIE, PAX y Exec Shield

En realidad lo que se comprueba es si el binario ha sido compilado con PIE (Position-Independent Executable). Los binarios de tipo PIE permiten en algunas distribuciones GNU-Linux orientadas a seguridad a hacer uso de PAX y Exec Shield, que son unas implementaciones realizadas a nivel de kernel. Estas implementaciones aumentan la seguridad del sistema, permitiendo por ejemplo el direccionamiento aleatorio de los objetos del programa en memoria, dificultando así posibles explotaciones de vulnerabilidades de tipo buffer overflow, entre otros. Aquí es donde ASLR entra en juego.

La siguiente imagen corresponde a la versión PAX de Tux. 😉

170px-pax_tux

Para evitar confusiones, aunque la finalidad es deshabilitar el direccionamiento aleatorio (ASLR), nos referiremos a PIE, ya que así es como se refleja el flag en el binario que vayamos a analizar. De hecho, con otool el resultado del análisis se muestra de la siguiente forma.

Comprobar PIE con otool

Se puede observar a la derecha de la imagen que el binario analizado muestra el flag PIE activado.

Radare2

Este magnífico framework de ingeniería inversa creado por Sergi Álvarez (@pancake), que surgió como una herramienta de forense, actuando como un editor hexadecimal capaz de abrir archivos de disco. A día de hoy cuenta con un interesante arsenal de utilidades que permiten analizar binario, desensamblar código, depurar programas o hacer depuración remota a través de servidores gdb.

Podéis encontrar toda la información en el siguiente enlace: https://github.com/radare/radare2

A título personal decir que, aunque la curva de aprendizaje es alta, es un framework que merece la pena conocer, estudiar y usar, sobre todo si te dedicas a ingeniería inversa, o estás pensando en dedicarte. Yo soy un auténtico novato de esta herramienta, pero lo poco que he aprendido hasta ahora quería compartirlo vosotros, y qué mejor manera que hacerlo de manera práctica con este ejemplo que estamos viendo.

¿Qué buscamos exactamente?

Después de analizar varios binarios de aplicaciones iOS de diferentes arquitecturas (ARMv7 y ARM64), he llegado a la conclusión que el volcado en hexadecimal que hay que buscar con Radare2 son los siguientes:

Hex bytes: 858021 para la arquitectura ARMv7

Después de abrir Radare2 con el binario a analizar (thin_binary), para lo que usaremos la sintaxis “r2 thin_binary“, haremos una búsqueda (seek) con el comando “s“, especificando que estamos buscando un volcado en hexadecimal, de ahí la “/x” y a continuación lo que queremos buscar (858021).

PIE hexdump in Radare2

Si estamos analizando una app de iOS de ARM64, los hex bytes a buscar serían 850020.

PIE flag in Radare2

Observad que en ambos casos, cuando encuentra el patrón buscado, es decir hace 1 hit, Radare2 automáticamente nos posiciona en el offset donde los ha encontrado (0x00000018, en el último ejemplo). Finalmente mostramos un volcado de 16 bytes con el comando “px” donde podemos ver que se muestran los hex bytes que estábamos localizando.

También podemos localizar fácilmente el offset donde encontrar estos hex bytes buscando la sección / segmento _PAGEZERO, que suele estar siempre muy cerca de estos bytes. Pero sin lugar a duda, lo más certero es utilizar el comando “s/x [hexbytes_armx]” para localizarlo y ubicarnos.

Hasta aquí esta primera parte de este artículo. En el siguiente artículo veremos qué bytes hay que modificar, cómo abrir el binario en Radare2 en modo escritura, cómo buscar diferencias enter el binario original y el parcheado con rabin2 y finalmente comprobar nuevamente con otool que hemos conseguido deshabilitar el flag de PIE.

Como siempre, espero que sea de vuestro interés y nos vemos pronto en la segunda parte de este artículo.

PD: Cualquier comentario, consulta y recomendación será bienvenido, sobre todo si es de Radare2, donde me tenéis que disculpar, pero soy muy novato. Eso sí, con muchas ganas de seguir aprendiendo y compartiendo. 🙂

 

Cazando Pokemon

Creo que no es necesario presentar ni aclarar que significa, actualmente, “cazar Pokemon” pero por si acaso voy a explicarlo brevemente para despistados.

Pokemon GO es una aplicación que se ha vuelto viral, utilizada para “cazar” pokemons utilizando un mapa de situación del lugar dónde te encuentres, con el estilo típico de pokemon pero totalmente ajustado a la realidad. Además utiliza la cámara para que cuando tengas un pokemon cerca, esta sirva para saber en que lugar de tu emplazamiento está.

La APP es gratuita en su descarga(importante) y cualquiera puede registrarse y patearse su ciudad en busca de los pokemon. No obstante, y ya os habréis dado cuenta, la app es gratis a costa de cierta información.

Para justificar nuestro parecer, en hacking-etico.com hemos hecho un breve análisis estático de esta APK (no de la app fake que está pululando por ahí que tiene sorpresa)para ver de qué tira esta afamada aplicación y a modo solamente educativo.

pok Read more

La seguridad actual de la autenticación inalámbrica PSK (III)

En esta tercera entrega, llega el momento de extraer nuestras propias conclusiones sobre la seguridad actual de la autenticación PSK. Resulta que con la ejecución de Pyrit en una instancia g2.8xlarge del Cloud de Amazon, se obtiene un rendimiento interesante en el cómputo de claves:

011 - pyrit benchmark AMAZON

Tal y como se puede observar en la ilustración anterior, se cuenta con un cálculo de 115.265 claves/segundo, un incremento más que considerable en referencia a las 836 claves/s iniciales de mi máquina virtual.

Pero esto no termina aquí. Aún podemos mejorar la capcidad de cómputo y de una forma más que considerable. Existen dos opciones:

  • Ejecución de Pyrit en modo distribuido.
  • Utilizar tablas PMK precomputadas.

Una vez más, debido a la magnitud que debe respetar el artículo, es necesario focalizar nuestros esfuerzos en una de las opciones anteriores y, en este caso, se ha optado por mostrar la velocidad extrema que se consigue con las tablas PMK precomputadas.

Read more

La seguridad actual de la autenticación inalámbrica PSK (II)

Este segundo artículo, de carácter más práctico, define el conjunto de herramientas a utilizar y además, se ha esquematizado para que sea un pequeño tutorial que nos permita efectuar la instalación de las mismas en las máquinas del Cloud.

Para los lectores que no desean conocer en profundidad los detalles técnicos, se recomienda obviar esta parte y saltar directamente a la tercera.

Empecemos.

Primeramente, necesitamos localizar un herramienta que sea capaz de utilizar toda la potencia de cómputo de nuestro hardware con el fin de cumplir con nuestro objetivo, que es calcular el mayor número posible de claves PSK por segundo, tal y como hemos comentado en la primera entrega. Para lograr la tarea, se propone la utilización de Pyrit.

Pyrit

Es una herramienta muy potente que permite realizar ataques a la autenticación WPA/WPA2-PSK. Destaca por tener la propiedad, a diferencia de otras herramientas, de utilizar la potencia extra de las GPUs para acelerar de forma extraordinaria el proceso de cómputo de las claves PSK. Se encuentra escrita mayormente en Python, pero también cuenta con algunos módulos escritos en C (cpyrit-cuda, cpyrit-opencl) que se encargan de permitir el uso de las tarjetas gráficas. Además, entre otras funcionalidades, nos brinda la posibilidad de crear tablas de claves PSK precomputadas.

Por otro lado, necesitamos un software intermediario que permita la interacción con las tarjetas gráficas. En este caso, se trabajará con CUDA Toolkit.

CUDA

CUDA son las siglas de Compute Unified Device Architecture (en Castellano, Arquitectura Unificada de Dispositivos de Cómputo) y hace referencia a un framework desarrollado por NVIDIA que permite a los programadores de C y C++ aprovechar la potencia del procesamiento paralelo de sus tarjetas gráficas, con el fin de proporcionar un incremento del rendimiento del sistema.

Con las dos herramientas anteriores y conjuntamente con el Cloud, ya tenemos todos los componentes necesarios. Sólo nos queda realizar la instalación de este software a una máquina remota y en el caso del panel de NIMBIX, la secuencia de pasos a realizar es la siguiente:

Read more