Bloqueo de servidores DHCP falsos

Seguro que ya os ha pasado en alguna ocasión. De repente, la gente empieza a decir que ha perdido la conexión en la red local, miras tu icono en la barra de tareas y parece que está todo levantado. Luego ejecutas ipconfig/ifconfig y observas que tienes una IP que no es la que sueles tener. "Ya está, algún listillo ha conectado a la red un Linksys u otro cacharro con un servidor DHCP..."
 Aunque parezca mentira, esta situación hoy en día es bastante frecuente en cualquier empresa y es que los administradores muchas veces insisten en no poner las medidas necesarias para evitar este tipo de situaciones. Lo malo es que no siempre se trata de un incauto consultor que conecta sin querer algo que no sabe exactamente lo que hace e impiden que los demás puedan funcionar correctamente. Algunas veces un atacante puede instalar un falso DHCP (rogue DHCP) para, por ejemplo, falsificar el gateway y/o los servidores DNS de los confiados clientes de la red, de tal forma que podría esnifar su tráfico (MiTM) o redirigirlos a sitios falsos con no muy buenas intenciones...

La solución siempre pasa por configurar la electrónica de red para evitarlo. En este caso hablaremos de Cisco por ser lo más ampliamente utilizado, pero otros fabricantes como HP, Juniper u otros tienen medidas similares (si es tu caso, te invitamos a compartir con nosotros tu experiencia ;)).

Una forma sería utilizar ACLs para bloquear UDP 68, que es el puerto destino que utiliza un servidor DHCP para hablar con el cliente (RFC 1531). Así que simplemente si quieres que un servidor DHCP no envíe paquetes offer o acks puedes crear una lista de acceso y aplicarla en los interfaces correspondientes:

ip access-list 100 deny udp any any eq 68
ip access-list 100 permit ip any any
int [interface facing the would-be rogue]
ip access-group 100 in

Esto no sería necesario si tenemos configurado el ip helper-address y el switch está actuando como un reenviador de broadcasts hacia el servidor DHCP adecuado. También podríamos bloquear el acceso al puerto 68 si queremos detener un DHCP falso detrás de una pasarela o firewall.

La otra forma de luchar contra un DHCP rogue y la más adecuada es utilizar DHCP Snooping. Básicamente, se basa en definir en el switch los puertos sobre los que el tráfico del DHCP server confiable puede transitar. Es decir, definimos como “trust” los puertos donde tenemos servidores dhcp, relays dhcp y los trunks entre los switches.

Configuramos a nivel global en el switch y lo activamos:

ip dhcp snooping vlan 100,101
no ip dhcp snooping information option
ip dhcp snooping

Autorizamos los puertos del servidor dhcp y los trunks:

interface FastEthernet0/3
 description SERVER DHCP
 switchport mode access
 switchport access vlan 100
 switchport nonegotiate
 spanning-tree portfast
 ip dhcp snooping trust

interface GigabitEthernet0/1
 description FIREWALL
 switchport mode trunk
 spanning-tree portfast
 ip dhcp snooping trust

interface GigabitEthernet0/2
 description UPLINK A SWITCH
 switchport mode trunk
 ip dhcp snooping trust

El comando “no ip dhcp snooping information option” lo añadiremos si no queremos la opción 82, es decir, no queremos que el switch añada información adicional para que el servidor DHCP destino pueda identificar el origen del cliente en entornos distribuidos (campo “giaddr”) y asignarle una IP dentro del pool o rango correspondiente.

Por último, si queremos verificar la configuración del DHCP snooping:

switch#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
100,101
DHCP snooping is configured on the following Interfaces:

Insertion of option 82 is disabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Interface Trusted Rate limit (pps)
———————— ——- —————-
FastEthernet0/3 yes unlimited
GigabitEthernet0/1 yes unlimited
GigabitEthernet0/2 yes unlimited

