martes, 30 de abril de 2013

DEFENSA OFENSIVA POR OSCURIDAD-PORT KNOCKING II



Antes de comenzar, GRACIAS a todos por la acogida,los "likes", "tweets", los comentarios y las críticas .. y como el público manda y parece ser que la "escritura" ese día no estaba como debía .. bueno, hoy seremos más ingenieros de seguridad que "colegas" ;) ... (aunque mi toque no lo pierdo . :P )

En esta segunda entrega vamos a ver que se puede hacer si quisiéramos atacar una defensa perimetral donde existi un port-knocking.. o visto de otro modo, cuales son las vulnerabilidades de esta "defensa"?

Exsiten voces que claramente abogan por la revisión completa de los mecanismos usados en Port-Knocking para la autenticación debido a los problema de (in)seguridad que conllevan y hace que sea vulnerable a lo que se conoce hoy y vamos a ver. NAT-Knocking

Pero recordamos rápidamente cual es la secuencia de autenticación.

1-El cliente comienza a hacer conexiones a los puertos, con el fin de generar entradas en el registro del servidor.

2-El servidor está analizando ese registro, y cuando detecta una secuencia válida se calcula el puerto de servicio (puerto 22 pongo siempre de ejmplo...) y la dirección del cliente

3-Se modifica la política de conexión con el fin de abrir el puerto que ha solicitada el cliente .

Desde el punto de vista del cliente, los puertos que tienne que hacer el “golpeo” "se puede calcular como:

p1 = f1 (puerto abrir, dirección del cliente; :::) (1)
p2 = f2 (puerto abrir, dirección del cliente; :::), (2)

etc. . , Donde p1 es el primer puerto utilizado en la secuencia de “golpeo”, P2 es la segunda, etc. .

Desde el punto de vista del servidor, todos los parámetros del servidor “golpeando” el puerto se tienen que tener en cuenta en la modificación de las políticas del cortafuegos que pueden expresarse como:

Puertos_abierto = f3 (p1, p2; :::; pn), (3)

IP_permitida f4 = (p1, p2; :::; pn), (4)

y así sucesivamente....



                                        Mecanismo de Autenticación Port-Knocking

NAT-Knocking<Burlando al Firewall>

Al compartir la misma dirección de red nos podemos encontrar con un serio problema de seguridad cuando estamos “Nateando”.

De nuevo ( si, soy muy pesado si … pero no se te olvida, ya verás ..) y como indico y repito , el port-knocking se basa en la idea de la apertura de puertos en el cortafuegos sólo para los clientes que han proporcionado la contraseña correcta a través de los “golpes” correctos contra el servidor. Para indentificar quien el el cliente al que se le debe abrir o no, el port-Knoking recae sobre la dirección de red del cliente.

Pero sin embargo, esto plantea la cuestión de lo que podría suceder si dos clientes comparten la misma dirección .. Por ejemplo “Nateando” (NAT)

Como se muestra más adelante en la Figura 2, cuando los paquetes desde el interior de la NAT salen de la red privada todos ellos comparten la misma dirección de origen (la dirección pública del NAT) y los paquetes no se pueden utilizar para identificar la fuente que existe detrás del NAT SIN PODER ACCEDER A LAS “TABLAS DE NATEO DEL ROUTER”

Como el port-knocking se basa en la dirección de red para abrir los puertos necesarios para los clientes de “confianza”, no puede diferenciar entre todos los clientes detrás de la misma dispositivo NAT. Como resultado de ello, cuando un cliente en una red que utiliza el mismo NAT se identifica ante el servidor “tocando” el puerto obtiene acceso total al puerto de servicio, que le ha dado por utiizar el mismo dispositivo para hacer NAT (y, en consecuencia, comparte la misma dirección de red pública).

Por otra parte, cuando el usuario es de confianza "golpeando" el cortafuegos no hay
necesidad de que un atacante potencial tenga que "ver" la secuencia de autenticación, sólo
hay que esperar hasta que el puerto de servicio está abierto para tener acceso a ella sin saber la secuencia de autenticación. Un ejemplo puede verse en la Tabla 1: Cliente
172.16.8.102 es el usuario autorizado que autentifica utilizando enfleche portk con

