Controlando dispositivos USB con soluciones Endpoint – Parte I

El panorama actual de la seguridad informática es bastante interesante puesto que cada vez vemos más información sobre este tema. Ataques, robos de credenciales, amenazas, suplantación de identidad… es evidente que en el “Internet de las cosas” toda protección es poca.

Muchos gremios profesionales se interesan, poco a poco eso sí, por formarse o al menos asistir a charlas y/o eventos de carácter no excesivamente técnico (como Hack&Beers) para iniciarse o aprender ciertas pautas a tomar para su empresa.

Antivirus o con suerte Firewalls, es lo que más podemos encontrar en todas las empresas. Otra cosa es encontrarse antivirus actualizados. Esta protección no está de más, como ya comentamos. Si todo está al día, y configurado correctamente, esta solución nos “protege” del exterior, bloquea malware, avisa de phishing, etcétera… Aunque a los más “arcaicos” les puede resultar una auténtica molestia el recibir bloqueos y/o avisos, esto puede salvarnos de una catástrofe de dimensiones casi mundiales en nuestro negocio.

¿Y qué pasa con la fuga de información?

Este aspecto (actualmente ignorado por la inmensa mayoría aunque si bien es cierto que determinados gremios están concienciándose bastante rápido) es muy interesante.

Existe el robo de información desde sedes físicas. Un individuo “A” llega a una empresa X, enchufa un USB Rubber Ducky, el famoso Pato, y “aspira” todo tipo de información y credenciales.

Otra forma, es que un empleado, o nuevo empleado o servicios externos en nuestra empresa de cualquier tipo (limpieza, servicio técnico, etcétera…) puede acceder a nuestras oficinas por confianza y pinchar un USB y extraer información confidencial.

Siendo más paranoicos, y no estoy exagerando, puesto que nos hemos encontrado ya varios casos de este tipo, un empleado utiliza un equipo de la empresa el cual no necesita introducir ni extraer información para compartir con compañeros ya que su trabajo no contempla esto, puesto que todo se hace mediante la intranet. ¿Por qué están activos los USB o grabadores DVD?

A continuación vamos a desgranar en este artículo primero y en otra segunda parte de “Controlando Dispositivos Externos“, soluciones válidas para contrarrestar fuga de datos.

En esta primera parte, trataremos con una reputadísima empresa de soluciones de Seguridad. Sophos.

Los EndPoints. Una medida más para evitar fuga de información.

Queramos o no, la inseguridad está en todos lados. Por ello vamos a exponer en este artículo, brevemente, el uso de el EndPoint SOPHOS como medida preventiva para evitar que fuga de información. Recordad, la información es negocio.

Nos vamos a centrar únicamente en su función de Control de Dispositivos.

Lo primero es irnos a su Web. Veremos algo similar a la siguiente captura.

Obviamente necesitaremos evaluar la versión para poder probarla durante 30 días. Suficiente para ver su efectividad.

Elegimos la instalación “en la nube”. ¿Por qué? Vamos a ver como gestionar varios equipos desde la nube, habilitando políticas, reglas, etcétera desde su sitio Web. Algo muy cómodo si se tienen muchos equipos.

Rellenamos los datos correspondientes, email real para activar el producto y pasamos a la siguiente fase. Debemos entrar en la URL de la captura para loguearnos con nuestro mail y password. Este es el panel de administración.

Es muy importante fijarse en todas las opciones que tiene puesto que son muy interesantes.

Este es el panel de administración. Nos ha gustado mucho que es muy “limpio” en su diseño, ofrece detalles estadísticos que pueden servirnos en el futuro para ver el uso del EndPoint, equipos no protegidos, etcétera…

Nos fijaremos en la sección de descargas puesto que tendremos los instalables para Windows, Linux, MAC…personalizados. Estos serán los que usaremos  para “propagar” (instalar) en nuestros equipos y poder gestionar así, desde el cloud, todos.

En la anterior captura vemos el menú correspondiente a la sección descargas.

Cuando instalemos en algún equipo nuestro ejecutable descargado desde el mencionado menú de Descargas, y cuando el equipo esté conectado a Internet, detectará la conexión y aparecerá en nuestro panel de administración.

En el menú “Usuarios y Dispositivos” aparece el apartado “Políticas” (Policies) en el cual tenemos entre otras opciones “Defina cómo se debe tratar los medios extraíbles y otros periféricos”. En ella vamos a denegar el almacenamiento extraíble para evitar que nos instalen un USB Rubber Ducky o que algún empleado malhumorado trafique con información confidencial.

Igualmente podemos bloquear todo tipo de conexiones. Lo vemos en la siguiente captura.

Al final de la página, guardamos. Automáticamente tras pocos segundos se actualiza en el equipo cliente, esta política bloqueando cualquier tipo de medio extraíble.

En el equipo cliente, SOPHOS ENDPOINT, nos aparecerá como un software antivirus pero con muchísimos más complementos. Igualmente podemos gestionar algunas actividades.

