Alarmado, rápidamente actualicé la versión de WordPress a la 2.9.1, pero no conseguí solucionar el problema. La prueba era fácil, poniendo este sencillo script en el formulario de búsqueda

<script>alert("hola");</script>

Se abría un cuadro de diálogo de alerta.

Hoy, con tranquilidad, me he dedicado a investigar. El error se produce sólo en algunos blogs de WordPress, no en todos. Por tanto no es un problema del gestor de contenidos.

Después de algunas pruebas y algunos cambios, el error ha aparecido. Es un problema de algunos temas de WordPress y es muy fácil de arreglar. En el formulario de búsqueda de los temas que tienen la vulnerabilidad podemos ver algo parecido a esto:

<label for="s"><input type="text" name="s" id="s" size="50" maxlength="200" value="<?php echo get_search_query(); ?>" /></label>

El problema es el echo del código php. Eliminándolo se elimina el problema. Fácil :)

Actualización: Tal como apuntan Javier y Oscar en los comentarios, el problema no es tanto del echo (que permite mostrar la cadena buscada) como el hecho que no se filtre adecuadamente get_search_query().

Por tanto, tal y como propone Javier, en vez de eliminar el echo la solución más elegante es <?php echo htmlentities(get_search_query()); ?>

Obtener la contraseña de una red Wi-Fi encriptada con WEP es fácil y está ampliamente documentado, así que, de hecho, no vamos a explicar nada nuevo. Sin embargo, estos días hemos estado haciendo algunas pruebas con un Acer Aspire One y dada la popularidad de este ordenador hemos pensado que podía ser interesante explicar cómo lo hemos hecho.

Aclarar que se explica sobre todo para que toméis conciencia de lo fácil que es reventar la Wi-Fi que tenéis en casa y que, naturalmente, es ilegal acceder a redes ajenas sin autorización. Nosotros las pruebas las hemos hecho con la red de la oficina, a la que, evidentemente, ya teníamos acceso.

No cualquier ordenador puede ser usado para obtener una contraseña WEP: es necesaria una tarjeta de red capaz de actuar en modo monitor y no todas lo permiten. Precisamente la de nuestro Acer Aspire One sí permite hacerlo, así que es este ordenador con el que hemos hecho las pruebas. No todos los netbooks ni portátiles disponen de una tarjeta así. De hecho, es probable que corran por ahí Aspire Ones que no lo permitan. Pero nada os impide hacer el experimento con el primer ordenador Wi-Fi que tengáis a mano.

Para hacer nuestras pruebas nos basamos en el post How to Crack a Wi-Fi Network’s WEP Password with BackTrack deLifehacker, que seguramente sea una mejor opción para quien no tenga problemas con el inglés.

El primer paso es bajarse la distribución BackTrack 3 (dedicada especialmente a aquellos que quieran dedicarse a los “test de penetración”) e instalarla en un drive USB. Se puede hacer de diversas maneras, nosotros hemos usado UNetbootin, desde donde puedes seleccionar directamente la distribución que te interesa e instalarla en un USB de arranque (de hecho, Unetbootin permite hacer eso mismo con docenas de distribuciones, con lo que es una herramienta muy práctica).

Una vez tenemos el USB con BackTrack 3 conectado al portátil lo ponemos en marcha y pulsamos F12 para seleccionar el arranque a partir del USB.

Cuando arranca BackTrack es importante seleccionar la opción de arranque con VESA, porque si no no se cargará el entorno gráfico que vamos a necesitar dentro de un rato…

Una vez tenemos el entorno de ventanas abierto, debemos abrir un terminal y ejecutar las siguientes instrucciones (ojo, son específicas para el Acer Aspire One):

airmon-ng stop ath0
ifconfig wifi0 down
macchanger --mac 00:11:22:33:44:55 wifi0
airmon-ng start wifi0
airodump-ng ath0

Descargar este conjunto de instrucciones en un script.

Con todo esto lo que estamos haciendo es poner la tarjeta de red en modo monitor y arrancando una aplicación que nos permite ver qué redes tenemos a nuestro alcance (las partes específicas son el ath0 y el wifi0: con otros portátiles puede que haya que cambiarlos por otros valores…).

Llegado a este punto, en la ventana que tenemos abierta aparecerán todas las redes accesibles con, entre otros (listo sólo los más importantes) los siguientes datos:

BSSID

la dirección mac del router

PWR

la potencia de la señal

#Data

que nos indica si tiene transmisión de datos

CH

el canal

ENC

el tipo de encriptación

ESSID

el nombre de la red

Con esa información podemos seleccionar cualquier red “asegurada” con WEP. Cuando tengamos claro qué red queremos, hacemos un CTRL+C, copiamos la dirección BSSID y escribimos lo siguiente:

airodump-ng -c CH -w nombre_archivo --bssid BSSID ath0

Descargar esta instrucción en un script.

Donde CH es el canal y BSSID es la dirección MAC, los dos datos obtenidos de la aplicación anterior. Los datos que obtenga se guardarán en un archivo con el nombre nombre_archivo. Este programa se dedicará a capturar paquetes y guardarlos en el archivo, lo cual nos permitirá, más adelante, obtener la clave. Podremos ver cuántos paquetes ha obtenido en la columna #Data.

Pero para poder conseguir la clave necesitamos un mínimo de 10.000 paquetes y eso puede tardar mucho en conseguirse, así que el siguiente paso es forzar al router a enviar paquetes.

Esto lo haremos en una nueva ventana de terminal. Así, sin dejar de correr el airodump-ng, y en una nueva ventana, ejecutaremos lo siguiente:

aireplay-ng -1 0 -a BSSID -h 00:11:22:33:44:55 -e ESSID ath0
aireplay-ng -3 -b BSSID -h 00:11:22:33:44:55 ath0

Descargar este conjunto de instrucciones en un script.

Donde BSSID y ESSID deben substituirse por sus valores correspondientes.

La última instrucción genera tráfico, con lo que el contador de paquetes se dispara y llega rápidamente a la cantidad necesaria. Ojo, a veces le puede costar algo generar el tráfico, dependiendo de la potencia de la red y de si tiene tráfico o no (si no tiene tráfico cuesta mucho más).

Finalmente, si todo ha ido bien, queda parar los programas (con CTRL+C) y obtener la clave. Esto último se hace con la siguiente instrucción (que se puede ejecutar en cualquiera de las dos ventanas):

aircrack-ng -b BSSID nombre_archivo

Descargar esta instrucción en un script.

Si todo va bien, aircrack-ng nos devolverá la clave de la red. Si va mal nos informará de que ha fallado y que necesita más paquetes para reventar la clave.

Como puede verse, no es nada complicado obtener la contraseña de una Wi-Fi encriptada con WEP, con lo que vale la pena echarle un ojo al manual de instrucciones de nuestro router y cambiar el estándar de seguridad de WEP a WPA…

Interesante clip de vídeo sobre lo [relativamente] fácil que es clonar la información de los nuevos pasaportes electrónicos que se están comenzando a distribuir en Estados Unidos, que hacen uso de la tecnología RFID. Vía.

Google may harm your computer. Lo dice Google. Será verdad

Puedo prometer y prometo que la captura de pantalla de aquí arriba está hecha hace cinco minutos y que no hay ni trampa ni cartón. Ahora mismo Google advierte de que visitar sus propios sitios puede ser dañino para el ordenador. A alguien se le va a caer el pelo…

¿Que por qué? Por esto.

No parece que el ataque se haya utilizado demasiado, aunque ya se han publicado ejemplos de código (más info). Y los parches para los diferentes sistemas de DNS se publicaron ya hace tiempo, por lo que a los proveedores de acceso a internet les debería haber dado tiempo de sobra de aplicar el parche, que para eso tienen profesionales dedicados a ello.

De todas formas, siempre va bien comprobar que estamos protegidos. Una manera de hacerlo, correr el test disponible en http://www.doxpara.com/ (haciendo clic en el botón “Check my DNS”: si sale Your name server, at nn.mmm.nnn.mm, appears to be safe y las direcciones IP que salen más abajo parecen aleatorias, todo va bien). En el muy poco probable caso que tengamos un agujero, una posible solución (además de darle una colleja muy fuerte al proveedor de acceso que usemos) es usar, al menos temporalmente, los DNS de OpenDNS (usando como IPs en la configuración de servidor de red 208.67.222.222 y 208.67.220.220).

Vía.

La seguridad informática es difícil. Muy difícil, de hecho. Y tiene el pequeño problema de que la cadena es tan débil como el más débil de los eslabones. De nada sirve implementar la criptografía más dura del mundo si tu usuario le regala su clave a cualquiera a cambio de un café… ni si tu generador de números aleatorios (esto es, generador de números pseudoaleatorios, de hecho) no es suficientemente aleatorio. Y eso es lo que pasó hace tiempo en la biblioteca OpenSSL, usada por Apache, entre otros (no, no todos los agujeros de seguridad vienen firmados por Microsoft. Ya sé que resulta sorprendente). El resultado: que muchos ataques de “fuerza bruta” requieren ahora mucha menos potencia de cálculo de la que en principio haría falta (hasta extremos que rozan lo ridículo, en algunos casos). La historia (verdaderamente como para no dormir, va a costar mucho tapar el agujero), en Technology Review.

PS 20080521 Para los interesados en ver la diferencia entre un buen generador de números aleatorios y no normalito, pasen y vean.