Tabla 1. Captura de red del ataque NAT-Knocking

No. Fuente Destino Info Protocolo

1 172.16.8.102 163.117.149.93 TCP 32987! 7682 [SYN]
2 172.16.8.102 163.117.149.93 TCP 32988! 7697 [SYN]
3 172.16.8.102 163.117.149.93 TCP 32989! 7810 [SYN]
4 172.16.8.102 163.117.149.93 TCP 32990! 7800 [SYN]
5 172.16.8.102 163.117.149.93 TCP 32991! 7811 [SYN]
6 172.16.8.102 163.117.149.93 TCP 32992! 7809 [SYN]
7 172.16.8.102 163.117.149.93 TCP 32993! 7673 [SYN]
8 172.16.8.102 163.117.149.93 TCP 32994! 7686 [SYN]
9 172.16.8.102 163.117.149.93 TCP 32995! 7603 [SYN]
10 172.16.8.102 163.117.149.93 TCP 32996! 7682 [SYN]
11 172.16.8.102 163.117.149.93 TCP 32997! 7602 [SYN]
12 172.16.8.102 163.117.149.93 TCP 32998! 7887 [SYN]
13 172.16.8.102 163.117.149.93 TCP 32999! 7699 [SYN]
14 172.16.8.102 163.117.149.93 TCP 33000! 7808 [SYN]
15 172.16.8.102 163.117.149.93 TCP 33001! 7629 [SYN]
16 172.16.8.102 163.117.149.93 TCP 33002! 7602 [SYN]
17 172.16.8.102 163.117.149.93 TCP 33003! 7686 [SYN]
18 172.16.8.102 163.117.149.93 TCP 33004! 7663 [SYN]
19 172.16.8.102 163.117.149.93 TCP 33005! 7655 [SYN]
20 172.16.8.102 163.117.149.93 TCP 33006! 7692 [SYN]
21 172.16.8.102 163.117.149.93 TCP 33007! 7992 [SYN]
22 172.16.8.102 163.117.149.93 TCP 33008! 7839 [SYN]
23 172.16.8.102 163.117.149.93 TCP 33009! 7637 [SYN]
24 172.16.8.102 163.117.149.93 TCP 33010! 7990 [SYN]
25 172.16.8.102 163.117.149.93 TCP 33011! 80 [SYN]
26 163.117.149.93 172.16.8.102 TCP 80! 33011 [SYN, ACK]
27 172.16.8.102 163.117.149.93 TCP 33011! 80 [ACK]
28 172.16.8.102 163.117.149.93 HTTP GET / HTTP/1.1 info.php
29 163.117.149.93 172.16.8.102 TCP 80! 33011 [ACK]
30 163.117.149.93 172.16.8.102 HTTP HTTP/1.1 200 OK
31 172.16.8.100 163.117.149.93 TCP 1196! 80 [SYN]
32 163.117.149.93 172.16.8.100 TCP 80! 1196 [SYN, ACK]
33 172.16.8.100 163.117.149.93 TCP 1196! 80 [ACK]
34 172.16.8.100 163.117.149.93 HTTP GET / HTTP/1.1 info.php
35 163.117.149.93 172.16.8.100 TCP 80! 1196 [ACK]



Podemos ver en la figura 2 como dos hosts A y B comparten la misma IP pública
abordar, por lo que tienen que utilizar NAT para acceder a otras redes. El Paquete 1 (creado por A) se traduce en el paquete 2, donde la dirección de origen y el puerto han cambiado a la dirección pública y un puerto libre en el dispositivo NAT. El mismo proceso es realizado con el paquete 3 de B. Como se puede ver, desde el exterior de la NAT es
imposible determinar qué paquete proviene de qué origen usando esa dirección ( source addresses)






Los Hosts A y B que comparten la misma red con la dirección del servidor 163.117.149.93 Y VEMOS que solicita la apertura del puerto 80. Podemos ver todos los “golpes”(knocks”) enviados al servidor ( mirar del 1 a 24 ) y cómo, después de que el cliente es capaz de conectarse al puerto 80 procede a establecer con la comunicación normal ( del 25 al 30 )