Un opción muy interesante, es un módulo “anti desinstalaciones” llamado Protección contra manipulaciones que nos sirve para que el usuario no desinstale el software sino conoce la password de desinstalación, reflejada en el DashBoard en el que gestionamos, como hemos dicho, nuestro endpoint.

Con ello, sumamos un punto más de control y seguridad a nuestros equipos. No por ataques, que también incorpora antivirus (como hemos hablado) sino que evita extracción de información. Si un usuario quisiera en un momento determinado introducir algún documento via pendrive, o extraer lo tendría que solicitar y quedaría registrado en nuestro Sophos Cliente y en el panel de administración.

Espero que os sirva de referencia para adoptar medidas. Invertir en seguridad no es derrochar el dinero, es ahorrar en incidencias.

Bloqueando accesos desde TOR

Muchas o mejor dicho miles de veces oímos hablar de la red TOR. Ya no es un término usado por gurús de la seguridad sino que más o menos es conocido por los aficionados a la informática.

Hay mucha suspicacia en el tema del anonimato en la red y obviamente esto tiene sus motivos. Pero tanto positivos como negativos.

Cuando hablamos de anonimizar tu conexión para que no te “espíen” podemos suponer que ya de hecho vamos a cometer un delito o vamos a practicar actividades de dudosa legalidad. Esto es muy relativo.

Pero como primera premisa, indiscutible (e “impepinable” como se dice por Córdoba :P) es que nadie tiene porque espiar tu actividad en la red. Podemos entrar en el debate de que se sospecha o se tiene indicios de que “tal” y “cual” pero un usuario de “a pie” no tiene por qué ser rastreado.

Con eso, se podría justificar el uso de TOR. Evitar que nadie te rastree o al menos ponérselo difícil.

Otro punto positivo y útil es evitar la censura en determinados países tanto dictatoriales como falsas democracias que atentan sin pudor ninguno, contra la privacidad y la libertad de expresión de sus ciudadanos.

Visto así podemos dilucidar un aspecto muy positivo del uso de TOR. Pero ¿Y si es para cometer delitos premeditados?

Obviamente es su parte mala. El símil de la navaja es muy gráfico. Todos tenemos acceso a navajas y podemos usarla para pelar naranjas, cortar alimentos, etcétera…pero también puede ser usada para hurtos, agresiones, etcétera…

TOR es lo mismo aplicado al anonimato.

Aspectos de seguridad.

Muchas veces nos centramos en proteger nuestra Web de ataques SQLi, cerrar puertos, etcétera… pero olvidamos acciones básicas que pueden evitarnos muchos dolores de cabeza al igual que MB en los logs de nuestros servidores.

La mayoría de sitios Webs y servidores que auditamos son accesibles desde la red TOR, ¿en serio queremos que accedan desde la red TOR?¿Es necesario?

Evidentemente si somos una Web de derechos humanos o relacionada con las libertades y derechos de las personas esto no sería recomendado puesto que estaríamos “taponando” la comunicación con seres humanos represaliados.

Bloqueando accesos desde TOR

Si tienes un sistema WAF (Web Access Firewall) o Firewall o cualquier sistema de seguridad perimetral puedes añadir reglas de tipo “blacklist” para bloquear estos accesos.

Esta lista, que se actualiza cada 30 minutos, puedes tomarla de https://www.dan.me.uk/torlist/ y dar un “toque” extra de seguridad a tu sitio.

De igual forma, es conveniente el bloqueo de IP’s que procedan de países del Este o Chinos que en un porcentaje bastante alto, tienen intenciones poco benignas.

En un sitio Web puedes hacerlo fácilmente usando .htaccess utilizando estos comandos por ejemplo:

    GeoIPEnable On

    SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry

    Deny from env=BlockCountry

Con estas órdenes anteriores bloqueamos acceso de IPs de países como Rusia o China.

A continuación una opción muy contundente que penaliza en visitas eso si, es usar una lista blanca de países que se permite el acceso a tu sitio:



    GeoIPEnable On
    SetEnvIf GEOIP_COUNTRY_CODE AR AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE PO AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE ES AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE VE AllowCountry

    Deny from all
    Allow from env=AllowCountry

Podemos usar .htaccess para bloquear IPs de nodos TOR pero es poco práctico. La síntaxis sería añadir línea por cada IP.

Por ejemplo:

deny from 217.13.197.5
deny from 217.40.254.177
deny from 217.70.191.13
deny from 217.115.10.131
deny from 217.115.10.133
deny from 217.115.10.134
deny from 217.123.236.30
deny from 217.160.24.166
deny from 217.173.74.91
deny from 217.210.165.43
deny from 217.245.151.118
deny from 218.191.130.126
deny from 219.78.40.173



Si tenemos 10, 20 o incluso 100 puede bastar pero estos listados son muy extensos como para añadir a “manopla” esto.