PS’ 2005021 Un postmortem del asunto interesante tanto para los que quieran saber más sobre entropía como para los que quieran saber más sobre el origen del fallo y las metodologías de desarrollo que se siguen en un proyecto de software libre. (Imperdibles, además, las dos tiras cómicas enlazadas en la entrada.)

Nota: Ayer alguien me comentaba que el agujero ponía en duda el funcionamiento del software libre. En mi opinión, no, para nada: pone de manifiesto que la seguridad es difícil, cometer un error y romperla relativamente fácil, a pesar de que se toman medidas para evitarlo, y que a veces esos errores son extremadamente difíciles de localizar. También significa que, aún cuando esos errores pueden tener consecuencias funestas (y el reducido catálogo de claves con que se mueven ahora mismo mucha gente y muchas aplicaciones debería provocar, cuando menos, pánico), cuando se cometen y se detectan es mucho mejor invertir esfuerzos en poner remedio a la situación y poner medidas para que no se repita que en señalar con el dedo al culpable (que siempre es una cadena considerable de culpables) y la organización para la que trabaja. Trabaje esta con código abierto o no.

Pues bien, ¿qué recomienda Google para esos caso? Primero, prevenir y darse de alta en Google Webmaster Tools para ver cómo indexa el sitio el buscador (yo ya estaba dado de alta. ¿Sabe alguien si el resto de buscadores ofrece algo similar?). Desafortunadamente, a pesar de que Google sabe a través de las ‘webmaster tools’ que mi sitio es mío, y que dispone de una dirección de correo asociada conmigo para ponerse en contacto, no lo hace y solo nos advertirá al entrar en las ‘webmaster tools’ si detecta ‘malware’ (digo yo que no les costaría tanto mandar un aviso automatizado antes de poner un sitio en la lista negra, aún con la consabida advertencia de que no hay posibilidad de asistencia humana). También recomiendan una serie de lecturas, pero tendréis que seguir el enlace y buscarlas desde allí (da palo enlazar PDFs en inglés…).

Si uno se ha visto infectado, los pasos que recomiendan son (en traducción libre):

• Poner off-line el sitio
  • Dejar el sitio off-line temporalmente, al menos hasta que estés seguro de que has arreglado el problema.
  • Si no puedes ponerlo off-line, devolver un 503 para impedir que lo visiten los ‘spiders’.
  • En Webmaster Tools, usar la herramienta de eliminación de URLs para eliminar las páginas o URLs hackeadas que puedan haberse añadido. Así no se servirán páginas hackeadas a los usuarios.
• Evaluación de daños
  • Intentar detectar qué buscaba exactamente el hacker (NdT: no me gusta nada el uso de la palabra hacker con esta acepción, pero es el que usa Google…). ¿Buscaban información sensible o usar el sitio para otros fines?
  • Buscar cualquier fichero modificado o subido al servidor.
  • Comprobar los registros del servidor a la búsqueda de actividad sospechosa, como intentos fallidos de login, la historia de comandos (especialmente como superusuario), cuentas de usuario desconocidas, etc.
  • Determinar el alcance del problema?¿podría haber otros sitios tuyos afectados?
• Recuperación
  • Lo mejor que puede hacerse es reinstalar completamente el sistema operativo de una fuente fiable. Es la única forma de estar completamente seguro de eliminar todo lo que pueda haber hecho el hacker.
  • Después de una reinstalación limpia, usar la última copia de seguridad para restaurar el sitio. No olvides asegurarte de que la copia de seguridad esté limpia de contenido hackeado.
  • Actualiza a su última versión todos los paquetes de software.
  • Cambiar las contraseñas.
• Restaurar tu presencia online
  • Volver a poner online el sistema
  • Si eres usuario de Webmaster Tools, conectarte a la cuenta. Si el sistema fue marcado por contener ‘malware’, pide una revisión para comprobar si el sistema está limpio (NdT: “Request reconsideration”, en la primera pantalla tras hacer login). Si usaste la herramienta de eliminación para URLs que quieres conservar en el sitio, solicita la reinclusión.
  • Permanece alerta, puesto que los “hackers” podrían volver.

En la entrada comentan que son “bastante buenos” a la hora de no penalizar sitios por haber contenido spamlinks en el pasado. En mi caso, al menos, eso parece cierto, pero, aún así me resulta poco tranquilizador no dar más alternativas…

Pseudotraduzco:

— ¿Qué puedo hacer por ustedes exactamente, caballeros?

— Necesitamos examinar sus registros de tráfico. Buscamos piratas musicales.

— Ya veo… ¿Y qué hay de buscar creadores de botnets, o spammers?

— ¿Qué es eso?

De la tira User Friendly de hoy, brillante como casi siempre.