Sin embargo, la dirección 172.16.8.102 cliente está “NATEANDO”, y otro cliente en el mismo red (172.16.8.100) puede conectarse PERFECTAMENTE SIN NECESIDAD de hacer ese golpeo de puertos (del 31 al 35).

Espero que os haya parecido interesante, porque todavía quedan más....

Un saludo

Live Free Or Die Hacking
5 0verl0ad Labs: abril 2013 Antes de comenzar, GRACIAS a todos por la acogida,los "likes", "tweets", los ...

miércoles, 24 de abril de 2013

Diario de mi pequeño Raspberry Pi -- Segunda cita

  Segunda entrada dedicada al lujurioso y sensual Raspberry Pi en la que continuaremos configurando el aparatejo.



  Lo primero que haremos será cambiar la IP del dispositivo para que no sea asignada por dhcp, sino que sea fija o estática. Para ello vamos (como root) hasta /etc/network/ y modificamos el fichero interfaces:


De dicho archivo tenemos que comentar la linea que hace referencia a la interfaz eth0 y el dhcp:
#iface eth0 inet dhcp
Y a continuación añadir lo siguiente:
iface eth0 inet static
address 192.168.0.108
netmask 255.255.255.0
gateway 192.168.0.1
donde la ip estática del dispositivo (en mi caso) será 192.168.0.108, la mascará sera 255.255.255.0 y la puerta de enlace 192.168.0.1.
  Con esto nos aseguramos que siempre tenga la misma dirección IP y podemos conectar cómodamente con él, tanto dentro de la misma red como desde fuera (para esto último hay que tocar opciones del router).

  En el siguiente paso crearemos un usuario nuevo distinto del que lleva por defecto para evitar, por ejemplo, intentos de conexión al servidor ssh con dicho usuario (pi).

Para ello como root:
adduser tux

Y este será nuestro usuario por defecto a partir de ahora. Ahora lo añadiremos al grupo ssh con la idea de configurar el servidor para que solo admita conexiones a usuarios de dicho grupo:
gpasswd -a tux ssh


  A continuación configuraremos el servidor ssh del Raspberry Pi puesto que la configuración inicial no es la ejemplar. En esta entrada daré solo unos tips básicos, pero si queréis unos posts más completos sobre el tema, en Flu Project tienen una serie dedicada a tal fin ;) .

  Para configurar el servidor editamos el archivo:
vim /etc/ssh/sshd_config
  Como he comentado arriba existen múltiples opciones a la hora de configurar/asegurar, pero estas son las que para mi son básicas:
  • Cambiar el puerto: cambiamos la opción Port 22 por Port 33222 evitando así muchos ataques.
  • Deshabilitar el acceso como root: la opción PermitRootLogin tiene que tener como valor no.
  • Permitir conexiones solo a determinados usuarios: Añadimos AllowGroups ssh, permitiendo solo el acceso a los usuarios que pertenezcan a tal grupo. Por este motivo cuando hemos creado antes el usuario lo hemos añadido al grupo ssh.
El resto de opciones las he dejado por defecto, aunque existen muchas mas opciones a configurar a gusto de cada usuario ;) .

  Por último último buscaba un panel administrativo vía web que me permitiera tener todo el sistema bajo control de forma gráfica (aunque al final apenas lo uso pues la terminal es mucho mas divertida xD). En este campo, leyendo un poco (junto con algunas recomendaciones por Twitter) encontré en Be Linux My Friend una entrada sobre Webmin, así que me puse manos a la obra.

Lo primero es importar la clave para que APT no empiece a "chillar":
wget http://www.webmin.com/jcameron-key.asc
sudo apt-key add jcameron-key.asc
rm jcameron-key.asc
y a continuación añadir al sources.list el repositorio de Webmin:
deb http://download.webmin.com/download/repository sarge contrib
Con la entrada añadida basta con un update de apt e instalar la aplicación:
apt-get update && apt-get install webmin
Ahora ya tenemos la aplicación instalada, basta con ir a nuestro navegador y conectar (con la ip que anteriormente le hemos asignado al Raspberry Pi) al puerto 10000:



  En posteriores entradas ya empezaremos a hacer cosas más interesantes (si tengo tiempo para probarlas xD), ésta aún formaba parte de la configuración básica de dispositivo.