No obstante, existen un plugin para WordPress “Maltor” que sincroniza las listas de IPs TOR que hemos comentado anteriormente con tu WordPress y evita y las bloquea.

Esto sirve como noción básica para al menos aprender como podemos dificultar visitas indeseadas en nuestras infraestructuras en Internet.

Sin más, espero que te haya gustado el artículo y no dudes en compartilo si lo crees conveniente.

Anonimato en la red con I2P

Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)con la misma idea. La primera utiliza “onion routing” y, la segunda, “garlic routing” para intentar conseguir este objetivo. En realidad, ambos tipos de enrutamiento presentan muchas similitudes.
¿Cómo funciona I2P?

En esta red, para conseguir anonimizar los mensajes enviados, necesitamos un router I2P. Este router, creará unos túneles de entrada y, otros tantos, de salida, unidireccionales. Si queremos enviar un mensaje a un cliente, será enviado por un túnel de salida, hacia un túnel de entrada del mismo.

Para encontrar los túneles hacia el cliente que queremos conectar, se hace una búsqueda en la base de datos distribuida, utilizando una adaptación del algoritmo   Estos túneles serían algo parecido a los circuitos que se utilizan en TOR, con una diferencia: Tienen una corta duración. Esto, en principio, permitiría, en caso de un ataque, complicar la captura de datos por parte del atacante.

Las apliciones y webs están alojadas bajo un dominio, .i2p, similar a los dominios .onion. Para acceder a ellos, necesitamos hacerlo a través del router I2P. También podremos navegar fuera de I2P, quedando nuestra IP oculta, al igual que ocurre con TOR.

Podemos utilizar cualquier aplicación web que queramos. Dentro de nuestro router, apuntaríamos a ella, para poder utilizarla. En principio, disponemos de varias aplicaciones preconfiguradas, como un servidor web, correo electrónico, cliente bittorrent, irc, etc.

Debemos tener en cuenta que I2P está todavía en fase beta, aunque ya va por la versión 0.9.14. Sus desarrolladores hacen incapié en esto, pero, a su vez, consideran que es suficientemente estable para poder ser usada.

Por otra parte, cuanto más grande sea la red, mayor será el anonimato de sus usuarios. En este sentido, comparando con TOR, I2P es una red muy pequeña. Sin embargo, este hecho hace que no tenga todavía demasiados ojos encima de ella, intentando romperla: Éstos están puestos en TOR, lo que supone un balón de oxígeno, para ir solventando problemas de escalabilidad, rendimiento, corrección de bugs, etc, y,  por supuesto, para crecer y poder aumentar la capacidad de anonimato.
Instalando en 3,2,1…

Tal y como podemos ver en la zona de descargas está disponible para sistemas Windows, OS X, FreeBSD, GNU/Linux y, en desarrollo, Android. Dado que software libre, también está diponible el código fuente.

Necesitamos tener Java instalado, pues el router está desarrollado en este lenguaje. Hay en marcha un router I2P, escrito en C++, en https://github.com/PrivacySolutions/i2pd.

Para sistemas Debian y derivadas, disponemos de repositoriospara las distribuciones basadas en ArchLinux, está disponible en el AUR.  En el caso de ArchLinux, disponemos de dos opciones: i2p o i2p-bin. El primero instalará compilando, y, el segundo, está precompilado. En mi caso, opté por i2p. Una vez instalado, tan solo hace falta levantar el servicio:

# Instalamos

wget https://aur.archlinux.org/packages/i2/i2p/i2p.tar.gz

tar -zxvf i2p.tar.gz

makepkg -si

# levantamos el servicio:

sudo systemctl start i2prouter.service

Una vez hecho esto, ya tenemos nuestro router I2P funcionando. Para acceder al panel de control, debemos ir a http://localhost:7657. Lo primero que debemos hacer hacer es configurar nuestro ancho de banda. Esto se hace en http://localhost:7657/config.

Hecho esto, debemos configurar el navegador. Nos dirigimos a la configuración del proxy y establecemos el http a localhost:4444 y https a localhost:4445. Por ejemplo, en Firefox, nos dirigimos a Editar -> Preferencias -> Avanzado y, en Conexión, pinchamos en Configuración:

Hecho esto, ya podemos navegar por la red I2P. Si queremos disponer de un correo electrónico que garantice nuestro anonimato, disponemos de la aplicación SuSiMail, ya configurada, para poder utilizar el servicio Postman’s anonymous email service Otra característica, es que podemos actualizar el router desde la consola, además de instalar pulgins desde la misma. Para ello, debermos establecer las siguientes opciones en el fichero /opt/i2p/.i2p/router.config:

router.updateDisabled=false

routerconsole.enablePluginInstall=true

Conclusión

Cómo puede verse, la instalación y uso es muy sencilla. La aplicación viene preconfigurada para poder crear nuestra propia web, además de otras aplicaciones. Su panel de control es muy fácil de administrar y muy completo.