switch#show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
—————— ————— ———- ————- —- ——————–
00:0C:AA:CC:AA:BB 10.66.0.113 64701 dhcp-snooping 100 FastEthernet0/16
00:0C:BB:CC:AA:AA 10.1.0.110 65827 dhcp-snooping 101 FastEthernet0/4
84:2B:AA:AA:AA:AA 10.1.0.104 50058 dhcp-snooping 101 FastEthernet0/6

Si deseamos desactivarlo temporalmente no hay que reconfigurarlo todo:

no ip dhcp snooping
Fuentes:
Understanding and Configuring DHCP Snooping
dhcp snooping – prevención de ataques DHCP
Blocking rogue DHCP servers
How to Block Rogue DHCP Server's on Cisco Equipment Using ACL's? 
http://www.hackplayers.com

Cómo crear un certificado SSL auto-firmado

Todos sabemos que, en una comunicación SSL cifrada, el certificado firmado por una Entidad Certificadora Autorizada (CA) nos asegura que el otro extremo es realmente quien dice ser. No obstante, muchas veces nos interesa generar un certificado auto-firmado para pruebas o uso interno. 

Con openssl y un Unix/Linux es realmente fácil y, aunque existe muchísima documentación al respecto, siempre viene bien tener a mano una pequeña guía. A propósito de una reciente entrada de Akadia podemos ver cómo hacerlo paso a paso:

Paso 1: Generar una Clave Privada

El kit de herramientas de OpenSSL se utiliza para generar una clave RSA privada y un CSR (solicitud de firma de certificado). Pero, como comentamos, también se puede utilizar para generar certificados auto-firmados que pueden ser utilizados para propósitos de prueba o de uso interno.

El primer paso es crear tu clave privada RSA. Esta clave es una clave de 1024 bits RSA que se cifra usando Triple-DES y se almacena en formato PEM de modo que sea legible como texto ASCII.

openssl genrsa -des3 -out server.key 1024

Generating RSA private key, 1024 bit long modulus
.........................................................++++++
........++++++
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:

Paso 2: Generar un CSR (solicitud de firma de certificado)

Una vez que hemos creado la clave privada, se puede generar una solicitud de firma de certificado. El CSR se puede utilizar entonces de dos maneras. Idealmente, el CSR se enviará a una autoridad de certificación, tal como Thawte o Verisign, quien verificará la identidad del solicitante y expedirá un certificado firmado. La segunda opción es la de auto-firmar el CSR, que se demostrará a continuación.

Durante la generación del CSR, se pedirá varia información. Estos son los atributos X.509 del certificado. Uno de los mensajes nos pedirá el Common Name. Es importante que este campo se rellene con el nombre de dominio completo del servidor que va a estar protegido por SSL. Es decir, si el sitio web será https://publico.prueba.com, introduce publico.prueba.com. El comando para generar el CSR es el siguiente:

openssl req -new -key server.key -out server.csr