Nos leemos en breve ;)

5 0verl0ad Labs: abril 2013   Segunda entrada dedicada al lujurioso y sensual Raspberry Pi en la que continuaremos configurand...

sábado, 20 de abril de 2013

Diario de mi pequeño Raspberry Pi -- Conociéndonos


  Desde hace unos días tengo en mis manos un pequeño y sensual juguete llamado Raspberry Pi, con lo que, durante una serie de entradas contaré las atrocidades mis aventuras con susodicho aparatejo.



  Una vez lo extraje de su "discreta" caja rosa tenia una apariencia como la siguiente:


  Si alguien quiere conocer mejor las especificaciones del bicho en la página de Raspberry Pi hay un bonito esquema:


  Una vez liberado de su colorida caja necesitamos un cable micro USB como alimentación (número 5 del esquema) e instalar un sistema operativo en una SD (número 1 en el esquema). Como sistemas operativos tenemos varias alternativas, ya sea Debian (Raspbian), Arch Linux ARMRISC OS u otras que no recuerdo en estos momentos. 

  Mi opción en este campo fue:



 Para su instalación, siguiendo una guía que encontré en elinux.org me decanté por utilizar Win32DiskImage desde Windows sintiéndome muy sucio pues no me funciona el lector de tarjetas en GNU/Linux, algún día arreglaré...

   La utilización de Win32DiskImage es trivial, basta con descargar y ejecutar la aplicación para obtener una interfaz como la siguiente:


  Una vez en ella basta con seleccionar la iso deseada, en mi caso Raspbian, seleccionar la letra de la tarjeta SD y pulsar en Write, una vez acabe tendremos Debian instalado en la SD.


 Con el sistema operativo ya en la SD toca colocarla en el aparatejo y conectarlo a la luz. Puesto que en mi caso no tenia monitor al que enchufarlo, lo conecté al router por el cable RJ-45 esperando que el DHCP hiciera su trabajo asignándole una IP y que estuviera activado el servidor SSH por defecto.
  Para encontrarlo opté por utilizar nmap para ver que equipos en mi red tenían el puerto 22 (SSH) habilitado:
nmap 192.168.0.1/24 -p22
  Una vez hallada su IP (a partir de ahora 192.168.0.111) me encontré con el siguiente problema, ¿cuales son las credenciales de acceso al SSH?
  Googleando un poco encontré en los foros de Raspberry Pi lo siguiente:
Default login Username: pi Password: raspberry
  Con lo que ya lo tenia todo, tanto el usuario → pi , como la contraseña → raspberry y conseguí acceder a sus intimidades.

  Una vez hemos conectado con Raspbian, lo primero que tendriamos que hacer son unas configuraciones básicas, para ésta tarea tenemos dos opciones, la primera es hacerlo todo manualmente (como yo hice la primera vez :D ) o la segunda, utilizando el genial menú de raspi-config (que yo ignoraba por aquel entonces):
sudo raspi-config
  Una vez ejecutado tendremos un menú como el que sigue:


 Desde éste podremos cambiar cosas como el nombre del equipo, la contraseña del usuario pi o extender la partición root, entre otros. La última opción comentada, es importante si no queremos quedarnos sin espacio en la partición / cuando empecemos a instalar cosas.

  Por ultimo, antes de cerrar la entrada, actualizamos el sistema con:
su root
apt-get update && apt-get upgrade



 En próximas entradas configuraremos algo mas el Raspberry Pi y empezaremos a experimentar con él, nos leemos en breve ;)


5 0verl0ad Labs: abril 2013   Desde hace unos días tengo en mis manos un pequeño  y sensual  juguete llamado  Raspberry Pi , co...

martes, 16 de abril de 2013

DEFENSA OFENSIVA POR OSCURIDAD -PORT KNOCKING I




Para la definición de Port knocking prefiero la de Wikipedia por sencilla y según nuestra amiga ..

El golpeo de puertos (del inglés port knocking) es un mecanismo para abrir puertos externamente en un firewall mediante una secuencia preestablecida de intentos de conexión a puertos que se encuentran cerrados. Una vez que el firewall recibe una secuencia de conexión correcta, sus reglas son modificadas para permitir al host que realizó los intentos conectarse a un puerto específico.