Aunque aún no pueda considerarse una alternativa real a TOR (todavía no se ha liberado la versión 1.0, estable, el tamaño de la red no es tan grande, hay pocos proxys de salida a internet, provocando cuellos de botella, etc), es un proyecto a tener en cuenta.

Si nos decantamos por utilizar esta red, es recomendable seguir su cuenta en Twitter, para estar informados de cómo va el proyecto. De todas formas, en el panel de control, nos muestra también las noticias actualizadas.

Cifrando el tráfico DNS con DNSCrypt

DNSCrypt nos permite cifrar el tráfico entre el usuario y el servidor DNS. De esta manera, nos vamos a proteger de diferentes ataques, como Spoofing, Man in the Middle o Spying. Para hacer esto, bastará instalar y configurar el proxy DNSCrypt.

Además, vamos a utilizar dnsmasq. Es un paquete que nos permite instarlar de una manera sencilla, un servidor DNS y un servidor DHCP, sólo tenemos que instalar y arrancar el servicio dnsmasq. De esta manera, podremos mejorar el rendimiento de DNSCrypt, al utilizar la caché de dnsmasq. Podremos resolver los nombres que tengamos configurados en el /etc/hosts y, esta resolución, será, tanto en sentido directo, como inverso. También podremos tener el servicio de DHCP, añadiendo, simplemente, una línea al archivo de configuración de dnsmasq, indicando el rango de cesión.

Estas herramientas suelen estar incluidas en muchas distribuciones GNU/Linux. Su configuración es muy similar. En este caso, utilizaré ArchLinux.

Vamos a empezar por dnsmasq:

$ sudo pacman -S dnsmasq



Lo primero que tenemos que hacer es editar /etc/dnsmaq.conf y descomentar la linea #listen-address= , y agregamos la dirección IP de nuestro servidor. Si solo lo vamos a utilizar desde nuestro equipo (útil para la caché), la IP será la de localhost, 127.0.0.1. Si queremos que otros equipos de nuestra LAN puedan utilizarlo, pondremos la IP del equipo.

listen-address=127.0.0.1

Ahora, necesitamos que la primera IP que se utilice para resolver los nombres, sea la de nuestro servidor. Para esto, deberemos configurar el cliente DHCP. Éste será quien genere el archivo /etc/resolv.conf, con los diferentes servidores que se utilizarán. Dependiendo del servicio que utilicemos para configurar la red, podremos utilizar varios métodos.

El método más rápido será generar nosotros mismos el /etc/resolv.conf. Tan sólo editamos el archivo, y ponemos, al principio:

nameserver 127.0.0.1

Tras esta línea, especificaremos los servidores DNS externos. Para que el servicio dhcpd no sobreescriba el /etc/resolv.conf, editamos el archivo /etc/dhcpcd.conf y añadimos la opción nohook resolv.conf.

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
noipv4ll
nohook resolv.conf


Otra opción, es utilizar una característica de dhcpd. Si existen los archivos  /etc/resolv.conf.head y /etc/resolv.conf.tail, los utiliza para generar la cabecera del /etc/resolv.conf. Bastará editar el /etc/resolv.conf.head y añadir ahí la línea nameserver (debe ser la primera).

Una limitación en los sistemas Linux, es que, en las consultas de DNS, sólo puede haber tres servidores, como máximo, en el /etc/resolv.conf. Esto podemos solucionarlo, creando un archivo con los servidores que necesitemos y pasándolo a dnsmasq. De esta manera, el /etc/resolv.conf, sólo contendrá un servidor, el nuestro. Primero, creamos el archivo /etc/resolv.dnsmasq.conf, con los servidores externos que necesitemos, por ejemplo, con las DNS de google:

nameserver 8.8.8.8
nameserver 8.8.4.4

En el archivo /etc/dnsmasq, buscamos la línea resolv-file, la descomentamos y añadimos el la ruta del archivo anterior:

# Change this line if you want dns to get its upstream servers from
# somewhere other that /etc/resolv.conf
resolv-file=/etc/resolv.dnsmasq.conf

Para dhclient, eliminamos en /etc/dhclient.conf, la siguiente línea:

prepend domain-name-servers 127.0.0.1;

Si estamos utilizando NetworkManager (es usado por defecto en multitud de distribuciones), podemos indicarle que levante el servicio dnsmasq y, además, añadir opciones de configuración. Para esto, editamos el archivo NetworkManager.con, que se encuentra en /etc/NetworkManager/ y, en la sección [principal], añadimos la opción:

dns = dnsmasq

Ojo, hay que asegurarse de que el servicio no se levanta automáticamente. En el caso de ArchLinux, como aún no lo hemos indicado, no lo hará.

Las opciones que deseemos añadir, las especificaremos creando archivos en el directorio /etc/NetworkManager/dnsmasq.d/ (si éste no existe, lo creamos). Por ejemplo, para aumentar la caché, creamos el archivo /etc/NetworkManager/dnsmasq.d/cache, con el siguiente contenido:

cache-size=1000

Bien, ya podemos utilizar dnsmasq. Para levantar el servicio, bastará ejecutar:

systemctl start dnsmasq.service

Y para que se inicie automáticamente en cada inicio del sistema:

systemctl enable dnsmasq.service

Una vez que ya tenemos dnsmasq, que nos va a servir como caché de DNS, vamos a instalar el DNSCrypt, que será quien nos cifre el tráfico, cuando realicemos las peticiones:

$ sudo pacman -Syu dnscrypt-proxy

El paquete viene preconfigurado para utilizar, como DNS externas, las OpenDNS. Si queremos utilizar otras, podemos ver el listado de alternativas aquí  Dado que viene configurado para escuchar en la IP 127.0.0.1, que es la misma que hemos utilizado para dnsmasq, deberemos cambiarla. Todo esto, se pude configurar editando el archivo /etc/conf.d/dnscrypt-proxy. Lo dejaríamos así:

NSCRYPT_LOCALIP=127.0.0.2
DNSCRYPT_LOCALPORT=53
DNSCRYPT_USER=dnsmasq
DNSCRYPT_PROVIDER_NAME=2.dnscrypt-cert.opendns.com
DNSCRYPT_PROVIDER_KEY=B735:1140:206F:225D:3E2B:D822:D7FD:691E:A1C3:3CC8:D666:8D0C:BE04:BFAB:CA43:FB79
DNSCRYPT_RESOLVERIP=208.67.220.220
DNSCRYPT_RESOLVERPORT=443

El usuario dnsmasq se crea automáticamente al instalar dnsmasq, para que este servicio se ejecute con un usuario sin privilegios, por seguridad. Podemos utilizarlo aquí también.

Una vez hecho esto, hay que asegurarse que dnsmasq no consulta a otros servidores externos. Esto quiere decir que, si hemos utilizado el método de editar directamente /etc/resolv, sólo deberán aparecer los servidores DNS internos. En nuestro caso, sólo la IP 127.0.0.1.

En el el archivo /etc/resolv.dnsmasq.conf, deberá aparecer sólo la IP de DNSCrypt, 127.0.0.2. Éste será el encargado de resolver las consultas externas, por lo que, no debemos añadir ningún servidor más.

Además de esto, debemos descomentar, en /etc/dnsmasq.conf, la línea:

bind-interfaces

Si utilizamos algún método diferente para configurar la red, debemos asegurarnos que el servidor de DNS apunte a 127.0.0.1. De esta manera, las peticiones pasarán primero por dnsmasq. Aquellas consultas que sea necesario realizar a un servidor externo, se harán mediante DNSCrypt. Podríamos utilizar DNSCrypt directamente pero, entonces, no tendríamos una caché, con lo que, la navegación sería más lenta.

Habilitamos los dos servicios para que se arranquen en el inicio (en el caso de NetworkManager, ya vimos que no es necesario levantar dnsmasq) y los iniciamos:

sudo systemctl enable dnscrypt-proxy.service dnsmasq.service

sudo systemctl start dnscrypt-proxy.service dnsmasq.service

Una consecuencia indirecta de utilizar DNSCrypt es que, si nuestro ISP ha bloqueado alguna dirección, podremos “saltarnos” esta restricción, siempre que OpenDNS o los servidores alternativos utilizados, no la tengan bloqueada.

Honeypot. Un tarro de miel para los atacantes.

En el artículo de hoy trataremos el tema de los Honeypots. Este tema es bastante desconocido para mucha gente, ya que es un concepto bastante contradictorio.

Honeypot significa en inglés, “tarro de miel”. Es una herramienta que se usa casi exclusivamente en el campo de la seguridad informática. Su función se basa en atraer y analizar ataques realizados por bots o hackers. Y podremos decir: ¿Atraer? ¿Pero el quid de la cuestión no es repeler?. Pues bien, su objetivo es atraer atacantes para ver sus pautas de ataque, generar diccionarios para recopilar que palabras usan en ataques (para no usarlas en tu sistema), conocer al enemigo y su perfil.

Bueno, ¿y cómo es un honeypot?. Un honeypot puede ser tan sumamente sencillo como un equipo informático cualesquiera que analice el tráfico entrante y saliente hacia Internet. Pero es importante “habilitar” o no sanear alguna vulnerabilidad del S.O, en algún protocolo, programa o cualquier otro elemento para así atraer más fácilmente a un atacante o atacantes.

Pero por otra parte, un honeypot puede ser bastante complejo. Puede funcionar como una red de ordenadores, funcionando con diversos sistemas, y con infinidad de servicios. Con esto, cuando uno de los equipos es atacado inmediatamente es informado el administrador de sistemas.