Country Name (2 letter code) [GB] :SP
State or Province Name (full name) [Berkshire] :Madrid
Locality Name (eg, city) [Newbury] :Madrid
Organization Name (eg, company) [My Company Ltd] :Hackplayers
Organizational Unit Name (eg, section) [] :Information Technology
Common Name (eg, your name or your server's hostname) [] :publico.prueba.com
Email Address [] :hackplayers at ymail dot com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Paso 3: Borrar la contraseña de la clave

Un desafortunado efecto secundario de la transmisión de una clave privada con contraseña (passphrase) es que Apache o el servidor web en cuestión te pedirá la frase de paso cada vez que se inicie el servidor web. Obviamente, esto no siempre es conveniente, sobretodo si el servidor se reinicia automáticamente. mod_ssl incluye la capacidad de utilizar un programa externo en lugar de escribir la frase a mano, sin embargo, esto no es necesariamente la opción más segura tampoco. Es posible eliminar el cifrado triple-DES de la clave para que no sea necesario escribir una clave. Eso sí, si la clave privada ha dejado de estar cifradas, ¡es fundamental que este archivo sólo pueda ser leído por el usuario root!. Si un tercero obtuviera la clave privada sin cifrar, el certificado correspondiente deberá ser revocado. Para quitar la frase de paso de la clave, utiliza el siguiente comando: 

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
 
El nuevo fichero creado server.keyya no tiene contraseña. 

-rw-r--r-- 1 root root 745 Jun 29 12:19 server.csr
-rw-r--r-- 1 root root 891 Jun 29 13:22 server.key
-rw-r--r-- 1 root root 963 Jun 29 13:22 server.key.org

 

Paso 4: Crear un certificado auto-firmado

En este punto ya podemos generar el certificado auto-firmado. Hay que decir que, evidentemente, este certificado generará un error en el navegador del cliente en el sentido de que la autoridad de certificado de firma es desconocida y no confiable.

Para generar un certificado válido para 365 días, ejecutaremos el siguiente comando:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=SP/ST=Madrid/L=Madrid/O=Hackplayers/OU=Information
Technology/CN=publico.prueba.com/Email=hackplayers at ymail dot com
Getting Private key

Paso 5: Instalar la clave privada y el certificado en Apache

Cuando se instala Apache con mod_ssl, se crean varios subdirectorios en el directorio de configuración de Apache. La ubicación de este directorio será diferente en función de cómo se compiló Apache.

cp server.crt /usr/local/apache/conf/ssl.crt
cp server.key /usr/local/apache/conf/ssl.key
 
Paso 6: Configurar host virtuales con SSL activado
 
SSLEngine on
SSLCertificateFile /usr/local/apache/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog logs/ssl_request_log \
   "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Paso 7: Reiniciar Apache y probar 

/etc/init.d/httpd stop
/etc/init.d/httpd stop

 https://publico.hackplayers.com

 

FUENTE: http://www.hackplayers.com 

Comprometiendo IPV6

Cuando se creó IPv4 no se atisbó a imaginar la extensión que la Red   alcanzaría. Desde febrero de 2011, sus 2³² direcciones IP ya no son suficientes.
Es aquí donde entró en juego el  protocolo IPV6.
 
IPv6 nació de manos de Steve Deering y Craig Mudge para paliar las deficiencias de IPv4 y sentar las bases del futuro de Internet, proporcionando un sistema más sólido y eliminando la posibilidad de un escenario en el que se produzca un nuevo colapso gracias a sus 2¹²⁸ direcciones. Además de este notable aumento, IPv6 introduce modificaciones en el formato de la cabecera de los paquetes, que promete un enrutamiento más eficiente, y mejoras en la seguridad. IPv6 fue adoptado por la Internet engineering task Force (IetF) en 1994 y está definido en el RFC 2460.

Al margen de otras cosas, este hecho a nosotros "los chicos malos" o nos supone un nuevo handicap o, por el contrario, si somos capaces de ver el vaso medio lleno en vez de medio vacío, nos da mas alternativas a la hora de atacar o poner en evidencia la seguridad de algún sistema, más aún ahora que ipv6 convive con ipv4 y no se sabe por cuanto tiempo (seguro que muchísimo)...

En esta ocasión nos vamos a poner las pilas con este protocolo de la mano de los chicos de The Hackers Choice y su completa suite THC-IPV6, cuya versión 2.0 fue liberada el mes pasado.

Vamos a abordar esta entrada desde el punto de vista practico:

Nos colocamos en la carpeta /home o donde queramos y nos bajamos el software desde la consola:

wget www.thc.org/thc-ipv6/thc-ipv6-2.0.tar.gz

O, si lo preferimos, podemos ir a su página y descargarlo con el navegador desde la siguiente dirección: http://www.thc.org/thc-ipv6/

Una vez descargada la suite atenderemos sus dependencias:

apt-get install libpcap-deb openssl libssl-deb

Ahora procedemos a la instalación:

make

y si todo va bien:

make install

Con esto habremos instalado la suite.

Dentro de esta suite encontramos las siguientes herramientas:

• Parasite6: anuncio spoofer, se encarga de hacer el arpspoof.
• Alive6: un escaner eficaz , que detectará todos los sistemas que estén en su rango de red.
• Dnsdict6:  permite enumerar las entradas DNS de un dominio. Utiliza un archivo de diccionario si se le proporciona o, en caso contrario, uno propio.
• Fake_router6: para anunciarse como un router en la red, con la más alta prioridad.
• Redir6: redirección del tráfico hacia nosotros de forma inteligente (man-in-the-middle).
• Toobig6: reductor mtu con la misma inteligencia que redir6.
• Detect-new-ip6: detecta nuevos dispositivos ip6 que se unen a la red.
• Dos-new-ip6: detecta nuevos dispositivos ip6 y dice que hay conflito de red  (DoS).
• Trace6: traceroute6 muy rápido con soportes icmp6, solicitud de eco y TCP -SYN.
• Flood_router6: inundación de un objetivo con anuncios de enrutador al azar.
• Flood_advertise6: inundación de un objetivo con anuncios de neighbor al azar.
• Exploit6: prueba las vulnerabilidades conocidas IPv6 contra un blanco.
• Denial6: una colección de ensayos de denegación de servicio contra un objetivo.
• Fuzz_ip6: fuzzer para ipv6.
• Implementation6: lleva a cabo diversos controles de aplicación sobre ipv6.
• Implementation6d: Pone en modo demonio implementation6.
• Fake_mld6: para anunciarse en un grupo multicast de su elección en la red.
• Fake_mld26: lo mismo pero para MLDv2.
• Fake_mldrouter6 : falsos mensajes de router MLD.
• Fake_mipv6: robar una IP móvil si IPSEC no es necesario para la autenticación.
• Fake_advertiser6: para anunciarse en la red.
• Smurf6: smurfer local
• Rsmurf6: smurfer remoto, se sabe que por el momento funciona sólo contra linux.
• Sendpees6: una herramienta de willdamn(at)gmail.com, que genera peticiones a vecinos con un montón de CGAs (cripto cosas;-) para mantener la CPU ocupada.
• Thcping6: envía un paquete ping6 modificado a mano.

 Y otras 25 que dejamos para que vosotros las descubráis (/usr/local/bin#).

Como veis son un buen puñado de herramientas que esta suite pone a nuestro alcance en un solo paquete, que desde mi punto de vista es "impepinable" tenerlo instalado en nuestros sistemas.

Enumeración de la red:

Bueno, ahora a pasar a la acción... Como en un ataque convencional a ipv4, lo primero que haríamos sería enumerar la red.  Una forma típica de actuar sería utilizar una herramienta como Nmap para buscar las direcciones de las máquinas en la subred a atacar. Con Ipv6, la secuencia de acciones sería similar, pero debido al enorme rango de direcciones válidas dentro de una subred (2⁶⁴), el tiempo que nos llevaría sería excesivo...

Como remedio con IPv6, las fuentes de información principales (y por tanto uno de los objetivos clave) serán los servidores DNS...
Normalmente, todas las máquinas necesitan tener registros en los servidores DNS privados con la finalidad de que los administradores no se vuelvan locos.

Para este fin tenemos una de las herramientas incluidas en Thc­IPv6: alive6.

alive6 "nuestra interfaz de red"
 

La respuesta obtenida serán las X direcciones de las interfaces de red locales.
En nuestro ejercicio serán A y V. 

Los errores de seguridad típicos que se pueden encontrar (y aprovechar), en su mayoría son debidos a descuidos o malas implementaciones.

Ataque man-in-the-middle

Sin la aplicación de IPSec, cualquier ataque que utiliza las técnicas "Man in the middle" tendrá la misma probabilidad en IPv6 que en IPv4.

Si tenemos en cuenta que IPSec está fuertemente ligado a IPv6, su uso sería suficiente para evitar cualquier problema con respecto a los intentos de un secuestro de la conexión. Por desgracia, la práctica dominante que vemos hoy en términos de despliegue de IPv6 ya existentes es que los operadores de red no hacen ningún uso de IPSec. El uso de los certificados también puede proporcionar la autenticación necesaria de extremo a extremo en el nivel de aplicación (por ejemplo, servidores web). Sin tales mecanismos de seguridad, un secuestro "Man in the middle " es una posibilidad.

En nuestro ejemplo anterior hemos visto la dirección ipv6 de dos maquinas :

A: fe80::21d:xxxx:xxxx:xxxx [ICMP echo-reply]
V: fe80::e60:xxxx:xxxx:xxxx [ICMP echo-reply]

Una vez apuntado ésto, nos disponemos a desarrollar un ataque archi-conocido man-in-the-middle.

La realización de este tipo de ataque en IPv4 se basa en el funcionamiento de las peticiones de ARP (para obtener la MAC correspondiente a una dirección IP) y mensajes DHCP (para asignar direcciones IP dinámicamente), enviados ambos a la dirección de broadcast de la subred. Por tanto, cualquiera puede responder a estos mensajes, falseando así la información. En IPv6 no se añade una seguridad especial a lo anterior, la diferencia radica en que se utiliza ICMP6 para realizar estas peticiones y se utilizan direcciones multicast (pues en IPv6 no hay direcciones de broadcast).

En ipv6 cuando la máquina A quiere comunicar con B , A emite una petición ICMP6 (para solicitar la MAC de B), a todos los nodos de la subred (dirección multicast). 

El atacante puede utilizar la herramienta parasite6 para enviar una respuesta afirmando que la MAC solicitada se corresponde con su dirección IP.

parasite6 [-lRFHD] interface [fake-mac]

-l loops and resends the packets per target every 5 seconds.  -R will also try to inject the destination of the solicitation -F fragment (used to bypass network security)-H hop-by-hop (used to bypass network security)-D large destination header (used to bypass network security)

interface nuesta el interface de red y MAC la mac a donde queremos redirigir el tráfico. Si la omitimos, por defecto será la nuestra o, si no existe, mandaremos los paquetes a Parla.

Suponiendo que entre A y V haya un trafico o conversión bajo IPV6, en condiciones normales no podríamos "meter el moco". Veamos que pasa al realizar el ataque:

Podemos ver que hemos interceptado perfectamente la conversión. Para verlo más claro os pongo la captura de wireshark:

Escaneando puertos en IPV6:

La verdad no es muy distinto de lo que estamos acostumbrados con IPV4 :

nmap -6 -PN 'dirección ipv6'%'interfaz red'

Veamos otro ataque:

Fake_route6

Este ataque funciona como un "man in the middle"  con esteroides. Se aprovecha de el hecho de que los sistemas operativos como Windows 7 aceptan casi ciegamente los anuncios del enrutador que reciben, sin requerir ningún tipo de autenticación por defecto. El atacante enviará a las asociaciones y tratará de establecer su PC como router por defecto para los dispositivos de red. Esto hará que los clientes envíen tráfico de red para el atacante, y el atacante sólo tiene que abrir Wireshark para empezar a esnifar todos los sabrosos paquetes de cada uno de los clientes.

Preparación:

Para que el ataque funcione y no levantar sospechas, las víctimas no deben tener ni idea de que algo ha cambiado. Por lo tanto, un atacante tiene que ser capaz de enviar datagramas hacia y desde un router legítimo que permite a las víctimas seguir utilizando los recursos de red.

Podemos configurar un túnel IPv6 gratis, cortesía de Hurricane Electric. 
Conectados al router a través de Fa0/1 están un cliente de Windows Vista, que representa a la víctima, y un cliente BackTrack 5, el atacante. La víctima está utilizando el router 2621 como puerta de enlace predeterminada, como resultado de los anuncios del enrutador que se envían desde ese router.

fake_router6 esencialmente sólo envía RA IPv6, y eso es todo. Es decir se anuncia como router principal de la red. Hay que tener en cuenta que para realizar un ataque exitoso, tenemos que mantener a la víctima conectada a los recursos de red. Por lo tanto, tenemos que convertir nuestro dispositivo en un router ataque improvisado, y tenemos que hacerlo antes de enviar el SAR para dirigir el tráfico a nosotros.

En primer lugar, tenemos que habilitar el reenvío IPv6 en nuestra máquina BackTrack. En una ventana de terminal, con el siguiente comando:

root@Bigben:# sysctl -w net.ipv6.conf.all.forwarding=1 4

Con esto redirigimos el trafico ipv6, no el ipv4.

El router 2621 es nuestra puerta de enlace predeterminada, y nos conecta a Internet. Si echamos un vistazo a la figura, preparamos la ruta con la dirección local de vínculo del interfaz Fa0/1 del router y la añadimos al sistema con la siguiente orden:

ip route add default via fe80::c200:15ff:fe70:d68f dev wlan0

Una vez tenemos lista nuestra cuartada en la red, es hora de hacernos pasar por el router dominante de la red y para esto utilizamos un simple comando:

fake_router6 wlan0 fe80::01/16

Por último, vamos a ver los efectos de un...

flood en ipv6:

Flood_router6 'interface'

Con este ataque consumiremos el ancho de banda de la red 
bloqueandola dejándola inservible mientras dure el ataque..

Fuentes:

http://keepingitclassless.net/

http://portalipv6.lacnic.net/
http://www.gont.com.ar/ipv6/index.html
http://lacnic.net/sp/
http://www.level3.com/en/resource-library/

http://www.hackplayers.com 

Qubes OS: sistema blindado

Es evidente que la industria del antivirus pasa por una crisis, o al menos cada vez resulta menos práctico pensar que estamos a salvo dejando la seguridad de nuestros sistemas simplemente en manos de un antivirus. 

Ésto, junto a la imposibilidad de tener controlado todos los bugs, ZeroDays y la nueva aparición de malware, está haciendo cambiar la mentalidad y el enfoque de la industria en cuanto a la seguridad se refiere. Esta situación también repercute en el usuario que cada vez es mas consciente de la importancia que merece la seguridad informática y esta dispuesto a sacrificar vistosidad y facilidad de manejo a cambio de que su sistema este a salvo.
 
Por otra parte, cada vez se esta haciendo menos rentable programar para sistemas que desde un principio enfocaron mal la seguridad y día a día pierden adeptos (a las pruebas me remito), y es que se está abriendo un nuevo nicho en el mercado que muchas empresas están dispuestas a abarcar: la creación de sistemas mas robustos y seguros, aún teniendo que dejar de lado a antiguos clientes y a riesgo de competir con los grandes del software privativo.

Esta semana Kaspersky Lab anunciaba  el desarrollo de  un nuevo sistema operativo de “máxima seguridad” creado desde 0.
En un reciente escrito decían: “estamos desarrollando un sistema operativo seguro para proteger sistemas de información, infraestructuras e industrias claves”.

Desde luego esta idea no tiene nada de nuevo... Es conocido desde hace tiempo que Linux ofrece numerosas ventajas de seguridad frente a otros sistemas operativos puesto que desde el principio contempló la seguridad como una prioridad.

Desde hace años en el mundo Linux hay varias distribuciones que basan su cimentación en este objetivo, hecho que no a pasado desapercibido a corporaciones, como el Departamento de Defensa de Estados Unidos, la Marina y sus Fuerzas Aéreas, las cuales han optado por implementarlas en sus infraestructuras.

Una de estas "Distros" llevada al extremo es QUBES OS.

Qubesos es un interesante proyecto open source basado en Linux y Xen...(claro que más que ser una distribución de linux que maneje xen, yo diría que es una distribución de Xen que maneja Linux.....).

QubeOs empezó en el 2010 de la mano de Invisible Things Labs, y en junio del 2012 se liberó su versión beta3 .

Una de las diferencias que nos ha llamado poderosamente la atención con respecto a las versiones anteriores es el proceso de instalación, que si bien era complicado, en esta versión no difiere de cualquier intalación linux moderna....

La mayor pega que le hemos visto son sus requisitos que por otra parte van de la mano a la hora de hablar de virtualización:

• 4GB of RAM
• 64-bit Intel or AMD processor (x86_64 aka x64 aka AMD64)
• Intel GPU strongly preferred (if you have Nvidia GPU, prepare for some troubleshooting; we haven't tested ATI hardware)
• At least 20GB of disk (Note that it is possible to install Qubes on an external USB disk, so that you can try it without sacrificing your current system. Mind, however, that USB disks are usually SLOW!)
• Fast SSD disk strongly recommended

Requisitos adicionales:

• Intel VT-d or AMD IOMMU technology (this is needed for effective isolation of your network VMs)
• TPM with proper BIOS support if you want to use option  Anti Evil Maid

Segun sus desarrolladores la idea de QubesOS es crear un sistema operativo utilizando muchas máquinas virtuales, donde cada una atiende, encapsula y aisla a cada uno de los programas utilizados en una máquina, incluyendo aquellos que administran los recursos de la misma.

Las premisas sobre las que está basada esta idea son las siguientes:

   1. Uno de los principales problemas de los sistemas operativos actuales, cualesquiera, es su incapacidad para aislar los procesos que se ejecutan en un máquina. De esa forma, si el navegador web se ve comprometido, el sistema operativo es incapaz de proteger otras aplicaciones de los usuarios y sus datos.

   2. Por otro lado, es impráctico, ¿imposible?, tanto resolver todos los bugs posibles en el software como detectar todo el software malicioso. Esto hace necesario un nuevo enfoque para la creación sistemas operativos seguros. Comenzar desde cero esta tarea tampoco está cerca de la realidad, así que ¿por qué no usar/reutilizar software existente y modelar con él una arquitectura como la deseada?

Con QubeOS estas ideas se materializan, utilizando máquinas virtuales que se aislan entre si de mejor manera que los procesos típicos que forman parte de todo sistema operativo actual.

¿Serán estas nuevas técnicas pan de todos los días en los sistemas operativos del futuro?

Fuente: http://qubes-os.org/Home.html.
http://www.hackplayers.com

icmpsh o cómo abrir un shell inverso mediante ICMP

A veces los administradores de red nos ponen las cosas difíciles. Algunos de ellos, sorprendentemente, utilizan firewalls para lo que se supone que valen y obtener una shell inversa a través de TCP resulta difícil. No obstante, no es la primera empresa en la que me encuentro que habilitan ICMP alegremente desde cualquier origen a cualquier destino. Total, ¿qué podemos hacer con un simple ping?

Pues, a parte de obtener información acerca de la topología de la red de los incautos administradores o estresar las tarjetas de red de alguna maquinita, podemos establecer sesiones bajo nuestro amado protocolo. Y no hace falta hablar en ruso o visualizar el código de Matrix, existen aplicaciones aptas para cualquier lammer que facilitan este trabajo como loki, soicmp o icmpshell y la herramienta de la que hablaremos en esta entrada: icmpsh.

¿Y por qué icmpsh y no otras? Pues porque es de código abierto y sobretodo no requiere privilegios de administración en la máquina objetivo. Es decir, la ejecutamos con nuestro usuario 'pelao' en un servidor comprometido (definido como slave) y ya tenemos una puerta abierta a través de cualquier firewall que se ponga por el medio. Eso sí, de momento el slave tiene que ser Windows, aunque el master (o sea, nosotros los malos) puede ser cualquier plataforma que ejecute código C, Perl o Python. Además, la herramienta de Nico Leidecker fue portada a Python por Bernardo Damele para poder integrarla en su famoso sqlmap (¿os suena, verdad?).

Para terminar, veamos un ejemplo ilustrado de su sencillo funcionamiento. Ejecutamos icmpsh slave en la máquina objetivo (192.168.136.129) especificando la IP 192.168.136.1 del master:

Y lanzamos icmpsh master en el equipo del atacante (192.168.136.1) y ejecutamos un par de comandos en la máquina comprometida (192.168.136.129):

Fuentes:
http://bernardodamele.blogspot.com.es/2011/04/reverse-connection-icmp-shell.html
https://github.com/inquisb/icmpsh
http://leidecker.info/downloads/index.shtml
http://www.hackplayers.com