El propósito principal? 

Evitar el scaneo por parte “usuarios” malintenciotenados ..
Para que?  Buscar vulnerabilidades? Of course ¡!

 “Normalmente” ( así debería ser siempre, pero veremos que no) los puertos donde se dan los servicios se muestran cerrados como una técnica típica de defensa perimetral ya que los mismos servicios expuestos solo se abrirán ante un Port Knocking correcto.. y esto ocurrirá gracias a la implementación en este servicio para que revise el log del firewall … Si claro!! para que detecte, como es lógico, esta secuencia de intentos de conexión.

Voy a hacer hincapié en lo que yo, diariamente, tengo junto a mis compañeros ..  y supongo que muchos de los que me estén leyendo sabrán a que me refiero..

El mayor uso del Port-Knocking  ?? No adivináis por donde los “malos” o lo bueno, según se mire, nos intentan entrar ..?

Venga ya… ¡!  Puerto 22 ? Suena bien verdad? ;), Pues Secure Shell (SSH) es quien se lleva la palma .. y aquí tenemos algo muy parecido a  un handshake secreto

Existen tantas maneras … podemos es tener un proceso examinando paquetes con alguna interfaz sniffando paquetes pero TCP  siempre Open, of course ¡!

Realmente la idea es que el cliente tenga una aplicación que ejecute el Knocking  antes de acceder al server de manera normal. 

Un servicio se encuentra escuchando en la máquina donde está el firewall .. con programa que ejecute comandos de ping o te creas un generador de hash.

Si un usuario ejecuta una secuencia errónea de PK pues el puerto simplemente estará cerrado .. y es el que debería estar abierto .. es sencillo realmente .. 

Pero, como ya explicaré, esto no es tan “efectivo” como pueda parecer … ;)
Pero…Como funciona ?

Port knocking 4 Pasos



1 El cliente no puede conectarse a una aplicación que se encuentra escuchando en el puerto n.





2 | (1,2,3,4) -El cliente intenta conectarse a un conjunto predefinido de puertos en secuencia, enviando ciertos paquetes. El cliente tiene conocimiento previo del servicio de golpeo de puertos y su configuración, pero no recibe ninguna respuesta durante esta fase ya que las reglas del firewall no lo permiten.





3 El servicio de port knocking intercepta los intentos de conexión y los decodifica para verificar un golpeo auténtico. El servidor realiza tareas específicas basadas en el golpeo de puertos, como abrir

                                      

               4 El cliente se conecta al puerto n recientemente abierto.


Por ejemplo no es necesario que el Knocking venga de intentos de conexión o el Knocking puede ser encapsulado en un payload y que este se envíe al puerto cerrado .. Existen diferentes maneras, pero lo importante es la comprensión del  “Golpeo de puertos”.Quiero comentar que esto es la idea general pero que este comportamiento puede ser cambiado “al gusto”..


HERRAMIENTAS

knockd es una herramienta de port-knocking de primera generación, que funciona enviando una secuencia ordenada de intentos de conexión a puertos TCP o UDP pero tenemos  posibilidad de que la secuencia de puertos sea interceptada por un atacante, siendo por tanto superado este primer filtro con facilidad.. poco seguro ..  

Por lo tanto fwknop, que implementa Single Packet Authorization (SPA), conocido como técnica de port-knocking de paquete único(se ampliará,,,)

En este caso, toda la secuencia -o contraseña- se encuentra dentro de un único paquete cifrado, evitando así la captura de los datos y no teniendo el problema de pérdida parcial de paquetes.

Otras funcionalidades de fwknop aumentan la seguridad, como la inclusión de la IP de origen dentro del paquete cifrado, lo que dificulta un ataque Man in the Middle, así como el soporte para usar criptografía de clave pública.
Se puede encontrar muy buena información sobre fwknop y el funcionamiento de SPA en la página oficial de fwknop.

Asi que, creo que se impone implementarlo no? Vamos allá