Una de las opciones más utilizadas es usar un honeypot en forma de programa. Hay honeypots que simulan ser una red local de múltiples equipos, ips falsas, directorios inventados, equipos no presentes, etc… para crear gran confusión al atacante y/o para detectar nuevos métodos de ataque y poder aplicar defensas a nuestra red real.

También pueden guardar usuario y contraseña que el atacante introduce, bien manualmente, o por medio de diccionarios para así poder excluir todos esos caracteres alfanuméricos o no de contraseñas en nuestra red real.

A continuación os mostramos un esquema de un honeypot en una red local:

Podemos decir, que un honeypot es un gran aliado para defender tu red, aunque el concepto sea atraer ataques, la mejor táctica para defenderse es saber como actúa el enemigo y que mejor que ponerle un cebo el cual no supondrá un riesgo para nuestra red, y nos ayudará a saber como incide el ataque y de que manera.

Los honeypots más conocidos son: honeyd, kippo(ssh), Valhalla, Specter, honeynet…

Unos son mas fáciles de usar, otros más complejos, pero altamente configurables, aunque la forma más fácil de saber cuál va a cubrir nuestras necesidades será probándolos.

dejando al desnudo a tu conexión

Los fallos de seguridad están que no paran desde que Heartbleed alcanzó nuestras conexiones, tenemos que enfrentarnos a otra vulnerabilidad en el SSL,  nos puede desnudar nuestra conexión rompiendo su seguridad.
El problema de Logjam reside en el protocolo criptográfico llamado Diffie-Hellman que permite negociar una clave compartida para generar una conexión segura, para cada conexión.

El ataque permite bajar el cifrado a 512-bits, haciendo que sea fácil de romper comparado a 2048-bits, por lo que se puede realizar un ataque MITM.

Los navegadores ya están trabajando en parchear el problema, pero también se tiene que poner las pilas los Sysadmin, para ellos tenemos que seguir los siguientes pasos:

Lo primero reconstruimos nuestro grupo único de Diffie-Hellman, los navegadores recomienda 1024-bits, los investigadores 2048-bits pues que nos ponemos yo los he pasado a 4096-bits, veremos quien rompe eso 😉
?
1
   
openssl dhparam -out dhparams.pem 4096

Una vez creado nuestro nuevo DH vamos a reconfigurar nuestros protocolos y cifrados.

Desactivando SSLv2 y SSLv3

Apache:
?
1
   
SSLProtocol             all -SSLv2 -SSLv3

Nginx:
?
1
   
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;



Y priorizando el orden de carga de los cifrados, cargando del mas robusto al menor.

Apache:
?
1
2
3
   
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

Nginx:
?
1
2
3
   
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;



Ahora para acabar nos queda reconfigurar donde esta nuestro nuevo archivo HD
Apache:
?
1
   
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"

Nginx:
?
1
   
ssl_dhparam {path to dhparams.pem}

Después de reconfigurar nuestro servidor, tenemos que reiniciar el servicio para cargar los nuevos parámetros y comprobar que ya somos seguros, para ello disponemos de esta web para realizar los test.

https://weakdh.org/sysadmin.html

Durante unos días hasta que todo el mundo realice el parche y actualice sus navegadores hay que extremar las precauciones con las conexiones que realizamos.

Y este problema nos vuelve a surgir por en Estados Unidos en la década de 1990 que como vemos en el informe original en la era Clinton, donde se limita el tamaño de DH a los primeros 512-bits primos para que fueran fáciles de romper para las agencias americanas.

    To comply with 1990s-era US export restrictions on cryptography, SSL 3.0 and TLS 1.0 supported reduced-strength DHE_EXPORT cipher suites that were restricted to primes no longer than 512 bits.

Lo grave es además de afectar a HTTPS, afecta también a SMTP+StartTLS, POP3S, IMAPS y de estos afecta al 8.4% según los investigadores de las páginas que están en el top 1 millón, no quiero saber cómo afectará a las medianas y pequeñas…

Así que ya sabes si no te fías de si la página a la que estás conectada ha corregido el problema primero compruébalo con este test y si no te queda otra que conectarte antes de que se repare el problema y no estas en una conexión que consideres segura es mejor que uses una VPN para poder salir por un sitio más seguro.

Usando Nmap para detectar Heartbleed

A estas alturas, pocas personas existirán que no hayan escuchado hablar de Heartbleed, considerado uno de los bug más críticos de la historia de internet.

No entraré en más explicaciones de Heartbleed, puesto que existen ya infinidad de sitios hablando de ello, aunque uno que explica todo muy claro lo tenéis en el blog Un Informático en el lado del mal.

En estos pasados días me ha tocado dedicarme exclusivamente a este bug en OpenSSL por lo que he debido informarme bien de en qué consistía exactamente hasta al mismo nivel del código fuente.

Una vez entendido ha tocado escanear una gran cantidad de IPs para comprobar qué hosts eran vulnerables. En esta ocasión me centro en servidores que pueden estar dando servicios que usan OpenSSL vulnerable, aunque no olvidéis que los clientes también pueden serlo.

