En ocasiones, podemos querer conectarnos a una red WiFi abierta; existen dos escenarios, a saber: (1) estamos en la universidad/cafetería/… de turno o (2) somos muy majos y queremos dejar nuestra red abierta para el disfrute de los demás. Obviamente, hacerlo sin seguridad es un suicidio porque cualquiera puede estar monitorizando nuestro tráfico y, quién sabe, intentando robar contraseñas, etc. Por ello, a continuación voy a pasar a explicar cómo añadir nosotros mismos una capa de seguridad para utilizar redes WiFi abiertas con tranquilidad (aunque este método tampoco es 100 % seguro, digamos que sí en un 99 %, a no ser que nos encontremos en una DEFCON o similar…).

Ambos escenarios descritos requieren un servidor SSH que puede estar disponible en nuestro router WiFi, o bien podemos poner nosotros mismos una máquina vieja con Linux en nuestra red (existen excelentes tutoriales para todo tipo de servidores). En el escenario (2) no se necesita nada más porque el servidor se encontrará en la misma red desde la que nos conectamos (la de casa). En el (1) accederemos a ese servidor a través de Internet, así que se hace difícil de localizar debido a que los ISP proporcionan direcciones IP dinámicas; luego necesitaremos un servicio como DynDNS (que puede configurarse en la mayoría de los routers, por no decir en todos) para disponer de un nombre de host fijo con el que “llamar a casa”.

El método que utilizaremos se denomina Dynamic Port Forwarding y nos sirve para enviar todas nuestras conexiones a través de un túnel SSH cifrado que actúa como proxy SOCKS local. Esto, que probablemente sonará a chino, es algo así:

Las conexiones que antes se realizaban en claro y que podían ser interceptadas durante su periplo aéreo, ahora viajan a través de un túnel cifrado hasta un servidor SSH desde el que se redirigen a su destino final. Este esquema es para el escenario (1); en el escenario (2), el router y el servidor SSH son el mismo equipo. Ahora bien, ¿qué aplicaciones y configuraciones necesitamos?

En Windows

Existen aplicaciones que ya implementan la posibilidad de utilizar un proxy SOCKS, como Firefox o Skype. Otras en cambio no: Tweetdeck, etc. En cualquier caso, aunque todas las aplicaciones lo soportasen, habría que ir una por una configurándolas a tal efecto. En su lugar, vamos a ver cómo utilizar una herramienta llamada proxyficador que se encarga de monitorizar las actividades de red de todos los programas y redirigir ese tráfico a un servidor proxy. En concreto, el software necesario es el siguiente:

• PuTTY: necesario para abrir el túnel SSH.
• Proxyfier: la misma palabra lo dice. No es freeware, pero no he encontrado nada mejor. En otros programas, como FreeCap, es necesario hacer un perfil para cada aplicación. Proxyfier, en cambio, redirige automáticamente todo el tráfico de cualquier aplicación si así se lo indicamos.

El primer paso consiste en abrir la conexión SSH indicando que se desea reenviar a través de dicha conexión todo el tráfico destinado a un puerto (para nuestros ejemplos utilizaremos el puerto 8080). Para ello, abrimos PuTTY y ponemos la ruta al servidor SSH en el campo Host Name (ejemplos: servidorssh.dyndns-home.com desde fuera de la red, 192.168.1.1 desde dentro de la red).

A continuación, en la columna de la izquierda desplegamos Connection > SSH y pinchamos en Tunnels. Una vez allí, (1) indicamos el puerto, (2) marcamos la opción Dynamic, (3) añadimos la opción y (4) abrimos la conexión. Se nos pedirá que aceptemos el certificado (¡hay que revisar bien que es el auténtico!) junto con el nombre de usuario y la contraseña (previamente configuradas en el servidor SSH).

El siguiente paso es instalar y configurar Proxyfier. En primer lugar configuramos las reglas de proxyficación.