Implementando (SPA)con “fwknop”..Al lío

 FireWall KNock OPerator a.k.a fwknop es una herramienta más avanzada que knockd, y  utiliza la técnica de port-knocking de paquete único (SPA) frente al envío de secuencias de paquetes que ya hemos visto. En este caso el cliente y el servidor de port-knocking van en paquetes separados.

$ aptitude install fwknop-server fwknop-client

Durante la instalación del servidor nos pide una serie de datos de configuración, como la interfaz de red donde debe escuchar fknopd en modo promiscuo y la clave para cifrado y descifrado del paquete SPA recibido. Además nos consulta por defecto si queremos proteger el puerto ssh, realizando la configuración necesaria. A través de los ficheros de configuración también podemos establecer estos parámetros, como veremos a continuación.

El fichero /etc/fwknop/fwknop.conf contiene una extensa relación de parámetros sobre el funcionamiento de fwknop, principalmente relacionados con el cortafuegos. De este fichero editamos el interfaz de red donde escucha fwknopd (en nuestro caso lo) y si nos parece oportuno el puerto hacia el que se envía el paquete SPA (por defecto UDP 62201).









Los parámetros susceptibles de modificar son los siguientes:

OPEN_PORTS, que define el puerto y el tipo de conexión a proteger a través de port-knocking.

FW_ACCESS_TIMEOUT, que define el tiempo máximo establecido desde la recepción del paquete correcto hasta que se produce la conexión ssh.
KEY, que define la contraseña de cifrado y descifrado del paquete SPA recibido (por defecto fwknop usa el algoritmo Rijndael).

En este ejemplo vamos a utilizar cifrado simétrico, pero es interesante mencionar que fwknop soporta el uso de criptografía de clave pública (de hecho es la opción recomendada por la documentación oficial) de forma similar a SSH. Una vez generado el par de claves con gpg, especificamos los datos necesarios en el fichero anterior, de acuerdo con los parámetros GPG_HOME_DIR, GPG_DECRYPT_ID, GPG_DECRYPT_PW y GPG_REMOTE_ID. Por otra parte, el cliente fwknop (cuyo uso veremos más adelante) debería ejecutarse añadiendo las opciones --gpg-recip y --gpg-sign.

Reiniciamos el servidor fwknopd y comprobamos qué procesos están ejecutándose:














Además del servidor fwknopd, vemos los procesos correspondientes a knoptm (daemon responsable de eliminar reglas de iptables) y a kfnopwatchd (daemon que monitoriza el buen funcionamiento de fwknop).

Para monitorizar el servidor fwknop y ver los envíos de paquetes SPA se puede consultar el syslog del sistema.
# tail -f /var/log/syslog | grep fwknop

Una vez en funcionamiento el servidor fwknopd, acudimos al cliente (fwknop) para enviar un paquete SPA a localhost y comprobar su funcionamiento.







Como podemos ver, hemos enviado desde nuestra ip de origen (-a localhost) un paquete SPA al puerto udp/62201 de la ip donde escucha el servidor fwknopd (-D 127.0.0.1).

 Este paquete tiene un tamaño de 182 bytes y ha sido cifrado previamente a su envío con una clave simétrica que nos ha sido solicitada (Encryption Key: 12345678) y que debe coincidir con la definida en el fichero /etc/fwknop/access.conf.
Ahora comprobamos qué ha recibido el servidor, consultando el fichero de log.





fwknopd ha recibido correctamente el paquete SPA, lo ha descifrado y lo ha reconocido como válido, añadiendo a iptables una nueva regla que permite conexiones al puerto tcp/22 durante 30 segundos. Al transcurrir este tiempo, la regla es eliminada a través de fnoptm y regresamos a la situación inicial.

Por último, para el que quiera profundizar en los aspectos más criptográficos de la herramienta, solamente decir que fwknop construye el paquete SPA concatenando los datos que muestra el cliente (Packet fields), codificando en Base64 y cifrando con el algoritmo Rijndael, dando lugar a los 182 bytes finales.

Para más información consultar el código fuente de fwknop y fwknopd (scripts en perl), los módulos MIME::Base64, Crypt::CBC y Crypt::Rijndael (también disponibles vía comando perldoc), y la documentación oficial sobre SPA que describe con detalle la estructura del paquete envíado.