Dado que la cantidad de IPs a escanear superaba los pocos miles, debía automatizar el scanning de alguna manera. Voy a explicar sin entrar en mucho detalle cómo fue el proceso.

Aclarar que he utilizado BackTrack 5 RC2 y Nmap 6.25.

1ª Situación

Cuando empecé el chequeo no existía exploit, tan sólo la web que todos conocemos para comprobar online si una aplicación bajo un dominio y puerto es vulnerable.

Por lo tanto el proceso sería usar nmap con fingerprinting de los servicios y una vez localizados aquellos servicios que podrían estar usando una versión vulnerable de OpenSSL comprobarlos en la web. Inviable dada la gran cantidad de IPs a comprobar.

2ª Situación

Sale el primer exploit en Python. Por lo tanto la idea cambia. Analizar qué servidores tiene esas servicios abiertos y crear un script para correr el exploit en esos servidores. Tedioso.

3ª Situación

Sale el primer script para nmap para comprobar Heartbleed. Suena perfecto. Tras unos cuantos escaneos me doy cuenta de que nmap me esta dando algunos falsos negativos, es decir, servidores que son de hecho vulneables, nmap los muestra como no vulnerables. Toca analizar a mano algunos de ellos aunque muchos otros ya son marcados correctamente gracias al script.

¿Situación final?

Sale una modificación del script para nmap que hace también Hearbeat request usando TLS 1.0, TLS 1.1 y TLS 1.2. En problema de los falsos negativos en la etapa anterior venía de que el script sólo comprobaba TLS 1.1.

El nuevo script podéis encontrarlo aquí . Se instala igual que cualquier otro script para nmap. En BackTrack (BT BT!!!) bajáis el fichero .nse y lo metéis en directorio usr/local/share/nmap/scripts/

En mi instalación de nmap por defecto el script me daba error ya necesita la librería tls para realizar conexiones “seguras” (si es que las hay hoy en día, un saludo  para la NSA por cierto). Para instalar esta librería debéis descargarla de aquí y alojar el fichero .lua en nselib de vuestro nmap.

Ya tenemos todo listo para escanear. Este es el comando que yo he usado:

 # nmap -iL ip_ranges -sV –top-ports 100 –script ssl-heartbleed -oA nmap_heartbleed_results

Breve explicación del comando:

-iL ip_ranges: ip_ranges es un fichero plano con todas las IPs a escanear. Muy útil cuando la cantidad es grande. Podemos incluir ahí IPs individuales, rangos de Ips, IPs de red con máscara… Se puede poder una en cada línea y mezclando formatos.

 –top-ports 100: Nmap escaneará sólo los 100 puertos más comunes. Esta clasificación está basada en el fichero nmap-services y cogerá aquellos 100 puertos con el ratio más alto. En mi caso era suficiente para cubrir los servicios más importantes que podrían utilizar OpenSSL.

–script ssl-heartbleed: Hacer uso del script para este bug.

-oA nmap_heartbleed_results: Cuando uso nmap, acostumbro a sacar los resultados en todos los formatos posibles, de modo que podremos grepearlos a nuestro antojo, exportar XML a otros formatos, etc.

No dudéis en reducir el scan sólo a los puertos que realmente queráis comprobar, ahorraréis tiempo.

Una vez tengáis los resultados, podréis exportarlos a un bonito HTML con la aplicación xsltproc.

Ahora a reportar y parchear, que la ocasión lo merece.PD: no tengo a mano los resultados por lo que no puedo publicar ninguna captura. Aún así, no os debe resultar difícil encontrar un servidor vulnerable o montar el vuestro propio para las pruebas.

Ataque BadUSB Man-In-The-Middle

Como ya habréis notado gracias a nuestro anterior artículo, en los últimos días en hacking-etico.com hemos estado probado la nueva maravilla que nos trae el equipo de Kali Linux: NetHunter. Aprovechando que yo también dispongo de un terminal Nexus 5 he decidido instalar y probarlo y las sensaciones son muy buenas.

Si aún no sabéis cómo descargarlo e instalarlo, os recomiendo nuevamente que leáis “NetHunter: Kali Linux en tu Android“, un estupendo artículo nos trae nuestro compañero Manuel Camacho en donde nos explica todo lo que necesitáis saber para tenerlo en vuestro dispositivo Nexus.

Uno de los ataques que más fácilmente nos permite hacer NetHunter es un curioso Man-In-The-Middle con el que me llevé una grata sorpresa. Vamos a centrar este artículo en explicar cómo funciona, por qué funciona, cómo explotarlo y cómo defendernos ante ello.