En el cuadro de diálogo que se abre, marcamos Process All except the following + manually proxyfied, lo que significa que proxyficará todo el tráfico salvo la lista de exclusiones siguiente. Aquí tenemos que añadir, aparte del loopback que ya viene por defecto, la propia aplicación PuTTY para no crear un bucle sin sentido, así que presionamos Add.

En el siguiente diálogo, (1) ponemos un nombre representativo, (2) añadimos el ejecutable de PuTTY y (3) presionamos OK.

Ahora le toca el turno a las opciones del proxy.

Para añadir el proxy que vemos en la siguiente imagen, presionamos Add.

En el diálogo emergente, (1) indicamos la dirección local como dirección del proxy, (2) el puerto, (3) el protocolo y (4) OK.

Para lograr mayor privacidad, si queremos que las peticiones DNS también viajen por el túnel y que nadie sea capaz de ver qué sitios visitamos, acudiremos a la pestaña de resolución de nombres.

Allí tenemos que marcar la opción Remotely para lograr lo descrito antes.

¡Y listo! Al cerrar el programa se minimiza a la barra de tareas y hace su trabajo en silencio. Ya podemos navegar tranquilamente.

En Linux

Para establecer la conexión SSH, basta con abrir una terminal y escribir el siguiente comando:

ssh -D 8080 <nombre_de_usuario>@<servidor_SSH>

No he encontrado ningún programa de Linux que redirija el tráfico de cualquier programa automáticamente hacia el proxy SOCKS. Lo más parecido a Proxyfier es el proyecto Kernel Socks Bouncer, pero es un módulo del kernel y no lo he probado. Sin embargo, tenemos otras soluciones menos versátiles pero fáciles de utilizar como ProxyChains y tsocks. Para utilizarlos, hay que editar el archivo de configuración correspondiente (/etc/proxychains.conf y /etc/tsocks.conf respectivamente) e incluir el servidor (127.0.0.1) y el puerto (8080). Después, para que una aplicación utilice el túnel cifrado basta con llamarla por línea de comandos de la siguiente manera:

tsocks <aplicación> [argumentos]

Steve Jobs ha arremetido en diversas ocasiones contra Adobe por la catidad de bugs que contiene Flash, pero parece ser que Apple tampoco se escapa de esta lacra. Y es que Charlie Miller, un reputado hacker formado en la NSA, revelará esta misma semana en la CanSecWest de Vancouver 30 vulnerabilidades críticas (que permiten la ejecución de código) en programas comunes de MacOS, el sistema operativo de Apple.

Lo más curioso es cómo lo hizo. Construyó un script en Python de apenas 5 líneas de código que cambiaba un bit aleatorio de ficheros PDF o PPT y se los pasaba a distintas aplicaciones. De esta manera, encontró unas 1000 maneras de hacer que dichos programas dejasen de responder y, de todas ellas, encontró que 30 permitían la ejecución de código. La aplicación Preview (vista previa) de Apple ha sido la peor parada, con 20 vulnerabilidades críticas realmente simples. Tanto es así que Miller ha titulado su descubrimiento Apple Hacking For Dummies. Dado que el navegador web Safari hace uso de dicha aplicación cuando se abre una página que contiene un PDF, es muy fácil explotar los fallos mediante documentos PDF debidamente manipulados.

Miller, en 2007, ya encontró una manera de ejecutar código en el iPhone visitando una web con Safari y otra mediante un SMS.

(Vía: Hispasec y The Firewall)

Diversas fuentes afirman que «Toshihiro Ohigashi de la Universidad de Hiroshima y Masakatu Morii de la Universidad de Kobe han llevado a la práctica la demostración teórica  de la vulnerabilidad de WPA/TKIP que el año pasado se desveló en la conferencia PacSec», además de que, mediante este ataque, son capaces de «recuperar la clave WPA en cuestión de minutos». Pero que no cunda el pánico, todavía…