Pero no he terminado Mi Opinión

1-Si  descubro la forma de acceder a la puerta se acabó el juego señores .. esta capa desaparece y el servicio queda protegido exclusivamente con la seguridad que existiese debajo del Port-Knocking ..

 2- Ataques MitM.

* En el caso de knockd : Capturar su secuencia de puertos es rápida, de hecho es INMEDITA.
fwknopd  va cifrada, solucionada .., el uso de este único paquete SPA elimina los errores en la     recepción de la secuencia de puertos

 Que a nadie se le ocurra tener Port-Knocking como única defensa  porque no es viable...

Pero yo me pregunto .. Incluir en una Tool “malvada” el Knocking? Puede ser curioso verdad?

Lo veremos en la siguiente .. Si es que vosotros quereis. No seais muy malos, que se que esto es un examen ;)

Live Free or Die Hacking

5 0verl0ad Labs: abril 2013 Para la definición de Port knocking prefiero la de Wikipedia por sencilla y según nuestra amig...

viernes, 12 de abril de 2013

Aplicaciones Android - DroidWall


  DroidWall dota a nuestros dispositivos Android de un eficiente cortafuegos (es necesario ser root). Podemos encontrarlo en Google Play y está disponible para la inmensa mayoría de versiones del sistema operativo del robot, es decir, a partir de la 1.5 podremos tenerlo en nuestros terminales.

  Para descargarlo basta con dirigirnos a:
https://play.google.com/store/apps/details?id=com.googlecode.droidwall.free&hl=es


 Una vez instalado, al ejecutarlo veremos que se listan las aplicaciones de nuestro dispositivo.


  Debido a que la aplicación funciona con una lista blanca, tenemos que seleccionar las aplicaciones que deseamos que accedan a la red.

  DroidWall separa el acceso a una red mediante wifi y mediante 3G, por tanto en función del trafico que queramos permitir tendremos que bloquear marcar una u otra (o ambas):


  En el caso de la imagen anterior hemos permitido el acceso a Shark for Root y a Conect Cat.

 Con las aplicaciones seleccionadas desplegamos el menú de opciones y activamos el cortafuegos:


 Si en otro momento es necesario modificar alguna regla no es necesario desactivarlo, pues la opción Aplicar reglas nos permite realizar esta tarea.

 Por último, es posible ver las reglas activadas o los logs mediante la opción (desplegando el sub-menu MásMostrar reglas o Mostrar logs.


  En resumen, disponemos de un interesante cortafuegos en nuestros dispositivos que puede sernos útil para controlar las aplicaciones que se conectan a  la red, pues estas no siempre nos avisan de ello.

  Nos leemos en breve ;)