Este año tuve la suerte de asistir a la BackHat en Las Vegas, donde una de las más esperadas charlas era la de BadUSB y que a título personal me dejó maravillado. Ya se empiezan a ver las primeras implementaciones y vectores de ataque: Por parte de los chicos de NetHunter tenemos “BadUSB MITM Attack“. Ya podéis imaginar cual será el vector de ataque… con tan sólo conectar el móvil por USB a un ordenador con Windows conseguiremos redirigir todo el tráfico a nuestro móvil y hacer lo que queramos con él… guardarlo, modificarlo, bloquearlo… ¿interesante verdad? ¡A partir de ahora nos pensaremos dos veces cuando alguien nos pida que le carguemos el móvil en nuestro ordenador! Pero eso no es todo… seguid leyendo porque os cuento más adelante que la cosa es más grave aún.

Vamos al lío. Para ello voy a diferenciar tres secciones:

    Explotando Ataque BadUSB MITM: Mostrando cómo se explota y resultado en un escenario real.
    Entendiendo Ataque BadUSB MITM: Analizaremos en detalle cómo y por qué funciona el ataque.
    Defendiéndonos del Ataque BadUSB MITM: Una vez hemos analizado y entendido cómo funciona, podemos tomar un serie de acciones para evitar que este ataque sea efectivo en nuestras máquinas.


Explotando Ataque BadUSB MITM

Es momento de ver en acción cómo funciona el ataque. He escogido el vídeo oficial que la gente de NetHunter ha publicando donde se puede ver una demostración del ataque de una manera muy sencilla y directa. Si no entedéis bien inglés no os preocupéis puesto que en la siguiente sección lo veremos en detalle

¿Tiene buena pinta? Pues pasemos al a siguiente sección donde vamos a entender un poco mejor cómo funciona.


Entendiendo Ataque BadUSB MITM

A continación explicaré un poco más en profundidad cómo funciona la implementación de este ataque MITM. Para ello he grabado el siguiente vídeo (no olvidéis verlo en HD para ver todos los detalles sin problema) en el que veremos con detalle paso a paso todo lo que va sucediendo desde el principio hasta el final del ataque:

Como prueba de concepto y para comprobar que realmente se está capturando el tráfico, he filtrado tcpdump para capturar sólo el tráfico con destino al puerto 21 y guardarlo en el fichero mitm.pcap

Una vez hecho lo anterior, me conecto desde la máquina víctima a un servidor FTP insertando un usuario y contraseña de prueba sólo para ver si realmente se está capturando el tráfico. Al abrir el fichero pcap con Wireshark vemos que efectivamente el usuario y contraseña han sido capturados

,

 Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.
Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

BadUSB MITM

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

Sin título3

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

Varios puntos a aclarar:

El dispositivo móvil debe estar conectado a internet para que esté propiamente en el medio de la comunicación.

Aunque no lo he probado, probablemente este ataque no funcione en máquinas UNIX debido a la manera en la que UNIX administra las puertas de enlace por defecto.

El ataque funciona aunque la sesión Windows del usuario esté bloqueada, es decir, nos encontremos ante la pantalla de inicio de sesión donde hay que meter la contraseña del usuario para acceder de nuevo a su sesión. Este escenario es muy común, puesto que en entornos de trabajo cuando el empleado se ausenta, una buena costumbre es bloquear la pantalla con “Windows + L”. Aún así, el ataque funcionará. Por lo tanto… imaginen un entorno donde podamos acceder a un puerto USB de una máquina importante (ufff se me ocurren tanto sítios públicos donde puertos USB son accesibles), es cuestión de enchufar el móvil, guardar el tráfico durante un tiempo y luego analizarlo en casa tranquilamente.

Defendiéndonos del Ataque BadUSB MITM

Como ha quedado demostrado, el principal problema es que Windows asigna a la métrica de la nueva ruta un valor menor al que la ruta por defecto ya tiene. ¿Qué podemos hacer entonces? Bueno se me ocurre algo bien sencillo como solución rápida y temporal: asignar un valor estático y menor a nuestra ruta por defecto y por lo tanto aunque se cree una nueva ruta para el tráfico por defecto, éste tendrá un valor mayor y por lo tanto el tráfico se seguirá enviando por nuestra interfaz de red.

Para ello nos vamos Conexiones de red y entramos en las propiedades de la interfaz de red que conecte con internet (igualmente con otras interfaces importantes, por ejemplo aquellas para tráfico de intranet).

A continuación quitamos la opción de que la métrica de la ruta se calcula automáticamente y le ponemos un valor manual de 1:

De este modo, cuando Windows tenga dos rutas para el tráfico 0.0.0.0 siempre lo enviará por esta interfaz al tener una métrica mejor que la creada por NetHunter.

Es importante no olvidar que esto se debe hacer tanto para IPv4 como IPv6.

Sólo una última nota: Ojo porque el tráfico DNS se seguiría enviando por ambos y si no estoy equivocado, tráfico multicast actuaría del mismo modo. Desde luego este “parche” no soluciona el verdadero problema de raíz.

- See more at: http://hacking-etico.com/2014/10/08/ataque-badusb-mitm/#more-3730