Ya hablábamos hace casi un año del ataque propuesto por Erik Tews y Martin Beck, que, por cierto, no tenía nada de teórico. Dicho ataque —que fue incluso implementado en una herramienta de la suite Aircrack-ng llamada tkiptun—, recordemos, era capaz de interceptar el tráfico dirigido al cliente y hallar mediante ChopChop unos cuantos bytes de keystream que permiten mandar paquetes encriptados falsos al cliente sin hallar la clave de encriptación. Recientemente, el método fue investigado y mejorado por la Norwegian University of Science and Technology para que produjese un keystream 10 veces mayor, lo que implica la capacidad de inyectar paquetes de mayor tamaño.

Ahora, los investigadores japoneses citados al comienzo, efectivamente han introducido nuevas mejoras al ataque que amplian su espectro de aplicación, pero en esencia sigue siendo lo mismo y sigue teniendo el mismo calado. La mejora principal radica en que este nuevo ataque no tiene la limitación del anterior, el cual sólo funcionaba sobre protocolos WPA con características de calidad de servicio habilitadas (IEEE802.11e QoS). Mediante la aplicación del ataque MITM, han conseguido eliminar esta restricción, convirtiéndose en una posible víctima cualquier implementación de WPA. La segunda mejora es el tiempo de ejecución. El ataque de Tews y Beck se completaba en unos 12-15 minutos, mientras que el nuevo, teniendo esta cota como máxima, consigue rebajar el tiempo hasta 1 minuto en el mejor de los casos.

Cierto es que WPA sufre un nuevo golpe y que esta capacidad para inyectar paquetes, utilizada por expertos, puede ser usada para realizar múltiples fechorías (léase la tesis de la universidad noruega enlazada anteriormente), pero es falso que se consiga la clave WPA. Sigue siendo un sistema robusto en este sentido y el único ataque posible para averiguar la clave sigue siendo por fuerza bruta.

Ohigashi y Morii realizarán una demostración de todo esto en la PacSec Conference de este año. Estaremos atentos.

CAPTCHA significa «Completely Automated Public Turing test to tell Computers and Humans Apart», es decir, «prueba de Turing pública y automática para diferenciar máquinas y humanos», y son esas imágenes deformadas de las que tenéis que averiguar su contenido y escribirlo para completar satisfactoriamente muchos formularios a lo largo y ancho de la web. Obviamente, aquí «diferenciar» se traduce en hacer algo que un humano pueda resolver y una máquina no. Pero muchas veces, dicha definición pierde toda razón de ser. Para muestra, un botón.

La carrera entre unos —los que inventan dichos CAPTCHA para proteger sus formularios— y otros —los spammers, que siempre se las ingenian para conseguir programas que los descodifican automáticamente— es eterna. Por eso, y para no acabar haciendo algo tan indescifrable como en el enlace de arriba, muchas veces sorprende el ingenio de la gente para inventarse nuevos métodos. Si realizáis una búsqueda, podréis encontrar páginas donde realizan algunas recopilaciones, como las siguientes:

• Top 10 Worst Captchas
• Most Craziest Captchas On The Web

Los hay de todos los tipos: imposibles, graciosos, curiosos, y frikis, muy frikis. Mis preferidos son estos:

Las operaciones matemáticas son muy sencillas. ¿Os atrevéis? Y el que me dé el resultado del último, obtendrá el carné oficial de friki.

Me entero a través de The Inquirer ES de que una de las últimas actualizaciones críticas de Microsoft instala una extensión de Firefox de forma oculta (si este está instalado) y desactiva el botón Desinstalar que llevan todas las extensiones. Si recientemente se ha descargado en vuestro sistema la versión 3.5 de la plataforma Microsoft .NET Framework, comprobad los complementos de vuestro Firefox, porque allí estará.