5 0verl0ad Labs: abril 2013    DroidWall  dota a nuestros dispositivos Android de un eficiente  cortafuegos  (es necesario ser ...

miércoles, 10 de abril de 2013

0verl0ad Wants you !

¡Saludos!

   Tras una charla con Aetsu, hemos llegado a la conclusión de que hace falta más contenido en el blog sobre temas de informática forense y sobre "defensa" (IDS, WAFs, firewalls, configuraciones de redes...).

   Es por ello que hemos decidido "reclutar" a algún interesado, y que tenga conocimientos en alguna de estas dos materias, para que nos eche una mano y publique, cuando pueda (ya sabeis que nuestro ritmo es bastante lento en cuanto a  publicar) en nuestro blog.

  Si estais interesados, comunicadlo en los comentarios. O podeis usar el correo del blog o nuestros twitters.

Byt3z!
5 0verl0ad Labs: abril 2013 ¡Saludos!    Tras una charla con Aetsu, hemos llegado a la conclusión de que hace falta más contenido en el blog sobre temas de informátic...

sábado, 6 de abril de 2013

Pequeñas modificaciones en el blog

¡Saludos!

   Sigo en mi centro de mando en el desierto, conectado por un módem USB a una media 200Kbits/s, lo que me ha permitido al menos twittear y leer el correo. Y hacer unas pequeñas modificaciones en el blog, que en "breve" se irán intensificando.

   Lo más grande ha sido que hemos comprado un dominio (0verl0ad.com), y ahora tenemos alojado el blog en el subdominio (blog.0verl0ad.com). La intención inicial es colgar por el momento (cuando tenga un internet decente, y no esté atado de pies y manos con trabajos y horas de laboratorio) una web sencillita con lo básico. Entre lo que considero "básico", estaría colgar un "About us" de los que publicamos en este blog, un listado con los papers que hemos publicado,otro listado con las vulnerabilidades reportadas, y otra a modo de biblioteca donde iré recopilando links a artículos interesantes, cursos On-line, etc. En un futuro se podría incrementar, pero por ahora sólo eso.

    A parte de esto, el otro día me dí cuenta que por twitter los de HackXCrack estaban linkeando a artículos y herramientas mías (algunas publicadas por mí mismo en su foro, otras las han extraído de este blog con consentimiento). En mi opinión se trataba de herramientas bastante sencillas, toscas, y por qué no decirlo, cutres. Pero al parecer hay gente a las que les ha servido, asi que se me ha ocurrido hacer un GitHub donde ir colocar todas las herramientas que hemos publicado en el blog (y algunos proyectos que llevo en paralelo) para ir actualizando y mejorando esas herramientas (¿Sabeis esos post donde publico algo y a continuación digo: pues en la siguiente versión implementaré tal o cual cosa y al final no vuelvo a publicar? Pues va a ser el momento de arreglarlo ;) ). La cuestión es que quiero que todo sea abierto, de tal forma que la comunidad pueda aportar y ayudar, de una u otra forma: detectando fallos, corrigiendo errores, sugiriendo mejores formas, etc.

   Ahora mismo está abierto, pero no tiene nada publicado. Cuando llegue a Salamanca (principios de esta semana) me pondré a subir las herramientas, y a añadir unos readmes para dejarlo todo ordenado. Por el momento he dejado el link a donde van a estar alojados los repositorios. El link podeis verlo en la barra azul, donde los RSS.

   Además de meter el enlace a GitHub, también he incluido el enlace a los PodCast que estamos haciendo en ivoox. Los cuales reanudaremos en breve, ya que @Aetsu ha vuelto hoy de su idílico crucero.

  Aprovecho para adelantar que en los siguientes post (sí, ya sé que tengo que publicar el tercer y último de la Rooted) vamos a hablar sobre PortKnocking, utilización de redes sociales como C&C, cosas divertidas con LocalStorage (vuelve la serie sobre ataques aprovechando cosillas de HTML5 :D )... y mucho más.


Byt3z!

P.D.: Sí, le he robado lo de colocar el nick al final a Aetsu, pero no se lo digais, es un secreto.
5 0verl0ad Labs: abril 2013 ¡Saludos!    Sigo en mi centro de mando en el desierto, conectado por un módem USB a una media 200Kbits/s, lo que me ha permitido al menos...

miércoles, 3 de abril de 2013

Aplicaciones Android - ezNetScan


  Esta aplicación ofrece prestaciones similares a la ya analizada anteriormente Fing, pero sacrificando algunas funcionalidades a cambio de una interfaz mas cuidada.

  EzNetScan nos ofrece un escáner de redes, mostrándonos información de los equipos que la forman y ofreciéndonos algunas aplicaciones para interactuar con ellos. Para obtenerla basta con acceder Google Play y descargarla:
https://play.google.com/store/apps/details?id=com.vrsspl.eznetscan&hl=es


  Cuando lanzamos ezNetScan nos mostrará información del punto de acceso al que estemos conectados, ya sea la puerta de enlace, ip, dirección mac o la máscara entre otros. Una vez pulsemos en el icono de Scan empezará a "escarbar en nuestra red":



  Una vez escogido el objetivo, podremos realizar diversas acciones sobre el equipo, desde un pingtracerouteescanear sus puertos (0-1024), wake on lan u obtener información del sistema mediante SNMP:



  En resumen, disponemos de una aplicación que nos mostrará información de los equipos de nuestra red con una interfaz muy cuidada y muy sencillo de utilizar.


5 0verl0ad Labs: abril 2013   Esta aplicación ofrece prestaciones similares a la ya analizada anteriormente  Fing , pero sacrif...
< >