Al parecer, esta nueva jugarreta de los de Redmond se conoce desde finales de febrero, pero dicha actualización en nuestro idioma llegó hace poco (a mí se me instaló hace una semana). Lo peor de todo —dejando a un lado que se hace sin nuestro consentimiento y que, para más inri, nos impiden la desinstalación— es que (según Annoyances.org) dicha extensión «añade a Firefox una de las más peligrosas vulnerabilidades presentes en todas las versiones de Internet Explorer: la capacidad de que cualquier sitio web instale software en nuestro PC de forma encubierta con total facilidad».

De la misma página, os traigo las instrucciones para eliminar esto de vuestros inmaculados navegadores:

1. Abrir el Editor del Registro de Windows (teclear regedit en la caja Buscar del menú Inicio en Vista/Windows 7, o en la ventana Ejecutar de XP).
2. Navegar hasta la siguiente rama del registro:
   • En sistemas de 32 bits: HKEY_LOCAL_MACHINE \ SOFTWARE \ Mozilla \ Firefox \ Extensions
   • En sistemas de 64 bits: HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Mozilla \ Firefox \ Extensions
3. Borrar el valor llamado {20a82645-c095-46ed-80e3-08825760534b} del panel del registro.
4. Cerrar el Editor.
5. Abrir una nueva ventana de Firefox, y en la barra de dirección, escribir about:config y presionar Enter.
6. Escribir microsoftdotnet en el campo Filtro para buscar rápidamente la opción general.useragent.extra.microsoftdotnet.
7. Click derecho en general.useragent.extra.microsoftdotnet y seleccionar Restablecer.
8. Reiniciar Firefox.
9. Abrir el Explorador de Windows, y navegar hasta la carpeta %SYSTEMDRIVE%\Windows\Microsoft.NET\Framework\v3.5\Windows Presentation Foundation.
10. Borrar la carpeta DotNetAssistantExtension.
11. Abrir los Complementos de Firefox para confirmar que la extensión Microsoft .NET Framework Assistant ha sido eliminada.

La bomba fork es un ataque de tipo DoS para sistemas operativos. Se llama así por la función fork() de UNIX, encargada de crear procesos hijos y base de este ataque. Mediante unas pocas líneas de código ejecutadas por cualquier usuario de manera local, se puede tumbar cualquier máquina en cuestión de segundos. No es algo que se pueda parchear fácilmente debido a que no es ningún fallo ni ninguna vulnerabilidad. Tampoco se puede identificar como virus o malware, porque tampoco lo es. Una bomba fork suele hacer uso de algo tan sencillo como un bucle infinito dentro del cual se crea un proceso hijo. Así, el número de procesos en el sistema crece de forma incontrolada hasta consumir los recursos de la máquina (memoria RAM y procesador), quedando colgada. ¿El resultado? Pues que hay que reiniciar a las bravas (léase tirando del cable o pulsando el botón), pero nada más. No supone ningún peligro, salvo que estemos trabajando con algún documento y no hayamos guardado…

En resumidas cuentas, la bomba fork no es un agujero en la seguridad de los sistemas operativos porque no produce ningún daño (salvo la molestia), porque lo tiene que ejecutar el propio usuario del sistema (luego es un suicidio en toda regla) y porque es más bien una característica de los lenguajes de programación y el resultado de un programador patoso. Vamos, que es lo mismo que tirar del cable de alimentación queriendo. Aun así, no deja de ser una bonita curiosidad.

Vamos a ver unos ejemplos. Empecemos con Linux. Existe una bomba fork para este sistema que tiene el honor de ser considerada «la bomba más bonita jamás creada», tanto por su simplicidad como por su elegancia. El código es el siguiente:

:() { : | : & };:

Así de simple. Si introducimos lo anterior en una consola de Linux, probablemente el ordenador quedará inmediatamente colgado. O no. Este código se conoce desde hace bastante tiempo y es posible que en vuestra distribución de Linux ya no funcione porque hayan implementado algún tipo de protección contra usuarios suicidas. Por ejemplo, en mi Fedora 10 no funciona. Si lo analizamos, es lo mismo que escribir lo siguiente:

funcion() {
	funcion | funcion &
};
funcion

Ahora está mucho más claro: definimos una función y luego la llamamos. Dentro de la misma, se llama a sí misma y el resultado se pasa por una tubería a ella misma de nuevo y todo estos se ejecuta en segundo plano (carácter “&”). Es decir, de cada proceso salen dos nuevos, y de cada uno de ellos, otros dos, y así hasta que el sistema operativo lo permita.

Windows también tiene su versión de línea de comandos, y tiene esta pinta:

:s
start %0
%0 | %0
goto s

Hace lo mismo que la anterior. Basta con guardar esto en un fichero de texto y cambiarle la extensión de “.txt” a “.bat”. Tras esto, ejecutar y disfrutar del espectáculo. Guardad todo lo que estéis haciendo primero, que esta sí que funciona, aunque no deja el sistema totalmente colgado, porque llega un momento que los procesos creados empiezan a dar errores de aplicación y la carga del sistema baja, con lo que se puede llegar a hacer algo, pero de todas formas hay que acabar reiniciando.

Y ahora vienen las bombas buenas. Las que dejan al sistema congelado sí o sí, tanto para Linux como para Windows, en lenguaje C. La primera la del pingüino:

#include <unistd.h>

int main(void) {
	while(1)
		fork();
	return 0;
}

Copiad este código en un archivo y guardadlo como “.c”. Tras esto, compiladlo con nuestro querido gcc —sí, de acuerdo, es una mierda, pero es nuestra mierda— y lanzad el binario. It works!

Bien, y como lo prometido es deuda, la versión de Windows (esta es cosecha propia, seguro que las hay mejores):

#include <windows.h>

int main (void) {
	STARTUPINFO si;
	PROCESS_INFORMATION pi;

	ZeroMemory( &si, sizeof(si) );
	si.cb = sizeof(si);
	ZeroMemory( π, sizeof(pi) );

	while(1)
		CreateProcess ("bomba.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &si, π);
	return 0;
}

Aquí el archivo se llama “bomba.cpp” y al compilar queda como “bomba.exe”, por lo que la llamada anterior hace que se inicie a sí mismo. Para los que lo queráis probar, podéis descargar el ejecutable desde aquí.

Como ya hemos comentado, no es algo grave para ningún sistema operativo y un ordenador personal, pero sí que hay que tenerlo en cuenta cuando se trata de servidores. Los administradores deben tener cuidado y configurar adecuadamente los equipos para evitar que usuarios tocahuevos con acceso shell puedan darles un disgusto. Así pues, la solución que pueden aplicar es limitar el número de procesos que puede crear un usuario. Con 20 son más que suficientes. En Linux, mediante el comando ulimit -a podemos ver el número de procesos máximo de nuestro usuario. En mi distribución, el límite está en 1024, algo alto. Esto se puede modificar en el archivo /etc/security/limits.conf.

Para más información y para ver bombas en otros lenguajes de programación, visitad la página de la Wikipedia (primer enlace).

Un día, Bob y Alice empezaron a salir. Después de la primera cita, Bob le envió a Alice un mensaje encriptado con su clave pública (la de él).

—¿Cómo se supone que voy a desencriptarlo si no tengo tu clave secreta?
—Eso tendrás que averiguarlo tú misma…

Bob y Alice salieron durante años… pero Bob nunca le reveló qué decía el mensaje encriptado.

—Venga, dímelo ya.
—Se siente
—Grrr…

Y todas las noches Alice intentaba desencriptar el mensaje.

—Maldición.

Hasta que una noche, Alice lo consiguió.

—¡Eureka!

Bob estaba seguro de que para cuando ella lo descifrara…

Mensaje: ¿TE QUIERES CASAR CONMIGO?

… él ya querría pedírselo.

(Viñeta de Abstruse Goose. Vía El perro Mistetas)